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.

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.

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

Ah, missed that.

@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.

@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.

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.

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()).

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.

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.