Understanding types of IO pins on FPGAs

[whack]

Hey all,

I'm looking at FPGA pinout documents for Altera and Lattice FPGAs and I ran into the problem where I don't understand why some IO pins are labeled "low speed" while some are "high speed". And the more important question, how slow is "slow" and how fast is "fast". I find those labels to be quite vague.

A quick Google search indicates that this question has been asked before, but it wasn't answered.

For example, consider the following pinout documents:
For Altera MAX10:
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/dp/max-10/10m02sc.xls
Under "IO Performance" column there are labels "Low_Speed" and "High_Speed"

For Lattice MachXO2:
https://www.latticesemi.com/~/media/LatticeSemi/Documents/PinPackage/MachXO23/MachXO2-4000Pinout.CSV?document_id=42571
Column "High Speed" with entries either blank or "TRUE".

So what does that mean?

Insight is appreciated. Thanks.

 

[FvM]

Some explanations in this previous thread https://www.edaboard.com/threads/365707/#post1566980

Discussions at Edaboard and Altera Forum suggest that most people are overrating the relevance of this pin attribute for their application.

 

[whack]

Some explanations in this previous thread https://www.edaboard.com/threads/365707/#post1566980

Discussions at Edaboard and Altera Forum suggest that most people are overrating the relevance of this pin attribute for their application.

Thanks, that's something. But it's a little light on specifics.

If I have wide data and address busses, would it be acceptable to mix "fast" and "slow" pins in the same bus? For the above device families, can the "slow" pins sustain data rates up to 56MHz? What about faster?

 

[FvM]

But it's a little light on specifics.

Why, the mentioned datasheets are specific.

My impression is that the MAX10 designers created the high speed pin option without actually thinking how much the speed difference might be. Actual speed difference, according to datasheet is a few percent and thus negligible for most applications. That's specific for MAX10, Lattice could be different.

I would used "low"- and "high" speed in a mix if necessary, and check timing analysis or real hardware for the results. 56 MHz isn't really fast in FPGA terms.

 

[whack]

I'm assuming you're referring to software timing analysis of synthesized and implemented logic. The tools for this are vendor-specific I assume, correct?

Post-synthesis timing analysis was not covered in college, sadly.

What's a good place for me to start to learn this? I've got Xilinx toolset on hand.

 

[FvM]

I must confess that I rarely use timing analysis for IO, only regularly for core logic.

But it's supported by the vendor timing analysis tools. They have libraries including IO time delays and can check the design margins against your requirements, also adjust routing and programmable IO delays (if available) to some extent.

But if a design has plenty of IO timing margin by nature, you don't need to check or adjust anything.

Rysc has written a great user guide for Altera TimeQuest , it should also apply to other STA tools using the Synopsys design constraints language.

 

[ads-ee]

You use set_input_delay and set_output_delay to properly constrain the I/O, then it doesn't matter if the I/O is low or high speed it just has to meet the timing constraints. With those constraints as long as the I/O is fast enough to transfer the data with enough margin across PVT then the design will work regardless of the type of I/O used. Given what has been stated by FvM already it looks like the fast/slow I/O was more an attempt by the IC designers to do something that the marketing people wanted to push as something special about MAX10. Instead it is just a source of confusion and marketing BS.

Unless you are trying to run your I/O at >>100 MHz. I really doubt you'll have any timing problems with using a mix of the (not so) fast/slow I/O.

 

[whack]

something that the marketing people wanted to push as something special about MAX10. Instead it is just a source of confusion and marketing BS.

Those marketing people are clearly not very good. Putting "Low_Speed" in documentation is not a good way to sell the product.