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 linsheng
Visitor
1,308 Views
Registered: ‎02-04-2018

ISE can not fix the hold time violation

Jump to solution

 I implemented a simple logic in the FPGA, but the tools could not fix the hold time violation.

 

The logic is to latch the Rd_Addr with the clock. Both Rd_Addr and clock is from outside fpga. Since the logic is very simple, the data path delay is low, but the clock delay is relatively large. But I wonder why the tools don't add delay into the data path to fix the hold violation.

 

My constrain is as following,

 

NET "clk" TNM_NET = clk;
TIMESPEC TS_sysclk = PERIOD "clk" 20 ns HIGH 10 ns INPUT_JITTER 500 ps;
OFFSET = IN 18 ns VALID 20 ns BEFORE clk;

 

 

The timing report shows as following,

 

Hold Paths: OFFSET = IN 18 ns VALID 20 ns BEFORE COMP "clk";
 --------------------------------------------------------------------------------
 
 Paths for end point Rd_Addr_latch_2 (ILOGIC_X1Y98.D), 1 path
 --------------------------------------------------------------------------------
 Slack (hold path):      -1.455ns (requirement - (clock path + clock arrival + uncertainty - data path))
   Source:               Rd_Addr<6> (PAD)
   Destination:          Rd_Addr_latch_2 (FF)
   Destination Clock:    clk_BUFGP rising at 0.000ns
   Requirement:          2.000ns
   Data Path Delay:      0.547ns (Levels of Logic = 1)(Component delays alone exceeds constraint)
   Clock Path Delay:     3.751ns (Levels of Logic = 2)
   Clock Uncertainty:    0.251ns
 
   Clock Uncertainty:          0.251ns  ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
     Total System Jitter (TSJ):  0.050ns
     Total Input Jitter (TIJ):   0.500ns
     Discrete Jitter (DJ):       0.000ns
     Phase Error (PE):           0.000ns
 
   Minimum Data Path at Slow Process Corner: Rd_Addr<6> to Rd_Addr_latch_2
     Location             Delay type         Delay(ns)  Physical Resource
                                                        Logical Resource(s)
     -------------------------------------------------  -------------------
     L1.I                 Tiopi                 0.688   Rd_Addr<6>
                                                        Rd_Addr<6>
                                                        Rd_Addr_6_IBUF
     ILOGIC_X1Y98.D       net (fanout=1)        0.000   Rd_Addr_6_IBUF
     ILOGIC_X1Y98.CLK     Tiockd      (-Th)     0.141   Rd_Addr_latch<2>
                                                        Rd_Addr_latch_2
     -------------------------------------------------  ---------------------------
     Total                                      0.547ns (0.547ns logic, 0.000ns route)
                                                        (100.0% logic, 0.0% route)
 
   Maximum Clock Path at Slow Process Corner: clk to Rd_Addr_latch_2
     Location             Delay type         Delay(ns)  Physical Resource
                                                        Logical Resource(s)
     -------------------------------------------------  -------------------
     D5.I                 Tiopi                 0.823   clk
                                                        clk
                                                        clk_BUFGP/IBUFG
     BUFGCTRL_X0Y31.I0    net (fanout=1)        1.525   clk_BUFGP/IBUFG
     BUFGCTRL_X0Y31.O     Tbccko_O              0.076   clk_BUFGP/BUFG
                                                        clk_BUFGP/BUFG
     ILOGIC_X1Y98.CLK     net (fanout=58)       1.327   clk_BUFGP
     -------------------------------------------------  ---------------------------
     Total                                      3.751ns (0.899ns logic, 2.852ns route)
                                                        (24.0% logic, 76.0% route)

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
1,783 Views
Registered: ‎01-23-2009

Re: ISE can not fix the hold time violation

Jump to solution

Can I change the constrains like following to make it more reasonable

 

Constraints are used to describe the environment outside the FPGA to the FPGA tool. So it isn't really a matter of using "reasonable" constraints, you must be using "correct" constraints.

 

This input to the FPGA comes from somewhere else in your system - presumably some other device. In order for these two devices (the other device and the FPGA) to talk to communicate properly, you need to tell the FPGA tools about the timing characteristics of this other device - this is the purpose of the OFFSET IN - to tell the tool about the timing characteristics of the input interface. So the "right" numbers for the OFFSET IN come from the datasheet of the device driving the FPGA, modified by your board (routing delays and skews, signal integrity, etc...)

 

How can I indicate the tools to take different clock architecture during synthesis and implementation, or I need modify the RTL code?

 

The clocking architecture is architecture. The designer is responsible for architecting the system, and hence you need to describe your desired clocking architecture in the RTL.

 

