cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
449 Views
Registered: ‎12-26-2017

Timing summary understanding

Jump to solution

Hi,
I'm implementing LVDS serial interface from image sensor on Zynq Ultrascale+. Interface is source synchronous and speed is 297 Mhz DDR (594 Mbps). Setup and hold times in sensor datasheet are specified to 400 ps: 

interface.png

Considering XAPP1324 - I cannot use MMCM because I have connected 4 sensors (4 input clocks) into one bank but there is only one MMCM per bank. So I need to use IDELAY to compensate data path delay. See schmeatic of final IDELAY and ISERDES implementation:

schema.png

Problem is that design fails to meet timing requirements. I cannot compensate delay by IDELAY because the design has negativ slack on both Setup an Hold time for D_IN path to ISERIES. Here is timing summary report:

setup.png

hold.png

What does parameter "clock uncertainty" means and why considered in clock path rise edge only and no in fall edge?

I have following Implementation warning:
[Route 35-468] The router encountered 1 pins that are both setup-critical and hold-critical and tried to fix hold violations at the expense of setup slack. Such pins are: deserializer_inst/IDELAYE3_inst/IDATAIN
What does it mean?

Is there any way to improve timing?

I included hdl files, constraints and complete timing summary report.

Thank you!
Mates

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
356 Views
Registered: ‎01-23-2009

Re: Timing summary understanding

Jump to solution

What does parameter "clock uncertainty" means and why considered in clock path rise edge only and no in fall edge?

Clock uncertainty is the uncertainty in the period of the clock. There are a couple of components, but basically it is the jitter of the clock. When we specify a clock, we give its period which is the average time between one rising edge and the next. But, like almost anything, it is not precise - the real difference between any two successive edges is a probabilistic distribution with a mean which is the period, but also has a standard deviation. The jitter is a mechanism of representing this standard deviation. Normally jitter is measured in RMS value (which is actually giving you information about the distribution), but in static timing analysis we use cycle/cycle or period jitter, which is an upper bound (in ps) of jitter that we allow for a working system - anything above that (i.e. in the tail outside the limit specified by the cycle/cycle jitter) is so infrequent that the failures associated with it is rare enough that we are willing to accept it (i.e. the MTBF is high enough for us to still ship the product).

Back to your question. The determination as to whether it is used is not dependent on whether we are looking at the rising edge or falling edge, but the nature of the check. In your post you have two timing paths that represent different checks - one setup check and one hold check. In the setup check (and for all normal setup checks), the check is verifying that the data caused by the change in a clocked element or port (a startpoint) has time to propage to the destination clocked element (an endpoint) before the next edge of the clock. Since this is a check from one edge to the next edge, it needs to take the clock uncertainty into account.

For a (normal) hold check, the check is verifying that a change in a startpoint cannot propagate to another clocked element clocked on the same clock edge. Since it is from a clock edge to the same clock edge, there is no uncertainty - the edge is the edge - its position relative to other edges is irrelevent, and hence the uncertainty of the time from edge to edge is irrelevent.

I say this is for "normal" setup and hold checks - the edge relationships can be modified with timing exceptions (like set_multicycle_path) which will change the launch and capture edges. This can, for example, change the setup check to be from a given edge to the same edge. The rule as to whether the uncertainty is used is associated with the edges involved in the check - if the check is form one edge to itself, then no uncertainty is used. If it is from one edge to a different edge, then the uncertainty is used.

Now back to your interface. With 400ps setup and hold (a total of 800ps) the data valid window is not wide enough to capture statically - nothing you are going to try (even using an MMCM) is going to change that.

However, in UltraScale you can use the I/O in Native mode. In Native mode, you can use the Built-in Self Calibration (BISC) which can capture interfaces with singificantly smaller static data windows. Given that your window is perfectly center aligned it is a good candidate for BISC capture. However, to use BISC, the clocks for capture must be on DBC/QBC pins, not on GC pins - if your board is already designed, then this will probably not be the case (although there are a few pins that are both DBC/QBC pins and GC pins), and you cannot use native mode with GC clocking. Take a look at this post on Native mode I/O with BISC.

