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: 
Explorer
Explorer
2,788 Views
Registered: ‎03-06-2014

Standard path delay vs. critical path delay

Jump to solution

Dear all,

 

I have a question that I would sincerely appreciate if someone can provide me a good and resonable definition of that.

 

We know that we can extract the critical paths in any FPGA design.

 

My question is that: "What is the difference between "Standard Path Delays" and "Critical Path Delays" in an FPGA design??

 

 

Kind replies and help are in advance appreciated.

 

Regards,

 

0 Kudos
1 Solution

Accepted Solutions
Adventurer
Adventurer
2,001 Views
Registered: ‎08-30-2018

Re: Standard path delay vs. critical path delay

Jump to solution

Hi @msdarvishi,

 

According to the Xilinx timing closure manual and my own experience by digging into the timing report of the Vivado or even the former tool, i.e., ISE, there is No definition for the standards path delay. But as I gues from your text, probably you want to find a correlation between the critical path delay which are reported by timing summary to those "Net Delays" of the nets that are contributing in routing. If so, just simply extract the net delay of a "routed" net and compare its value with any critical delay value in the timing summary list that you like.

 

Hint : You can extract a net delay of a routed net by typing this command in the Tcl Console:

 

get_net_delays -of_objects [get _nets {netname}]

Look here on page 394 for more information.

 

3 Replies
Explorer
Explorer
2,754 Views
Registered: ‎03-06-2014

Re: Standard path delay vs. critical path delay

Jump to solution
Is there any reply on this post??
0 Kudos
Highlighted
Historian
Historian
2,747 Views
Registered: ‎01-23-2009

Re: Standard path delay vs. critical path delay

Jump to solution

There is not really such a thing as a "standard delay path".

 

A critical path is the static timing path that comes closes to failing its requirement (or that fails it by the most). In timing closure we need to focus on reducing the timing on the critical path. When we do so, another path will become the next critical path, and so on.

 

Timing is closed when the critical path is no longer a failure (has at least 0 slack).

 

The term is also used in a larger sense in an architecture - you can refer to the longest (most timing intensive) set of steps that must be done in sequence in order to implement the needed functionality. This is the critical path of the architecture. In this case we are often talking about multiple clock cycles; i.e. the critical path of this design takes 10 clocks to complete its function. This becomes particularly important when there is feedback between iterations of the design (where it now is a critical loop); a critical loop places an upper bound on the performance of a system, often regardless of how it is pipelined or replicated.

 

Avrum

Tags (1)
0 Kudos
Adventurer
Adventurer
2,002 Views
Registered: ‎08-30-2018

Re: Standard path delay vs. critical path delay

Jump to solution

Hi @msdarvishi,

 

According to the Xilinx timing closure manual and my own experience by digging into the timing report of the Vivado or even the former tool, i.e., ISE, there is No definition for the standards path delay. But as I gues from your text, probably you want to find a correlation between the critical path delay which are reported by timing summary to those "Net Delays" of the nets that are contributing in routing. If so, just simply extract the net delay of a "routed" net and compare its value with any critical delay value in the timing summary list that you like.

 

Hint : You can extract a net delay of a routed net by typing this command in the Tcl Console:

 

get_net_delays -of_objects [get _nets {netname}]

Look here on page 394 for more information.