Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

How to determine your critical path from Xilinx Timing Report?

Status
Not open for further replies.

sajjad.hussain

Junior Member level 1
Joined
May 20, 2015
Messages
17
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,477
Dear All,

I have a design which uses a DCM to downscale my main clock to 5 more clocks. When I see the PAR timing report. It shows, different paths, how can I figure out that which path is actually is the critical path?
It also shows that:

Clock to Setup on destination clock clk_in
---------------+---------+---------+---------+---------+
| Src:Rise| Src:Fall| Src:Rise| Src:Fall|
Source Clock |Dest:Rise|Dest:Rise|Dest:Fall|Dest:Fall|
---------------+---------+---------+---------+---------+
clk_in | 25.219| | | |
---------------+---------+---------+---------+---------+


Timing summary:
---------------

Timing errors: 0 Score: 0 (Setup/Max: 0, Hold: 0)

Constraints cover 3490153 paths, 0 nets, and 27939 connections

Design statistics:
Minimum period: 25.219ns{1} (Maximum frequency: 39.653MHz



That is critical path should be corresponding to 25.219ns path, but how to verify this from different paths shown in the timing report?
The timing report is attached herewith.

Regards
 

Attachments

  • dlx_toplevel.twx.txt
    69.2 KB · Views: 87
  • dlx_toplevel_twx.txt
    86.9 KB · Views: 65

In the first file dlx_toplevel.twx.txt look in the file starting at line 760:
Code:
 Timing constraint: TS_Inst_DCM_100_CLKOUT5_BUF = PERIOD TIMEGRP "Inst_DCM_100_CLKOUT5_BUF"         TS_Inst_DCM_100_CLK0_BUF * 0.25 HIGH 50%; 
  3468680 paths analyzed, 11470 endpoints analyzed, 0 failing endpoints 
  0 timing errors detected. (0 setup errors, 0 hold errors, 0 component switching limit errors) 
  Minimum period is  25.219ns. 
 -------------------------------------------------------------------------------- 
  
 Paths for end point Mtridata_datadb_ports<2>_2 (SLICE_X37Y72.CX), 1 path 
 -------------------------------------------------------------------------------- 
 Slack (setup path):     4.711ns (requirement - (data path - clock path skew + uncertainty)) 
   Source:               kcuart_rx_instance/data_loop[2].data_reg (FF) 
   Destination:          Mtridata_datadb_ports<2>_2 (FF) 
   Requirement:          10.000ns 
   Data Path Delay:      8.467ns (Levels of Logic = 0) 
   Clock Path Skew:      3.402ns (5.047 - 1.645) 
   Source Clock:         clk_100 rising at 30.000ns 
   Destination Clock:    clk rising at 40.000ns 
   Clock Uncertainty:    0.224ns 
  
   Clock Uncertainty:          0.224ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE 
     Total System Jitter (TSJ):  0.070ns 
     Discrete Jitter (DJ):       0.195ns 
     Phase Error (PE):           0.120ns 
  
   Maximum Data Path: kcuart_rx_instance/data_loop[2].data_reg to Mtridata_datadb_ports<2>_2 
     Location             Delay type         Delay(ns)  Physical Resource 
                                                        Logical Resource(s) 
     -------------------------------------------------  ------------------- 
     SLICE_X36Y72.BQ      Tcko                  0.471   kcuart_rx_instance/start_bit 
                                                        kcuart_rx_instance/data_loop[2].data_reg 
     SLICE_X37Y72.CX      net (fanout=2)        7.992   data_in<2> 
     SLICE_X37Y72.CLK     Tdick                 0.004   Mtridata_datadb_ports<2><3> 
                                                        Mtridata_datadb_ports<2>_2 
     -------------------------------------------------  --------------------------- 
     Total                                      8.467ns (0.475ns logic, 7.992ns route) 
                                                        (5.6% logic, 94.4% route) 
  
 --------------------------------------------------------------------------------
 

Thanks ads-ee,

But this line only indicates what is the minimum period as also shown in Timing Summary Section:
Minimum period is 25.219ns.

On the following lines from 760 onward there are some Paths, I think this values is coming from these paths somehow (is it true).
Which are the paths that add up to make a critical path with path delay=25.219ns. I m looking for the critical path.
Can you please further help me?
Regards
Sajjad
 

Ah, I get what you are after now...

You want to know what your worst case path is for logic, then don't look at the clk_100 to clk or clk to clk_100 etc cross clock domain paths (unless you've got a lot of logic between the cross clock domain path, you shouldn't...). The cross clock domain path has a strange minimum period because it is a clock crossing path. That 25.219 path is based on the fact that you could still pass timing if the clocks were scaled such that clk has a period of 25.219 instead of 40. You can see the same thing for the path from clk to clk_100, which has a minimum period of 8.607 instead of 10.

Look at the worst case path (least amount of slack path) for a clk to clk or clk_100 to clk_100 or any other same clock to same clock path. That will tell you the worst case critical path.

- - - Updated - - -

You should note that due to the 8.607 minimum period of the clk to clk_100 path you can't actually get down to 25.219 but are limited to 34.428 (4*8.607), there may be other paths that restrict the 8.607 minimum, but I don't have time to go through the entire report. I leave that as an exercise for you :).
 

