Apart from the devices we proudly display in our cubicles here at the factory (because they represent the fruits of a lot of labor), FPGAs usually end up on printed circuit boards (PCBs).

Closing on a pin assignment that will meet requirements from both the PCB and FPGA environments is becoming more challenging. On one side of the interface, ever-increasing FPGA performance, density, and I/O count are placing tighter board constraints on the layout of the signal to and from the FPGA. On the other side, timing, congestion, and signal integrity of ever-faster signals on the PCB are placing constraints on FPGA pin assignment.

The latest EDA survey conducted by EE Times tends to reflect this challenge. Two-thirds of respondents said that their latest design uses two or more programmable devices. They also selected “getting the FPGA to work on the PCB” as the second most challenging part of FPGA design projects.

Until recently, very few tools or processes existed to assist with FPGA pin assignments, but this is changing. In this article, I’ll look at the causes of pin assignment changes in today’s design environments, describe the implications of such changes, and review the different tools available to simplify and automate FPGA pin assignment closure.

The Need for FPGA Pinout Changes
There are many good reasons to modify the FPGA pinout throughout the system design process. The flowchart in Figure 1 presents a typical design flow, with an emphasis on FPGA pinout closure and the sources for these changes. It clearly shows many areas where changes may occur; however, these are introduced by three specific sources:

1. Pinout changes because of design flow constraints. With today’s highly competitive and constantly evolving electronic markets, it has become critical for companies to shorten design cycles so as to react faster to market demand changes. Therefore, product development is parallelized wherever possible. This goes for FPGA and PCB design processes too. The system architect defines an initial list of interface characteristics, which PCB and FPGA designers use to start their design. This assignment is later refined (that is, changed) as both the PCB and FPGA teams progress with product development. Additionally, market changes throughout the development cycle may require changes to the pinout, such as adding support for a new protocol or adding a feature at the last minute.
   • Pinout changes because of PCB constraints. Because of form-factor restrictions or board cost control, the available real estate on the board may be limited. In such cases, using the programmability and flexibility of the FPGA pinout can help solve PCB congestion or routing problems. Some of the FPGA features you can use include:
   • Swapping pins to untangle nets on the board. This diminishes the number of vias needed and may reduce the number of layers. Reducing the number of layer changes a signal encompasses will also improve its signal integrity and electromagnetic emissions.
   • Adjusting I/O properties to augment board signal integrity by lowering the signal drive strength or slew rate.
   • Using the programmable internal terminations to save on discrete component costs or to save board space in congested areas.
2. Pinout changes because of FPGA constraints. In turn, FPGAs impose constraints on the design of the PCB, which may require pinout changes as the implementation progresses. These pinout changes are because of:
   • Timing. Margins on some signals going into or out of the device may be tight enough that only a limited set of package pins will work.
   • Dedicated/special-purpose pins. Because only a subset of package pins can be programmed to function as special- purpose pins (such as global or regional clocks or programming pins), this places constraints on the board to route signals to these capable I/Os.
   • Voltage/termination compatibility. FPGA I/Os are grouped in banks, with all pins in a particular bank sharing power and reference voltages. This means that once a particular voltage is used in this bank, only I/Os with compatible voltage can be assigned in the same bank. This too may force you to select pins on the FPGA package that are not optimal from a PCB routing standpoint.
   • Simultaneous switching outputs (SSO). To ensure that signals driven by the FPGA will meet I/O standard electrical characteristics, Xilinx publishes a recommended maximum number of SSOs per area of the device. You might have to scatter pins across different areas if you exceed these recommendations.
   • Device decoupling circuits. As with any other IC on the board, FPGAs require certain characteristics for the power delivery system, which includes adding local decoupling networks (discrete components) to supply power to the circuit (the voltage regulator is typically unable to respond to rapid device demand changes).

