Solving FPGA I/O pin assignment challenges

By Brian Jackson, Xilinx
pldesignline.com (November 19, 2008)

A few weeks ago we looked at an article on Replacing obsolete video game circuits with Xilinx CPLDs, and now I'm delighted to have the opportunity to present the following piece from the Third Quarter 2008 issue of Xcell Journal, with the kind permission of Xilinx.

Input/Output (I/O) pin assignment is one of the main challenges facing designers integrating large FPGA devices onto PCBs. Many designers find the process of defining the I/O pin configuration, or "pinout," of large FPGA devices and their advanced BGA packages an increasingly difficult task for a seemingly ever-expanding number of reasons. But with a mix of smart I/O planning and new tools, you can remove the pain from the pinout process.

The task of defining an I/O pinout from FPGA to PCB is a major design challenge that can make or break a design. You must balance requirements from both the FPGA and PCB perspectives while designing both sides in parallel. If you prematurely optimize a pinout specifically for the PCB or the FPGA, it can lead to design issues in the other domain.

In order to understand the ramifications of your pin assignment choices, you need to be able to visualize both the PCB placement and FPGA physical device pins, along with the internal FPGA I/O pads and related resources. Unfortunately, as of today, there isn't just one tool or methodology to address all of these co-design concerns.

What you can do, however, is combine various techniques and strategies to optimize the pin-planning process and add new co-design tools like Xilinx PinAhead technology to devise an effective pinout methodology (Xilinx includes PinAhead in its ISE software design suite 10.1).

At Xilinx, we have developed a rule-driven methodology in which we define an initial pinout that considers both the PCB and FPGA requirements, allowing each design group to begin their respective design processes as early as possible by using a pinout that should be very close to the finalized version. If the design requires changes because of PCB routability or internal FPGA performance issues late in the process, this methodology is such that those issues are typically localized, requiring you to make only small changes in either design domain.

Click here to read more ...

E-mail This Article

Printer-Friendly Page