Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
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.
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.
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?
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.
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?
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.
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)?
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)?
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.
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.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
