Sync Reset Implementation

Hi All,

Attached please find one of the Sync Reset implementations. Please suggest suggest yours.



Thank you!

That seems good.

rca, could you please take a look at this post: https://www.edaboard.com/threads/269890/
Are the timing constraints correct there?

why the falling edge clock on the 2nd register?

Doing that just turns the path setup requirement to 1/2 the clk clock period, instead of the full clk period.

-alan

ads_ee said:

why the falling edge clock on the 2nd register?

Doing that just turns the path setup requirement to 1/2 the clk clock period, instead of the full clk period.

-alan

Click to expand...

ads_ee is correct - the second register should be clocked on the same edge as the first. Your reset tree may turn out to have a high fanout and in this case the full clock period will help with the implementation. I don't mean to be a pedant but I find your schematic a little unclear: bear in mind the following considerations:

\[\to\] it's a good idea to have the power-on reset active low because during the power up of the system, a logic '1' may not be well defined ;
\[\to\] thusly, the power-on reset line should be connected to an active low reset (as opposed to a set) (this isn't indicated in your schematic) ;
\[\to\] your synchronous reset line is active low in this scheme (there's nothing to indicate that this is the case in the schematic).

We use a scheme like this to cleanly handle the case where there's no clock present when the reset is asserted, or the reset is shorter than a clock period, and also metastability in the first register. In this case metastability could come from the deassertion of the reset line during the reset recovery period, but note that the second register will not be affected because the input and output will have the same state when the reset line is deasserted.

best wishes,
sharted.

Sampling the reset line by a negedge flop, just gives the maximum margin in terms of the removal/recovery restrictions.

In this case metastability could come from the deassertion of the reset line during the reset recovery period, but note that the second register will not be affected because the input and output will have the same state when the reset line is deasserted.

Click to expand...

Good tip!

BTW, during assertion of the asynchronous reset, the second flop could also enter to a metastable state... Is this dangerous? Probably better to add an AND gate, which would gate the asynchronous reset itself with the output of the second flop?

Please share your thoughts.

- - - Updated - - -

BTW, how would you explain that a metastable state is not dangerous if the device (flop/latch) should not change its output value?

ivlsi said:

Sampling the reset line by a negedge flop, just gives the maximum margin in terms of the removal/recovery restrictions.

Click to expand...

I don't know what you mean by this. Your implementation tool will ensure the setup and hold time between the two registers is correctly implemented. The issue that was raised by ads_ee (that I agree with) is that you reduce the setup time available for the registers receiving the synchronous reset. The deassertion of the asynchronous reset line will, at some point, violate the timing requirements of the registers because it's asynchronous.

ivlsi said:

BTW, during assertion of the asynchronous reset, the second flop could also enter to a metastable state... Is this dangerous? Probably better to add an AND gate, which would gate the asynchronous reset itself with the output of the second flop?



BTW, how would you explain that a metastable state is not dangerous if the device (flop/latch) should not change its output value?

Click to expand...

You can forget about the assertion of the asyncronous reset - the reset line takes priority over clocking activity, it's the deassertion that could cause metastability, but only on the first register. In order to have a metastibility problem, there must be a logic differential across the register. Since the second register will have the input '0' and the output '0' it's impossible for it to oscillate between '1' and '0' even if the deassertion of the asynchronous reset line violates the recovery time.

hth,
sharted.

Do you define the metastability as an oscillation of the sequential device output? Could not it be just a slow ramp/slop of the signal in its output (as a result of the racing condition between clock and reset or the data sampling on the active edge of the clock)?

ivlsi said:

Do you define the metastability as an oscillation of the sequential device output? Could not it be just a slow ramp/slop of the signal in its output (as a result of the racing condition between clock and reset or the data sampling on the active edge of the clock)?

Click to expand...

An oscillating output is one possible manifestation of metastability; I didn't mean it as a definition. Outher behaviours might include, but not be limited to:

\[\to\] oscillations that do not reach valid logic '1' and '0' levels that may continue or stop spontaneously;
\[\to\] oscillations that do reach valid logic '1' and '0' levels that may continue or stop spontaneously;
\[\to\] an output that transitions to the correct state, but later than the clk-to-q time;
\[\to\] an output that transitions to the correct state, and then later (without a clock edge) transitions back;
\[\to\] some voltage between '0' and '1' that appears stable, but later transitions (without a clock edge) to a '1' or '0';

almost certainly others that I cannot recall immediately. The point of my previous post was not to define metastable behaviour, simply to try to convey the idea that a change of state is required to produce this behaviour.

hth,
sharted.

I'm under the impression that the discussion is somehow complicating simple facts, that are well covered by digital logic text books.

To charactreize the present circuit, it's essential purpose is to release a reset synchronously. The detail behaviour during reset assertion can be almost ignored, it's sufficient to know, that it's reliably propagated to the output and results in a sufficient long reset of connected logic blocks.

Reset deassertion is the critical point. By nature of synchronous FFs, a deassertion exactly on the active clock edge can generate a metastable state. As already mentioned, the usual reset synchronizer is driving both FFs with the same clock edge. Metastability of the first stage will be supressed in the second, if certain prequisites for D versus clear input setup time of the FF are met. I wonder , if the clock inversion in the original post has been applied due to unsure conditions in this regard.

Hi friends
how do i check setup and hold time for incoming database but there is no delay ...