Prototyping ASICs using FPGAs -

Prototyping ASICs using FPGAs


This “Product How-To” article focuses how to use a certain product in an embedded system and is written by a company representative.

Electronic system designers are today in need of a new debugging approach that is fast, affordable and addresses both hardware and software errors. In terms of debugging hardware it's no secret why the old methods are no long sufficient. Chip complexity is rising fast.

The products they power are growing rapidly in functionality as consumers demand more and more features. Cell phones that used to do no more than make phone calls are now asked to do everything from taking pictures to surfing the Internet to playing sophisticated games and much more.

Gaming consoles provide features like real-time 3D display and interaction that just a few years ago required tens or hundreds of thousands of dollars worth of hardware. Televisions, DVRs, even your kitchen appliances are being asked to do much more than ever before.

Yet size, weight, and cost restrictions remain as exacting and as important as ever. The only way to accommodate all these demands is to pack more and more content into the ASICs that deliver all the features people want, and that means vastly higher densities. And as gate counts rise, the potential for errors rises, too.

As if the hardware challenge by itself wasn't formidable enough, design teams must increasingly also deal with the emergence of chip-borne software that is at least as much of a design and debug challenge as the hardware itself.

Drivers, middleware, controllers, and even application code now reside on your ASICs. All this co-resident technology compounds the design challenge to be sure, but it has a far greater impact on the verification challenge.

As a result, companies are finding that detecting, isolating, and correcting bugs in a design is completely swamping the original creation in terms of time, cost, and engineering resources.

In short, we still have a verification crisis to deal with. Not long ago at all, we simplified matters by debugging a design's hardware first, creating silicon, and then tending to the software. Each step was short enough back then, and trying to save time by overlapping hardware and software debugging was not worth considering.

But with the complexity of today's hardware and software designs, time-to-market pressures no longer make sequential debugging a viable approach. Besides, a hardware bug could always evade detection until the software debugging stage, leaving you with no choice but to re-spin the hardware ” often with a calamitous impact on cost and delivery dates.

Therefore to stay competitive, companies no longer have the luxury of doing everything sequentially. They must debug the hardware and the software at the same time and in an environment where changes of all kinds can be made quickly and easily.

A Comprehensive Debugging Environment
Rapid prototyping with FPGAs can mean a three to six month head start to an ASIC project. Using reprogrammable FPGAs to test and debug all aspects of a design concurrently, can accelerate the design cycle and get the surprises out of the way before committing a design to silicon. But using the right hardware platform, an FPGA board, is not enough.

You also need the right debugging environment for testing your design: an FPGA-based rapid prototyping system that lets you overlap hardware and software debugging. Until recently, all approaches to debugging complex ASIC designs suffered in the area of productivity.

Some were fast, but did not provide the visibility necessary for figuring out what design behavior was causing bugs to occur. Others provided the necessary visibility but were excruciatingly slow, so slow that debugging teams lost their time-to-market edge waiting for answers. Still others were extremely expensive and still fell short on visibility and speed.

To achieve the potential of rapid ASIC prototyping, designers have desperately needed an affordable debugging environment for FPGAs that delivers both high visibility and high speed. As is so often the case in the semiconductor industry necessity has proven to be the mother of invention.

With the debugging challenge arising from increasingly complex hardware and the growing prevalence of chip-borne software now posing a serious risk to design efforts, Synopsys unveiled its Identify Pro application based on TotalRecall technology.

Used in conjunction with Synopsys' Synplify Premier FPGA synthesis product, this toolset supports an approach to FPGA debugging that simultaneously achieves speed and high visibility, while keeping costs low.

It is far more than simply a refinement of traditional debugging strategies as new challenges demanded a new approach. However, to best understand this new paradigm it is worth first reviewing conventional debugging methods.

Conventional Debugging Approaches
By themselves FPGAs are poorly suited for debugging. They do not provide the visibility necessary for understanding the design behavior that is producing bugs. Thus as a debugging platform they are far from inexpensive ” they cost too much in terms of design cycle time and engineering resources.

