Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ASIC support tracking issue #185

Open
1 of 4 tasks
nmigen-issue-migration opened this issue Aug 22, 2019 · 9 comments
Open
1 of 4 tasks

ASIC support tracking issue #185

nmigen-issue-migration opened this issue Aug 22, 2019 · 9 comments

Comments

@nmigen-issue-migration
Copy link

nmigen-issue-migration commented Aug 22, 2019

Issue by whitequark
Thursday Aug 22, 2019 at 21:49 GMT
Originally opened as m-labs/nmigen#184


A number of people have expressed a desire to use nMigen for ASIC design. This issue tracks missing aspects of that workflow.

  • 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
Copy link
Author

nmigen-issue-migration commented Aug 22, 2019

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
Copy link
Author

nmigen-issue-migration commented Aug 23, 2019

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
Copy link
Author

nmigen-issue-migration commented Aug 23, 2019

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


Ah, missed that.

@whitequark
Copy link
Member

whitequark commented Mar 8, 2020

@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
Copy link
Contributor

Fatsie commented Mar 9, 2020

@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
Copy link
Contributor

hofstee commented Apr 22, 2020

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
Copy link
Member

whitequark commented Apr 22, 2020

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
Copy link
Contributor

Fatsie commented Apr 22, 2020

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
Copy link
Contributor

hofstee commented Apr 23, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants