[Methodology] - How to solve setup timing errors ?

[nicoxp31]

Hello,

I need some help concerning some setup timing violations occuring in my design with a negative clock skew. my hardware is xilinx virtex-5 and i am using xilinx ise tool (TRACE) to get timing analysis.

I would like to know what is the general methodology (any advices) when this kind of issues occurs..

Here below is one of the timinng violation extracted from the timing report:

================================================================================
Timing constraint: TS_HT_CLK_DCM50_CLKFX_BUF_0 = PERIOD TIMEGRP
"HT_CLK_DCM50_CLKFX_BUF_0" TS_sys_clk_in / 0.5 HIGH 50%;

32500984 items analyzed, 3 timing errors detected. (3 setup errors, 0 hold errors)
Minimum period is 20.606ns.
--------------------------------------------------------------------------------
Slack: -0.303ns (requirement - (data path - clock path skew + uncertainty))
Source: u_digi/u_async/u_ht80c51/i_oci_VAR_reg__3_m0/r_e_g11_1 (FF)
Destination: u_digi/u_async/u_ht80c51/i_core_c6817_s_0_qn_m0/r_e_g31 (FF)
Requirement: 10.000ns
Data Path Delay: 9.969ns (Levels of Logic = 10)
Clock Path Skew: -0.172ns
Source Clock: ht_clk falling at 10.000ns
Destination Clock: ht_clk rising at 20.000ns
Clock Uncertainty: 0.162ns

Clock Uncertainty: 0.162ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE
Total System Jitter (TSJ): 0.070ns
Total Input Jitter (TIJ): 0.000ns
Discrete Jitter (DJ): 0.253ns
Phase Error (PE): 0.000ns

Maximum Data Path: u_digi/u_async/u_ht80c51/i_oci_VAR_reg__3_m0/r_e_g11_1 to u_digi/u_async/u_ht80c51/i_core_c6817_s_0_qn_m0/r_e_g31
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
SLICE_X25Y17.BQ Tcko 0.445 u_digi/u_async/u_ht80c51/oci_oci_exec_2[2]
u_digi/u_async/u_ht80c51/i_oci_VAR_reg__3_m0/r_e_g11_1
SLICE_X25Y15.A2 net (fanout=19) 1.696 u_digi/u_async/u_ht80c51/oci_oci_exec_1[2]
SLICE_X25Y15.A Tilo 0.094 u_digi/u_async/u_ht80c51/i_oci_c9732_s_0_xnk
u_digi/u_async/u_ht80c51/un1_oci_oci_exec_13_6
SLICE_X31Y16.C2 net (fanout=12) 1.525 u_digi/u_async/u_ht80c51/n_39703553_6
SLICE_X31Y16.C Tilo 0.094 u_so_translator/so_nxp_translator_c/mb_opb_M_DBus<3>
u_digi/u_async/u_ht80c51/un1_oci_oci_exec_34
SLICE_X31Y16.A3 net (fanout=5) 1.018 u_digi/u_async/u_ht80c51/un1_oci_oci_exec_34_i
SLICE_X31Y16.A Tilo 0.094 u_so_translator/so_nxp_translator_c/mb_opb_M_DBus<3>
u_digi/u_async/u_ht80c51/un1_i_core_binary_or_560_0/1.4
SLICE_X30Y19.B6 net (fanout=1) 0.446 u_digi/u_async/u_ht80c51/un1_i_core_binary_or_560_0/1.4
SLICE_X30Y19.B Tilo 0.094 u_so_translator/so_nxp_translator_c/microblaze_0/microblaze_0/Use_Debug_Logic.Debug_I1/New_Instr_Reg_TCK<19>
u_digi/u_async/u_ht80c51/un1_i_core_binary_or_560_0
SLICE_X33Y24.D6 net (fanout=5) 0.512 u_digi/u_async/u_ht80c51/un1_i_core_binary_or_560_0_i
SLICE_X33Y24.D Tilo 0.094 u_so_translator/so_nxp_translator_c/debug_module/debug_module/MDM_Core_I1/data<17>
u_digi/u_async/u_ht80c51/un1_i_core_binary_or_560_0_1
SLICE_X33Y24.C5 net (fanout=5) 0.539 u_digi/u_async/u_ht80c51/un1_i_core_binary_or_560_0_1_i
SLICE_X33Y24.C Tilo 0.094 u_so_translator/so_nxp_translator_c/debug_module/debug_module/MDM_Core_I1/data<17>
u_digi/u_async/u_ht80c51/un1_n_11925181_9_1
SLICE_X35Y30.D1 net (fanout=13) 1.260 u_digi/u_async/u_ht80c51/un1_n_11925181_9_1
SLICE_X35Y30.D Tilo 0.094 u_so_translator/so_nxp_translator_c/debug_module/debug_module/MDM_Core_I1/JTAG_CONTROL_I/tdo_reg<6>
u_digi/u_async/u_ht80c51/un1_i_core_call_handle_call_ret_R_15_1
SLICE_X35Y30.C6 net (fanout=1) 0.139 u_digi/u_async/u_ht80c51/un1_i_core_call_handle_call_ret_R_15_1
SLICE_X35Y30.C Tilo 0.094 u_so_translator/so_nxp_translator_c/debug_module/debug_module/MDM_Core_I1/JTAG_CONTROL_I/tdo_reg<6>
u_digi/u_async/u_ht80c51/un1_i_core_call_handle_call_ret_R_15
SLICE_X30Y34.B3 net (fanout=1) 0.774 u_digi/u_async/u_ht80c51/un1_i_core_call_handle_call_ret_R_15_0
SLICE_X30Y34.B Tilo 0.094 u_digi/u_async/u_ht80c51/un1_ixdata_rdata_i_5_0_0[0]
u_digi/u_async/u_ht80c51/un1_n_59718895_2
SLICE_X27Y34.A6 net (fanout=6) 0.743 u_digi/u_async/u_ht80c51/un1_n_59718895_2_i
SLICE_X27Y34.CLK Tas 0.026 u_digi/u_async/u_ht80c51/n_3436352_1
u_digi/u_async/u_ht80c51/un1_n_38923475_4
u_digi/u_async/u_ht80c51/i_core_c6817_s_0_qn_m0/r_e_g31
------------------------------------------------- ---------------------------
Total 9.969ns (1.317ns logic, 8.652ns route)
(13.2% logic, 86.8% route)

