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: 
Visitor shartman1
Visitor
19,595 Views
Registered: ‎06-08-2009

multi-corner timing analysis

I'm familiar with timing analysis tools that ensure timing is met at the slow (high temp, low voltage) and fast (low temp, high voltage) operating corners.  It looks like the TRACE timing analyzer only checks timing at the slow corner.  How does Xilinx guarantee a design will function correctly across all operating conditions if timing is only verified at the slow corner?

 

For a simple V5 design, I used the TEMERATURE & VOLTAGE constraints and ran TRACE at both operating corners.  I used location & directed routed constraints to ensure the PAR used indentical routing at both corners.  The setup & hold timing equations from the .twx report are shown below.

 

Slow Corner

setup req             3.000ns

+ clock path        2.209ns

+ clock arrival      0.000ns

- uncertainty        0.025ns

-data path delay   4.175ns

= setup slack     1.009ns

 

hold req               0.500ns

-clk path              3.621ns

-clk arrival            0.000ns 

uncertainty           0.025ns 

+data path delay  3.760ns

= hold slack       0.614ns

 

 

Fast Corner

setup req             3.000ns

+clk path             1.997ns

+clk arrival           0.000ns

- uncertainty         0.025ns

- data path delay  3.772ns

= setup slack      1.200ns

 

hold req               0.500ns

-clk path              3.276ns

-clk arrival            0.000ns 

uncertainty           0.025ns 

+data path delay  3.397ns

= hold slack        0.596ns


The worst case hold time occurs at the fast corner, yet this is not an operating condition that is covered by default with the TRACE timing analyzer.  For this design we have plenty of margin.  But for designs that have little hold margin, how can we guarantee correctness by only verifying timing at the slow corner?  When I perform a similar anaylsis for S6 I get an error message indicating voltage and temperature pro-rating is not supported.  I'm working on a S6 design with ~50ps of hold margin, yet I can only run the TRACE at the slow corner.  How do I guarantee my S6 design will work across all operating conditions?

 

In the timing analysis tools I'm familar with, setup margin with is calculated using the max data delay and the min clock delay seen across all PVT variation, and hold margin will be calculated using the min data delay and the max clock delay seen across all PVT variation.  For the timing equations above, a different delay value is used for setup & hold analysis for a given path and a fixed operating condition.  Is this simply due to process variation?  When determining the effect of process variation, does Xilinx assume it is possible to have the data path and the clock path on a single chip at opposite process corners, or do the timining analysis tools only account for the worst case process variation expected on a single chip?

19 Replies
Scholar austin
Scholar
19,582 Views
Registered: ‎02-27-2008

Re: multi-corner timing analysis

s,


I know as an ASIC designer, it is hard to believe that Xilinx has done all the work, so you do not have to, but that is the case.  After all, if I had to do all this work in the design of the FPGA, why should I ask you do to it again?  That would be foolish, and a waste of your time.


There is no de-rating for PVT in Spartan 6, because it is not needed.  In fact, it is not needed in Virtex 6, nor any other device.  The speeds file method has all the worst case values for PVT, and you do not need to do anything at all.

 

To the extent that the tools appear to "know" about variatons in temperature, and voltage, they really do not (know anything about this).  There are some numbers in there to help engineers see what happens with unsupported temperatures and voltages, but I really do not think anyone should use, or even believe these numbers, and they are not supported (they are outside the recommended operating conditions).  I think these numbers and formulas are left over from earlier times, when we had (from time to time) occasional issues with the speeds file flow that could not be explained, or understood.  Those days (before Virtex 5) are gone, as we now have a much better flow (to guarantee timing).

 

The change in how we specify and guaranatee timing occured during the Virtex 4 technology hode, and has been used exclusively since.

 

We have also accounted for NBTI, and all other known and measured effects, over the 15+ year operating life we guarantee.

 

Bottom Line:  we guarantee the timing, on all parts, with your bistream, within the recommended operting voltages and junction temperatures.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
Visitor shartman1
Visitor
19,578 Views
Registered: ‎06-08-2009

Re: multi-corner timing analysis

Austin,

 

Thanks for the timely response.  I do have 1 follow up question:

 

In my original post the data path delay used for setup analysis was 4.175ns.  For hold analysis on that same exact path, the data delay was 3.760ns.  Does this mean the maximum delay for this path across PVT is 4.175ns and the minimum delay for the path across PVT is 3.760ns? 

 