Implications of Pin Assignment Change
Given the reasons I have discussed, it is almost certain that the FPGA pinout will change during the system design process. But what implications – in terms of time and effort – do these changes have on both the FPGA and PCB environments? What steps are necessary to verify that both environments are in sync and that constraints on either side are met?

From the FPGA side, after each pinout change you will need to update the user constraint file (.UCF) and verify that the internal timing constraints are met. You can also run PACE and SSO calculations to verify the assignment’s I/O banking or SSO guidelines.

From the PCB side, you will need to update the schematic and layout symbols following a pinout change. You may also want to run the DRC to ensure that electrical and physical properties of the changed signal(s) pass the constraints. You can also run signal integrity analysis to verify that timing and amplitude margins are still adequate.

The important step is to communicate pin assignment changes to the other environment. Historically, PCB and FPGA design environments have been pretty isolated, with only limited communication channels between them. As I will explain in the next section, there are now tools and options available that make synchronization and data transfer far less cumbersome and time-consuming.

Available Tools and Processes
Now that you know that FPGA pin mapping will change, and you understand the frequency and implication of such changes in both FPGA and PCB designs, what are your options to minimize the burden of incorporating these changes? How can the pin mapping be propagated between environments in an automated fashion so that no data gets lost in translation? How can this be done quickly so that you can iterate pinout changes until a solution satisfactory to both the PCB and FPGA teams is found?

Within the FPGA Environment
The PACE (Pin and Area Constraint Editor) program allows you to graphically assign design signal names to package pins. PACE also presents a die view with a graphical representation of the FPGA internal logic. Thus, you can assign pins close to the driving logic while also being mindful of the location recommendations from the PCB designer. You can enter pin properties for I/O standard, drive, and slew rate. The graphical view easily identifies special-purpose pins such as global or regional clocks. As illustrated in Figure 2, PACE also performs voltage compliance and SSO checks so that the pin assignment is correct by construction.

This tool proves valuable at different stages in the design process. You can create a pin assignment from scratch or read in the signal names from a synthesized netlist. After place and route, you can interactively adjust the pin assignment to satisfy the implementation or PCB tool constraints. PACE generates a Verilog module or VHDL entity, along with a pinout file that can be loaded in most PCB tools to generate and update schematic and layout symbols. PACE also reads pin files from the PCB tool and generates a UCF constraint file for ISE™ software.

Another tool worth mentioning here is DesignF/X from Product Acceleration. With this application, you define the I/O properties (standards, drive strength) and general area of the package on which your interfaces will be placed. The tool will then place every I/O so as to facilitate PCB routing, while making sure the FPGA banking, clocking, and SSO rules are obeyed.

Within the PCB Environment
Your favorite PCB design tool likely has a wizard or some documented process to assist with the creation and maintenance of your FPGA schematic and layout symbols. There is probably an assisted way to update these symbols after a pinout change. Finally, to assist with high-pin-count devices, there is also an option to fracture symbols onto multiple sheets to simplify documentation and the connectivity process.

FPGA/PCB Co-Design Tools
Tools designed to bridge the FPGA and PCB environments have recently debuted, with their feature lists continuously expanding. Shown in Figure 3, programs such as Mentor I/O Designer (although not the panacea, because they do not yet understand all of the FPGA and PCB constraints related to pin assignment) already go a long way toward simplifying and accelerating FPGA pinout closure. From a single environment, you can:

• Automate the synchronization of both environments after a pinout change.

• Assign or swap pins from a graphical view of the FPGA package. Like PACE, it will perform DRCs to ensure that the pin assignment does not violate any device rules.
• Assign or swap pins from a graphical view of the PCB. Visualizing the physical location of the other components the FPGA is interfacing provides you with information you can use to assign pins in a manner that will reduce wire crossover on the board and simplify the FPGA breakout. This can in turn lead to saved design time (PCB router iterations) and money (better use of board real estate, reduced layer, or via count).

Printable PDF version of this article with graphics.  (12/1/05) 320 KB