Predicting that IC density and complexity will continue to increase is kind of like predicting that the sun will come up in the morning-you'd literally have to be living under a rock to not be aware of this. And so it is with FPGAs, which are getting more, not less, complex; whose pin counts are going up, not down; and for which the available silicon seems to grow faster than many engineers can figure out how to use it. The only thing that steadfastly refuses to change is design schedules, which bewilderingly remain as constant as the sun.
Integrating these ever-more complicated devices into their host PCBs has proven to be extraordinarily challenging. FPGA designers, schematic engineers, and PCB designers find themselves locked in a divergent battle, struggling to create device pin assignments that satisfy both the FPGA and the PCB. Traditional tools almost encourage each specialist to "throw the design over the wall." As the design progresses, this tool-mandated "not my job" mentality dooms the team to wasting precious time, often late in the project, iterating between the FPGA and PCB design, searching in vain for common ground in pin assignments.
Regrettably, it's the PCB that usually suffers, with more layers and vias being added to accommodate the FPGA. To make matters worse, this typically manual round-trip process introduces errors that may not be exposed until the first prototype is powered up in the lab.
All's Well That Starts Well
Take an average FPGA-based PCB design containing two or three FPGAs. Most processes let the FPGA designer have all of the pin assignment fun (as in ,"It's fun to hit my thumb with a hammer"), using the FPGA tools, scripts, text files, spreadsheets, home-grown utilities, and whatever other tricks are at his/her disposal. Those pin assignments are then passed to the schematic engineer who gets the fun (see above for the definition of "fun") of creating symbols and wiring up the schematic using precisely the same pins as the FPGA designer, including all of the power pins that can number in the hundreds. Not to mention the lingering fear lurking in the back of his/her mind that if anything is misconnected, the system won't work. Or even worse, on first power up the prototype will do nothing more than radiate lots of heat until it melts into a useless pile of expensive FPGAs and fiberglass.
And this doesn't even begin to address the PCB designer, that poor soul at the bottom of the design food chain who just happens to have had all of his/her allotted time chewed up by everyone else, who has little say in the design process, and whois told to "fix it but don't change anything" on a board where the PCB routing was never considered for a fleeting µ-second!
That this situation sets the stage for a lot of hand wringing, late nights, finger pointing, heated battles, and endless loops through the flow-usually at the end of the design cycle, when it can least be afforded-is only too predictable. Oh, and don't forget that all FPGA pin assignment changes have to propagate through the entire flow, every time, with flawless accuracy.
This, with a little embellishment, is what happens with manyaverage FPGA-based boards. Just imagine ASIC prototyping designs, which can contain dozens of FPGAs. The problems listed above become practically unmanageable, and it is a testament to the engineers'-and PCB designers'-skill that any of these prototyping systems are ever made to work correctly in a time frame that ensures the ASIC is taped out before the market renders it obsolete.
Take the following two screenshots (Fig. 1 and Fig. 2), which are admittedly an exaggeration but nevertheless highlight what can happen while picking pins if component placement is either ignored (bad) or considered (good):
Assuming both designs satisfy the needs of the FPGA (the large device in the middle), which one would most likely inspire the PCB designer to request an unpleasant chit-chat with engineering? True, only the rat's nests are represented here. But their implication is clear: the tangled mass of connections scattered across the FPGA in Figure 1 are destined to cause a routing nightmare. To understand the roots of this issue, you need to look no further than the techniques that are generally deployed, and the data that is normally acknowledged, during the FPGA pin assignment process.
Article Sections