Arrgghh! My FPGA's not working: Problems with the *RTL*

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.