Verification and FPGAs

aliss · Junior Joined: Jan 07, 2004 Posts: 7

I am currently trying to determine the verification needs in our organization. We are a company that makes products that require subsystems/boards with the typical controls, dsp and data buffering/acquisition functions. Since we have low volumes, most, if not all, of our boards are designed with FPGAs, rather than ASICS. The real bottleneck for us, in terms of re-spin time, ends up being the boards, and not the HDL-designed chips (FPGAs) on them. A typical design might have 10k lines of RTL code, a pci core IP, sdram controller etc. We have some in-house vhdl-based transaction generators and bus functional models. Other than that, our testbenches are more vector-oriented, than transactions-oriented.

The important point to note however, is that any functional bug, when discovered in a system, can be reproduced after a few hours of head-scratching and force- release-ing signals in a vhdl simulator, and fixed. A re-spin does not have a high cost associated to it. Thanks to FPGAs.

What should be the verification environment in such a setting? Should HDLs be enough for FPGA-based designs? Is investment in more sophisticated environments (assertions, hvls or other higher level libraries) warranted? What is the industry's take on this?

This question should become increasingly important (unless there is a one-line answer to it), as FPGAs become more and more feasible.

vhdlcohen · Posted: Mon Jan 12, 2004 1:26 pm **Post subject:**

Alis,

aliss · Junior Joined: Jan 07, 2004 Posts: 7

My own gut feeling was also that assertions and sugar are probably the best verification methodology that we could adopt. Executable specifications and the ability to do whitebox/blackbox testing in a compact form make assertions a very powerful concept. Also, the implementation of ABV (as sugar comments) makes it easier to adopt it.
But the issue is also a more general one: what is the industry's view on the amount of functional verification effort needed for FPGAs. How does that compare with what is needed for ASICs.
Right now, from what I have seen, it seems to be blow and go. You create directed tests and scenarios, simulate those, and put the chip in the system. So long as software doesn't complain, you are all set. When you hit a bug, recreate it in simulation, view the waveforms, and create a fix for it. The amount of time needed for a respin can be anything from a few hours to a few days.
Or, if I could be more specific, does one need to concern himself with higher levels of abstraction, and libraries like testbuilder? Should I, knowing that my design would end up in an FPGA, continue to develop my testbenches in HDLs, or should I invest in more extensive verification using C++ libraries?

Mike · Newbie Joined: Jan 06, 2004 Posts: 3

Hi Aliss,

The "blow and go" approach might work for small designs (50k gates or less), but as the designs grow in size and complexity, you may find that the amount of time spent in the lab verifying the design gets out of hand. I parachuted into just such a development and I can tell you that there is a lot of "spinning the wheels" going on.

Also, if there are plans to cost-reduce to ASIC, I would recommend a more methodical approach with the FPGAs.

Mike

vhdlcohen · Posted: Mon Jan 12, 2004 3:26 pm **Post subject:**

aliss · Junior Joined: Jan 07, 2004 Posts: 7

Let me give a specific example.
I recently worked on a PCI card that received data from a fiber optic cable, buffered it, and then bursted it out into the system memory. The card was inherited from a similar system, and so there were only minor modifications that were required (slightly different data format, different data rate etc.) PCI and a dram controller IPs were used. There were some configuration registers insde the logic. The testbench was an in-house configurable pci master and slave vhdl model. Data was pumped in from the vhdl on the fibre side, and ended up on the pci bus. Some directed tests (from the requirements document) were also simulated. The requirements were well-specified, but ofcourse, not executable.
When the board came in, it was plugged into the system, and software carried out other tests (from the specs); any bug identified was created in simulation, and changes were made to the VHDL code, and the fpga reprogrammed. (The criticality of this particular application was low.)

Given that such scenarios are typical, (and granted that ABV is still a good idea), should we invest in functional verification using testbuilder sort of libraries? Or should we stick to VHDL for testbenching, especially, if we supplement it with ABV? I guess thats the short question that I am looking an answer for.

Thanks for all your useful comments.

vhdlcohen · Posted: Mon Jan 12, 2004 8:50 pm **Post subject:**