How to make sure that setup and hold times are not violated

Hi,

I am trying to design a digital access control circuit at which a user enters certain code to be granted access . When I was doing simulation , I came across this question ... how do i make sure that the input doesnt come with the clock edge for example (setp time is violated ) ?

DRC might check these race conditions. We had to check race conditions manually in the old days or ensure everything had ample setup time using a the right clock phase to latch data or use asynchronous set, reset after read data.

makanaky said:

Hi,

I am trying to design a digital access control circuit at which a user enters certain code to be granted access . When I was doing simulation , I came across this question ... how do i make sure that the input doesnt come with the clock edge for example (setp time is violated ) ?

Click to expand...

Two cardinal rules:
- Since the user input cannot be controlled, it is impossible to guarantee that setup or hold time requirements are not violated.
- Since setup/hold time requirements cannot be guaranteed to be met, a proper design must minimize the probability that a violated requirement will cause a system malfunction.

The design techniques that are used are:
- The input must be received by exactly one flip flop. If the signal goes to more than one flip flop (either directly or through combinatorial logic), then there is a good chance that one flip flop will see the input in one state, the other flip flop will see it in another state which will (likely) cause a system malfunction thus violating the second cardinal rule.
- Recovering from a timing requirements violation simply involves waiting for a sufficient period of time. Since one doesn't know when the violation occurs, this means that one must design extra delays on that input signal. The typical approach is to bring the input signal into a shift register (which is typically only two deep) with the output of the shift register being the only signal that is then used throughout the rest of the design. The reason this works is because even though the input is uncontrolled relative to the clock, the output of that first flop is pretty well controlled. The probability that potential metastability is not resolved by the time the next clock arrives to clock that signal into the second flop is typically very low. Therfore, the probability of the second flip flop ever becoming metastable is much, much lower. Cascade a third one and it is likely the IC will disintegrate into the sand from which it came from before that flop is ever predicted to go metastable.

For more information, Google for 'metastability'. With typical FPGAs today, metastability is resolved in times measured in picoseconds, whereas clocks cycle in nanoseconds. As you read, you'll find that in order to compute the probability, you'll need to know with some degree of certainty approximate values for these two times. While it is easy to know your clock period, the metastability resolution time is a bit harder to discern from the manufacturer but not impossible. So unless you're contemplating a design that runs in the 500+ MHz range or higher, cascade the two or three flip flops in your shift register and rest assured that the probability of the timing violation causing a system hiccup is so low that you will be dead and buried long before one would ever see the design fail for this reason...it will have long since failed for some other reason.

Kevin Jennings

---------- Post added at 21:57 ---------- Previous post was at 21:50 ----------

SunnySkyguy said:

DRC might check these race conditions. We had to check race conditions manually in the old days or ensure everything had ample setup time using a the right clock phase to latch data or use asynchronous set, reset after read data.

Click to expand...

How does any of this apply to the OP's question about sampling an asynchronous user input? There is no race condition with one input. This is a simple case of clock domain crossing from the user input clock domain into the design's clock domain...the usual assumption being that the user input clock domain is completely asynchronous to the design's clock domain.

Kevin Jennings

Kevin we made different assumptions.

In your case ;

• the input state must be long than the clock interval and frequency < ½ the clock synchronization rate. (Shannon rate)
• the inputs are asynchronous
• the prop delays and setup times could create a meta time could be (almost) as much as clock interval

In my case;

• the input frequency must be> clock rate for edge set/clear latch
• the prop delays and setup times if < 1/2 the clock interval could reduce latency

In both cases the input must be latched to avoid a race between clock and asynchronous (or synchronous) input event to prevent a metastable condition with a missed event.

added:
actually in the old days it was common to have quadrature clock phases to access memory to reduce latency. Now it is overclocked with a FSB clock to get finer tuning of digitally controlled delays for CAS RAS etc settings with fine control over sub nanosecond clock positioning of , address and data to optimize thruput or margin of Computer memory.