Avrum

View solution in original post

3 Replies
Highlighted
Xilinx Employee
Xilinx Employee
431 Views
Registered: ‎05-14-2008

Re: Timing summary understanding

Jump to solution

For clock uncertainty, the following answer record is for ISE Timing tool, but the concept is the same.

https://www.xilinx.com/support/answers/37430.html

If the setup and hold cannot be both met for your input interface, you'll need to change your input interface structure, such as using MMCM, using IDELAY in dynamic mode and etc. 

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Explorer
Explorer
416 Views
Registered: ‎06-25-2014

Re: Timing summary understanding

Jump to solution

I believe this post may prove helpful to what you are trying to achieve. There is a lot of good info here:

 

https://forums.xilinx.com/t5/Timing-Analysis/Constraining-ISERDES/m-p/798937

0 Kudos
Highlighted
Guide
Guide
357 Views
Registered: ‎01-23-2009

Re: Timing summary understanding

Jump to solution

What does parameter "clock uncertainty" means and why considered in clock path rise edge only and no in fall edge?

Clock uncertainty is the uncertainty in the period of the clock. There are a couple of components, but basically it is the jitter of the clock. When we specify a clock, we give its period which is the average time between one rising edge and the next. But, like almost anything, it is not precise - the real difference between any two successive edges is a probabilistic distribution with a mean which is the period, but also has a standard deviation. The jitter is a mechanism of representing this standard deviation. Normally jitter is measured in RMS value (which is actually giving you information about the distribution), but in static timing analysis we use cycle/cycle or period jitter, which is an upper bound (in ps) of jitter that we allow for a working system - anything above that (i.e. in the tail outside the limit specified by the cycle/cycle jitter) is so infrequent that the failures associated with it is rare enough that we are willing to accept it (i.e. the MTBF is high enough for us to still ship the product).

Back to your question. The determination as to whether it is used is not dependent on whether we are looking at the rising edge or falling edge, but the nature of the check. In your post you have two timing paths that represent different checks - one setup check and one hold check. In the setup check (and for all normal setup checks), the check is verifying that the data caused by the change in a clocked element or port (a startpoint) has time to propage to the destination clocked element (an endpoint) before the next edge of the clock. Since this is a check from one edge to the next edge, it needs to take the clock uncertainty into account.

For a (normal) hold check, the check is verifying that a change in a startpoint cannot propagate to another clocked element clocked on the same clock edge. Since it is from a clock edge to the same clock edge, there is no uncertainty - the edge is the edge - its position relative to other edges is irrelevent, and hence the uncertainty of the time from edge to edge is irrelevent.

I say this is for "normal" setup and hold checks - the edge relationships can be modified with timing exceptions (like set_multicycle_path) which will change the launch and capture edges. This can, for example, change the setup check to be from a given edge to the same edge. The rule as to whether the uncertainty is used is associated with the edges involved in the check - if the check is form one edge to itself, then no uncertainty is used. If it is from one edge to a different edge, then the uncertainty is used.

Now back to your interface. With 400ps setup and hold (a total of 800ps) the data valid window is not wide enough to capture statically - nothing you are going to try (even using an MMCM) is going to change that.

However, in UltraScale you can use the I/O in Native mode. In Native mode, you can use the Built-in Self Calibration (BISC) which can capture interfaces with singificantly smaller static data windows. Given that your window is perfectly center aligned it is a good candidate for BISC capture. However, to use BISC, the clocks for capture must be on DBC/QBC pins, not on GC pins - if your board is already designed, then this will probably not be the case (although there are a few pins that are both DBC/QBC pins and GC pins), and you cannot use native mode with GC clocking. Take a look at this post on Native mode I/O with BISC.

Avrum

View solution in original post