cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to Read a Data Sheet, Part II

austin
Scholar
Scholar
0 5 4,996

How to Read a Data Sheet, Part II

 

One of the most mysterious elements of the data sheets is the relationship between the numbers in the data sheet and the speeds files which describe the timings which are built into the software.  Here is a news flash:  “Problem Solved.”

 

AC Specifications

 

If we look ahead to page 13 for “Switching Characteristics:”

 

http://www.xilinx.com/support/documentation/data_sheets/ds182_Kintex_7_Data_Sheet.pdf

 

We first see the various grades of performance (speeds grades) available for the Virtex-7 family.  -1L is the slowest, and -3 is the fastest device.  The -1L is specified to operate at 0.90V for the core (Vccint), and has lower power with a guaranteed level of performance.  The 1 is the slowest speed grade for 1.0V operation.  -3 is the fastest speed grade that operates from a 1.0V core supply.

 

All of the performance numbers are worst case, with the voltage supplies inside their recommended operating range.

 

The devices are tested such that they will meet the specified numbers.

 

When devices are released to production, you should check to make sure your software release is using the production qualified speeds file database, as indicated in Table 23.  Prior to production release, while devices are in the engineering sampling phase, timing has not been finalized and test programs are still being optimized.  The speeds files in the early software releases are intended to be more pessimistic that they may be otherwise, but not all paths are fully characterized and verified.

 

The next section is on I/O speeds and delays.  Read the measurement methodologies in tables 27 and 28, as they define the conditions under which the numbers apply.

 

The following pages contain the ILOGIC, OLOGIC and other specialized I/O function timings.

 

Then, at Table 34 the CLB internal timing numbers begin.

 

At Table 37, the block RAM (BRAM) and BRAM FIFO numbers are presented.

 

Then, at Table 38 the DSP48 performance is detailed.

 

Following that are the configuration block timing numbers, the clocking resource performance numbers, and finally, the multi-mode clock manager (MMCM) performance numbers.

 

That’s a Lot of Numbers!

 

Yes, there are a lot of numbers in the data sheet, but they are all part of a larger set of numbers which we call the speeds files.  The speeds files are built into the ISE tools so that the tools can govern the place and route and the resulting design can meet its timing constraints.  For details on the timing, one can interrogate any net or resource using FPGA_Editor, and there are ‘verbose’ report modes for the tools to report more information on the nets in your design.

 

It is often the best practice to try to synthesize, constrain, and place and route a small design to get an idea of its performance.  To perform the task by hand using the data sheet numbers would be far too difficult, and you would be unable to choose something as a route delay (as routes get placed where they meet timing).

 

One may compare numbers from similar tables for previous technology devices, but actual performance depends on more than just the numbers in the speeds files.  Routing resources, improvements in the synthesis tools, or improvements in the architecture are not represented in a few numbers.

 

Next Time

 

In the next part, we will examine the other modules of the data sheet.

5 Comments
larthe
Adventurer
Adventurer

Thanks for the clarifications! Here is a suggestion for improvement: One thing that I recently didn't find in the data sheet, even though I would have expected to find it, was the IO-standard and DC input and output levels for the configuration pins. For Spartan-6, it is mentioned in passing in the Configuration User Guide (UG380) that "The Spartan-6 FPGA configuration I/Os use the LVCMOS25 slow slew rate 8 mA I/O standard", but AFAIK this is the only place where it is mentioned. It is not even entirely true, since some of the pins may be in IO-banks having a different VCCO than 3.3V, whereupon the IO-standard will be something strange and different...

 

/Lars

larthe
Adventurer
Adventurer

Sorry, I meant ...different VCCIO than 2.5V..., but I guess you all spotted that. I also wonder if/how different VCCAUX (3.3V or 2.5V) might influence this.

 

/Lars

austin
Scholar
Scholar

Lars,

 

The IBIS models are not only really useful, they are part of our gauranteed specifications.  Dedicated IO pins are most usually 12mA FAST, although Spartan parts needed less ground bounce, so they backed off to SLOW, and I think they went to 8 mA for all dedicated IO.  Again, its in the specs, and it gets written by IBISWriter in the ISE tools for your part, your design (all the pins models).  You can read the files in ASCII and see the IO type, strength, voltage, etc. (you do not need a simulator, just an ASCII txt editor like WORDPAD).

 

If an IO is programmed for 2.5v, 8 mA, and you instead use 3.3v, the IO will be stronger than 8 mA.


Now, since 8 mA is the minimum, any 8 mA IO is likely stronger anyway, but it will be "more" stronger at 3.3v than it would be at 2.5v.


Can't hurt anything (on S6, there are some restrictions on 7 series IO voltages).

 

 

larthe
Adventurer
Adventurer

Thanks Austin, but as I understand that model will only be valid for the device _after_ configuration. What happens before and during configuration is what I can't seem to find. OK that the dedicated IO have LVCMOS25 8mA slow and that that will change slightly if/when the VCCO of the bank in question is not 2.5V, but if all the "functional" IO-standards where important enough to get a notion in the data sheet (SelectIO™ Interface DC Input and Output Levels on page 8 forward), I find it strange that the configuration IO didn't.

 

I guess I will have to brush up on my IBIS :=)

 

/Lars

austin
Scholar
Scholar

Lars,

 

The dedicated are 8 or 12 mA, slow or fast (it is discussssed in the config users guide).


The shared pins are the above before config, and then what they are programmed to after config.