At the other end of the spectrum are RTL simulators. Since designs start out as RTL code in the first place, it is easy to plug that same code into a simulator and then take advantage of the great many debugging features and functions that today's simulators provide. There is nothing better for visibility.

On their own however, RTL simulators suffer an enormous disadvantage – speed. Cycle for cycle, simulators are on the order of a million times slower than FPGAs. Finding even a routine bug is a time-consuming affair, and finding an elusive bug – perhaps caused by a once-in-a-great-while intermittency – can take months, if it can be found at all.

These deficiencies are not new, and so the industry has come out with alternative approaches that have helped, but only to a limited degree. To boost the speed of RTL simulation we now have hardware accelerators, but they add cost and even with their help simulation still falls far short of an FPGA in speed. Then there are the really expensive solutions ” hardware emulators ” but even they cannot match FPGAs for speed or simulators for visibility.

Combining FPGA-based Rapid Prototypes and RTL Simulators
The ideal solution is clearly a debugging environment containing both FPGAs and RTL simulators in which each does what it does best ” the FPGAs run at their full unparalleled speed while RTL simulators provide the ultimate in visibility and debugging features.

But how to connect them? One answer is to employ the TotalRecall technology implemented in the Identify Pro product in conjunction with Synplify Premier for synthesizing designs from RTL (Figure 1, below ).

Figure 1: The key concept underlying TotalRecall Technology is to replicate logic inside the device.

As you can see in Figure 1 above the diagram above, TotalRecall adds two new components in addition to a design synthesized by Synplify Premier. One is a replica of the design, and the other is a memory that buffers up a user-defined number of clock cycles worth of the stimuli applied to the design.

In addition, triggers and/or assertions are added to the original design so that the detection of an error causes a signal to be sent to the replica telling it to instantly freeze the contents of all registers and the stimulus buffer.

Then, to commence the debugging process, both the design and its replica are run at full speed in the FPGA. Stimuli are then applied that not only flow through the original design but are also buffered up and delayed in the memory and sent through the replica.

Then when an error condition occurs, the triggers cause both the current state of the replica and the contents of the stimulus buffer to freeze, while the original design continues to run. The content of the stimulus buffer and the current state of the replica are now used to create a Verilog testbench that will be simulated in an RTL simulator such as VCS from Synopsys.

Since this buffer contains on the order of several hundred to several thousand cycles worth of stimulus history, the set of conditions that caused the bug are usually contained somewhere within it. When these conditions arise during the replay on the simulator, the user employs the debugging features of the simulator to track down the reasons for the bug and repair the design.

Detecting errors
Two methods for detecting error conditions and triggering a freeze of the replica design state and stimulus buffer are supported. One is to embed “logic analyzer” macros into the design that monitor specific signals and watch for values outside an expected range.

The second, more elegant, method is to employ assertions, which are in essence descriptions of the intended behavior of a design. Assertions can represent operations that are considerably more complex than simply monitoring a signal for breakpoint conditions ” an output pattern many bits long for example.

To employ assertions, the user codes up the expected behavior in RTL and infuses this code into the original design, whereupon during verification TotalRecall monitors actual behavior and triggers a freeze when this behavior fails to comply with expectations.

This approach makes assertion-based verification practical in cases where it has been difficult because of the depth of test vectors that can be captured for fully understanding the sequence of actions that caused an assertion to fire.

Like the design itself, assertions are expressed at the gate level in the FPGA itself and need to be referenced back to RTL to be useful in simulator debugging. And like the design itself, assertions can be accurately traced back into RTL because they too were synthesized in Synplify Premier, which remembers all the steps employed in creating their gate-level representations.

Automatic Creation of the right Testbench
Conventional methodologies for using RTL simulators for ASIC prototyping with FPGAs are slow not only because simulators themselves are slow, but because generating testbenches that are well-suited to exposing error conditions is difficult and time-consuming.