Thanks for any help.

- Jerome

 

[echo47]

These are the important lines:
Source: u_digi/u_async/u_ht80c51/i_oci_VAR_reg__3_m0/r_e_g11_1 (FF)
Destination: u_digi/u_async/u_ht80c51/i_core_c6817_s_0_qn_m0/r_e_g31 (FF)
Requirement: 10.000ns
Data Path Delay: 9.969ns (Levels of Logic = 10)

You have 10ns available, but the ten levels of combinatorial logic between those two flops are causing almost 10ns of delay. Plus a few more picoseconds due to the imperfect clock, and your timing budget is exceeded, slightly.

Examine the design to see why it has so many levels of logic. If the design allows it, consider adding pipelining to reduce the number of logic levels. That would make a tremendous improvement in speed.

Search your ISE "Development System Reference Guide" for the words "closure", "effort", and "strategy", and you'll find various options for improving optimization. A good one to try first is "timing driven packing".

Also read the "Design Considerations" chapter in your "Synthesis and Simulation Design Guide". It describes various helpful techniques.

 

[nicoxp31]

Hi,

thks for yr answer.
I tried different options during mapping and PAR. I noticed that the following options improved quiet a lot my design timing report:

-timing
-xe n

However i have still some timing errors but less than before...

If you have some others ideas about how to improve it, let me know..

Regards,
Jerome

 

[echo47]

How close are you to meeting your timing goals?

The "-timing" option enables timing driven packing. The "-xe n" requests extra effort. Good ones to try.
If you have lots of spare computer time, maybe try PAR's "-n" option too, but don't expect miracles.

I see "80c51" in the module name. Is that your own microcontroller design, or is it an IP core? Many IP cores are poorly written and slow. Does its documentation say how fast is should run in a Virtex-5?

You might try applying area constraints or some other floorplanning/partitioning scheme to confine the various sections of your overall design into rectangular areas of the FPGA. That sometimes gives a significant speed improvement, by keeping the routes relatively short within each section.

 

[nicoxp31]

Yeah this is an IP core, so no pipeline is allowed this time. however, when we take a look to the data path given above, the clock signal is going out from 80c51 and going into one of my external module, so on and so forth ...

So a first idea should be to put these 2 modules closer at each other but i don't know how to specify this via the PAR command..

Otherwise you advised to apply flooplanning/area constraints...Which PAR options did you think about ?

Tks again,
Jerome

 

[echo47]

I normally use the LOC constraint to confine an HDL module's slices, rams, and other stuff to a rectangular region. For example:
INST "foo" LOC = "RAMB16_X0Y0:RAMB16_X2Y0, DSP48A_X0Y0SP48A_X2Y0, SLICE_X0Y0:SLICE_X69Y7;

To learn the coordinate system for your particular FPGA, open your routed chip in FPGA Editor and study the layout. FPGA Editor is also a good tool for examining the routing quality.

ISE includes a floorplanner utility, but I've never used it. You can run it from Project Navigator between various build phases: Tranlate, Map, or Place & Route. Or you can launch it directly from your operating system with the Floorplanner icon, or simply type "floorplanner" from the command line. It has built-in HTML help (what madman dreamed up that idea?).