cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cleber
Visitor
Visitor
8,564 Views
Registered: ‎05-30-2011

Virtex 6 hold time violations

Hello,

I have a problem with hold time violations. It is a middle sized design for a xc6vlx240t-2 and uses about 40% of the FPGA.

When i build the design for speedgrade 3 everything is fine, but for speedgrade 2 i get the hold violations because the clock skew is bigger than the data delay and somehow the router fails to solve this.

Tool version: ISE 12.4

Example:

 

 Hold Paths: Default period analysis for net "d_clk" 
  
 -------------------------------------------------------------------------------- 
  
 Paths for end point i2c_wrapper_I/si570_configurator_I/Mram_MEM1 (RAMB36_X3Y43.ADDRARDADDRL7), 1 path 
 -------------------------------------------------------------------------------- 
 Slack (hold path):      -0.012ns (requirement - (clock path skew + uncertainty - data path)) 
   Source:               i2c_wrapper_I/si570_configurator_I/mem_read_addr_2 (FF) 
   Destination:          i2c_wrapper_I/si570_configurator_I/Mram_MEM1 (RAM) 
   Requirement:          0.000ns 
   Data Path Delay:      0.125ns (Levels of Logic = 0) 
   Clock Path Skew:      0.137ns (0.591 - 0.454) 
   Source Clock:         d_clk rising 
   Destination Clock:    d_clk rising 
   Clock Uncertainty:    0.000ns 
  
   Minimum Data Path at Fast Process Corner: i2c_wrapper_I/si570_configurator_I/mem_read_addr_2 to i2c_wrapper_I/si570_configurator_I/Mram_MEM1 
     Location                   Delay type         Delay(ns)  Physical Resource 
                                                              Logical Resource(s) 
     -------------------------------------------------------  ------------------- 
     SLICE_X52Y218.CQ           Tcko                  0.115   i2c_wrapper_I/si570_configurator_I/mem_read_addr<3> 
                                                              i2c_wrapper_I/si570_configurator_I/mem_read_addr_2 
     RAMB36_X3Y43.ADDRARDADDRL7 net (fanout=7)        0.203   i2c_wrapper_I/si570_configurator_I/mem_read_addr<2> 
     RAMB36_X3Y43.CLKARDCLKL    Trckc_ADDRA (-Th)     0.193   i2c_wrapper_I/si570_configurator_I/Mram_MEM1 
                                                              i2c_wrapper_I/si570_configurator_I/Mram_MEM1 
     -------------------------------------------------------  --------------------------- 
     Total                                            0.125ns (-0.078ns logic, 0.203ns route) 
                                                              (-62.4% logic, 162.4% route) 
  

 

The very same code is used in another design that fills up the FPGA(speedgrade 2) to 90%, this design has it's problem to meet the setup time, but no problem with hold times.

 

The constrain for the clock is:

NET "i2c_wrapper_I/clk_20" TNM = "CLK20";
TIMESPEC TS_CLK20 = PERIOD "CLK20" 20 MHz HIGH 50 %;

 

And according to the clock report it is using the BUFGCTRL_X0Y29.

 

In theory i could of course set manual constrains to increase the data delay or insert some logic (though that would not work in the xaui code from xilinx), but i'm sure that there would be always another path with a hold violation.

 

I also tried things like making the PBLOCKs of the modules very small or big, but that not really change the situation.

 

So does somebody know the magic switch/constrain to get the router to fix hold time violations?

(export RT_FORCE_HOLD_ROUTER=1 does not help)

 

Regards

