ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
ZirconiumX has quit [Quit: Love you all~]
ZirconiumX has joined #nmigen
<awygle> does nmigen have an internal logic analyzer as part of the stdlib?
<whitequark> awygle: no, but it should
<awygle> lol
<whitequark> migen had "microscope", which sort of worked, but it had serious footguns
<whitequark> in fact, those footguns prompted a redesign where logic is no longer defined inside __init__
<whitequark> because that required finalization
<whitequark> the problem with finalization was that it (a) didn't iterate to fixed point and (b) didn't have controllable order
<whitequark> so you could have added a probe and it'd just be ignored in the end because the order was wrong
<awygle> that sounds less than ideal, yes
<whitequark> nmigen's design... unfortunately, has issues that are only slightly less serious, but at least they're obvious so they don't hit you by surprise
<whitequark> let's go through them because i still don't know what a perfect ILA in nMigen would look like
<whitequark> first, there are internal signals. think FSM state signal. think anything assigned to a local var in elaborate()
<whitequark> in migen, you still had those--nothing stopped you from assigning signals to locals in __init__, after all
<whitequark> but i think usually people did assign them to attributes, so although the theoretical problem was the same, in practical terms it was not as acute
<whitequark> i actually do have a way in nmigen to expose these signals (specifically so that FSMs are testable), but it's very much imperfect
<whitequark> you can assign arbitrary objects to the Fragment.generated dictionary in each fragment, and query them from the elaborated design
<whitequark> (grep the nmigen tree for find_generated)
<awygle> i was going to suggest that perhaps what's wanted is to instrument the post-synthesis design, but then i remembered that ABC eats net names for breakfast
<awygle> so probably elaborated but pre-synthesis is the right time
<whitequark> yeah
<whitequark> hold on for a moment
<awygle> yup
<awygle> i'm getting `s_push: parser stack overflow` followed by a MemoryError exception... interesting
<awygle> i don't _think_ it's filling up 16 gigs of RAM
<awygle> seems to be a limitation of python's recursive descent parser
<awygle> probably unhappy with the way i'm accessing into this thing that's come out to be a very large expression as the concatenation of multiple Consts each of which has been operated on quite a bit
<awygle> i bet i can do most of this in python proper...
<awygle> yup. dunno why that didn't come to me last night. ah well.
<whitequark> uhhh
<whitequark> what on earth are you doing
<awygle> so there's a seed value, which gets munged by a shitty "encryption" algorithm, which i have implemented in python
<awygle> for some reason i instantiated the seed as a list of Consts, then ran the algorithm on them, then catted them together, then wrote them out on a serial line one bit at a time with .bit_select
<whitequark> sounds mildly cursed but go o
<whitequark> *on
<awygle> now i have just made a list of ints, run the algorithm on _that_, and mapped Const over them afterwards
<awygle> so now python's parser doesn't explode
<awygle> because previously every operation on the Const was getting added to some kind of lisp-esque AST thing
<awygle> which apparently found its way into python's parser at some stage
<awygle> does that make sense?
<whitequark> oh
<whitequark> oh i know what happened
<whitequark> pysim translates your nmigen statements into python code, it's basically an AOT compiler
<whitequark> and it looks like the generated code was quite pathological
<awygle> yep
<whitequark> it's not really lisp-esque; that's just the __repr__ function
<awygle> sure, i mean, "print an AST" gives you "lisp-esque" just naturally
<whitequark> right
<whitequark> awygle: ok, so, the second part
<whitequark> re logic analyzer
<whitequark> the part about a race condition in finalization i explained earlier is actually inherent here, in that an ILA *must* run after the *entirety* of user design is done
<whitequark> this means you can't just add it as another submodule in your toplevel
<whitequark> since the order of submodule elaboration isn't really defined, and even if it was, relying on it would be error-prone
<whitequark> you want to *wrap* the design in the ILA, really
<whitequark> this is a much smaller issue (you just need to decide on an API) but it still requires effort
<awygle> right
<awygle> so for now, given that i need one, the best ILA option is "write one or steal one", as the nmigen builtin is not on a short timeline to inclusion. true?
<whitequark> awygle: not quite
<whitequark> there's nothing special about the ILA that requires it to be builtin specifically
<whitequark> and there's currently no ILA that works with nmigen
<awygle> well, sure. but that still falls under "write one or steal one", basically.
<whitequark> so... someone's got to write one, all else being same
<awygle> steal, port, potato, potato
<awygle> thinking i'm probably going to grab SUMP2 from black mesa labs and figure out how to reference it from nmigen (it's verilog, but i know using verilog modules is a supported use case), then maybe try to port it over afterwards
<awygle> but we'll see
<awygle> anyway, goodnight
electronic_eel has joined #nmigen
<_whitenotifier-3> [nmigen-soc] jfng opened issue #6: RecursionError when elaborating a csr.Multiplexer with alignment >= 8 -
<_whitenotifier-3> [nmigen-soc] whitequark commented on issue #6: RecursionError when elaborating a csr.Multiplexer with alignment >= 8 -
<_whitenotifier-3> [nmigen-soc] jfng commented on issue #6: RecursionError when elaborating a csr.Multiplexer with alignment >= 8 -
<_whitenotifier-3> [nmigen-soc] jfng commented on issue #6: RecursionError when elaborating a csr.Multiplexer with alignment >= 8 -
proteus-guy has quit [Ping timeout: 268 seconds]