Subscribe by Email

Your email:

RocketBlog - a discussion about all things related to FPGA verification and debug

Current Articles | RSS Feed RSS Feed

Beware the IP mismatch in FPGA debug

Share on Twitter Twitter | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon | Submit to Reddit reddit 
IPIncorporating 3rd party IP in a complex ASIC design is a fairly standard practice these days. There's a lot of great functionality available, it saves time compared to designing from scratch, and by and large the IP is of good quality if you get it from a reputable supplier.

Should work the same for FPGAs right? Sounds simple enough - plug in the IP you need and verify it with the context of your entire design. You've got enough simulation horsepower and you can synthesize right to your FPGA target.

But there's a ‘dirty little secret' about IP for FPGAs that you should consider. For FPGA design, IP vendors often give you their cores as both RTL (for simulation) and FPGA netlist models for the device. So the IP models you use for RTL simulation differ in significant ways from the corresponding models the place-and-route software uses. Often, the high-level simulation model contains behavioral constructs to make the software simulations run faster. Synthesis tools cannot handle these constructs, however. Moreover, subtle differences often exist between the behavioral- and gate-level representations that manifest themselves only when you deploy the FPGA design in its target system.

This difference is one that can drive you bonkers, not to mention make your boss a little testy. So how do you deal with this? Even if you try adding some debugging logic around the IP block, it may not solve the problem, leaving you to resort to rounds and rounds of gate-level simulation - a tedious and time consuming chore to say the least. The long-chain test patterns are just too, well, long! Re-running synthesis and place-and-route in hopes of shaking out the bug is equally as time consuming and nerve wracking.

Wouldn't it be great if you could move directly between the RTL representation and the actual FPGA target chip to pinpoint the problem, without having to keep churning through synthesis and place-and-route runs? That's where GateRocket comes in. Our RocketDrive system bridges the gap between RTL and FPGA by putting your design into your FPGA directly. We give you the tools you need to move back and forth between RTL and FPGA without guessing, re-synthesizing and re-routing.

So don't let headaches from IP libraries get you down. The solution is just a call or a click away.


Comments

One alternative is to turn to those who supply the source code in VHDL or Verilog form, not only RTL. One such vendor is OrSOC<i/> and their OpenCores repository.
Posted @ Wednesday, March 17, 2010 9:46 AM by Jakob Eriksson
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics