Altera FPGA Fabric Timings - Avaliable?

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.

--- 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?

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.

--- 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.

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.