ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
* awygle wonders what a ClockDomainRenaimer does...
<whitequark> awygle: kind of ... exactly what it says on the tin
<whitequark> so let's say you have a module that has `m.d.sync += ...` and you do DomainRenamer({"sync":"foo"})
<whitequark> the renamer will return a module that behaves as if you wrote ` += ...`
<awygle> ahh i see
<awygle> interesting
<awygle> yaaaaay i passed the test
<whitequark> test?
<whitequark> oh!
<awygle> I successfully brutalized litescope into passing its test suite under nmigen
<awygle> (you pass tests more easily if you set up _all_ the expected clocks...)
<whitequark> heh
proteus-guy has quit [Ping timeout: 260 seconds]
<ktemkin> “currently there are no ILAs targeting nMigen” <— depends what level of “sample internal signals on a trigger event and render them visually” you want to consider an ILA >.>
<whitequark> pretty much anything
<cr1901_modern> A portable no-bullshit FPGA LA that links to sigrok or glscopeclient would be nice
<awygle> ktemkin: i mean if you have something i'd love to use it :)
<whitequark> cr1901_modern: neither of those make a lot of sense
<whitequark> sigrok can't display buses
<whitequark> glscopeclient works with analog captures
<awygle> glscopeclient supposedly can handle digital as well
<awygle> though i've not tried it
<awygle> certainly scopehal supports some LAs
<whitequark> right, ok
<awygle> we the community need _something_ to serve the "real-time GTKWave" use case
<cr1901_modern> whitequark: pulseview, oops. I brought glscopeclient up because the fact that azonenberg _wrote_ it means ppl object to pulseview
<whitequark> or even just "better gtkwave"
<awygle> yes
<whitequark> cr1901_modern: yes pulseview can't display buses
<whitequark> it's a major issue with it and it's not getting fixed any time soon
<cr1901_modern> hmmm :(
<whitequark> pulseview chokes on the vcd files i produce in glasgow
<ktemkin> trivial and spi-read, since that’s what’s easy on that platform
ronyrus has quit [Quit: Textual IRC Client:]
noobos has joined #nmigen
<awygle> whitequark: if i downscope that genlib.misc PR to just WaitTimer is that less problematic?
<whitequark> just as much
<whitequark> for that matter, displacer and chooser seem to have a straightforward migration path
<whitequark> and WaitTimer doesn't
<awygle> i assume i'd have to impement WaitTimer in nmigen proper and make the compat one a wrapper
<awygle> but it's a very simple module
<awygle> although i suppose it may not be clear that we _want_ it, or where it should live
<whitequark> awygle: yes, that last part is exactly the issue here
<whitequark> it's not the code, the code is very easy here
<awygle> yes
<awygle> well nvm then, no biggie
<whitequark> in practice a timer is usually a part of some other module
<whitequark> and including one plus hooking up control signals is ~as verbose as just writing it out
<awygle> agreed, but on the other hand, it does exist in migen (and, more specifically, litescope uses it)
<awygle> i'll just inline it into this hacked up version, that's no problem
<awygle> but the larger question remains (for another day)
<whitequark> i mean, lots of things exist in migen in spite of not being good ideas
<awygle> oh definitely, i just meant for nmigen.compat
<whitequark> to be clear, it should definitely be in nmigen.compat. the only question is which deprecation notice should it carry
<awygle> ah. DeprecationWarning(use this instead) vs DeprecationWarning(stop doing this)
<awygle> that's what i meant by "the larger question remains" so we're on the same page
<whitequark> right
<awygle> unrelated, i can create a clock domain, but i can't add it to m.d. do i just use the clockdomain directly? how does m.d. get filled in?
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel has joined #nmigen
<Sarayan> ~I puke in verilog's general direction
<Sarayan> that language is terrible
<awygle> hello sarayan :p
<Sarayan> hi you
<awygle> i figured out the answer to my question ( +=)
<whitequark> awygle: fwiw, that part of syntax is pretty confusing; someone (Nina?) mentioned it before
<awygle> yeah i had to get robert barusch to teach me lol
<awygle> *baruch
<awygle> hm, if each logic statement in the FSM is assigned to a clock domain, i guess `domain=` on the m.FSM method controls the domain the state register is clocked by?
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #nmigen
<awygle> could somebody take a look at these two state machines (one nmigen, one migen-style) and tell me what, if anything, the behavior difference is between them?
<awygle> guessing it's gonna be something obvious, probably to do with clock domains...
<whitequark> awygle: yes, domain= controls the behavior of
<awygle> ... it's, isn't it. fuck.
<whitequark> yeah
<awygle> oh okay good that wasn't my problem lol
<awygle> that woulda felt dumb
<awygle> or well, it's _a_ problem but not the only one, apparently
<awygle> okay, i ported litescope to nmigen (not nmigen.compat) except for the state machine in the gist above and the elements of litex stream it uses
<awygle> that was pretty fun, or at least satisfying
<awygle> the only thing in that subset of litex stream that's still using nmigen.compat is the FIFOs, which i'm not sure how to convert because of the inheritance pattern they use (other than just duplicating the code into each which would not actually be _that_ bad...)
<awygle> ok yeah that wasn't even an issue. so now the only thing is that FSM problem described above. if anybody has a chance to check that gist at some point, i'd appreciate it :) i'm gonna go to bed now i think...
<whitequark> awygle: I think all of those should be m.d.comb, not m.d.scope
<awygle> yep that was it
<awygle> i thought migen statements defaulted to sync (or sys)
<awygle> so i expected the clockdomainrenamer to bring them all into the scope domain
<awygle> thank you
<whitequark> nope; migen FSMs are quite confusing
<awygle> indeed
<awygle> well now i can sleep peacefully
<awygle> tomorrow i'll try to use this thing in anger instead of just in a test suite
<Sarayan> wq: I think I now understand what you tried to explain to me, and I'm reconfiguring my designs to be one random clock fast (well, not random, but heh) and clocks represented as edge selectors
<Sarayan> f.i. a 1MHz both-edges clock is a 2MHz (or more) clock and a couple of phase signals
<Sarayan> that seems way more in the sync way of thinking
<whitequark> yep
Asu has joined #nmigen
cr1901_modern has quit [Ping timeout: 268 seconds]
cr1901_modern has joined #nmigen
Asu has quit [Ping timeout: 240 seconds]
alexhw has joined #nmigen
<anuejn> whitequark: i see your point re writing but i found it hugely confusing too. I (as a beginner) found it to be one of these unnescessarily magic things which become only clear by reading the nmigen codebase.
<anuejn> also the assign a clockdomain to and accessing it by m.d
zignig has quit [Ping timeout: 240 seconds]
zignig has joined #nmigen
jfng has quit [Ping timeout: 240 seconds]
emily has quit [Ping timeout: 248 seconds]
Asu has joined #nmigen
jfng has joined #nmigen
<awygle> is there a way to clean a python package? i want to kill all the .pyc, __pycache__, and .egg-info files/directories
<awygle> can just do it manually of course but was hoping could do it
<mwk> is it a git checkout?
<mwk> (if so, git clean can do wonders)
<awygle> it is, but i have un-checked-in changes... suppose i could just... check them in
<awygle> does nmigen have a logo?
electronic_eel_ has joined #nmigen
electronic_eel has quit [Ping timeout: 272 seconds]
jfng has quit [Quit: killed]
<whitequark> awygle: yeah, I think should clearly be reworked, likely to something along the lines of
<whitequark> but it's not quite clear yet what those ... should be
<whitequark> er, aneujn ^
<awygle> were you - yeah that
<whitequark> awygle: re not that I know, I use git clean
<whitequark> re logo: not yet, but esden offered help with that
<esden> Yeah I reached out to someone with a design/graphics background to help out.
<awygle> i see
electronic_eel_ has quit [Ping timeout: 265 seconds]
electronic_eel has joined #nmigen
emily has joined #nmigen
jfng has joined #nmigen
<awygle> whitequark: for Record.connect, can i exclude fields from a subordinate record?
<awygle> m.d.comb += self.sink.connect(mem.sink) gives AttributeError: Cannot connect field 'hit' of record 'payload' to subordinate record 'payload' because the subordinate record does not have this field
<awygle> m.d.comb += self.sink.connect(mem.sink, exclude={"hit"}) gives AttributeError: Cannot exclude field 'hit' because it is not present in unnamed record
<awygle> i'm not up to speed on records yet, maybe that question doesn't make sense even
<Sarayan> what's connect?
<awygle> afaict it's .eq but for records instead of signals
<awygle> checks directions and field names and whatnot
<Sarayan> and.. what's a record ? :-)
<awygle> my mental model is it's kind of like an sv interface? named group of signals with a defined layout?
<awygle> (the above information is presented without warranty of any kind, not even the implied warranties of merchantability or fitness for a particular purpose)
<whitequark> awygle: what's context here?
<whitequark> designing the stream interface?
<whitequark> just hacking on litex?
<awygle> Working on my litescope port
<awygle> I stole the parts of litex it used, and I'm porting them away from nmigen.compat
<awygle> Their Endpoint is a subclass of Record
<awygle> But the nmigen record seems to be subtly different from the compat record
<awygle> ffffffThat line used to be self.sink.connect(mem.sink, omit={"hit"})
<awygle> ... Weird formatting, probably phone's fault
<whitequark> yeah, I thought that could cause issues, which is why compat record is just a copy of migen code
<awygle> I saw that it had no native backing
<awygle> Is the intent that the same ideas be expressible in both?
<awygle> Or was the migen record flawed in some critical way?
<awygle> I should print these records out, first of all...
<whitequark> awygle: the original intent was to clean up migen's records a bit, but while doing that i realized that Record.connect is probably fatally flawed
<awygle> Uh oh
<awygle> ah so you can exclude subrecord signals with {"payload": {"hit"}}
<awygle> whitequark: i'm getting an error in pysim that says "unsupported operand types for &: tuple and int", but the location is just "<string>". is there a way to figure out where this error is coming from?
Asuu has joined #nmigen
<awygle> whitequark: i'm getting an error in pysim that says "unsupported operand types for &: tuple and int", but the location is just "<string>". is there a way to figure out where this error is coming from?
<awygle> oops, sorry, that was meant to be a terminal up-enter
<awygle> didn't mean to re-ping you
Asu has quit [Ping timeout: 265 seconds]
<whitequark> awygle: not currently; please file an MCVE (if easy) or any repro as a bug (otherwise)
<awygle> mk, i will try
<awygle> ah, this is my fault. never mind.
<emily> it should probably give better errors even if it's your code's fault
<awygle> i think i am convincing myself it's not my fault actually.
<awygle> still trying to reduce this test case....
futarisIRCcloud has joined #nmigen
<_whitenotifier-3> [nmigen] awygle opened issue #325: pysim TypeError: unsupported operand type(s) for &: 'tuple' and 'int' -
<awygle> filed with terrible test case :/
<awygle> ohh okay i found it
<awygle> whitequark: is there a replacement for `Record.raw_bits()`?
<awygle> i just deleted it under the theory that `.eq` would just work but that seems to be the issue
Asuu has quit [Remote host closed the connection]
<awygle> all i actually need to do here is pass a record through a fifo to synchronize it
<whitequark> .eq should just work