Dear ads-ee,
Thanks for your time. I have still some confusions. Hope to get more from you.
1.
You mean if there are multiple paths due to different clocks, I have to look for the path with from/to same clock with worst case slack is the critical path. But 8.607ns is also not within same clocks. Its from clk to clk_100. Isn't it?

================================================================================
Timing constraint: TS_Inst_DCM_100_CLKOUT0_BUF = PERIOD TIMEGRP "Inst_DCM_100_CLKOUT0_BUF" TS_Inst_DCM_100_CLK0_BUF HIGH 50%;
21473 paths analyzed, 469 endpoints analyzed, 0 failing endpoints
0 timing errors detected. (0 setup errors, 0 hold errors, 0 component switching limit errors)
Minimum period is 8.607ns.
--------------------------------------------------------------------------------

Paths for end point kcuart_tx_instance/pipeline_serial (SLICE_X26Y69.C6), 13 paths
--------------------------------------------------------------------------------
Slack (setup path): 1.393ns (requirement - (data path - clock path skew + uncertainty))
Source: Mtrien_data_out (FF)
Destination: kcuart_tx_instance/pipeline_serial (FF)
Requirement: 10.000ns
Data Path Delay: 3.316ns (Levels of Logic = 4)
Clock Path Skew: -5.067ns (1.622 - 6.689)
Source Clock: clk rising at 0.000ns
Destination Clock: clk_100 rising at 10.000ns
Clock Uncertainty: 0.224ns



2.
Where this 34.428 (4*8.607) comes from?
3.
Why the Minimum period is 25.219ns in this design? Why not 8.607ns?
4. If we have to run this design in real on FPGA, this 25.219ns will determine the maximum frequency to operate? or it will correspond to 8.607ns?

I have attached the timing constraints screenshot. The first constraint is the actual clock constraint define in ucf file while other constraint auto generating as we are using DCM to scale down this original clock to multiple clocks.
Screenshot from 2017-02-03 19:21:06.png
Please guide. Sorry for being lengthy.
Thanks in anticipation.
 

1.
You mean if there are multiple paths due to different clocks, I have to look for the path with from/to same clock with worst case slack is the critical path. But 8.607ns is also not within same clocks. Its from clk to clk_100. Isn't it?
Yes it is from clk to clk_100.

Now your cross clock domain might be the worst case path but you'll have to analyze all the clock-to-clock paths to determine which is the worst.

2.
Where this 34.428 (4*8.607) comes from?
I deduced it from the timing reports as the edge to edge timing shows launch edge at 30 ns (clk_100) and the capture edge at 40 ns (clk). So the timing diagram of the two clocks must look like this:
Code:
          0       10      20      30      40
           ___     ___     ___     ___     ___ 
clk_100 __|   |___|   |___|   |___|   |___|   |
           ______________                  ___ 
    clk __|               |_______________|
                                  ^       ^
                               launch   capture
                                edge     edge
Therefore if the clk_100 has a minimum period of 8.607 ns then the minimum period of clk would be 4 times that or 4*8.607 (34.428 ns).

Does that make more sense?

3.
Why the Minimum period is 25.219ns in this design? Why not 8.607ns?
I already explained this above, the functional minimum would be 8.607 ns for clk_100 and 34.428 ns for clk, if you want the transfers between the two domains to keep working correctly.

4. If we have to run this design in real on FPGA, this 25.219ns will determine the maximum frequency to operate? or it will correspond to 8.607ns?
Same answer as Q2 &Q3. I think you need to do more studying about calculating setup and hold timing of a register to register path. Look up "How to calculate setup and hold time", you should get a lot of results on google.

I have attached the timing constraints screenshot. The first constraint is the actual clock constraint define in ucf file while other constraint auto generating as we are using DCM to scale down this original clock to multiple clocks.
You don't show any paths to/from the *0.8, *0.6667, *0.5, and *.4. Just be aware that you better have a methodology for handling asynchronous clock domains if you ever use the 0.8, 0.6667, and 0.4 as they will have edges which are less than 10 ns and in the case of the 0.6667 clock there will actually setup time requirements that are extremely close to 0 ns and impossible to meet. From what I've seen from the current STA results you aren't doing any cross clock domain synchronization between the 100 MHz and the 25 MHz (I guessed correctly), which is okay as the rising edges of the slower clock always lines up with a rising edge of the faster clock (integer multiple of the slower clock). This will also be the case with the 0.5 or 50 MHz clock, which you will be able to cross between the three clocks 100 MHz, 50 MHz, and 25 MHz without synchronization. Just make sure you use some clock crossing scheme if you start using any of the other clocks.
 

Dear ads-ee,
Thanks for your time and explanation. I will look into in details.
Regards
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top