Pad-to-pad hold time

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Probably stupid question (sorry), but I cannot figure out an answer:

Xilinx devices has optional delay element in IOB which causes (when
used) that pad-to-pad hold time is zero.
Maybe someone could explain me, how to understand this pad-to-pad hold
time, and when I should use this optional delay element?

Why does it only affects pad-to-pad hold time and not for example
pad-register in CLB hold time? Is it because registers in CLBs have
significantly shorter hold times?


Robert P.

Re: Pad-to-pad hold time
Hold time issues.
Inside the FPGA, the global clock has very little skew, which means
there are no hold-time issues ( clock-to-Q + routing delay + set-up time
) is always longer than any clock skew.

In the I/O input register, the timing relationship is different. Let's
assume that the transmitting chip's output driver and the receiving
chip's input flip-flop use the "same" clock. And let's assume thet the
trasnmitter is pretty fast ( short clock-to-Q). That means the "new
data" will arrive soon after the incoming clock edge. But that clock
edge has to be amplified and distributed in the receiving chip, and it
is still supposed to clock in the "old data".
If the internal clock delay is longer than the incoming data delay, you
end up clocking in the wrong ( the new ) data. The part would have to be
specified with a positive hold time (The old data must be kept valid
beyond the clock edge that changes old data to new data) This is a bad
specification, very difficult to live with.
The solution to avoid any posittive hold time requirement is to
artificially delay the incoming data. (which does cause a performance
penalty, since it also increases the set-up time)
But it is better to sacrifice some top performance than to sacrifice
reliability. A hold time violation can cause system failure at any
speed. "Unsafe at any speed", to miquote Ralf Nader.
Inside the chip, this is a non-issue.

Peter Alfke, Xilinx
Quoted text here. Click to load it

Site Timeline