Looking at the growth of FPGA pin counts and device complexity over the past 15 years, it's easy to view them as modern-day, high-tech Tribbles. And, like Tribbles, solutions for dealing with them, at the board level, are proving just as illusive.

Unfortunately, designers aren't Captain Kirk and there are no sacrificial extras that can be killed off in an attempt to resolve the crisis (unless you consider perhaps the managers that produce unrealistic schedules in the first place). While engineers can't yet beam the final design to their desktop with just seconds to spare, there are products that can significantly reduce the torment associated with FPGA-based systems design while increasing the design team's overall productivity.

This article explores the tools, techniques, and problems that designers struggle with when developing FPGA-based systems and, using a couple of real-world examples, attempts to offer solutions.

From PALs to ASICs and FPGAs: A brief history
Before we look at some of the newer technologies that have been developed to deal with this problem, it might be helpful to review the chronology of board-level design tools (and where that development history has led us) by examining a typical FPGA-based board design flow used today.

In 1975, Signetics released a device they termed the FPLA (Field Programmable Logic Array). While these FPLA's demonstrated a departure from standard logic components (i.e. 7400-series devices), they were, among other things, expensive, difficult to use, and slow.

In 1978, MMI (Monolithic Memories, Inc.) released the first PAL (Programmable Array Logic) device, a simple 10-input, 8-output, 20 pin DIP – and the digital engineering world has never been the same. (Tracy Kidder's excellent book "The Soul of a New Machine," published in 1981, chronicle's the development, by a company called Data General, of the first mainframe, based on extensive use of PAL's.)

1980 heralded perhaps the first manifestation of a gate array, a device the manufacturer, Ferranti, referred to as a ULA (Uncommitted Logic Array). LSI followed soon after with the announcement of their CMOS arrays, which effectively laid the foundation for all large-scale, cell-based, ASIC devices used today. Then, in 1985, Altera changed the field again with the EP300, a UV-erasable, 3 micron, 300-gate, 8-macrocell, reprogrammable device.

Initially, programmable logic design tools were simple, text-based applications that adequately, if crudely, allowed engineers to capture logic intent. And, in order to control the complete design to silicon path, ASIC design tools, being much more complex, were written and owned by the silicon vendors.

But in the mid- 80's, Optimal Solutions arrived on the scene, heralding the era of independent, third-party, EDA vendor ASIC and (eventually) FPGA design tools. (Optimal Solutions would later become the company we now all know as Synopsys (from Synthetic Operating System). As the ASIC and field programmable silicon matured, so did the offerings from the software (EDA) vendors.

Another interesting bit of trivia: In the mid-50's, IBM unveiled the first commercial software compiler, based on the FORTRAN (Formula Translation) programming language. This was a major achievement as it raised the level of abstraction by removing the intricacies and inefficiencies inherent in assembly code, enabling engineers to scribe in a more human-readable format.

This in turn boosted productivity and improved the structure and maintainability of the software. (Ironically, we can thank the FORTRAN team for technology that even today enables software artisans to create thousands of lines of bug-infested code very, very quickly.) High-level RTL languages such as VHDL and Verilog, and compilers such as Synopsys' Design Compiler deliver the same benefits to hardware engineers. More about why this is relevant later.

In theory, this sounds great. Better silicon, better tools, everybody's happy, right? The problem is that the EDA vendors, and even the FPGA and ASIC vendors for that matter, forgot that, sooner or later, the FPGA or ASIC needs to be placed on a printed circuit board and routed to the other components. The result is that most solutions seem to focus on either the silicon or the board but not both at the same time. In fact, it wasn't until about four years ago that any EDA vendor finally acknowledged that getting today's FPGA's onto a PCB (in a way that doesn't create a routing nightmare for the PCB designer) is a huge problem.

A typical FPGA-based system design flow
In order to illustrate this, let's look at a typical FPGA-based board-level design process as illustrated in Fig 1.

1. A typical FPGA-based system design flow.
(Click this image to view a larger, more detailed version)

Of course this figure isn't meant to represent every FPGA-on-board design process; but at a high level, it does represent a typical flow.

• In general, FPGA pin assignments are created by the FPGA designer in his effort to define the structure and logic of the FPGA.
• From there, a set of symbols are created by importing the pin assignments into the symbol creation tool. The data to do this is captured in, or transcribed into, a text file, a spreadsheet, a Visio drawing or perhaps a combination of these. User-written scripts are also often deployed at this point. Compounding the problem, these semi-custom symbols are not always immediately available for placement in the schematic. Many times those symbols must pass muster with the librarian before they can be used in a design.
• Once a set of symbols are created and sanctified, the schematic capture process proceeds as usual.
• After schematic capture the design proceeds to PCB layout and routing.

This is, of course, not a forward-only procedure. Any changes to the pin assignments needed by the PCB designer (to meet routing or signal integrity or a host of other constraints) must necessarily be validated by the FPGA designer to ensure that the new assignments don't create issues for the FPGA functionality.

So the PCB designer feeds requests back to the schematic designer, who then passes those on to the FPGA designer, and the whole process starts over. Ultimately, the team spins in what seems like an endless loop, slowly converging on a set of pin assignments that work well for the entire system.

There are two glaring drawbacks to this approach. The first is starting the process by letting the FPGA designer pick the pin assignments. With no comprehension of the PCB topology, the FPGA designer is working 'blind', unable to fully appreciate the ramifications of the pin assignments on the routability of the PCB.

The second obstacle is that by the time the design does get to PCB layout, if pin swaps are necessary, the PCB designer knows nothing about the rules of the FPGA. He finds himself staring at an exercise in routing futility, with no tool-assisted knowledge about which pins can be swapped and which can't. He, like the FPGA designer, is working 'blind'. It's a classic case of the blind leading the blind.

Adding more FPGA's only makes matter worse. Throw in the need to maintain a consistent set of pin assignments across the entire design database, the demand to meet multiple (sometimes conflicting) constraints, and it's a wonder that designers aren't fitted for straightjackets by the time the board finally tapes out. Is anybody listening?
So, you might be asking yourself if any solutions exist to marry the FPGA to the board in a coherent, intelligent manner. Actually, there are several, and the differences in their functionality and approach to the problem might surprise you.

One approach is the "roll-your-own" solution. Here, the design team takes on the additional, usually unwelcome task of cobbling together spreadsheets and/or text files, writing scripts, and documenting (and presumably following) processes that minimize, but in the end do not completely remove, the pin assignment obstacles. This entire effort is a distraction from the real design work, fashioning a band-aid when the situation is screaming for a tourniquet.

Another tactic, the divining approach, is to simply use the FPGA vendor's tools aided, perhaps, by a graphical view of the component layout. In this scenario, the design team attempts to deduce and create optimal system-level pin assignments by working with a separate board placement illustration, often a Visio drawing.

As there is no electronic link between the graphical representation of the component placement and the FPGA vendor's pin assignment tool, pin changes require separate databases to be updated and synchronized – a manually-intensive process that is prone to mistakes. (This also begs the question: which source is the master?)

Finally, tools from the FPGA vendors have two other shortcomings: they don't understand anything even remotely resembling a PCB, and they operate on only one FPGA at a time (placing yet another demand on the designer's ability to divine system-optimized pin assignments).

A third method, which I'll call "the purgatory approach," delivers a user interface that uses the placed PCB to expose the poor pin decisions that have already been made and then offers various manual methods to assist the designer in improving those assignments. The downside here is that although the PCB doesn't need to be routed, it does have to be placed, so that the information necessary to reveal the problems can then be used to correct them.

This establishes a "chicken and the egg" condition, where the design team doesn't have the data required to create good pin assignments until after bad ones have already been made. In other words, they're forced to create at least part of the problem just so they can figure out how to fix it. At least one EDA vendor sells a product endorsing this methodology.

None of these approaches are ideal and they all boil down to the fact that in each case the right data is not available at the right point in the process. At the start of the design cycle the FPGA designer lacks knowledge of the PCB and at the end of the cycle the PCB designer knows nothing about the FPGA (other than what may be identified in a crude swap matrix, which is not nearly comprehensive enough to support pin swapping on an FPGA).

A smarter approach
Now what? Lacking a sound commercial solution, most design teams have been forced to employ one, or a variation of one, of the pin assignment methodologies described above. What is needed is a tool that allows designers to create pin assignments in the context of a PCB-like component layout. Before launching into an explanation of why this strategy has potential, it might make sense to review some of the constraints that every designer must deal with during the FPGA pin assignment process.

• Physical constraints: These define the characteristics and topology of the PCB " the physical placement of the components on the board. Clearly, high-quality pin assignments are directly influenced by the physical proximity of the connected components. Assigning signals to the lower left bank of an FPGA makes no sense if the other end of those signals connect to a component residing on the upper right of the FPGA (assuming of course that a conflicting constraint does not dictate the use of that lower left bank). 
   
• Electrical constraints: In the course of making pin assignments with a goal of producing a more-easily routed board, the FPGA pin usage rules must still be followed. Not all pins on an FPGA are created equal – and how those pins can be used changes as the design matures. A 3.3V signal, for example, cannot be placed (usually) into a bank already containing 2.5V signals. The FPGA will not pass DRC and will not function as intended. Adhering to the electrical mandates of the FPGA while simultaneously striving to ensure that the pin assignments are optimized for the PCB can be challenging, especially with a tool that does not use the PCB component layout data during the assignment process. 
   
• Logical constraints: Finally, the logical relationships between signals must be understood and respected. For example, data bits that are latched into a set of registers by a clock must be assigned to the FPGA so that the clock can be properly routed, in relation to the data, on the FPGA fabric. Source synchronous busses, in which the clock and data are generated by the same logic, are another good example. In this case, keeping these signals confined to the same section of the silicon is not only desirable, it is a hard requirement. The need to [also] abide by logical constraints is the single biggest reason why swapping FPGA pins in the PCB environment can be so dangerous; many designers and EDA tools fail to fully appreciate this. Swapping pins based on simple logical and electrical equivalency matrices completely discounts the fact that signals in a design have clear relationships that must be preserved.

Obviously there are many other constraints that figure into the picture but these are, at a high level, the top three. The main reason for complying with these constraints is to achieve high-quality results for the entire system. An FPGA that works perfectly is worthless if the PCB routing required to wire it up violates the design goals of the rest of the product.

For designs containing multiple FPGA's, achieving quality system-level results using the processes described in the previous section is simply unfeasible. The sheer complexity and magnitude of variables that must be concurrently dealt with can bring those processes (and designers) to their knees. That's not to say that high-quality designs with multiple FPGA's can't be realized. But doing so efficiently and productively is virtually impossible using traditional methods.

For many designers, it has become painfully apparent that a new strategy for designing FPGA-based systems is long overdue. One such solution is 7Circuits from Taray, Inc. 7Circuits uses a PCB-like "canvas", coupled with a user-configurable synthesis engine, to automatically generate I/O connections across multiple FPGA's.

In its quest to boldly go where no EDA tool has gone before, 7Circuits simultaneously considers component placement (physical constraints), FPGA usage rules (electrical constraints), and signal relationships (logical constraints) to synthesize pin assignments that are optimized for the complete system.

2. 7Circuits screenshot.
(Click this image to view a larger, more detailed version)

With conventional techniques, the designer must contemplate signal placement for every pin on the FPGA (not to mention all of the power and ground connections). 7Circuits raises the abstraction focus to the interface level, enabling users to specify not which pins on the FPGA must be connected but rather which components must be connected. It then uses its knowledge of the three constraints mentioned above to synthesize the best system-level FPGA pin assignments.

This not only boosts productivity, it delivers higher quality results and gives design teams a more repeatable, standardized, and maintainable FPGA pin assignment process.

So does this really work?
This may sound good, but does it work? Maybe the best way to make the case for this approach is by reviewing an actual customer example; in this case, a five-board, 48-FPGA system recently completed by Qualcomm. A screenshot of one of the boards, containing 16 Xilinx Virtex-5 FPGA's, 1 Xilinx Virtex-4 FPGA, and 2 CoolRunner CPLD's, is shown in Fig 3.

3. One board in Qualcomm's five-board system.
(Click this image to view a larger, more detailed version)

Prior to their deployment of 7Circuits, Qualcomm's process (Fig 4) consisted of a combination of manually-intensive steps utilizing Microsoft Visio drawings, Excel spreadsheets, assorted scripts, and a lot of communication.

4. Qualcomm's original design process.
(Click this image to view a larger, more detailed version)

1. To start the design, engineers first captured bank-level pin assignment intent in a spreadsheet.
2. Using this information, a Visio drawing was created to establish a visual link between connectivity and PCB component placement. The Visio "layout" thus formed a more complete view of the final design, allowing the team to quickly see the correlation between PCB topology and bank-level connectivity.
3. Next, a CSV file was created by manually combining the Visio drawing with the spreadsheet.
4. This CSV file was then imported into the schematic tool, where Qualcomm-written scripts were used to generate schematics and UCF files (for use in the FPGA tools).
5. Finally, the schematics were forwarded to CAD for PCB layout and routing.
6. Pin assignment changes, which could come from multiple sources, triggered modifications to both the spreadsheet and the Visio drawing, starting the entire process over.

The challenges associated with this intensely manual process were numerous...

• Creating and keeping the Visio drawing up-to-date and in sync with the spreadsheet was tedious and exacting.
• Manually merging the Visio drawings with the spreadsheets to create the CSV file for schematic generation was very error-prone.
• Managing the multiple FPGA voltage levels, thousands of I/O connections, and number of I/O standards was arduous and time-consuming.
• Picking FPGA bank locations to minimize PCB trace length was difficult to visualize and accomplish.
• Creating the actual PCB layout required face-to-face interaction with the PCB designer.
• Ensuring correct power, ground, and reference voltage connections entailed careful, manual review of the FPGA files.

...and the ramifications were painful...

• Correctly implementing change requests required a rigorous attention to detail in order to keep the data correct and in-sync in both the Visio drawing and spreadsheet.
• Initial, non-optimized FPGA connections led to multiple iterations between the CAD and FPGA teams in an attempt to improve first-pass PCB routability
• I/O pin assignments spanning multiple FPGA's had to be made manually, extending the PCB design cycle.
• PCB routing constraints, pin changes, etc., required multiple PCB/FPGA iterations to achieve closure, especially during the final design stage (the worst possible time!).

This process was employed on several projects, the most recent (prior to the 48-FPGA system discussed above) being a 19-FPGA, single board effort that required six months, not including final PCB layout and routing.

Contrast this with Qualcomm's new process based on 7Circuits (Fig 5). Not only is this process less complex and more automated (read, less error-prone), it is also more repeatable and maintainable.

5. Qualcomm's new process founded on 7Circuits.
(Click this image to view a larger, more detailed version)

1. The interface-level connection requirements and PCB "floorplan" are captured in 7Circuits. Using its knowledge of the FPGA rules, floorplan, and signal constraints, 7Circuits synthesizes the FPGA I/O pin assignments for the entire board, including power, ground, and reference voltage connections. Once complete, 7Circuits generates a CSV-formatted file of the results.
2. The CSV file is imported into the schematic tool, where the Qualcomm-written scripts are used to generate the schematics and UCF files.
3. The schematics are forwarded to CAD for PCB layout and routing.
4. Changes are handled easily by modifying a single source, the 7Circuits input data. 7Circuits implements the new connectivity and outputs a new CSV file.

It should be noted that – due to the fact that the Qualcomm scripts performed other, Qualcomm-specific, schematic-related tasks – Qualcomm chose to not use two key 7Circuits features: the ability to automatically generate the UCF files for the FPGA's as well as the schematic set for the FPGA-related portion of the design.

Comparing the new process to the old process, the improvements are obvious as illustrated in Table 1.

Table 1. Comparison of Qualcomm's old and new processes.
(Click this image to view a larger, more detailed version)

• Qualcomm was able to complete a 48-FPGA, five-board design in half the time of their previous 19-FPGA, single-board system – a more than 100% productivity boost.
• The entire FPGA and electrical design process was simplified. By enforcing the FPGA, board, and design-specific rules, 7Circuits was able to completely automate the entire connectivity process, including all logic and power-related assignments.
• Validation and testing was more straightforward and efficient.
• 7Circuits' rules-based engine established the foundation for a correct-by-design result.
• Lastly, and perhaps most significantly, PCB routing times were reduced from days to hours.

Qualcomm recognized that their old processes were not going to scale well to larger systems, and that a radical change in methodology was going to be needed if they were to have any hope of keeping up. To this end, they adopted 7Circuits, which helped simplify and improve their design flow.

By replacing manual, tedious, and error-prone steps with automation (including I/O synthesis), they were better able to manage their FPGA pin assignment effort and incorporate design changes and ECO's more easily. In the end, their new flow afforded them a significant boost in productivity while simultaneously improving the quality of results.

Even small designs can benefit
While the productivity benefits from the approach discussed above might be somewhat obvious for large, multi-FPGA designs, even designs containing only a few FPGA's can benefit. The screenshot in Fig 6 is of a portion of an actual production design. As you can see, the two memory chips above the FPGA and the two connectors at the bottom have been connected to the FPGA with little attention paid to the PCB.

Will the board auto-route to completion? Probably – but at the unnecessary expense of extra vias and possibly an extra layer. Had the FPGA designer, or system designer, or whoever picked the FPGA pins assignments spent much time at all considering the system-wide ramifications of the pin locations, these particular FPGA pins would likely not have been chosen.

6. Small FPGA-based design with crossovers.
(Click this image to view a larger, more detailed version)

Now ponder the same design, but with the pin locations picked using 7Circuits, where not only the FPGA but the component placement constraints are considered concurrently (Fig 6). The superior choice of FPGA pin locations is readily apparent. This design will route faster and consume fewer vias in the process. If any of these signals are high-speed signals, this optimized design will also exhibit improvements in signal integrity.

7. Small FPGA-based design with optimized connections.
(Click this image to view a larger, more detailed version)

What is not apparent with the second screen shot is the amount of effort (or lack thereof) that was expended in creating these optimal pin assignments. With 7Circuits' ability to raise the level of abstraction, this design is not only superior to the original, it was also created in less time since the focus was moved from the FPGA pin level to the component level.

Instead of picking the pins individually (or with one of the other inefficient methods mentioned earlier), the components were placed on the 7Circuits canvas (Fig 8), device-level connection intent was specified, and 7Circuits automatically synthesized the FPGA I/O pin assignments (in this case in less than a minute).

8. Optimized small design in 7Circuits.
(Click this image to view a larger, more detailed version)

Summary
Semiconductors have progressed faster than any technology in human history. Programmable logic is no exception; it could even be said that this particular niche is the ultimate example of the pace of electronics development. From the simple 20-pin components that revolutionized digital design 30 years ago, to the 1700-pin FPGA's available today, the path to cramming more and more stuff into a smaller and smaller space seems to have no end. And thanks to the advent of HDL's and synthesis tools, making use of all that silicon is even easier than it used to be.

Unfortunately, for the system designer, all that cramming is only making everything harder to swallow. While the internal complexity of the devices themselves has grown by orders of magnitude, the tools and techniques for designing those devices onto a PCB just haven't kept up. It is more difficult to design-in a 1500 pin FPGA today than it was to design-in a 500 pin FPGA ten years ago. The reasons are simple and obvious: thanks to the EDA vendors' inability (or unwillingness) to address the problem, engineers continue to be saddled with the same old tools, forced to either create their own solutions or resign themselves to doing it the old-fashioned way. Not a lot of options.

With the design community crying "uncle", new tools are finally hitting the market – not from the major EDA vendors (although to be fair at least one of them has attempted to give it a good shot), but from smaller companies. One, from Taray, Inc., is 7Circuits, a product that uses synthesis technology to simultaneously attack the problem on both the FPGA and the PCB fronts.

As evidence of the soundness of this approach, Qualcomm was able to cut their design cycle in half – while more than doubling the number of FPGA's and quintupling the number of boards in their system. And while the Qualcomm design is arguably at the upper end of the complexity scale, smaller designs can benefit, too.

For more information on Taray's 7Circuits product, you can view a Short Introductory Video.

Bruce Riggins has 25 years of experience in various roles, including electronics design, applications engineering, consulting, and product marketing.

Bruce has held positions at Boeing, Veribest, Mentor Graphics and Intrinsix and is currently the marketing and applications manager for Taray, Inc.