ASIC support tracking issue

[nmigen-issue-migration]

Issue by whitequark Thursday Aug 22, 2019 at 21:49 GMT Originally opened as https://github.com/m-labs/nmigen/issues/184

---

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_less signals are not initialized at power-on.

(There are likely more.)

[nmigen-issue-migration]

Comment by programmerjake Thursday Aug 22, 2019 at 23:58 GMT

---

I would think that most SRAMs don't get reset on ASICs either, so that shouldn't interfere with BRAM inference.

[nmigen-issue-migration]

Comment by whitequark Friday Aug 23, 2019 at 00:01 GMT

---

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.

[nmigen-issue-migration]

Comment by programmerjake Friday Aug 23, 2019 at 00:19 GMT

---

Ah, missed that.

[whitequark]

@Fatsie you're interested in active low resets for ASIC work, right? I was wondering if you have any opinion on handling ResetSignal in that case; unlike ClockSignal, a lot of generic code depends on ResetSignal polarity being logic level (i.e. active high), so if we add clock domains with negative polarity resets that have inverted levels of ResetSignal, all such logic will break. There are a few solutions I can think of, but none are ideal.

[Fatsie]

@whitequark I don't think it is a problem to have nmigen only have active high reset support in it's clock domain. For ASICs you typically want the external reset pin active low so you can keep the reset low during power ramp up by a simple RC circuit. But you can handle that by PinsN definition for the platform. If the standard cell library would have flip-flops with active low set and reset signals yosys should optimize away the two inverters in the logic path of the set/reset signal.

[hofstee]

I've seen lots of inverters get added to a design since tools will often synthesize things to use active-low resets (sometimes due to what's available in technology libraries). That ends up leading to a bunch of extra inverters in the design, especially at black-box boundaries where you've synthesized something to be used as a hard macro elsewhere (back to back inverters in timing reports confused the heck out of me for a while).

I can't say to what degree it actually affected the quality of the design, I don't remember the numbers at the moment.

[whitequark]

One possible solution here would be to add a late-bound ResetActive() AST node (so that, if you are branching on a reset in a generic module, you'd need to use m.If(ResetActive()) rather than m.If(ResetSignal())), and then emit a diagnostic on use of m.If(ResetSignal()).

[Fatsie]

I've seen lots of inverters get added to a design since tools will often synthesize things to use active-low resets (sometimes due to what's available in technology libraries). That ends up leading to a bunch of extra inverters in the design, especially at black-box boundaries where you've synthesized something to be used as a hard macro elsewhere (back to back inverters in timing reports confused the heck out of me for a while).

For ASIC one typically does tech mapping on the full flattened design, this allows yosys optimization pass to remove all double inverters.

[hofstee]

For ASIC one typically does tech mapping on the full flattened design, this allows yosys optimization pass to remove all double inverters.

We were using Design Compiler and Innovus, not yosys (same problem, different source language than nmigen). The issue in our case stems from the fact that we have a repeated architecture with the same elements stamped out multiple times. To speed up synthesis, we synthesize each of the repeated elements and then stamp them out as hard macros at the top level. The double-inverters are seen at the boundaries of the hard macros and won't be optimized out.