You said the data path is fixed at the routing time, but is it possible that the tool redo the placement to increase the delay time during implementation, or pass the data path through some LUT(don't change the logical value) to increase the delay time?

 

If you use the ILOGIC (the IOB flip-flop, or IDDR or ISERDES), then the only legal inputs are directly from the associated pad, either directly or via the IDEALY. If you do need to delay the data, then you can do so by using the IDELAY.

 

You cannot put a LUT in this path, since the ILOGIC input cannot come from the fabric. If the input is single data rate and reasonably slow (so doesn't use the IDDR or ISERDES), you can use a fabric flip-flop for capturing the data. If you do so, the tools can then place the capture flip-flop where it wants to, and can fix some hold time issues by inserting extra routing. However, this is not recommended - delay added by the tool is highly process/voltage/temperature dependent, and fixing a hold time can well mess up your setup time. It is preferable to stick with the IOB flip-flop and use the IDELAY (or a phase shift with your MMCM) instead.

 

Avrum

0 Kudos
3 Replies
Highlighted
Historian
Historian
1,292 Views
Registered: ‎01-23-2009

Re: ISE can not fix the hold time violation

Jump to solution

The basic answer is "because it can't".

 

For the path in question, both the clock and the data path are using fixed and dedicated resources

  - The clock IBUF connects directly to the BUFG using a dedicated rout

  - the BUFG drives the clock network which reaches the C input of the ILOGIC using dedicated routing

  - The data IBUF connects directly to the ILOGIC data input

  - The ILOGIC is fixed in place based on the placement of the IO pin

 

There is nothing in these paths that the tool has any timing control over - they are all fixed routes with fixed timing. All the tool can do is report the timing on this path, and it is telling you that the timing fails.

 

If you want to fix this, you need to architect a clocking system that can meet the timing - the one that you have chosen cannot. Take a look at this post on different architectures for capturing input interfaces. The architecture that you are using is the slowest one possible, and requires huge data hold times to offset the large clock insertion delay of the IBUFG->BUFG->global clock network.

 

But, even before that, lets look at your timing constraints. They are clearly not correct. You have told the tools that the data arrives 18ns before the clock, and remains valid for an entire 20ns period. This implies that the data changes instantaneously 2ns after the clock - all bits change together and at precisely the same moment, regardless of process, voltage, temperature, board routing, etc... This is clearly impossible. So, the tools are telling you that you are violating timing in spite of the fact that your interface is seriously under-constrained. So, yes, it is failing the hold check, but is the hold timing requirement you specified even correct?

 

Avrum

Tags (1)
0 Kudos
Visitor linsheng
Visitor
1,268 Views
Registered: ‎02-04-2018

Re: ISE can not fix the hold time violation

Jump to solution

Hi, Avrumw,

 

Thanks a lot for your reply. But I still have some points not too clear.

 

1. Can I change the constrains like following to make it more reasonable

NET "clk" TNM_NET = clk;
TIMESPEC TS_sysclk = PERIOD "clk" 20 ns HIGH 10 ns INPUT_JITTER 500 ps;
OFFSET = IN 18 ns VALID 19 ns BEFORE clk;

 

2. How can I indicate the tools to take different clock architecture during synthesis and implementation, or I need modify the RTL code? For example, to take the c) Direct Capture with BUFIO (ChipSync) as your post  in different architectures for capturing input interfaces

 

3. You said the data path is fixed at the routing time, but is it possible that the tool redo the placement to increase the delay time during implementation, or pass the data path through some LUT(don't change the logical value) to increase the delay time?

 

Best Regards!

 

Sheng

 

 

0 Kudos
Historian
Historian
1,784 Views
Registered: ‎01-23-2009

Re: ISE can not fix the hold time violation

Jump to solution

Can I change the constrains like following to make it more reasonable

 

Constraints are used to describe the environment outside the FPGA to the FPGA tool. So it isn't really a matter of using "reasonable" constraints, you must be using "correct" constraints.

 

This input to the FPGA comes from somewhere else in your system - presumably some other device. In order for these two devices (the other device and the FPGA) to talk to communicate properly, you need to tell the FPGA tools about the timing characteristics of this other device - this is the purpose of the OFFSET IN - to tell the tool about the timing characteristics of the input interface. So the "right" numbers for the OFFSET IN come from the datasheet of the device driving the FPGA, modified by your board (routing delays and skews, signal integrity, etc...)

 

How can I indicate the tools to take different clock architecture during synthesis and implementation, or I need modify the RTL code?

 

The clocking architecture is architecture. The designer is responsible for architecting the system, and hence you need to describe your desired clocking architecture in the RTL.

 

You said the data path is fixed at the routing time, but is it possible that the tool redo the placement to increase the delay time during implementation, or pass the data path through some LUT(don't change the logical value) to increase the delay time?

 

If you use the ILOGIC (the IOB flip-flop, or IDDR or ISERDES), then the only legal inputs are directly from the associated pad, either directly or via the IDEALY. If you do need to delay the data, then you can do so by using the IDELAY.

 

You cannot put a LUT in this path, since the ILOGIC input cannot come from the fabric. If the input is single data rate and reasonably slow (so doesn't use the IDDR or ISERDES), you can use a fabric flip-flop for capturing the data. If you do so, the tools can then place the capture flip-flop where it wants to, and can fix some hold time issues by inserting extra routing. However, this is not recommended - delay added by the tool is highly process/voltage/temperature dependent, and fixing a hold time can well mess up your setup time. It is preferable to stick with the IOB flip-flop and use the IDELAY (or a phase shift with your MMCM) instead.

 

Avrum

0 Kudos