Optimising pin allocation

B

Bruce Varley

Guest
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?
 
On 02/01/2014 10:51, Bruce Varley wrote:
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?
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
 
Tim Wescott <tim@seemywebsite.really> wrote:
On Thu, 02 Jan 2014 18:51:44 +0800, Bruce Varley wrote:

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.

(snip)
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.

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.

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.

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

-- glen
 
On Thu, 02 Jan 2014 18:51:44 +0800, Bruce Varley wrote:

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?

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
http://www.wescottdesign.com
 
On 1/2/14, 5:51 AM, Bruce Varley wrote:
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?

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.
 

Welcome to EDABoard.com

Sponsor

Back
Top