m-labs
ASIC support tracking issue
A number of people have expressed a desire to use nMigen for ASIC design. This issue tracks missing aspects of that workflow.
- [x] On FPGAs, asynchronous resets inhibit inference of BRAMs, DSPs, etc. On ASICs, asynchronous resets are required to make sure the chip is reset properly even with no clock.
- [ ] On FPGAs, resets are generally positive polarity, and using the wrong polarity can have severe consequences for timing. On ASICs, resets are generally negative polarity, such that the chip is held in reset during power rail ramp-up.
- [ ] On ASICs and in some cases on FPGAs, memories may not be initialized.
- [ ] On ASICs,
reset_lesssignals are not initialized at power-on.
(There are likely more.)
I would think that most SRAMs don't get reset on ASICs either, so that shouldn't interfere with BRAM inference.
I would think that most SRAMs don't get reset on ASICs either, so that shouldn't interfere with BRAM inference.
The problem isn't that the SRAM itself gets reset, but that you might want to fold address or data registers into an SRAM core. This is less of a problem in nMigen than in Verilog because some registers are implicit in the read port, but it's still a problem if a few of them are pipelined; e.g. Xilinx offers this as an option on BRAMs.
Of course if you're making an ASIC you can just make those registers with an asynchronous reset, so asynchronous reset isn't a problem there, but I didn't say it is.