<John_K>
(or rather the questions that I posed in my response)
<Wanda[cis]>
as for your questions
<zyp[m]>
I think the largest issue is the multiple drivers one
<Wanda[cis]>
well tbh the main problem with your PR is that it just plain doesn't work
<Wanda[cis]>
because it triggers a multiple-driver conflict
<zyp[m]>
simply put: you just can't drive a signal from more than one module
<Wanda[cis]>
you are not allowed to assign to a single signal-bit from more than one module
<Wanda[cis]>
if you drive valid yourself, it's a conflict with the user's driver of the valid input, and any further discussion about the details is moot
<Wanda[cis]>
there isn't really any concept of ordering of events; it all ends up translated to gates and wires
<Wanda[cis]>
and by "doesn't work" I mean it raises an error in synthesis
<John_K>
aha, thank you. I've been working in simulation and hadn't seen any issues. I just tried to generate a bitstream and see the synthesis error that you're referring to
<John_K>
thank you both
<Wanda[cis]>
yeah we don't currently have full netlist validity checking in pysim, unfortunately
<Wanda[cis]>
(it's on the roadmap as part of pysim2)
<Wanda[cis]>
anyway; if you want to connect the CRC block to some kind of MCU, you'll have to make some register wrapper that will, in addition to whatever other bridging responsibilities, have to take care of asserting valid for exactly one cycle after a write
John_K has quit [Quit: Client closed]
<whitequark[cis]>
amaranth-soc can help you build the register wrapper for it
<zyp[m]>
since there's no backpressure, driving valid is in practice just a matter of hooking it up to the write strobe of the same CSR that feeds the data