cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
430 Views
Registered: ‎03-05-2020

Limits for static timing

Jump to solution

is there a datasheet parameter or a way to approximate what is achievable in terms of passing static timing constraints for each FPGA device/speed grade?

As a background, I've been looking around the forum for the answer, and this is what I've concluded:

1) The datasheet setup/hold times are specified for various selectIO, GTX, etc, using various clocking schemes (BUFG, BUFR, BUFIO, etc). Operating them at these maximum speeds will require dynamic timing calibration, IE the continuous reconfiguration of IODELAY.

2) Some forum posters just seem to have a inherent knowledge about what is achievable in terms of static timing. I see comments like "you will never be able to achieve this valid pulse-width timing on any XYZ family FPGA".

Is the answer simply trial and error, or is there a better way?

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
400 Views
Registered: ‎01-23-2009

is there a datasheet parameter or a way to approximate what is achievable in terms of passing static timing constraints for each FPGA device/speed grade?

As a general rule, no.

For internal signals, the absolute maximum frequencies are dictated by the clocking resources - mostly the frequency of the BUFG (in fact, I suspect that the maximum frequency of the BUFG is defined as being the maximum usable frequency of the fabric). But beyond that, it entirely depends on your coding style - at the maximum frequency, you can generally only run small "islands" of functionality, and the code needs to be restricted to functionality that can (more or less) be implemented as Flip-flop -> one single LUT -> a smallish carry chain -> a flip-flop). For very small sub-circuits, this may be doable, but can is quite restrictive - generally it is preferable to run closer to the "sweet spot" of the technology, which is often around 1/2 (or less) of this maximum frequency. For example, for the Kintex-7 (DS182), the maximum frequency of the BUFG is 625MHz in a -1 speedgrade, but it is probably a good idea to run at around 300MHz or even lower if possible. Even this, you have to be careful with your coding.

For other resources, the datasheet does have some useful information. As an example, the maximum frequencies of the DSP48 cell in different configurations is documented in the datasheet notably the FMAX_* (i.e. Kintex-7 Table 35 at the end). These are real, attainable frequencies - at least within the DSP cell and the DSP cascade; it may be difficult to get data to and from them at some of the fastest frequencies, but internally, these are real numbers. The same is true of BRAMs.

For the Gigabit Transceivers, the numbers are real - the maximum frequencies are attainable as long as you follow the board design guidelines for power and signal integrity.

For the I/O, they are much more complicated - there are tons of topologies and tons of I/O standards. But even with these the datasheet does give you some help. The final section in the I/O of the datasheet "Device Pin-to-Pin... Parameter Guidelines" (for DS182, tables 43 onward) give you some good "guidelines" for the timings of I/O in different clocking topologies. While these aren't "guaranteed" numbers (and they don't entirely match the results the tools give you) - they do give you some ideas as to the range of attainable statically captured interfaces. These are all based on a single I/O standard (SSTL15 for Kintex-7), so for different I/O standards you can refer to the "IOB ... Switching Characteristics" (Tables 20 and 21) to see how the number for the I/O standard you are expecting to use compares against the number for SSTL15.

But, ultimately, it is the tool that makes the final determination as to whether a design meets timing or not - everything must pass timing (with the exception of dynamically captured interfaces, which, by definition, cannot be times using static timing analysis).

Avrum

View solution in original post

2 Replies
Highlighted
Guide
Guide
401 Views
Registered: ‎01-23-2009

is there a datasheet parameter or a way to approximate what is achievable in terms of passing static timing constraints for each FPGA device/speed grade?

As a general rule, no.

For internal signals, the absolute maximum frequencies are dictated by the clocking resources - mostly the frequency of the BUFG (in fact, I suspect that the maximum frequency of the BUFG is defined as being the maximum usable frequency of the fabric). But beyond that, it entirely depends on your coding style - at the maximum frequency, you can generally only run small "islands" of functionality, and the code needs to be restricted to functionality that can (more or less) be implemented as Flip-flop -> one single LUT -> a smallish carry chain -> a flip-flop). For very small sub-circuits, this may be doable, but can is quite restrictive - generally it is preferable to run closer to the "sweet spot" of the technology, which is often around 1/2 (or less) of this maximum frequency. For example, for the Kintex-7 (DS182), the maximum frequency of the BUFG is 625MHz in a -1 speedgrade, but it is probably a good idea to run at around 300MHz or even lower if possible. Even this, you have to be careful with your coding.

For other resources, the datasheet does have some useful information. As an example, the maximum frequencies of the DSP48 cell in different configurations is documented in the datasheet notably the FMAX_* (i.e. Kintex-7 Table 35 at the end). These are real, attainable frequencies - at least within the DSP cell and the DSP cascade; it may be difficult to get data to and from them at some of the fastest frequencies, but internally, these are real numbers. The same is true of BRAMs.

For the Gigabit Transceivers, the numbers are real - the maximum frequencies are attainable as long as you follow the board design guidelines for power and signal integrity.

For the I/O, they are much more complicated - there are tons of topologies and tons of I/O standards. But even with these the datasheet does give you some help. The final section in the I/O of the datasheet "Device Pin-to-Pin... Parameter Guidelines" (for DS182, tables 43 onward) give you some good "guidelines" for the timings of I/O in different clocking topologies. While these aren't "guaranteed" numbers (and they don't entirely match the results the tools give you) - they do give you some ideas as to the range of attainable statically captured interfaces. These are all based on a single I/O standard (SSTL15 for Kintex-7), so for different I/O standards you can refer to the "IOB ... Switching Characteristics" (Tables 20 and 21) to see how the number for the I/O standard you are expecting to use compares against the number for SSTL15.

But, ultimately, it is the tool that makes the final determination as to whether a design meets timing or not - everything must pass timing (with the exception of dynamically captured interfaces, which, by definition, cannot be times using static timing analysis).

Avrum

View solution in original post

Highlighted
Observer
Observer
382 Views
Registered: ‎03-05-2020

Thanks. This helps a ton.

0 Kudos