I need link to some very basic parameters of different FPGAs

There are simple answers here:

1. You can set the clock to whatever you want/need it to be for the data rate you need on the IO.

2. It depends on your design

3. It depends on your design

4. It depends on your design

5. It depends on your design.

6. The FPGA has no gates. Only LUTs - hence the Tpd of a single gate through a LUT is meaningless, because gates dont exist. And the timing will depend on your design

7. Level reset (Altera recommends Async assert, sync de-assert) - Xilinx on the other hand recommend sync resets only

8. Yes.

As you will see, the "it depends on your design" is key here. Altera publish maximum theoretical speed, but its unlikely you will ever get near these speeds.

edit: because i was wrong

last edited by tricky (http://www.alteraforum.com/forum/posthistory.php?p=200677); Today at 08:26 AM.

I really don't get it, a flip flop is a simple basic unit, how can you not have a max clock speed, no clock to Q delay? Every flip flop in the pass have spec. there is always data setup time and hold time to clock. How can there is no specification? If everything depends on the design, then I can make a MAX run as far as the Stratix just by design!!!

I spent days reading, and I spend time typing 4 pages in another post here just to find out there is no spec? this is hardware with real wires and transistors that limit the rise time and fall time that can quantify by prop delay. I just cannot see how people can design without these specs. Do you just TRUST the simulation? Everything is based on simulation?

regarding to NAND, AND, OR, NOR, this is just the most basic building blocks of random logics that if you know the spec, you can estimate others like MUX, ALU etc.

What I asked are very very basic spec that EVERY logic datasheet specifies.

Do you mean if I know my design need to have pipeline registers with simple logics in between. Instead of calculating the max frequency by adding the

1) clock to Q delay

2) delay of a few logic gate

3) data setup time of D input to the following clock.

to get the max frequency. I have to write the program and simulate the whole thing to get a SIMPLE answer that I can do it in 1 minute to decide whether the particular FPGA and the speed grade can work for me if I have the few basic spec? this is SERIOUSLY WRONG. No offense.

Depend of the design?? Using the GCLK or RCLK? using particular clock pin? Just give the spec of the pin and the clock!!! These are so easy for Altera to print out the spec, one page will give every basic information needed for design. Instead you have over 300 pages in the manual, 78 pages in the data sheet, then another 70 pages in design guide. IN WHICH still keep referring to other articles.

Give the basic info, if people decide to use your chip, then they can spend the time to learn quartus II and learn the detail simulation and design rules. I am at this point tending to go find other solutions after 4 days, reading hundreds of pages and I am no more informed than 4 days ago. I don't want to spend 2 weeks getting good at all the software before I can decide what to use!!

Data given by ASIC vendors includes tables for io timing requirements and fmax since these are fixed at fabrication.

FPGA vendors do not give such data since io timing is configurable to some extent(based on your io timing statements in sdc file).

On the other hand FPGA fabric registers are left at mercy of fitter routing and need not be known to user but overall fmax achievable may be given for specific design types as an idea.

There is no point to know tSU/tH/tCO of any fabric registers as the job is left for timing tool to achieve them across the rtl chain.

For io registers you can get them after compilation of a given design (in the datasheet section of timing report).

io toggle rate may be given as it may restrict fmax independent of register timing restriction

The problem is its not the register thats the problem timing, its the routing that causes the delay. Im sure you'll find a quote in most of the handbooks about the theoretical max speed of the rams, registers etc, but these are stupidly high and at a speed you would never reach in reality (figures like 400MHz for stratix 4 parts for example).

--- Quote Start ---

regarding to NAND, AND, OR, NOR, this is just the most basic building blocks of random logics that if you know the spec, you can estimate others like MUX, ALU etc.

--- Quote End ---

THis again is meaningless - like I said, each design is made of LUTs, so a 2 to 1 mux can be done in a single LUT, but a 4 to 1 may be a 2 luts (or 1 LUT for newer devices). THen you have synthesis optimisation that may merge some of your logic together or minimise it. Then the fitter has to link all the LUTs together - you see where Im going. And because it uses a random seed for the fit the delay through the logic can vary with every build. This is where the timing analyser comes in and checks your design meets high and low temperature timing requirements.

So in another words, unless I stop and learn Quartus II, input all the circuits, do the simulation, I won't know whether it will work with certain device. Then I cannot even do the cost estimation to decide what approach I should use.

I am an old time designer that actually relies on real circuit data to design circuits. I design plenty of complicated digital hardware. I know how to estimate delay due to signal length, buffer delay and can estimate timing and speed easily just by simple addition. To me there is something wrong with this picture that people get away with this BASIC common sense knowledge and totally at the mercy of a simulation program. I am not a FPGA engineer, but many times in the past I fix FPGA programs designed by supposedly a "FPGA engineer". case in point, our system had intermittent problem that I traced down to the "FPGA engineer" drive the reset of the DFF with combination logic. IN AHDL, it is like dff.r= a+b+c. BUT in real life, A, B and C can have condition that A goes low before B goes high and create a glitch and reset the DFF intermittently. These are REAL circuit, not a program, this is REAL CIRCUIT that has timing. Experience people can spot this in a heart beat. But it would not be apparent. Maybe that's one of the reason why there are robust circuit of error detection and resend data to hide these problems.

Far as I concern, this is SAD. I did AHDL in old Quartus in the pass, I am doing cost estimation and come up with a design approach. I wasted 5 days on this forum and I am not better off than 5 days ago.( Well I know what I cannot get out of Altera now). I cannot even tell whether I can use Arris II or I have to go to Stratix. this is sad. I might have to try Xilinx and see whether they are any better.

Altera should just waste a page and just give out the data of these basic building blocks. Sounds like you can force the compiler to use RCLK or PCLK in very specific quadrant/region to estimate the prop delay. Just PUT the delay of these clocks, I/O buffer on the datasheet and let people do the estimation!!! Specify the speed of the trace like 5" per nS time!!! It's not that hard and it's not that hard for people to do addition!!!

regard to temperature, You can estimate using the slowest speed!!!

You'll get the same things with Xilinx (and in some cases worse documentation and worse tools).

But what are your requirements? FPGAs are designed to be synchronous - so as long as you know what data throughput you need, you then know what clock you need, and as long as it's < 200 MHz inside the FPGA - there wont be a problem ( < 300 Mhz requires more effort, and > 300 Mhz will require lots of effort). Then estimate your memory requirements, DSP resources and Pinout - then you can easily decide what part to take. Because you know your clock speed, you know the reg -> reg delay requirements, and you let the fitter put all the effort in to make it work. Doesnt meet timing? modify your code to improve the pipelining.

FPGAs are not very good at asynchronous circuits - so why would you care about delays through luts? using luts to delay signals is a bad idea.

Altera could specify routing delay all they want - but it's pretty useless when someone decides to put 10 luts between two registers and cant acheive a clock speed any more than 50 Mhz. People are not drawing schematics at the gate level, they are writing code at the behavioural level.

Total FPGA novice here (software guy). I haven't seen timing information like that listed for any brand of recent FPGA. I think the expectation is that the tool set will be used to get timing info.

On a project I worked on several years ago, the FPGA team coded what they knew was the most time critical logic and entered the time requirements in the tools. They then tried to meet timing with several different brands and families of FPGA dev tools. Once they knew what would work they looked at size, memory, transceivers etc. Mgt then negotiated with vendors for quantity prices. We then purchased dev boards for an FPGA in the brand selected that was one size bigger than what we thought we needed and used that. Sometimes we could drop down a size in the end and sometimes not.