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!

AR# 25128

11.1 Release Note - Timing Analyzer- Why are my Timing Analyzer Results better than the Data Sheet numbers?

Description

When I view my timing results with Timing Analyzer, they are better than those in the Data Sheet specs. Why is this?

Solution

The numbers listed in Timing Analyzer are a much more accurate representation of your system; the Data Sheet specification is a worst case estimate to indicate whether a design will work. The number reported in Timing Analyzer is an accurate representation of your system. The given application that you are working with is better compensated in this instance by a System Synchronous setting. Only the worst case numbers can be represented in the Data sheet and the actual case only in Timing Analyzer.

The numbers listed in the actual Data Sheet are numbers that are measured on the device and are guaranteed for all designs that use the same conditions (see below). Two types of setup/hold times are listed. The first is Tpsdcm/Tphdcm or Tpsdll/Tphdll. These are setup/hold times for designs that use a DCM or DLL. The second type is Tpsfd/Tphfd. These are for designs that use global clock resources, but do not use a DCM or DLL. Each of these parameters have some specific conditions:

Global Clock Setup and Hold with DCM:

- The numbers listed are using the default I/O Standard (that is, LVTTL 12 mA FAST for Virtex-II devices).

- The input FF is in the IOB and is not using the IOB delay element. (This might vary depending on the device family. Check the Data Sheet to verify exact conditions.)

- The clock is coming in on a GCLK IOB and has an ideal IBUFG->DCM and DCM->BUFG connection. This means that the IBUFG and DCM or DCM and BUFG cannot be on opposite sides of the device (that is, GCLKIOB on the bottom of the device goes to DCM on the top of the device).

- Setup time is measured relative to the Global Clock input signal with the fastest route and the lightest load. Hold time is measured relative to the Global Clock input signal with the slowest route and heaviest load. This means that the setup/hold reported here should be more "worst case" than what is reported by static Timing.

Global Clock Setup and Hold without DCM:

- The numbers listed are using the default I/O Standard (that is, LVTTL 12mA FAST for Virtex-II devices).

- The input FF is in the IOB, and is using the IOB delay element. (This might vary depending on device family. Check the Data Sheet to verify exact conditions.)

- The clock is coming in on a GCLK IOB, and has an ideal IBUFG->BUFG connection. This means that the IBUFG and BUFG cannot be on opposite sides of the device (that is, GCLKIOB on the bottom of the device goes to BUFG on the top of the device).

- Setup time is measured relative to the Global Clock input signal with the fastest route and the lightest load. Hold time is measured relative to the Global Clock input signal with the slowest route and heaviest load. This means that the setup/hold reported here should be more "worst case" than what is reported by static Timing.

The numbers listed in the "Data Sheet Section" of the timing report are design-specific and calculated based on several measured values (Tiopi, Tiopick, Tgio, net delay, Tdcmino, etc.). The numbers are more accurate to the specific design. Both numbers are correct, but for the following reasons you might see a discrepancy between the Data Sheet and the "Data Sheet Section" of the report:

- The IOSTANDARD for the Data and/or Clock is not the default (that is, LVTTL 12 mA fast for Virtex-II). In this case, you will have to adjust the number in the Data Sheet using the I/O Adjustment tables.

- The implementation tools did not do an ideal job on the automatic clock placement (that is, GCLKIOB and DCM are on opposite sides of the device).

- The input FF is not in the IOB.

- The input FF is in the IOB, but uses or does not use the Delay element when it is supposed to.

- Either all or part of the clock does not use global routing (that is, if you gate the clock or use local clocking, the numbers will change).

In any case, the easiest way to check all of these conditions is to use FPGA Editor. Even in ideal conditions, or with all adjustments made, you will never get a direct correlation between the Data Sheet and the "Data Sheet Section" because the Data Sheet is more "worst case." The Data Sheet numbers can be used to estimate your I/O Timing before the design process, but the static timing "Data Sheet Report" should be used to get the actual I/O timing of a completed design. Also, the setup/hold times reported in the "Data Sheet Section" can be hand-calculated using the numbers reported by the OFFSET/IN constraints in the verbose section of the timing report.

Timing Analyzer does include the IOSTANDARD during the analysis of a design. The delays associated with the PAD will change based upon the IOSTANDARD that is used in the design for both Data and Clock pads. Timing Analysis automatically adjusts the delays through the Pads based upon the IOSTANDARD that is used.

AR# 25128
Date Created 09/04/2007
Last Updated 12/15/2012
Status Active
Type General Article