what's the meaning of the different paths under A single timing delay name noted in speedprint ?

[james_zhu]

  The speed file , getted by using the command "speedprint xc7z010iclg400-1L" ,note that:

"

A single timing delay name may be used for different paths, and can have
different values. In the case where a timing delay name has more than
one set of values, speedprint will report two sets of max and min values
representing the slowest path information and the fastest path information
as such:

Timing Delay Name (fmin/fmax, fmin/fmax) (smin/smax, smin/smax)

"

such as the delay Trckd_DIA  in RAMB18E1 , we get a set of delay data (155/155, 296/296)  (405/405, 667/667);

Confused by  different paths , I found some light in ds187(P46),the same delay name Trckd_DI was suffixed by words indicating different configuration like Trckd_DI_RF(read first); Does that mean different paths born of  different configuration ? And what's the configuration corresponding to the slowest path  and the fastest path?

 THANKS!!

[hongh]

You can refer to AR 54196 and UG612（Multi-Corner, Multi-Node Timing Analysis）
https://www.xilinx.com/support/answers/54196.html

[james_zhu]

Thank U for your reply/

however , I have already read that AR befor this message. Which is a copy of the previous section of speed file,I want to known what configuration lead to the slowest path and the same as the fastest path/

Thank U !!

[avrumw · Accepted solution]

This is really more a question about how static timing analysis works.

To do a timing check the tools must be "as pessimistic as is realistically possible". To do this, it needs to ascribe delays to cells differently based on what part of the analysis it is doing...

For a setup check, we need to make sure that [EDIT: corrected forumula]

• source clock delay (max) + datapath delay (max) <= period + destination clock delay (min) - clock uncertainty

If we use anything other than the max for the source clock delay or datapath delay, then these are not the most pessimistic. Similarly if we use anything other than the min for the destination clock delay, we are not being the most pessimistic. So, at any given process/voltage/temperature (PVT) corner (usually just called process corner, even though it is PVT) we need two numbers - the min and the max.

So what do these represent. Lets look at the slow process corner. At this corner the "max" is truly the slowest a cell can be at any combination of PVT - this is referred to as the [SLOW_MAX] corner.

Now lets look at the min at this process corner - [SLOW_MIN]. This represents the fastest possible delay through the cell that can exist on a die that has at least one cell at [SLOW_MAX]. This is "on chip variation" - the variation that can occur from cell to cell on the same chip.

In Vivado, setup checks are done are both process corners. So in addition to the SLOW_MAX and SLOW_MIN numbers, a second check is done at FAST_MAX and FAST_MIN. FAST_MIN is the true fastest delay that can exist at any combination of PVT. FAST_MAX is the slowest delay that can occur on a cell that is on a die with at least one FAST_MIN cell on it.

For completeness, the hold time checks are done the other way

• source_clock_delay (min) + data path_delay (min) >= destination_clock_delay (max) + clock uncertainty
  • (if not using the same clock for source and destination - it gets complicated...)

Likewise this check is done at both process corners, using SLOW_MAX and SLOW_MIN for the slow process corner check and FAST_MAX and FAST_MIN for the fast process corner.

These formulae are a bit simplified - the "period" in the first formula is really "requirement", which is "period" in a simple one clock path, but is far more complex in a path that involves different clocks). Furthermore, the hold check is really

• source_clock_delay (min) + data path_delay (min) >= requirement + destination_clock_delay (max) + clock uncertainty

where requirement is 0 in a simple one clock path...

Avrum

[george_mrch]

@avrumw 

I just now came across your brilliant post! I think there is a small error here, which can be misleading:

source clock delay (max) + datapath delay (max) >= period + destination clock delay (min) - clock uncertainty

Perhaps what you mean is:

source clock delay (max) + datapath delay (max) <= period + destination clock delay (min) - clock uncertainty

That's how it all makes sense.

Sorry for my ridiculous correction, I think it was probably obvious to most forum members. Thank you!

[avrumw]

I think there is a small error here, which can be misleading:

Thanks! I corrected the error.

Avrum