<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 - https://git.io/JvZvM
<_whitenotifier-3>
[nmigen-soc] whitequark commented on issue #6: RecursionError when elaborating a csr.Multiplexer with alignment >= 8 - https://git.io/JvZfH
<_whitenotifier-3>
[nmigen-soc] jfng commented on issue #6: RecursionError when elaborating a csr.Multiplexer with alignment >= 8 - https://git.io/JvZJe
<_whitenotifier-3>
[nmigen-soc] jfng commented on issue #6: RecursionError when elaborating a csr.Multiplexer with alignment >= 8 - https://git.io/JvZUC