ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen · IRC meetings each Monday at 1800 UTC · next meeting TBD
<_whitenotifier> [YoWASP/nextpnr] whitequark pushed 1 commit to develop [+0/-0/±2] https://git.io/JtrQC
<_whitenotifier> [YoWASP/nextpnr] whitequark 560d3c1 - Update dependencies.
richbridger has joined #nmigen
aquijoule_ has quit [Ping timeout: 256 seconds]
sakirious has quit [Quit: The Lounge - https://thelounge.chat]
sakirious has joined #nmigen
lf has quit [Ping timeout: 258 seconds]
lf has joined #nmigen
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
Degi has quit [Ping timeout: 272 seconds]
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
pftbest has quit [Ping timeout: 240 seconds]
ali-as has quit [Ping timeout: 265 seconds]
<awygle> whitequark: we basically stopped talking about multiclock in https://github.com/nmigen/nmigen/issues/526 in favor of debating the semantics of Past(), but am i right that there's no way to access the smt_clk/global_clock from nmigen at all right now, because it exists in yosys' verilog frontend and not in rtlil, so the actual rtlil emission code would have to change?
<cr1901_modern> smt_clk doesn't exist until write_smt2
<cr1901_modern> (uhh... I think that's how it works last time I looked at it)
<awygle> cr1901_modern: is that a "yes, you can't reach it from nmigen, so until we change nmigen core to know about it and do sensible things you essentially can't do multiclock"?
<cr1901_modern> You can't reach $global_clock from nmigen right now
<awygle> ok
<cr1901_modern> I don't remember where global_clock is added in, but it's not an nmigen Signal you can manipulate
<awygle> i was hoping i could just add attrs={'gclk'} to something but i now see it doesn't work that way
<cr1901_modern> awygle: Disclaimer, this is my "sandbox" code, but if you run make, you can see basically every single thing yosys does to get from Verilog code to smt2 proof
<cr1901_modern> Oh wait, I remember a bit now
<cr1901_modern> awygle: There's a yosys pass called clk2fflogic
<awygle> mhm
<cr1901_modern> this adds a special type of yosys FF that is currently _undocumented_
<awygle> $ff cells, yes?
<cr1901_modern> this FF is clocked by the $global_clock
<cr1901_modern> it might be, I don't remember offhand
<cr1901_modern> But that pass is what adds stuff that can be driven by $global_clock
<cr1901_modern> In the SMT backend, there's _always_ one clock, called the smt_clock.
<awygle> right
<cr1901_modern> If you don't use the clk2fflogic pass, the net effect is that every always(@clk) block in your code runs on every smt clock tick
<awygle> mhm
<awygle> and this is what "multiclock on" does in sby is run that pass
<cr1901_modern> yes
<awygle> which is why it used to be called clk2fflogic but nvm
<cr1901_modern> this "run on every tick" is almost certainly what you don't want unless you have exactly one clock
<awygle> yes
<cr1901_modern> the clk2fflogic puts all clocks under control of the $global_clock, so the only things that run on every smt_clock tick is the $global_clock
<cr1901_modern> and your clocks become explicit inputs to your design
<awygle> yes
<awygle> this is what i want
<cr1901_modern> The main issue w/ multiclock is: since all your clocks become explicit inputs, what prevents the smt solver from just holding one clock indefinitely?
<awygle> and then any additional phasing requirements, like forward progress, or a phase relationship, has to be defined in terms of $global_clock
<awygle> err drop phasing, but you get the idea
<cr1901_modern> Right, and last I discussed this, we "couldn't agree" on what constraints should be included to force forward progress
<awygle> right
<cr1901_modern> other than "wq didn't want to expose $global_clock and rather wanted to auto-calculate a constraint"
<awygle> (i'm not sure we should do that at all tbh)
<cr1901_modern> and that's the state of affairs AFAIR right now
<awygle> but what i wanted to know (and it sounds like i have my answer) is whether there's a way to get to the "must define all relationships manually" state of affairs with nmigen as it is today
<cr1901_modern> No.
<cr1901_modern> Unless something changed since 526. I never did attempt to convert multiclock.v to nmigen, and I forgot what I was trying to accomplish.
electronic_eel_ has quit [Ping timeout: 272 seconds]
electronic_eel has joined #nmigen
Bertl_oO is now known as Bertl_zZ
davidlattimore has quit [Read error: Connection reset by peer]
davidlattimore has joined #nmigen
sorear has quit [Read error: Connection reset by peer]
sorear has joined #nmigen
<_whitenotifier> [nmigen] Ravenslofty opened issue #592: Fragment.get should detect cycles in elaboration - https://git.io/JtrxW
davidlattimore has quit [*.net *.split]
jfng has quit [*.net *.split]
XgF has quit [*.net *.split]
Qyriad has quit [Ping timeout: 246 seconds]
Qyriad has joined #nmigen
davidlattimore has joined #nmigen
XgF has joined #nmigen
jfng has joined #nmigen
vmedea[m] has quit [Ping timeout: 246 seconds]
blazra has quit [Ping timeout: 240 seconds]
whitequark[m] has quit [Ping timeout: 246 seconds]
PyroPeter_ has joined #nmigen
jfng has quit [Ping timeout: 258 seconds]
emily has quit [Ping timeout: 268 seconds]
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter_ is now known as PyroPeter
cesar[m]1 has quit [Ping timeout: 268 seconds]
vmedea[m] has joined #nmigen
blazra has joined #nmigen
FFY00 has quit [Ping timeout: 260 seconds]
jfng has joined #nmigen
whitequark[m] has joined #nmigen
cesar[m]1 has joined #nmigen
emily has joined #nmigen
<awygle> do we have a real-ass rfc template? are we stealing the rust one, or just kinda winging it?
<awygle> (to be clear either is fine w/ me)
pftbest has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
<_whitenotifier> [nmigen] awygle commented on issue #542: Using ClockSignal in platform.add_clock_constraint - https://git.io/JtovT
<_whitenotifier> [nmigen] awygle edited a comment on issue #542: Using ClockSignal in platform.add_clock_constraint - https://git.io/JtovT
<_whitenotifier> [nmigen] awygle commented on issue #592: Fragment.get should detect cycles in elaboration - https://git.io/JtovC
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
<_whitenotifier> [nmigen] whitequark commented on issue #592: Fragment.get should detect cycles in elaboration - https://git.io/JtoUy
miek has quit [Ping timeout: 265 seconds]
MadSquirrel has joined #nmigen
<_whitenotifier> [nmigen] awygle commented on issue #592: Fragment.get should detect cycles in elaboration - https://git.io/Jtotz
<anuejn> is there a way to get better error messages with Assert() & formal in nMigen?
<anuejn> like giving it a string that is printed when the assertion fails?
<whitequark> unfortunately not, sby doesn't support it i believe
<anuejn> ah sad
MadSquirrel has quit [Ping timeout: 272 seconds]
MadSquirrel has joined #nmigen
<whitequark> this is something that is on my long-term radar
<anuejn> okay no hurry, it is not important to me
<anuejn> I was just hitting a case where that would have been helpful
<awygle> whitequark: i was looking at https://github.com/nmigen/nmigen/issues/398 and friends
<awygle> and i am pretty sure it's very easy to give a better error message in those cases, but where i'm struggling is in writing a test case that reproduces the errors without using a real platform
<awygle> it's easy enough to reproduce them with a platform ofc
<awygle> do you think you could help me figure out the minimal interaction of fragment/instance/elaboratable to get a repro? or alternately, would it be so terrible for a new error message to go in without a unit test?
<awygle> the risk is that the user gets an error with an incorrect diagnosis, which is worse than an inscrutable error, but not a lot worse imo
Bertl_zZ is now known as Bertl
revolve has joined #nmigen
bvernoux has joined #nmigen
<vup> awygle: not sure this hits the exact same codepath, but I think so: https://github.com/nmigen/nmigen/issues/320
<vup> and that does not use a platform
chipmuenk has joined #nmigen
Bertl is now known as Bertl_oO
slan has joined #nmigen
Bertl_oO is now known as Bertl
FFY00 has joined #nmigen
ali-as has joined #nmigen
miek has joined #nmigen
slan has quit [Ping timeout: 256 seconds]
sakirious has quit [Quit: The Lounge - https://thelounge.chat]
sakirious has joined #nmigen
peeps[zen] has joined #nmigen
peepsalot has quit [Ping timeout: 264 seconds]
emeb has joined #nmigen
peeps[zen] has quit [Ping timeout: 265 seconds]
peepsalot has joined #nmigen
peepsalot has quit [Ping timeout: 240 seconds]
peepsalot has joined #nmigen
Degi has joined #nmigen
GenTooMan has quit [Quit: Leaving]
GenTooMan has joined #nmigen
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #nmigen
revolve has quit [Read error: Connection reset by peer]
revolve has joined #nmigen
_whitelogger has joined #nmigen
mik1234mc has joined #nmigen
emeb has quit [Quit: Leaving.]
<mik1234mc> Hi all, I have very basic question on nMigen development. There currently two github repositories (https://github.com/m-labs/nmigen and https://github.com/nmigen/nmigen) with active development. What is the reason for this situation? Are there plans to merge the repositories one day or these two projects will live along together? Your
<mik1234mc> implementation seems to me more progressive because of CXX support. Michael
<modwizcode> The correct repository is the nmigen/nmigen one
<modwizcode> mik1234mc: it is likely the other repo will continue to exist but we do not control that repository.
chipmuenk has quit [Quit: chipmuenk]
<d1b2> <dub_dub_11> I think "active development" is quite generous to the m-labs repo if you look at the insights page...
<mik1234mc> Thanks for the answer, I understand. My concern is if nMigen syntax will remain the same between these two implementation?
<modwizcode> who knows... they're free to do whatever they like. We are not associated with them.
<d1b2> <dub_dub_11> there will be a lot of unfixed issues etc if you work from the wrong place and it is something that trips people up so it would be helpful to star the correct repo (nmigen/nmigen) so that google starts showing the right one in searches
<mik1234mc> So, you think that nmigen/nmigen is the implementation which will be widely accepted by the community? For example in Litex and Lite* ecosystems?
<d1b2> <dub_dub_11> it is the widely accepted implementation
<d1b2> <dub_dub_11> it's the one under active development by everyone who originally contributed to the project when it was based at m-labs/nmigen
<mik1234mc> <dub_dub_11> Thanks, now, I understand
<d1b2> <dub_dub_11> hmm looks like most tutorials are up to date but the lambda concept wiki has the wrong repo
<vup> jfng: ^
mik1234mc has quit [Quit: Ping timeout (120 seconds)]
peepsalot has quit [Ping timeout: 264 seconds]
nengel has joined #nmigen
peepsalot has joined #nmigen
emeb_mac has joined #nmigen
lkcl has quit [Ping timeout: 256 seconds]
lkcl has joined #nmigen
peepsalot has quit [Ping timeout: 256 seconds]
chipmuenk has joined #nmigen
<emeb_mac> last year I decided to try out nmigen and spent a few weeks playing around with it. While I loved the nmigen works, one of the things that I found interesting was how easy it was to damage my python toolchain during the install / update process - the whole paradigm of how packages are installed, what gets priority and how to detect if one has the proper dependencies seemed incredibly fragile.
<nickoe> dub_dub_11 why was it forked it its own ord and still having the m-labs thing?
<d1b2> <TiltMeSenpai> in my experience, pyenv + poetry has been a pretty reliable way of keeping pip from shooting itself in the foot
<d1b2> <TiltMeSenpai> m-labs did some pretty jackass-y stuff
nengel has quit [Quit: gone afk]
<d1b2> <TiltMeSenpai> resulted in the nmigen creators leaving/distancing themselves from m-labs
<d1b2> <TiltMeSenpai> but m-labs, being the jerks they are, are keeping the repo around and pretending they have a relation to nmigen/nmigen
<ali-as> Is nmigen officially an m-labs product, or was that just migen on which it was based?
<sorear> just migen
<ali-as> Was the m-labs github the original?
<ali-as> I spent some time trying to unpick it and failed.
<ali-as> It looks like 3rd parties might be able to lodge an appeal at this stage.
<d1b2> <TiltMeSenpai> at one point, yes
<ali-as> The copyright file is confusing because it doesn't attribute based on the product.
<d1b2> <TiltMeSenpai> in nmigen/nmigen or?
<ali-as> In nmigen.
nengel has joined #nmigen
<d1b2> <TiltMeSenpai> m-labs/nmigen is a rouge fork at this point, it should be disregarded
<ali-as> I understand less about github than I thought. Why do both forks seem original and contain the same early stuff?
<ali-as> But github says none of them are forks of eachother.
<vup> its not a fork done with github
<vup> because forks for example don't carry the issue and pr history over
<ali-as> I've read 3rd party objections have a 4 month time limit. So I'm interested if there is any way to meaningfully object.
<vup> object to what?
<ali-as> Registration of the trademark by m-labs.
<vup> the objection period is over
<d1b2> <TiltMeSenpai> I think nmigen/nmigen has a valid defense should m-labs try to enforce it but as I understand it, there's nothing that can be done proactively at this point
<ali-as> 4 months from november for 3rd part objections, I think.
<vup> m-labs got their notice of Notice of Allowance on 2021-01-12
<vup> pretty sure that marks the end of the objection period?
<vup> The first sentence in the NoA is "No opposition was filed for this published application"
<DX-MON> that GitHub issue thread makes me blood boil
<d1b2> <TiltMeSenpai> anyways, should m-labs attempt to enforce their trademark, I would gladly chip in to a legal defense fund for nmigen/nmigen
Bertl is now known as Bertl_oO
<d1b2> <TiltMeSenpai> until that happens, idk if there's anything that can be done
<DX-MON> given how the project is licensed, it's not as easy as renaming the repo to change the name.. and I have to side with WQ that it probably wouldn't help anyway so why do so
<DX-MON> so yeah.. I'd be glad to chip in for a legal defense
<awygle> personally my priority would be resolving the issue with as little stress as possible, so i'd recommend changing the name if it comes to that, but i'll support whatever decision wq makes
<balrog> the end of the official objection period is after 30 days. It is possible to file an objection afterwards, with a petition that will be considered. In any case, it costs $600 per class to object, and since they registered with two classes, it would cost $1200; additional fees may apply if it is a petition to object after the 30 day period.
<balrog> sorry -- 30 days from publication, which ended in mid-January iirc
<nickoe> where is that publication?
<nickoe> mmm
nengel has quit [Quit: gone afk]
nengel has joined #nmigen
<Ultrasauce> seems like a good excuse to come up with a proper weeb name for the project
_whitenotifier-5 has joined #nmigen
<_whitenotifier-5> [nmigen] newhouseb opened pull request #593: Update UART Example so that acknowledging RX data sets RX ready low. - https://git.io/JtoMh
<d1b2> <benzn> this was after i accidentally diffed agains the m-labs one because i wasn't careful 🤦
<_whitenotifier-5> [nmigen] newhouseb edited pull request #593: Update UART Example so that acknowledging RX data sets RX ready low. - https://git.io/JtoMh
<_whitenotifier-5> [nmigen] codecov[bot] commented on pull request #593: Update UART Example so that acknowledging RX data sets RX ready low. - https://git.io/JtoDU
<_whitenotifier-5> [nmigen] RobertBaruch opened issue #594: Time-0 race condition for simulation - https://git.io/JtoDT
<_whitenotifier-5> [nmigen] codecov[bot] edited a comment on pull request #593: Update UART Example so that acknowledging RX data sets RX ready low. - https://git.io/JtoDU
<_whitenotifier-5> [nmigen] codecov[bot] edited a comment on pull request #593: Update UART Example so that acknowledging RX data sets RX ready low. - https://git.io/JtoDU
<_whitenotifier-5> [nmigen] codecov[bot] edited a comment on pull request #593: Update UART Example so that acknowledging RX data sets RX ready low. - https://git.io/JtoDU
<_whitenotifier-5> [nmigen] codecov[bot] edited a comment on pull request #593: Update UART Example so that acknowledging RX data sets RX ready low. - https://git.io/JtoDU
<d1b2> <DX-MON> just FYI @benzn, edits don't reflect through to IRC (this channel is bonded with #nmigen on freenode)
nengel has quit [Quit: gone afk]
peepsalot has joined #nmigen
XgF has quit [Remote host closed the connection]
XgF has joined #nmigen
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
pftbest has quit [Remote host closed the connection]
pftbest has joined #nmigen
pftbest has quit [Ping timeout: 260 seconds]
revolve has quit [Read error: Connection reset by peer]
MadSquirrel has quit [Ping timeout: 272 seconds]