Stupid reset question

Nick,

I assume that Cyclone works similarly to our own FPGAs in that all flip flops are inti tally set to 0 by the house-cleaning (initialization prior to configuration) at power on.

You can check this by reading their manual on what happens during power on and configuration.

Then, during configuration, the state of the flip flops for logic may (or may not) be set, or reset to a state as specified by the bitstream (depends on the device, and its options when being configured).

If you have designed the state machine with no hidden states, and in such a way that it will always return to a known state given a set of good inputs, there is no need for a reset.

In the case of a 1-hot state machine (very popular in FPGAs) this also means that detection of having more than one state set (more than one flip flop) must decode and send you back to a known state of having only one state active!

Aust> Hello,

Thank you Austin. I'll check the documentation and secure the state machines.

Regards, Nick

I've never used Cyclon, but I'd expect that there is an asynchronous reset and/or set applied as part of configuration. If so, then what you need to worry about is the first clock. As the reset will be released at different times across the chip, some FFs may be released from reset before others, and a statemachine may end up in a non valid state that will prevent correct functioning. This can be solved by using safe statemachines, so that all non-valid states map into valid states in at most a few clocks, or by using statemachines with no invalid states at all. A binary counter, for example, has only valid states.

Now, suppose there was a "reset" statemachine that held reset to the rest of the statemachines until the configuration was released and all?

This is fairly simple, put in a binary counter or similar safe statemachine with more than enough counts (or states) to make sure that the reset is released, have it hold synchronous reset to the reset of the design until count complete, then release it. Example in VHDL follows:

use ieee.numeric_std.all; entity ... architecture ... Signal reset : std_logic := '1'; Signal count : unsigned(3 downto 0) := "0000"; begin -- -- This counter is used to hold all statemachines in reset for the -- first 8 or so clocks after the end of configuration. -- RESET_STATE: process(clk) begin if rising_edge(clk) then reset

When Quartus runs it prints a little message that all flip-flops that have a reset high.. will be high after initialisation.. or words to that effect.

Simon

Nick,

I don't know about Cyclone FPGAs but I suppose that they have some sort of digital clock manager, DCM, as the Xilnx FPGAs have. In some designs I have used the inverse of the DCM lock signal as global reset signal. In that way all flip-flops in the design are reset simultaneously when the clock is stable. (The DCM lock signal is asserted when all outputs from the component are locked).

I don't know if this is considered good or bad practise, but it is working quite good. Hasn't failed yet.

Shouldn't: if count(3) = '1' then count

Very interresting solution. I buy it.

Nick

This is not safe as presented, as you can't guarantee all the flip-flops in the counter will be released from reset on the same clock cycle. To make this robust, the power up reset has to be registered by clk and that local synchronous reset used to reset the counter. In Xilinx FPGAs, it is easier and more compact to use the SRL16 as a shift register to delay the reset, and it avoids the reset signal time of arrival issue inside the reset circuit.

Then please show how it fails.

If bit 0, the LSB, is released last, then it works. None of the other bits can go high until bit 0 goes high. Agree?

If bit 1, the next bit, is released last, then the bit 0 goes high first, reset is released, then it works. Agree?

Even if two clocks could come into the LSB FF before the release of reset to the next bit, then the count sequence would be:

And it works.

Same thing for each bit up to the MSB.

I disagree. SRL16's are wonderful for logic, but have horrible metastable charactistics. This really is a metastable problem, so SRL16's are a bad idea. Use slice FFs to make a shift register. Or use a SRL16, and follow it with FFs.

The problem is that if the reset is released right at the clock edge at any one flip-flop, that flip-flop can go metastable, and can result in it landing in the '1' state instead of the '0' state. I saw this exact failure on an SDRAM controller provided as part of the infrastructure IP on one of the high-end 3rd Party FPGA boards two years ago. The fix, BTW, was to add a synchronizing flip-flop to make removal of the reset to the whole counter synchronous with the counter's clock.

For the SRL16, yes, you are correct, the metastable performance sucks. I should have been more exact by stating the SRL16 should be preceded by a flip-flop. The SRL16 is essentially being used as a counter to delay the reset. You want the FF before the SRL16, as that is where the clock domain crossing is. You will also want a FF after the SRL16, but that one is for timing closure, not metastability reasons.

Yes, this can happen, and it is OK. If the FF has an asynchronous clear, the D input is one, and the clear is released just before the clock edge, the FF can go metastable, and might resolve to one or zero.

If the FF has an asynchronous clear and the D input is zero, there is no chance of a metastable result.

So the only FF that can go metastable on the first clock edge after reset is the LSB. That may well mess up a SDRAM controller, but will not cause this circuit to do anything other than have the extra delay of the metastable resolution time if that slips past the next clock edge. Which is acceptable, as all we are hoping for is a clear release from reset for the rest of the design.

Good explanation.