Best Case Timing Parameters

Hi All,

If any of you folks know how, to calculate the best case timing parameters for a Xilinx FPGA (for eg: Global clock to out -- the pin to pin output parameter ) ?

Googling through the archives , I came across this post from Austin Lesea posted in 2001.

Article: 37740 "We did not tend to specify minimums (although we do now, more and more in the newer parts) because it wasn't supposed to matter. Now that it does, we do provide that information once the process is stable (the part is in manufacturing as a regular product, not ES material)...."

But the device data sheets for a very much in production device like Virtex-II Pro doesn't provide any best case /Min values for the clock to out parameter.

Also ,Another document that gives a lot of info. about approximating the best case timing is the xcell article

formatting link
. But, is this document relevant for the latest Xilinx FPGAs ?

Thanks, Ajay

Reply to
Ajay
Loading thread data ...

I think I wrote that article in XCell. If you follow the reasoning, you will agree that it has to apply to all CMOS manufacturing. It is not even Xilinx-specific. Assuming the best-case (min) delay to be a quarter of the worst case (max) delay still seems to be a conservatively realistic assumption.

My real question is: Why do you care? What are you gambling on? Min delays do not matter in a synchronous design. Peter Alfke, Xilinx Applications

Reply to
Peter Alfke

Sure, they do. You need them to calculate hold margins. Even if the receiving device's hold time is zero (and sometimes it isn't), you need to ensure that clock skew doesn't exceed minimum path delay.

I'm not just trying to be picky here--this is important.

Bob Perlman Cambrian Design Works

Reply to
Bob Perlman

On the same die, probably not, in absolute number terms, but some min delay is necessary.

However, move across die and process, and it can become important if some devices HOLD times have finite post-edge windows.

-jg

Reply to
Jim Granville

Yes, I agree. Inside the chip, we make sure that the delay tolerances on a global clock are less than the min delay clock-to-Q, and we can guarantee that, since delays track inside the chip. Between chips, the min delay is important since the clock delay differences are determined by the pc-board, and the transmitting device may also have nothing in common with the receiving device (neither temperature nor processing, although probably voltage).

That's why source-synchronous design is now popular (sending the clock together with the data) and IDELAY in Virtex-4 gives you the ability to delay clock or data by a precise amount, so that you can achieve near-optimal relative timing. Peter Alfke

Reply to
Peter Alfke

Thank you so much Peter. We are using the 4:1 rule.

Regards, Ajay

Peter Alfke wrote:

Reply to
Ajay

The 4:1 rule is a very good starting point since it covers the range of variability in the most important delay mechanisms within a CMOS process. However, it is important to remember that it is just that, a scaling of the delays related to channel conductance, capacitances, and internal wire propagation. When the delays you are considering consist of these factors, then the 4:1 rule is good.

However, to be REALLY REALLY picky, there are some cases where you have to be careful with the 4:1 rule for I/O timing. Specifically, it is questionable to apply this rule to one of the main delay parameters in the the FPGA datasheet, Tickofdcm.

Tickofdcm (or Tickofdll) is a composite parameter that relates the timing of an output to the arrival of the clock at the FPGA clock input. This path goes through a lot of things (the IBUFG, a DCM/DLL with internal feedback, the GCLK buffer and global clock net, the output flip-flop in the IOB and then the final output driver in the IOB). Many of these are appropriately scaled using the 4:1 rule, but the some aspects of the clock and DLL are not...

The DLL/DCM with internal feedback is, in fact, designed specifically NOT to scale with the 4:1 rule; that is the whole reason that we use one; to cancel out the delay of the clock distribution net (and associated other circuitry), even though that circuitry does scale with process temperature and voltage. If the cancellation of the clock net by the DLL were perfect, then this portion of the path would contribute no delay to Tickofdcm, and hence the 4:1 rule would apply to the whole path. However, this is not the case. The DCM is not perfect, and, in some systems, is intentionally designed to result in a slightly negative total delay. By doing this, Xilinx reduces the required hold time at input FF's in the IOBs, resulting in a negative (or at least very small) required hold time (Tphdcm). However, applying the 4:1 scaling factor to this portion of the delay results in a slightly OPTIMISTIC value.

To be quite paranoid (and I admit, that for most designs this is excessive, since the 4:1 rule is pretty generous, and will cover a little "slop" in the path), you should scale Tickofdcm differently. For the min of this parameter, I would use

Tickofdcm(min) = Tickofdcm(max) - 3/4Tiockp(max)

as a starting point. The values for both of these parameters should already be derated for the appropriate I/O standard being used. Note: this can acutally result in a negative number for certain I/O standards, and is technically correct, due to the negative delay of the DLL/clock tree combination.

Also, Tickofdcm contains some allowance for the phase error and jitter of the DCM. For Tickofdcm(max), these are assumed to be their worst case in the positive direction, for Tickofdcm(min), they need to be accounted for in the negative direction, so for a TOTALLY paranoid application

Tickofdcm(min) = Tickofdcm(max) - 3/4Tiockp(max) - 2xCLKOUT_PER_JITT0 -

2xCLKIN_CLKFB_PHASE

And finally, the system designer must not forget to factor in the clock jitter on the input clock, which adds to Tickofdcm(max), and subtracts from Tickofdcm(min). This can get somewhat tricky, since it is a bit pessimistic to add the external clock jitter directly to the jitter added by the DLL/DCM; these jitters are probabilistic, and hence add probabilistically; truly random jitters add using a root-sum-of-squares calculation.

Avrum

Reply to
Avrum

Using the "-s min" command line option on trce may get you closer to what you're looking for. It uses an "absolute minimum" speed file, if available for that device family, to run the timing analysis.

Russ

Reply to
Russ Panneton

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.