Christian Leber

 


 Hold Paths: Default period analysis for net "d_clk"
 
 --------------------------------------------------------------------------------
 
 Paths for end point i2c_wrapper_I/si570_configurator_I/Mram_MEM1 (RAMB36_X3Y43.ADDRARDADDRL7), 1 path
 --------------------------------------------------------------------------------
 Slack (hold path):      -0.012ns (requirement - (clock path skew + uncertainty - data path))
   Source:               i2c_wrapper_I/si570_configurator_I/mem_read_addr_2 (FF)
   Destination:          i2c_wrapper_I/si570_configurator_I/Mram_MEM1 (RAM)
   Requirement:          0.000ns
   Data Path Delay:      0.125ns (Levels of Logic = 0)
   Clock Path Skew:      0.137ns (0.591 - 0.454)
   Source Clock:         d_clk rising
   Destination Clock:    d_clk rising
   Clock Uncertainty:    0.000ns
 
   Minimum Data Path at Fast Process Corner: i2c_wrapper_I/si570_configurator_I/mem_read_addr_2 to i2c_wrapper_I/si570_configurator_I/Mram_MEM1
     Location                   Delay type         Delay(ns)  Physical Resource
                                                              Logical Resource(s)
     -------------------------------------------------------  -------------------
     SLICE_X52Y218.CQ           Tcko                  0.115   i2c_wrapper_I/si570_configurator_I/mem_read_addr<3>
                                                              i2c_wrapper_I/si570_configurator_I/mem_read_addr_2
     RAMB36_X3Y43.ADDRARDADDRL7 net (fanout=7)        0.203   i2c_wrapper_I/si570_configurator_I/mem_read_addr<2>
     RAMB36_X3Y43.CLKARDCLKL    Trckc_ADDRA (-Th)     0.193   i2c_wrapper_I/si570_configurator_I/Mram_MEM1
                                                              i2c_wrapper_I/si570_configurator_I/Mram_MEM1
     -------------------------------------------------------  ---------------------------
     Total                                            0.125ns (-0.078ns logic, 0.203ns route)
                                                              (-62.4% logic, 162.4% route)
 
0 Kudos
7 Replies
paullee3
Xilinx Employee
Xilinx Employee
8,548 Views
Registered: ‎08-12-2008

That seema to be a hold violation on Unconstrained paths, please take a look at AR31881, http://www.xilinx.com/support/answers/31881.htm, to get them constrained, please apply FROM:TO TIG or FROM:TO DATAPATHONLY on the path
0 Kudos
cleber
Visitor
Visitor
8,528 Views
Registered: ‎05-30-2011

No, unfortunatelly it is no a unconstrained path, today i wondered about the different naming of my constraint and the clock name in the timing report (they are actually one clock net), so i also set a constrain for d_clk, just to be sure, this changed nothing, of course.

I also let the trce run with the -u parameter so that it searches for unconstraint paths, but there were none of them in the report.

 

AR #31881 is also not helpfull, because in this path there is no clock domain crossing, when i set a TIG the warning will go away, but the hold violation will still exist. (most likely it will never cause a problem, but i want to be sure)

 

 

0 Kudos
rcingham
Teacher
Teacher
8,519 Views
Registered: ‎09-09-2010

A suggestion from the "Clutching at Straws" department:
In the Mapper Process Properties, change the Starting Placer Cost Table property value to something other than 1.
Doing that has sorted minor Timing Failures on more than 1 design here!

------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos
cleber
Visitor
Visitor
8,511 Views
Registered: ‎05-30-2011

Thanks for the suggestion, I had different builds running,  the result of cost table 7 and extra cost table 2 (randomly choosen) was again edatastic:

FATAL_ERROR:Map:Port_Main.h:159:1.27.394.1 - This application has discovered an exceptional condition from which it
   cannot recover.  Process will terminate. For technical support on this issue, please open a WebCase with this project
   attached at http://www.xilinx.com/support.

 

I also had complete map runs with other parameters, but unfortunatelly the cost table parameters did not help against the hold violations.

 

Sunday i also let the "smartexplorer" run and the hold time violations were stable (not always exactly the same path, but very simular, e.g. different adddress bits connected to a ramblock were affected).

 

0 Kudos
Anonymous
Not applicable
8,468 Views

I suggest you may run enough SmartXplorer strategies and run enough cost tables (0~15). Have a try.

0 Kudos
cleber
Visitor
Visitor
8,459 Views
Registered: ‎05-30-2011

Of course i tried this.

