Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20641 Discussions

Altera FPGA Fabric Timings - Avaliable?

Altera_Forum
Honored Contributor II
1,254 Views

I've been looking at some Microsemi/Actel FPGA datasheets and they appear to specify timings for different types of gates (AND, XOR, etc). 

For instance, the Microsemi ProASIC3 nano Flash FPGAs Datasheet ( https://www.microsemi.com/document-portal/doc_view/130705-ds0111-proasic3-nano-flash-fpgas-datasheet ) has Figure 2-2 and Table 2-65 showing various logic gate propagation delays. 

 

Are they available for Altera parts (e.g. the Cyclone IV)? 

Is there somewhere in the Quartus software libraries that specifies them? 

Are there too many variables affecting delay (voltage, temperature, device class and variation, etc) and so Altera don't even bother with "worst case" timings? 

 

I figure it's probably either a licensing thing, or everything is done via the simulation software so routing delays can be taken into account, but I just wanted to check there isn't somewhere really obvious that I haven't checked.
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
493 Views

The technology is fundamentally different. Altera uses luts to model logic. As such, the lut delay is very small compared to the routing. The luts also do not implement a single gate, but anything from one to several.  

 

The routing is affected by Pvt, process voltage temperature, so accurate timing cannot be given in the datasheet. In addition, the routing will likely change from build to build. 

 

For FPGAs, you should have a fully synchronous design, which can then be timing analysed, so timing simulation not necessary. As long as rtl simulation is verified and running analysis passs, your design should work in FPGA.
0 Kudos
Altera_Forum
Honored Contributor II
493 Views

 

--- Quote Start ---  

The technology is fundamentally different. Altera uses luts to model logic. As such, the lut delay is very small compared to the routing. The luts also do not implement a single gate, but anything from one to several. 

--- Quote End ---  

 

We'll sure, but if I want to chain two LE's 4-to-1 LUTs together to form a larger LUT, surely I can bypass one LE's register if I know how long it will take to travel through one LUT to the input of the next LUT, and allow for it by leaving enough time between clocks. 

 

 

--- Quote Start ---  

For FPGAs, you should have a fully synchronous design, which can then be timing analysed, so timing simulation not necessary. As long as rtl simulation is verified and running analysis passs, your design should work in FPGA. 

--- Quote End ---  

 

But how can timing analysis take place without knowing the parameters?
0 Kudos
Altera_Forum
Honored Contributor II
493 Views

You usually wouldnt generate the logic yourself. Your RTL code will be converted by the synth tool. Hand placing LUTs and registers is a slow and laborious process, and you are unlikely to get better results than the synthesis and place and fitter. These can use your timing specs to help them get good results.  

 

The timing analysis has worst case timing for all routing and LUTs, with several models (standard being fast/slow and high temp and low temp). It works out the delay between registers and if it meets the timing specs (usually specified with a clock definition) then it will work in the chip. 

 

If your design fails timing, then the best course of action is to increase the number of pipeline stages and reduce the number of levels of logic (sequential luts) between registers. This is most easily done in the RTL.
0 Kudos
Altera_Forum
Honored Contributor II
493 Views

 

--- Quote Start ---  

If your design fails timing, then the best course of action is to increase the number of pipeline stages and reduce the number of levels of logic (sequential luts) between registers. This is most easily done in the RTL. 

--- Quote End ---  

 

Which is exactly what I'm trying to do, but I just thought there might be a way to do it by checking timings rather than just trial and error, "suck it and see" type methods. 

For instance, if I need to restructure a 32-to-1 LUT to make it quicker, I figured it would be nice to know if I should do it in two or three registered stages based on some maximum delays and calculations. 

But I'll give it a go and see what it routes.
0 Kudos
Altera_Forum
Honored Contributor II
493 Views

At that level, it can come down to understanding the fundamental technology. FPGAs use 4/5/6 input LUTs. Knowing this, then you should be able to work out (or at least look at the mapping diagram) how many layers of LUTs there are in your logic. If you have 2 layers, then 1 extra register is all you need, as this is all thats needed to break up the logic. any more wouldnt be beneficial. 

 

What I will say is that many timing problems dont come in the LUT logic, they are a consequence of DSPs and RAMs being in fixed locations. It is quite expensive, timing wise, to route into/out of these. If timing is getting tight you can start failing timing at the block boundaries, likely because the fitter is being forced to pull a single register in two directions to meet timing. Adding extra registers here can be very beneficial, as it gives the fitter more options to place/move registers.
0 Kudos
Reply