In ISE 11.5 S6/V6 I see that timing is verified at both fast and slow process corners when using S6/V6.  There is still variation between the data/clock delays used for setup/hold analysis at each corner.  Since we've fixed process to either slow or fast corner, does the variation simply represent the variation due to temperature and voltage?

 

Thanks.

 

-Scott

 

 

0 Kudos
Scholar austin
Scholar
19,575 Views
Registered: ‎02-27-2008

Re: multi-corner timing analysis

Scott,

 

Yes, this represents min and max (which isn't supported on earlier families).


I still say the fast/slow is something I would ignore, completely.  Hopefully if someone from Xilinx says what this fast/slow is used for, we will then both know.


I just know how the part is designed, characterized, and what goes into the speeds file.  And, I can't see any way that the fast/slow is anything other than an (ancient) estimation, unsupported by reality ....

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Xilinx Employee
Xilinx Employee
18,992 Views
Registered: ‎11-06-2007

Re: multi-corner timing analysis

Just to clarify the multi-corner analysis.

 

The Multi-corner timing analysis is analyzing the timing at the slow process corner and the fast process corner. Once the analysis is done in both process corners, the tools then reports the worst analysis. Either process corner can be reported as the worst case analysis.  

 

The analysis accounts for variations in PVT. The old method of using relative mins was seen to be overly pessimistic. This new method matches more closely to the industry standard and offers the same analysis confidence as the relative mins methodology.

 

Each process corner has a maximum measured delay and a minimum measured delay. The fast and slow process corners are analyzed simultaneously and the process corner with the  greatest min/max variance is reported as worst case.

Visitor susanaeiroa
Visitor
17,991 Views
Registered: ‎02-07-2011

Re: multi-corner timing analysis

I need to obtain the values for the fastest and slowest delay possible in Xilinx FPGAs and so i need to obtain the values for fast and slow corners in the timing analysis. Usually trace uses the slow corner model so i would like to know how to obtain the values for the fast corner.

Thank you!

0 Kudos
Xilinx Employee
Xilinx Employee
17,979 Views
Registered: ‎05-14-2008

Re: multi-corner timing analysis

Older Devices - Use relative minimum

---------------------------------------------------

The relative minimum is a factor of the maximum value, which is based on characterization of the device family. The factor can typically be 80% or 85% of maximum.

 

 

New devices - Multicorner Analysis

-----------------------------------------------

The slow process corner is defined as the Slow Process Corner, high temperature, and low voltage, which the traditional worst-case or max over PVT.

 

The fast process corner is defined as the Fast Process Corner, low temperature, and high voltage, which is traditional absolute min or -0 speed grade.

 

Once the analysis is done in both, it then reports the worst analysis. In the majority of cases, the slow process corner will be used as the worst case analysis. But in some case, the fast process corner will be used. 

 

The reason why the timing engine is using the Multi-corner analysis is to improve accuracy of the speed files/specs.

0 Kudos
Scholar austin
Scholar
17,976 Views
Registered: ‎02-27-2008

Re: multi-corner timing analysis

Scott,

 

The max is the max.  The min is either specified separtately in the speeds file (we now have some numbers for min delays where needed), or not at all (they don't matter).

 

Austin

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Xilinx Employee
Xilinx Employee
17,949 Views
Registered: ‎11-06-2007

Re: multi-corner timing analysis

Hello All,

 

It is not possible to report both the slow and fast process corner analysis. The tools only report the worst case corner.

 

Thanks

Enda

0 Kudos
Visitor susanaeiroa
Visitor
17,941 Views
Registered: ‎02-07-2011

Re: multi-corner timing analysis

Does it mean that the tool only uses the slow corner models for both the situations of "high temperature" and "low voltage"  (what should be slow corner) and the situation of "low temperature" and "high voltage" (what should be fast one)? In this case, the fastest possible situation would never be reported, because only the slow models are used, isn't it?

Thank you

Susana

0 Kudos
Scholar austin
Scholar
13,081 Views
Registered: ‎02-27-2008

Re: multi-corner timing analysis

s,

 

We are not here to teach you how to make FPGA devices, and compete with us.


Sorry.  It has been explained that Xilinx has done all the work for you, use the tools, and the timing reports.  Make sure you have no timing violations, and have sufficent slack.  Nothing more.  If this is related to a customer issue, file a web-case.

 

If you are a student, and wish to learn about how to make FPGA devices, apply for an internship...

 



Austin Lesea
Principal Engineer
Xilinx San Jose
Historian
Historian
13,074 Views
Registered: ‎02-25-2008

Re: multi-corner timing analysis

 


@susanaeiroa wrote:

Does it mean that the tool only uses the slow corner models for both the situations of "high temperature" and "low voltage"  (what should be slow corner) and the situation of "low temperature" and "high voltage" (what should be fast one)? In this case, the fastest possible situation would never be reported, because only the slow models are used, isn't it?

Thank you

Susana


 

When doing static timing analysis against constraints, the engineer doesn't usually care about the fastest path, only the slowest paths. The whole point is that you say, "I need to go at 10 ns," and the tools tell you if all paths meet that 10 ns requirement, and if not, which ones failed.

The fact that a path may go at 5 ns is interesting but completely unimportant.

----------------------------Yes, I do this for a living.
0 Kudos
Visitor susanaeiroa
Visitor
13,054 Views
Registered: ‎02-07-2011

Re: multi-corner timing analysis

Hi,

Thank you very much, for the info. Anyway I would like to obtain values for maximum frequency variations of Ring oscillators in FPGA. This is why I needed to obtain the fastest possible case, so in my situation, it matters not only the slowest but also the fastest.

Thanks for the quick answer.

0 Kudos
Historian
Historian
13,043 Views
Registered: ‎02-25-2008

Re: multi-corner timing analysis

 


@susanaeiroa wrote:

Hi,

Thank you very much, for the info. Anyway I would like to obtain values for maximum frequency variations of Ring oscillators in FPGA. This is why I needed to obtain the fastest possible case, so in my situation, it matters not only the slowest but also the fastest.

Thanks for the quick answer.


 

What is it with the obession for implementing ring oscillators in FPGAs?

People really like to live dangerously.

----------------------------Yes, I do this for a living.
0 Kudos
Teacher eteam00
Teacher
13,040 Views
Registered: ‎07-21-2009

Re: multi-corner timing analysis

What is it with the obession for implementing ring oscillators in FPGAs?

People really like to live dangerously.

They are students.  Their minds are being trained to think (hopefully), and they'll not need to worry about which endeavours are useful until they hit the real world.  For now, it doesn't matter.

 

- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
12,714 Views
Registered: ‎09-18-2009

Re: multi-corner timing analysis

Without telling me how to build FPGAs: How do fast/slow corners play into the speed grades?  Does XLNX skew the process for extra timing or is some kind of speed  binning done at test?   Thanks, T

 

Tags (1)
0 Kudos
Scholar austin
Scholar
12,711 Views
Registered: ‎02-27-2008

Re: multi-corner timing analysis

tj,

Parts are binned at test (which is what everyone does, and has done, since the beginning of time -- the first discrete transistors were graded, and then marked).

We would prefer that the process was so well controlled, that every device was exactly the same. Reality is that we get a very nice Gaussian distribution, from slow through to fast. Devices that are too slow can't be sold, and devices that are too fast can't be sold (draw too much power). The speed grades are adjusted to maximize the yield, minimize the loss, which is what is done for any semiconductor device.


Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Visitor spssps
Visitor
9,484 Views
Registered: ‎08-06-2009

Re: multi-corner timing analysis

Hi,

 

I have a related question. It the Timing Analysis is made for 0 to 85 C when using a Spartan6 Commercial device (with ISE 14.2), how can I ensure that the timing is met for a similar industrial grade device for -20 C. Can I generate a compatible bitstream which will work on both C and I device grades?

 

Setting the TEMPERATURE UCF constraint does not have any effect, and selecting I parts does not seem possible using ISE:
Initializing temperature to 85.000 Celsius. (default - Range: 0.000 to 85.000 Celsius)
Initializing voltage to 1.140 Volts. (default - Range: 1.140 to 1.260 Volts)
WARNING:Par:236 - Voltage and/or Temperature prorating constraints have been defined for this design but they are not
   yet supported for this architecture.

 

I understand that C and I parts are basically the same silicon, but basically qualify as faster or slower, but I would expect that a design which may perfectly run between 0 and 85 C, may have timing at other temperature ranges.

 

Thanks in advance

0 Kudos
Xilinx Employee
Xilinx Employee
9,477 Views
Registered: ‎02-16-2014

Re: multi-corner timing analysis

Hi,

 

The TEMPERATURE constraint is not applicable for 6-series and later devices.

The basic static timing analysis will cover the whole range of operating temperatures and utilitze the worst-case scenario for setup, hold, and component switching limit checks.

 

 

0 Kudos
Moderator
Moderator
9,473 Views
Registered: ‎01-16-2013

Re: multi-corner timing analysis

0 Kudos