Maybe you're an ASIC designer forced by short product lifecycles to move into FPGAs. Or perhaps you're a team leader whose latest project requires chip-level integration, and an FPGA implementation seems to be the obvious choice. Or possibly you're actually used small- and medium-sized FPGAs in the past, but your new project requires you to push the envelope with the newest, highest-performing, highest-capacity FPGA architectures.

The problem is that you've been led to believe that getting a design to work on an FPGA is relatively simple. How hard could it be? All you have to do is capture the design, simulate it, synthesize it, load the resulting configuration file into the FPGA, test the result, modify the design, and repeat...

Simulate > Synthesize > Load > Test > Modify, Simulate > Synthesize > Load > Test > Modify, Simulate > Synthesize > Load > Test > Modify... It sounds easy enough, doesn't it? In reality, however, although Apply > Lather > Rinse > Repeat may work in the case of shampooing your hair, that reality is that designing with high-end FPGAs is harder than you think!

One problem is that we all tend to have high levels of faith in various aspects of the FPGA design flow, but it's not long before we discover how unfounded this faith can be. In reality, bugs can manifest themselves in any portion of the FPGA design flow. As a simple example, let's consider the RTL as illustrated in Figure 1.

Figure 1. Bugs can manifest themselves in any portion of the design flow; for example, the RTL (click on image to enlarge).

Once you've captured your RTL, you loop around performing functional simulations, checking the results, and tweaking anything that concerns you until you are happy with the way things look. Eventually you synthesize the design to your FPGA target, load the configuration file into the FPGA and run. But what's this? Something's gone wrong!

You re-check your RTL and your simulation results. Both appear to be correct. You add some debugging logic around what you think may be the problem. You re-run synthesis—and associated tools like place-and-route)—all of which may take hours or days. Things still are not working in the FPGA as expected, you can't see why, and you can't debug what you can't see. You're left guessing at the problem and running in crisis mode. All you can do is to keep on cycling through that "long loop": tweaking the RTL, simulating, running the synthesis and place-and-route, loading the FPGA, and hoping that if you "shake" things hard enough something useful will "fall out."

Why is this happening? What is going wrong? What you don't see is that your simulation runs are ignoring the pragmas intended for use by the synthesis engine " the directives that provide the synthesis tools with the flexibility to fit your design into the silicon. The end result is that your RTL simulation doesn't match your netlist and your FPGA implementation is overwriting registers that you didn't care about in your RTL.

But you don't know what is happening and you can't identify the problem because every step in the process appears to produce the results you expect ... until you reach the programmed FPGA. Simulation was fine. Synthesis and routing complete with no warnings or errors. The netlist loads without issues. But the FPGA doesn't work in the system and designing with FPGAs has suddenly become a lot harder than you expected.

An RTL Example
An RTL Example

Now you may be thinking to yourself: "How often does this sort of thing really happen?" Trust me, it happens more often than you might think. Consider the following example from opencores.org:

In this case, the engineer's well-intentioned desire was to produce a better quality gate-level implementation netlist. Unfortunately, this code is guaranteed to behave differently in synthesis versus simulation, because the synthesis pragmas will be ignored by the simulator.

The problem is that the pragma told the synthesis tool that it could make arbitrary decisions about unspecified choices. This is contrary to what happens in the simulator. The end result is that a register was overwritten when an unspecified address was written to inadvertently.

Of course there are a wide variety of linting tools available, but generally speaking the majority of FPGA designers don't have access to them and—even if they do—they don't use them. This is very different to the ASIC world, because ASIC designers have these tools and always use them. But design engineers in a traditional "FPGA shop" don't tend to have ASIC tools lying around; managers don't want to spend money buying them; the designers don't want to spend time learning to use them; and oftentimes the end result is ... not very pretty.

The Solution is the RocketDrive
The Solution is the RocketDrive

The GateRocket RocketDrive was uniquely developed to solve debugging problems with the traditional FPGA design process. The RocketDrive bridges the gap between the RTL and the FPGA.

Consider, for example, a design comprising say 100 functional blocks. Some of these blocks will be your own internally-developed, proven IP from previous projects; some will be IP from third party vendors; and some will be your newly-created "secret sauce" that will differentiate your design from all others.

Using the RocketDrive and its associated software, you can immediately move the gate-level representations of any "known good" blocks (your existing internally-developed IP and trusted third-party IP cores, for example) into the same type of FPGA you are targeting for your real-world design. Next, you can verify these blocks in conjunction with the rest of the design running in your software simulator of choice. Right-from the start, you are dramatically speeding your verification runs.

As each new block is verified at the RTL (or behavioral) level in the context of your full-chip design, its synthesized/gate-level equivalent can be moved over into the physical FPGA in the RocketDrive. As soon as a problem manifests itself, the verification run can be repeated with the RTL version of the suspect block resident in the simulation world running in parallel with the gate-level version realized in the physical FPGA. By means of a special software application, the signals from the peripheries of these blocks (along with any designated signals internal to the blocks) can be compared "on-the-fly."

Using this technology—combining conventional simulation with physical hardware and an appropriate debugging environment—it is possible to very quickly detect, isolate, identify, and resolve bugs, irrespective of where they originated in the FPGA design flow.