The testbench that is generated is well-suited for debugging because by definition it exposes the conditions that are known to have caused the bug to occur. Furthermore it takes minimal engineering time to create since it is automatically generated and loaded into the simulator as part of the process.

Debugging specific blocks of a design
In some cases the FPGAs are not big enough to hold the original design, the replica, and the stimulus buffer. For designs that consist of multiple blocks, it is possible to overcome this issue by debugging the design a block at a time with TotalRecall as shown in Figure 2, below :

Figure 2: TotalRecall technology can be applied to a subset of the design

In this case, only the block of interest is replicated and it is the inputs to this block that are stored up in the stimulus memory buffer. The methodology operates as above except that when a trigger condition occurs, the block being debugged and only that block is replicated and debugged in the simulator, using the stimulus buffer contents as its testbench.

Using this approach, each block of the design is debugged in sequence, starting with the first block. It works as long as no one block and its replica are too large to fit in FPGA memory along with the stimulus buffer.

Extending FPGA Memory
Certain designs do not lend themselves to debugging a block at a time. Even if they do, the FPGA still might lack the memory needed to replicate large blocks and their stimulus buffers.

In these cases, debugging teams need a way to extend FPGA memory if they wish to employ TotalRecall. A solution to this problem is to plug the FPGA and an add-on memory chip into a printed circuit board.

This add-on memory serves as an extension to the FPGA's own memory, providing sufficient space to replicate entire designs of virtually any size as well as the stimulus buffer. Synopsys provides such an environment with its HAPS High Performance ASIC Prototyping System.

Tracking Down Elusive Intermittent Bugs
Many a time ASIC prototypers using FPGAs have observed a completely unexpected result from a design and said to themselves: “Wow, look at that behavior! I sure hope I can recreate it.”

Sometimes they can after a great deal of work, but other times they simply cannot because the bug was caused by an intermittency or an extremely unlikely coincidence of events that takes a week, a month, or a year to arise again, if at all ” until it shows up again in the end-user product.

The methodology described here addresses exactly that situation. The system remembers everything that could have contributed to the behavior ” the state of the design at the moment the bug occurred and all the stimuli the design was receiving at that time and for many clock cycles before. As a result, debugging teams do not need to wait ” and hope ” for rare bug-causing situations to arise again.

Rather they can go “back in time” to the stimuli that actually caused a bug and use them as a testbench to analyze and debug the design. Since other debugging methods count on a recurrence of the error-causing conditions, it is difficult or impossible for them to find these “one-in-a-million” bugs.

A Fast-Forward Button for RTL Simulators
The march of complexity in ASICs will continue unabated indefinitely, ever heightening the need to use FPGAs to prototype ASIC designs and RTL simulators to debug them. All the added complexity will only slow down these already ignominiously slow simulators unless novel technology comes to their aid.

With the this approach, the test and verification process runs at full speed almost all the time, because the FPGA that is used in testing the design is running at full speed and the slow component of the environment, the RTL simulator, is idle and out of the loop.

Only at those moments when an error occurs does the RTL simulator spring into action, wasting no time testing instances of intended design behavior and instead contributing only when its contributions are vital for efficient debugging.

Using the techniques described here allows RTL simulation to rise to the top of the preferred methods for ASIC prototyping. This approach preserves simulators' visibility, productivity, and cost superiority over all other debugging methods while turning their glaring deficiency, speed, into an asset.

Juergen Jaeger is Director, Product Marketing, Confirma Rapid Prototyping Platform, at Synopsys, Inc. and brings over 20 years of experience in marketing and product marketing of design and verification solutions for ASICs. He is responsible for the Confirma ASIC/ASSP verification platform including the HAPS prototyping system. Mr. Jaeger studied electrical engineering at the Fachhochschule of Kaiserlautern, Germany and computer science at the University of Hagen, Germany.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.