<cr1901>
These wires in module sequencer DO EXIST!! They're just not marked as input/output: wr__data, and ctl__cmd__ops
<cr1901>
What's interesting about these two particular wires in my working code is that I had to use as_value() to convert them to Signals() before the ports= input arg to verilog.convert was happy (m.ctl.cmd.ops and m.wr.data are both unions)
<cr1901>
Memo to self... sim.add_clock() takes a period. Not a frequency. So I was generating traces with periods of 12e6, and wondering why gtkwave was having a stroke loading them
<cr1901>
Huh, looks like I missed a whole bunch of messages due to scrollback being screwy.
<cr1901>
> Uses amaranth.lib.data, but not wiring (b/c I couldn't figure out how to parameterize the signature) <-- well, uniterm has an example of parametric signatures (w/o using Component).
<cr1901>
>hey, while I'm at it, are you using MachXO2 nextpnr? does it work? <-- Yes, it works last I checked a few months ago. But seeing as you already packaged it, that info prob doesn't matter :P.
<whitequark[cis]>
yep, to make a parametric signature, I would suggest implementing a @property signature
<whitequark[cis]>
and then returning an object with values you compute
Ekho has quit [Server closed connection]
Ekho has joined #amaranth-lang
<cr1901>
Everything but the top-level, and EFB Verilog instantiation has been ported. Incredibly, I transcribed the Verilog of this last module to Amaranth correctly the first time.
<cr1901>
I will take this Murphy's Law violation and run