Optimising pin allocation

New to FPGAs, not much understanding of what goes on inside them, and I may never get very far in that direction. I'm building an app on Cyclone II that involves some parallel 8-bit wide I/O busses connecting to device pins, and various routing and logic operations in btween the in and the out. I'm wondering whether it matters which pins are used for the I/O in terms of optimising the internal connections and processing within the device. As a converse example, would it matter at all if I scattered my bus I/O all over the place randomly. Or can these devices and their IDE magically still make it all work just as efficiently? I presume not.

Are there any guidelines that a relative beginner would be able to understand?

Reply to
Bruce Varley
Loading thread data ...

I don't use Cyclones but so far (based mainly on Lattice parts) I've never had a serious issue optimising my pin assignments for pcb layout and letting the FPGA tools worry about the insides. It's obviously easier for the tools if you don't push to the limits on capacity or speed. It's also normal that a pinout which is optimum for the pcb will cluster IO in sensible groups. If you are using different IO standards on different IO banks you do need to think about that (and of course to make sure that any pin you do assign can support the IO configuration you want).

Michael Kellett

Reply to

Back when I was sociable enough to work with other people, Xilinx would push the FPGA guys to let the Xilinx tools assign pins to signals. Since they were also the board designers, they usually reacted to that with about as much enthusiasm as you might to the idea of eating soup made with lawn clippings.

They generally assigned pins in some "sensible" grouping by port; the preference was for busses to be physically grouped, etc. Sometimes they'd let the Xilinx tool assign pins, but would then nail that down for subsequent design iterations, so that the board layout would not change.

Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott


As well as I understand it, early FPGAs didn't have as much routing resource, such that it mattered more where the pins went. Later, some added extra routing around the edge to make it easier to get the pins where you wanted them.

Also, more recent FPGAs allow different I/O voltages for different sets of pins. That sometimes restricts which signals come out where.

-- glen

Reply to
glen herrmannsfeldt

Generally (especially if the signal go into logic that will use carry chains etc) there are some pinouts that are "better" than other, being faster and/or not needing to use extra logic resources to help with the routing. The routing matrix from pin to internal is generally no where near complete, but generally flexible enough to handle most "normal" cases, especially if you can let the system use internal logic cells to help routing,

There normally are a few signals that do need extra care. Signals like clocks sometimes need to be placed on one of a limited set of pins. Differential pairs need to be on related pins, so assigning one will assign the other. Often pins are grouped for signal type/io voltage, so if you have multiple types, you need to be sure you assignments are compatible with the ability of the device.

Some tight timing conditions (like a DDR Memory or other high speed bus) may require specific pinouts to meet full timing, these can often also have board layout issues, so these really need to be worked out with an understanding of both.

Ideally, you would have time to completely design the FPGA before laying out the board, so you can easily work out the trades knowing everything that is important. Much more often, you need to make good guesses based on experience up front, and hope that both paths can make it work. If you aren't pushing the FPGA, you can normally get away with a lot of flexibility in pinout. The Altera tool does have the ability to check if a pinout is "feasible", which you should check as a minimum.

Reply to
Richard Damon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.