Using yesterday's methodologies to design today's multi-FPGA systems is a recipe for disaster

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.