By code changes and timing optimizations in other parts, mainly due to better placement, the hold time violations were reduced, ATM i'm only seeing them in the async fifos generated with the xilinx fifo generator, this is the worst one:

 

 Hold Paths: TS_ht_16_cave_htax_top_I_ht_link_I_ht_link_wrapper_I_clk200_1 = PERIOD TIMEGRP         "ht_16_cave_htax_top_I_ht_link_I_ht_link_wrapper_I_clk200_1"         TS_HTX_REFCLK * 1.5 HIGH 50%; 
 -------------------------------------------------------------------------------- 
  
 Paths for end point ht_16_cave_htax_top_I/ht_link_I/ht_queue_wrapper_I/np_cntl_fifo_in_I/ht_queue_fifo_96x5/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_asreg_1 (SLICE_X35Y4.BX), 1 path 
 -------------------------------------------------------------------------------- 
 Slack (hold path):      -1.502ns (requirement - (clock path skew + uncertainty - data path)) 
   Source:               ht_16_cave_htax_top_I/ht_link_I/ht_queue_wrapper_I/np_cntl_fifo_in_I/ht_queue_fifo_96x5/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_1 (FF) 
   Destination:          ht_16_cave_htax_top_I/ht_link_I/ht_queue_wrapper_I/np_cntl_fifo_in_I/ht_queue_fifo_96x5/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_asreg_1 (FF) 
   Requirement:          1.666ns 
   Data Path Delay:      0.283ns (Levels of Logic = 0) 
   Positive Clock Path Skew: 3.305ns (4.864 - 1.559) 
   Source Clock:         ht_refclk rising at 5.000ns 
   Destination Clock:    ht_16_cave_htax_top_I/ht_link_I/ref_clk rising at 6.666ns 
   Clock Uncertainty:    0.146ns 
  
   Clock Uncertainty:          0.146ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE 
     Total System Jitter (TSJ):  0.070ns 
     Discrete Jitter (DJ):       0.105ns 
     Phase Error (PE):           0.082ns 
  
   Minimum Data Path at Slow Process Corner: ht_16_cave_htax_top_I/ht_link_I/ht_queue_wrapper_I/np_cntl_fifo_in_I/ht_queue_fifo_96x5/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_1 to ht_16_cave_htax_top_I/ht_link_I/ht_queue_wrapper_I/np_cntl_fifo_in_I/ht_queue_fifo_96x5/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_asreg_1 
     Location             Delay type         Delay(ns)  Physical Resource 
                                                        Logical Resource(s) 
     -------------------------------------------------  ------------------- 
     SLICE_X37Y4.BQ       Tcko                  0.228   ht_16_cave_htax_top_I/ht_link_I/ht_queue_wrapper_I/np_cntl_fifo_in_I/ht_queue_fifo_96x5/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc<3> 
                                                        ht_16_cave_htax_top_I/ht_link_I/ht_queue_wrapper_I/np_cntl_fifo_in_I/ht_queue_fifo_96x5/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_1 
     SLICE_X35Y4.BX       net (fanout=1)        0.176   ht_16_cave_htax_top_I/ht_link_I/ht_queue_wrapper_I/np_cntl_fifo_in_I/ht_queue_fifo_96x5/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc<1> 
     SLICE_X35Y4.CLK      Tckdi       (-Th)     0.121   ht_16_cave_htax_top_I/ht_link_I/ht_queue_wrapper_I/np_cntl_fifo_in_I/ht_queue_fifo_96x5/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_asreg<3> 
                                                        ht_16_cave_htax_top_I/ht_link_I/ht_queue_wrapper_I/np_cntl_fifo_in_I/ht_queue_fifo_96x5/BU2/U0/grf.rf/gcx.clkx/rd_pntr_gc_asreg_1 
     -------------------------------------------------  --------------------------- 
     Total                                      0.283ns (0.107ns logic, 0.176ns route) 
                                                        (37.8% logic, 62.2% route) 
 -------------------------------------------------------------------------------- 

Is it necessary to constrain this paths too?

In another design with exactly the same source for the hypertransport core hold time violations are a complete non issue and i get them every time, no matter in how many runs i let "smart"explorer do.

0 Kudos
scb_macb
Contributor
Contributor
8,255 Views
Registered: ‎09-02-2008

cleber,  I noticed that the most recent hold time error you posted was due to logic crossing clock domains (different source and destination clocks).

 

I just solved hold time violations in my current design (same source & dest clocks) by using different cost table settings.  I ran 4 different implementations with cost table set from 2-5.  Hold time issues were corrected in two of the builds.  Another build couldn't even finish routing (unroutes). 

 

Thanks for the succestion, rcingham.

0 Kudos