I downloaded the new minsoc release candidate and it ran the uart simulation so I thought that I would strip out the ethnetmac and drop it onto a digilent Nexys2 board. Well it didn't fit which surprised me since I have a similar design that fit nicely. Then I remembered that I had converted the old or1200 from an asynchronous reset to a synchronous one. So I edited out all of the "or posedge wb_rst" text and found that it would fit and give me "hello World." as expected.


I then compared the two xilinx webpack design summaries and it shows exactly what using an async reset costs in a modern fpga design. The difference is rather striking. The biggest difference was that I only inferred the srams instead of setting the `XILINX define and about half of the LUTs went to build four of the srams. The interesting number is the number of 4 input LUTs used as logic which is an apples-apples comparison of the same logic with the two different reset styles. Async uses 42% more LUTs than sync.


Number used as logic: 8,895 async reset
Number used as logic: 6,253 sync reset


John Eaton


original async reset:
-----------------------------------------------

Design Summary:
Number of errors: 2
Number of warnings: 93
Logic Utilization:
Number of Slice Flip Flops: 2,612 out of 17,344 15%
Number of SLICEMs: 4,888 out of 4,336 112% (OVERMAPPED)
(SLICEMs can only be placed in SLICEM sites.)
Number of 4 input LUTs: 17,119 out of 17,344 98%
Logic Distribution:
Number of occupied Slices: 9,207 out of 8,672 106% (OVERMAPPED)
Number of Slices containing only related logic: 9,207 out of 9,207 100%
Number of Slices containing unrelated logic: 0 out of 9,207 0%
*See NOTES below for an explanation of the effects of unrelated logic.
Total Number of 4 input LUTs: 17,245 out of 17,344 99%
Number used as logic: 8,895
Number used as a route-thru: 126
Number used for Dual Port RAMs: 8,224
(Two LUTs used per Dual Port RAM)

The Slice Logic Distribution report is not meaningful if the design is
over-mapped for a non-slice resource or if Placement fails.

Number of bonded IOBs: 112 out of 250 44%
Number of RAMB16s: 8 out of 28 28%
Number of BUFGMUXs: 5 out of 24 20%
Number of DCMs: 1 out of 8 12%
Number of BSCANs: 1 out of 1 100%
Number of MULT18X18SIOs: 4 out of 28 14%

Average Fanout of Non-Clock Nets: 5.43




Converted sync reset
----------------------------------------------------

Design Summary:
Number of errors: 0
Number of warnings: 96
Logic Utilization:
Number of Slice Flip Flops: 2,543 out of 17,344 14%
Number of 4 input LUTs: 6,285 out of 17,344 36%
Logic Distribution:
Number of occupied Slices: 3,942 out of 8,672 45%
Number of Slices containing only related logic: 3,942 out of 3,942 100%
Number of Slices containing unrelated logic: 0 out of 3,942 0%
*See NOTES below for an explanation of the effects of unrelated logic.
Total Number of 4 input LUTs: 6,411 out of 17,344 36%
Number used as logic: 6,253
Number used as a route-thru: 126
Number used for Dual Port RAMs: 32
(Two LUTs used per Dual Port RAM)

The Slice Logic Distribution report is not meaningful if the design is
over-mapped for a non-slice resource or if Placement fails.

Number of bonded IOBs: 112 out of 250 44%
Number of RAMB16s: 12 out of 28 42%
Number of BUFGMUXs: 5 out of 24 20%
Number of DCMs: 1 out of 8 12%
Number of BSCANs: 1 out of 1 100%
Number of MULT18X18SIOs: 4 out of 28 14%

Average Fanout of Non-Clock Nets: 3.75

I'm not sure I quite understand what you mean. What you describe is that XST fails to identify some constructs as Block RAM and has to map them to logic. You would have to manually instantiate RAMB16 in those places to get a fair comparison.

Async

Number of RAMB16s: 8 out of 28 28%
...
Total Number of 4 input LUTs: 17,245 out of 17,344 99%
Number used for Dual Port RAMs: 8,224

Sync
Number of RAMB16s: 12 out of 28 42%
...
Total Number of 4 input LUTs: 6,411 out of 17,344 36%
Number used for Dual Port RAMs: 32

Well, you have to consider that the OpenRISC is used in ASICs too, where you probably will want to have asynchronous set and synchronous release. Other FPGA vendors may also have a different best-practice.

In my opinion, resets shall be kept asynchronous. It's then up to the top-level designer to decide if the reset shall be synchronized to a clock domain before it enters the IP core.


The number you present are very interesting, but I still want to see the async reset with manually instantiated Block RAM. Parts of the extra LUTs could be a side-effect caused by increased replication and higher fanouts as you are driving a lot more logic in the async case.

Hi,

I agree with Olof. For ASIC, I *much* prefer asynchronous reset to all FF'.

Why?
- ATPG and Test: It's easy to put all registers into a known state at startup
- Multiple (On/Off) Power Domains: Last design I was involved in, an external IP with synchronous reset added lots of complexity where we needed to switch domains on and off
- Timing is potentially better (no reset in data path)

I am with John and Xilinx on this one. FPGA's naturally support synchronous resets and to timing is actually easier and more accurate when using synchronous resets.

http://www.sunburst-design.com/papers/CummingsSNUG2002SJ_Resets_rev1_1.pdf
http://www.asic-world.com/tidbits/all_reset.html
http://only-vlsi.blogspot.com/2009/05/synchronous-reset-vs-asynchronous-reset.html

New Note 21

Describe your new note here.



That second link had only good things to say about async resets, except that it was sensitive to metastability.

I don't know about all FPGAs, but at least the Virtex-5 CLBs (same as Spartan-6) has selectable async or sync reset on all slice FFs, so they support both styles just as well (see page 174 in ug190 v5.3 or fire up the fpga_editor (which doesn't really work well on latest Ubuntu btw)). You really want sync resets on state machines, but most places can do without reset or have an async reset.

As I said before, the best of two worlds is asynchronous set and syncronous release (which is what happens if you use @posedge rst). I find it hard to see that it would require more logic, as you only need one FF per clock domain to do this, given that you have enough reset nets. I think this is an interesting topic, and I would like to investigate it more. I'm even willing to admit I'm wrong if someone comes up with more evidence :)

If you consider an soft IP (i.e. RTL delivery), it must be designed to support multiple targets i.e. ASIC and FPGA.



Synchronous reset does add to the data path logic depth, even if it simply changing 2 input to 3 input AND on the D input of a flop, it adds to the timing.
You are correct that the synthesis tool will re-order logic etc to meet timing (but this may increase runtime)



I think this reset wrapper is more complex than is implied here. Consider clock gating, switched on/off power domains etc. I have always found it is much easier with async flops.
With asynchronous de-assertion (as recommended by Cummings), timing can also be guaranteed.


BTW, does anyone have a copy of the Re-use Methodology Manual? I would be interested to hear what it has to say.

Steven

I second the opinion "the best of two worlds is asynchronous set and syncronous release".
From my experience, i can share following..

------------------
Advantages:
------------------
(1) keeps ur reset logic simple.
(2) all flops get reset in single cycle. (synchronous_reset needs clocks to be running during reset-duration so that whole pipeline of flops are cleared)
(3) "comparatively" less dynamic current load during "Power-up", as clocks can remain gated. This might be advantageous at system-level, if you have weak power-supply because during "Power-Up" everything starts sourcing current in single go.. (even the unused logic)

------------------
Disadvantages:
------------------
(1) "de-assertion" needs to be synchronized per clock-domain basis.
(2) FLOP standard-cell size is bit large (due to extra circuit inside standard-cell to account for asynchronous clear). So bit area hit (LUT hit)
(3) from STA (Static Timing) point of view, need to block arcs for assertion from "async reset" to output of flop.

------------------------------------------------------------------------------------
If FPGA/Technology does not support "async reset flops", but RTL has "async reset flops"
------------------------------------------------------------------------------------
(1) During netlist synthesis, you can force the synthesis tool to convert all async-reset flops to sync-reset flops.

(2) you can always convert it into "synchronous reset" by adding synchronizer in front of it. but at Power-Up you need to extend "system level" to longer duration, so that synchronizer captures it. However, this can be done external to block as and when required.

(3) Time the paths during building of reset-tree.

(4) And extend reset till all flops are cleared in pipeline


(still async-reset with sync deassertion is best)
with regards, pekon

I second the opinion "the best of two worlds is asynchronous set and syncronous release".
From my experience, i can share following..

------------------
Advantages:
------------------
(1) keeps ur reset logic simple.
(2) all flops get reset in single cycle. (synchronous_reset needs clocks to be running during reset-duration so that whole pipeline of flops are cleared)
(3) "comparatively" less dynamic current load during "Power-up", as clocks can remain gated. This might be advantageous at system-level, if you have weak power-supply because during "Power-Up" everything starts sourcing current in single go.. (even the unused logic)

------------------
Disadvantages:
------------------
(1) "de-assertion" needs to be synchronized per clock-domain basis.
(2) FLOP standard-cell size is bit large (due to extra circuit inside standard-cell to account for asynchronous clear). So bit area hit (LUT hit)
(3) from STA (Static Timing) point of view, need to block arcs for assertion from "async reset" to output of flop.

------------------------------------------------------------------------------------
If FPGA/Technology does not support "async reset flops", but RTL has "async reset flops"
------------------------------------------------------------------------------------
(1) During netlist synthesis, you can force the synthesis tool to convert all async-reset flops to sync-reset flops.

(2) you can always convert it into "synchronous reset" by adding synchronizer in front of it. but at Power-Up you need to extend "system level" to longer duration, so that synchronizer captures it. However, this can be done external to block as and when required.

(3) Time the paths during building of reset-tree.

(4) And extend reset till all flops are cleared in pipeline


(still async-reset with sync deassertion is best)
with regards, pekon

Hi John Eaton,



I agree on ur point of hefty area penalty, but such "important" design decisions should be taken cautiously. A single mistake or wrong approach here, might make ur design buggy and manytimes un-reusable, which is far more costly in today's time than 40% area hit. Because time-to market with correct features and right ingredients is what is required to survive..
I would like to highlight one more following issue while using "sync-reset flops" at "outputs" of design.

----------------------------------------------------------------------------
CASE 1: Possible Issue in "sync-reset", due to duplication of synchronizer
----------------------------------------------------------------------------
There are duplicated sychronizers on reset path (A) and (B).
And output of design is OUT = A ^ B = A XOR B

Now on actual silicon cycles taken by sychronizer to propagate reset is "un-deterministic" (1-3).
Suppose synchornizer on path(A) takes 2 cycles, while synchornizer on path(B) take only 1 cycle.
(assuming both A and B are at '1' before reset.. Something like in below waveform will happen)

|--0--|--1--|--2--|--3--|--4--|--5--| (clock cycles)

|__/--------------------------- (Reset)

|====|====|====|____|____|____| (A)

|====|====|____|____|____|____| (B)

|____|____|====|____|____|____| (OUT= A XOR B)

(NOTE: signals edges might be somewhat skewed in above waveform due to white-space formatting)

Issue: OUT(A^B) will have glitch at cycle-2 due to mismatch in sychronizer timings.

----------------------------------------------------------------------

So, I propose one more implementation format, which will serve both purpose (reduce area hit + no need of wrappers)
(1) Use async reset flops for all registered outputs, and last flops on combo outputs or design.
(2) Use sync reset flops for any paths which are internal to design.

ADVANTAGES:
(1) Reduces area penalty as only flops which are "driving" to external world will be 'async-reset' flops, while most of all other data-path flops can be made sync-reset.
(2) External pluggable bus/modules, need not to worry about reset-tree delays, as any signal coming to them will be reset asynchronously.

DISADVANTAGES
(1) However, this puts some burden on RTL designer and requires recursive checks whether he has adhered to the given guidelines.
(2) Reset assertion needs to be extended to multiple cycles, till all pipelines inside the design are synchronously cleared.


(Please analyze and suggest a feedback)

with regards, pekon