UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor jparriaux
Visitor
1,014 Views
Registered: ‎09-04-2018

Output hold time

Jump to solution

I am having an issue ensuring timing constraint on my project.

I am using a Spartan6 and ISE 14.7.

 

The problem is the following : There is a device that generates a clock. The clock is fed to the FPGA. The FPGA generates a stream of data (synchrnous to the clock) and feed it to the device. In the device, the data is sampled on the clock rising edge.

The datasheet of the device specifies that, on the input interface (the data one), a minimum setup time of 2 ns and a minimum hold time of 2ns are required.

Several Xilinx documents highlight that in my situatuion the OFFSET OUT constraint should be used to set both the setup and hold times (see https://www.xilinx.com/support/documentation/white_papers/wp237.pdf page 1). This makes perfect sense to me regarding the setup constraint. However, I do not see how OFFSET OUT can affect the hold time.

What did I miss?

 

I have been browsing the Internet and the Xilinx documentation but I could not find anything satisfactory.

 

Some post seem to mention that the hold time is the minimum fastest path. But is it really the case ? I would say this time tells me the time before my data changes but does it really guarantee that it remains valid before ?

 

Is there any way to set or to put a constraint on the output hold time ?

Is there any way to retrieve the hold time associated with an output for a given design afetr Place&Route?

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
994 Views
Registered: ‎01-23-2009

Re: Output hold time

Jump to solution

Basically the answer to your question is "no".

 

One of the most significant shortcomings of the timing engine in ISE (and UCF) was incredibly poor treatment of hold times.

 

Originally (i.e. VERY originally) FPGAs had only one clock. Since the clock tree was balanced inside the FPGA, internal hold failures were impossible. As a result, the tool simply ignored the concept of hold times - it only checked setup times.

 

As the FPGAs became more complex, some hold time checking was added; inter-clock domain and input hold times. However, output hold times were never added - there is no way to ask for, guarantee or measure output hold times in ISE.

 

So, you have a number of choices...

 

Before we go into the choices, I would ensure that you are using IOB flip-flops for all your output data. While this is a bit counter intuitive (since it makes the clock to output faster), using the IOB flip-flops is really the best way to have reliable interfaces - ones whose timings don't change from run to run.

 

Now for the hold time. The first option is to do the hold check manually. Here you have

  - the clock propagation on the board from your device to the FPGA (min)

  - the delay of the IBUF (min)

  - the delay of your clocking structure (min)

    - this can get VERY complicated if a DCM/PLL are involved

    - with a DCM/PLL with global clock feedback this is actually pretty negative

  - the clock to q of the IOB flip-flop (min)

  - the delay of the OBUF (min)

  - the board routing back to your external device (min)

 

The board delays are easily calculated by the length of the traces.

 

Unfortunately for the internal stuff, the datasheet does not give the min for any of these - it only gives the max. So the "best" you can do is assume the 3:1 rule - the min value is 1/3 the value of the max value. This is only valid for pure gate delays (which are the vast majority of delays in the FPGA - even through the interconnect) - it cannot be applied to things like the DCM/PLL (which are compensated).

 

If this doesn't satisfy the 2ns requirement (with some margin), then you have to consider another way. The best way is to clock the output data with "some other clock".

 

There are two big options here. If the interface is very slow, the easiest solution is to clock the outgoing data (in the IOB) with the falling edge of the clock. This trades 1/2 period of setup margin for 1/2 period of hold margin. This will surely satisfy your hold requirement of 2ns, but may break the setup requirement.

 

If this is too much delay, then you will need to use the DCM/PLL to generate a clock with a different phase to clock your outputs - perhaps "CLK90" - which will give 3/4 of a clock period for setup and 1/4 of a clock period for hold.

 

Avrum

2 Replies
Scholar drjohnsmith
Scholar
1,000 Views
Registered: ‎07-09-2009

Re: Output hold time

Jump to solution

Hold time is this not from an output is the time after the signal has settled till the next clock of the output ?

 

any chance of a picture of your clocking / data flow  ?

 

Are you using the PLL / MMCM in the FPGA to zero out the clock delay  through the device ?

 

are you putting output registers in the IOB's ?

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Historian
Historian
995 Views
Registered: ‎01-23-2009

Re: Output hold time

Jump to solution

Basically the answer to your question is "no".

 

One of the most significant shortcomings of the timing engine in ISE (and UCF) was incredibly poor treatment of hold times.

 

Originally (i.e. VERY originally) FPGAs had only one clock. Since the clock tree was balanced inside the FPGA, internal hold failures were impossible. As a result, the tool simply ignored the concept of hold times - it only checked setup times.

 

As the FPGAs became more complex, some hold time checking was added; inter-clock domain and input hold times. However, output hold times were never added - there is no way to ask for, guarantee or measure output hold times in ISE.

 

So, you have a number of choices...

 

Before we go into the choices, I would ensure that you are using IOB flip-flops for all your output data. While this is a bit counter intuitive (since it makes the clock to output faster), using the IOB flip-flops is really the best way to have reliable interfaces - ones whose timings don't change from run to run.

 

Now for the hold time. The first option is to do the hold check manually. Here you have

  - the clock propagation on the board from your device to the FPGA (min)

  - the delay of the IBUF (min)

  - the delay of your clocking structure (min)

    - this can get VERY complicated if a DCM/PLL are involved

    - with a DCM/PLL with global clock feedback this is actually pretty negative

  - the clock to q of the IOB flip-flop (min)

  - the delay of the OBUF (min)

  - the board routing back to your external device (min)

 

The board delays are easily calculated by the length of the traces.

 

Unfortunately for the internal stuff, the datasheet does not give the min for any of these - it only gives the max. So the "best" you can do is assume the 3:1 rule - the min value is 1/3 the value of the max value. This is only valid for pure gate delays (which are the vast majority of delays in the FPGA - even through the interconnect) - it cannot be applied to things like the DCM/PLL (which are compensated).

 

If this doesn't satisfy the 2ns requirement (with some margin), then you have to consider another way. The best way is to clock the output data with "some other clock".

 

There are two big options here. If the interface is very slow, the easiest solution is to clock the outgoing data (in the IOB) with the falling edge of the clock. This trades 1/2 period of setup margin for 1/2 period of hold margin. This will surely satisfy your hold requirement of 2ns, but may break the setup requirement.

 

If this is too much delay, then you will need to use the DCM/PLL to generate a clock with a different phase to clock your outputs - perhaps "CLK90" - which will give 3/4 of a clock period for setup and 1/4 of a clock period for hold.

 

Avrum