FPGA I/O Design is (also) a PCB Problem

In FPGA-based systems, the traditional approach is to split the design at the boundary of the FPGA’s pins.  Everything from the pins in is the responsibility of the FPGA designer while that outside the FPGA is handled by, well, everyone else.  Which begs the question: who handles the pins themselves, that nebulous boundary that is part of the FPGA but whose assignments can have such a drastic effect on the quality of not the FPGA, but the PCB itself?  Again, tradition holds that the FPGA designer does the I/O assignment - an often monotonous, tedious, but nevertheless essential, part of the process which offers little in the way of creative problem solving, at least from the FPGA designer’s perspective.  Tools have evolved to ease the pain, but it is still the FPGA designer who is made to suffer through it.  Combine a laborious, unglamorous job with tools that ‘solve’ the problem automatically and it is easy to predict the results – FPGA pin maps that work fine for the FPGA but breed a hopeless mess for everything else, particularly the PCB router.

The nature of this problem suggests that it can not and will not be solved simply with better FPGA tools.  It will require a change in design methodologies.  It will require design teams to realize that FPGA I/O design is a PCB layout problem and that they need to begin to deploy the right techniques and tools targeted at that part of the process if they are to ever get a grip on the issue.  This article looks at why the choice of I/O pins has relatively little bearing on the quality of the FPGA but can have serious consequences for the finished system.

I/O Assignments: FPGA vs. PCB Consequences

Good FPGA I/O design strategies are not either/or propositions.  That is, a solid methodology never shows a preference to the FPGA at the expense of the PCB or vice-versa.  Depending on the constraints of the FPGA and the PCB, truly optimized I/O assignments are those defined by looking at the entire system.

To illustrate this, consider the following simple examples in figures 1 and 2 (from a timing perspective, these examples are not intended to illustrate real-world design practices, just to highlight the issues).  In the first, the FPGA’s I/O assignments were chosen by the FPGA tools in order to meet the FPGA’s constraints.  Consequently, the PCB router is forced to deal with a veritable mess.  As a result, the FPGA meets its timing goals but at a cost to the PCB in the form of less-than-optimal first-pass routing (it’s clear just by looking at the point-to-point rats-nest that vias will be required to route the FPGA signals).

Figure 1 – I/O assignments optimized for the FPGA

In the second figure, the same I/O assignments were made but this time by deferring to the PCB.  The PCB routing (judging from the rats-nest) is much cleaner, allowing for shorter traces, requiring potentially fewer vias, and, presumably, improving overall signal quality.  But now the FPGA suffers in that it can no longer meet its timing constraints, as evidenced by the four negative slack times, which were determined by re-running the FPGA P&R tools with the PCB-optimal pin assignments.

Figure 2 – I/O assignments optimized for the PCB

Depending on the utilization of the FPGA and its required operating frequencies, FPGA routing channels and switch matrices are generally more flexible than the PCB’s resources (assuming a densely populated, high-speed board) and are often substantial enough to facilitate changes to the I/O assignments without violating timing.  But this is certainly not a hard and fast rule; for a highly utilized FPGA, the FPGA tools simply won’t have the luxury of exploiting synthesis and P&R options such as logic duplication or alternate channel routing.

Finally, remember that it is the system that determines the timing budgets for board-level signals, not just the FPGA.  In fact, the majority of a signal’s delay is consumed on the board, not inside the FPGA. Thus, even though moving a pin on an FPGA may cause timing violations in the FPGA itself, doing so may improve the signal’s board-level characteristics enough that the FPGA constraints can be relaxed, enabling the complete path to still meet timing.  And the side effects, either positive or negative, of moving a pin will be more evident on the PCB than in the FPGA since so many factors weigh on signals at the PCB level: signal integrity, crosstalk, via count, routing length, trace width, etc.  This is readily apparent with high speed boards containing high pin-count FPGA’s, prompting designers to adopt novel solutions, such as embedded passive technology, to help solve their board level timing problems.  Obviously, a comprehensive understanding of a signal and its total path is an essential part of the I/O design process.

Enabling a ‘Backwards’ Methodology

If, as claimed, FPGA I/O assignments can have far-reaching effects on the PCB, why not give the I/O design job to the schematic or PCB designer, let them assign the pins and feed this information back to the FPGA designer?  At the worst it would provide an early indication that PCB component placements relative to the FPGA are not optimum and at best it would mitigate the I/O assignment task faced by the FPGA designer while still providing him a set of pin assignments that meet his needs.

For many design teams this is a scary proposition.  Let the PCB designer define the FPGA’s pin out?!  That is a radical departure from long-standing, widely-accepted methodologies but one which new EDA tools such as Mentor Graphics’ I/O Designer have begun to enable.

I/O Designer is intended to facilitate a collaborative I/O assignment effort.  While it can read existing pin location information from the FPGA tools, it also supports the assignment of pins starting from a clean slate.  And it contains the information and process management capabilities that are the key in enabling a PCB-designer-driven I/O assignment flow: complete FPGA device intelligence and the ability to orchestrate and control the use of that intelligence.  In other words, I/O Designer can guide the user in selecting the proper I/O pin for a given signal while preventing them from making illegal assignment choices.

In the ‘backwards’ scenario proposed above, the FPGA designer provides a minimum set of data to the PCB and/or schematic designer, namely the top-level I/O signal list and, if available, signal characteristics such as voltage and current requirements, operating frequencies – anything that would constrain the signal or require it to be placed at a particular location on the FPGA.  The PCB designer would also need a first-pass set of schematics in order to create an initial layout.  Given this information, and the FPGA device intelligence which is built into IOD, the PCB/schematic team, using I/O Designer, could set about assigning the FPGA’s I/O pins based on their proximity to the other components on the board.  These pin assignments would then be back-annotated to the FPGA tools for P&R using the FPGA’s constraints.

Tackling this problem from the back-end first does not have to be an all-or-nothing venture.  Bringing the PCB and/or schematic designers into the I/O assignment process earlier in the design cycle does not preclude the FPGA designer from imparting his knowledge and control over the effort.  It merely adds other sources of valuable information into the I/O design effort.

Conclusion

Conventional wisdom holds that the FPGA designer assigns the FPGA’s I/O pins.  Either from a lack of process, a lack of tools to support a new process, or both, companies continue to risk the quality of the finished PCB by placing too much authority in the hands of FPGA designers when it comes to pin assignments.  Clearly, the PCB designer has at least as much at stake in the pin locations as the FPGA designer, sometimes more.  Until recently, EDA tools that understood enough of the FPGA-on-board process (FPGA vendor file formats, FPGA characteristics, schematic and PCB capture tools) did not exist.  But this is changing, as evidenced by Mentor’s I/O Designer.  Now, FPGA, schematic and PCB designers can come together in a single tool to solve the board-level problem of optimizing FPGA I/O assignments.

February 20, 2007

[back to top]