Release asynchrounous resets synchronously

W

William Wallace 22 years ago

THE IMPORTANCE OF PROVIDING A RESET THAT LEAVES THE RESET SYNCHRONOUSLY EVEN IF IT DRIVES THE ASYNCHRONOUS RESET:

Consider a simple one hot state machine that cycles through 3 states:

S001: 001 S010: 010 S100: 100 S001: 001 S010: 010 S011: 100

This is a simple, trivial state machine, but it will serve the purpose of highlighting why you should leave reset synchronously.

What happens if the asynchronous reset comes at a time and has delays such that two of the flops to see clock N as the first clock, but the third flop to see clock N+1 as the first clock. Your state machine might end up running like so:

S001: 001 Invalid: 011 Invalid: 110 Invalid: 101 Invalid: 011 Invalid: 110 Invalid: 101

Two flip flops are hot. This is bad.

You could get around this by treating your one hot as a binary encoded state machine, and treating all other states other than {001, 010,

100} as dead end states that must transition to one of the valid states, but in doing so, you loose the advantages of a one hot state machine (specifically, the combinatorial logic required to protect against these dead end states may make it harder to meet timing, and may chew up more resources than you want).

A different approach would be to process your reset into the FPGA such that the entire design is reset asynchronously, but the majority of the design leaves reset synchronously (though under control of the asynchronous reset input)

E.g., (and not syntax checked):

process(clk,iReset) begin if(iReset='1') then ResetSR="00"; elsif(clk'event and clk = '1') then ResetSR(0)

Vote

K

ka 22 years ago

...

Yes; for DFF cells there is a parameter called Reset Recovery Time on the reset input which is similar to setup parameter for D input. If you release the reset synchronously to the clock input, STA tools can time the reset path too.

Vote

J

Jeff Cunningham 22 years ago

You cannot rely on async reset at startup for initializing one hot state machines and the like. You need to do something like generate your own sync reset from some flip flops at startup as in your code example. If you are using DLLs you also might want to factor the lock output into your synch reset. This has been discussed here before, you might search the ng archive. I have been burnt by this bug before, i.e. state machines starting up 0-hot. This works for me:

-- synchronous part of state machine process(clk,asynch_rst) begin if asynch_rst = '1' then -- the startup global async reset. state

Vote

R

rickman 22 years ago

This is correct. The async global reset is not designed to be fast. So you have to make sure that your design will work if the FFs come out of reset on different clock cycles. There are other ways to do this than using a sync reset. If your design is large, a sync reset may be hard to route to all the FFs that need it within a single clock cycle as well.

For state machines, you can use a few prior states to assure that the reset has been released before the FSM gets to "critical" states. For example, if your machine is one hot, you can use a few states that are not one hot, e.g. 000 -> 100 -> 110 -> 111 before your FSM can operate (any gray code will do). Of course, this is really the same as having a "local" sync reset which is another way of doing this.

Or if your logic does not have an immediate transition then you don't need to do anything. For example, if your FSM depends on an external signal such as a write strobe, if you have time before the write strobe comes along to let the global reset settle, a separate sync reset is not needed.

Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX

Vote

Release asynchrounous resets synchronously

Join the Discussion

Didn't find your answer?