Eeeeek! My FPGA's not working: Problems with the *IP*

In my previous post (see my blog #222600858) I waffled on about the challenge of RTL mismatches in an FPGA methodology. This week we'll look at how using third-party IP can also introduce some nasty little issues...

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...

In reality, however, 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 flow. As an example, let's consider any third-party intellectual property (IP) blocks you may decide to incorporate in your design as illustrated in Figure 1.

Figure 1. Bugs can manifest themselves in any portion of the design flow; for example, the IP.

What about that Fast Fourier Transform (FFT) core you purchased to speed up your design cycle? It seemed like such a good idea at the time you were selecting it, but integrating it into the rest of the design is another matter.

In the case of ASIC designs, any third-party IP cores are typically presented in the form of RTL (encrypted, obfuscated, or unencrypted). Thus, the same RTL representations of the IP blocks that are used during initial software simulation are subsequently synthesized, placed, and routed along with the rest of the design. This provides a high level of confidence that the RTL and gate-level representations of the design are functionally equivalent.

The situation is very different in the FPGA domain because the third-party IP models used for software simulation may be different to the corresponding models used by the FPGA's place-and-route software. That is, the IP vendor often supplies two different models " one at a high-level of abstraction and one at the gate-level.