Case 2 : Your boss just read his favorite EDA magazine and is all excited about "Design Reuse." Your next design assignment involves adding new features to an existing design without breaking the old features set. How do you do this efficiently?

Now what do I do?

The first case might allow formal verification, while the second case precludes it by definition.

Where formal verification is an alternative, tools such as Chrysalis by Avanti (Fremont, CA) are capable of mathematically proving that two designs are identical. These tools are not perfect though, as they are expensive and have problems with extremely large designs.

There is, however, another practical solution. You can employ the original test suite to validate the new design. The goal would be for a given stimulus of each valid output of the new design to match the stimulus of the previous design. We're going to present a basic methodology that has been employed twice recently on quite different problems with very successful results.

Why Argue With Success?

Using comparison between two different descriptions of a design is a time-tested method. For example, the space shuttle employs several levels of redundancy within its design. This redundancy exists both in hardware and software components. Within the software side of its systems, the main control computers run one set of software with complete mission capability on a interrupt-driven priority scheme. At the same time, a back-up computer is running a separately derived minimal-software package capable of no-frills take-off and landing management executing on a time-sliced operating system. These two systems come to a mutual check-point and then compare whether they both reached the check-point simultaneously. This check-point system is similar to the comparison method described below and in-fact, was used to debug both software systems.

A popular design methodology for large complex designs involves first writing a description of the algorithms involved in a design in a higher-level language. This description is used to derive test vectors for the RTL-based design. When the resultant vectors don't match, the difference indicates a design problem. When all the vectors match ý it's time for silicon.

Methodology

The input and bi-directional ports of both versions of the module should be connected with nets of the original design and driven with the input vector from the test bench.

The output from the old module will remain connected as in the original design while the output from the new module is used to drive one side of a comparator. This on-the-fly comparator also receives the outputs from the old module (see Figure 1). Use whatever state is appropriate to determine when to sample the comparator output. If there is a "valid" signal used to move data from one stage to the next this might be needed to qualify the sample. These should also be done synchronously.

Both designs should be excited in exactly the same way. In situations where you are verifying a stage whose inputs originate in another module under test, feed the new designs' inputs from the old designs' outputs. You want correct inputs and the assumption is the old design is initially correct.

If you are faced with the translation scenario where two different HDL languages are involved, it can get interesting. The good news is that if those HDLs are Verilog versus VHDL, then there are quite capable simulation environments like Model Tech by Mentor Graphics (Wilsonville, OR) that can handle simulation with modules written in both HDLs simultaneously with no major headaches.

Figure 1 - The EASY way to debug your design

By driving both the new and old design with the same test vectors and adding a comparator, you can simplify your debug task.

Once all of the new modules under test have been validated against the entire test suite you have shown that for the given set of inputs represented by the old design test suite, the outputs of both the new and old design are identical.

For the case where some signals run between modules (which is the normal case) you next need to validate that the new designs outputs can drive the new designs inputs and still get the same final output. Do this by swapping the input source of the new design one module at a time and repeat the test suite. By the time you've completed the swap-in of the new design for the old in this process, you've managed to run through the entire test suite using the new design.

Advantages

This methodology has several nice features. Differences between the two designs are immediately obvious at module level. Expensive and exotic tools aren't required to get the job done and the methodology works under some conditions where the exotic tools simply wouldn't function.

Since you are doing a cycle-by-cycle comparison between the new and old designs, the test bench will detect a difference between the two designs every time the difference occurs. This identifies not only the failing signal, but the clock at which it failed. Merely back track along the logic cone to determine where the two designs differ. Correct the difference and move on.

This method involves adding more test code in a fashion that makes the test bench self-checking without the need of tools beyond the simulation environment already being employed. When a design differs in function, in particular, the addition of pipe-lining, formal verification becomes impossible. This method can deal with even this pipe-lining issue by simply delaying when the comparison occurs.

The Real World

The original problem mentioned verifying that a VHDL and Verilog description of the same design were equivalent. We were faced with exactly this problem recently with one client. The VHDL was hand translated to Verilog since this project was "on a budget" and automatic translating tools weren't available. This came out to around 7000 lines of code to verify. While not a huge design, it wasn't trivial either.

Once the translation for a module was completed, it was placed in parallel with the original VHDL module and a comparator was added across all the module outputs. Testing began while the translation effort was still under way. As the test suite was run several compare errors occurred. Each was followed up and corrected. Eventually we managed to get all of the tests passing in this parallel configuration.

Next, the inputs on one module were changed so that the new design provided its input. All of the comparators remained in place and the test suite was run again. This process was repeated until all of the inputs on all of the new modules were being sourced from the new design. At this point we've managed to get the designs to the same level of conformance with the test suite and, because of the methodology, managed to do it in a straight-forward manner. We had a good idea of our progress and knew quite literally when the job was accomplished.

This same bag of tricks came into play at our very next job as well. Another dual-language scenario was involved, but this time with pipe-lining as thrown into the mix. The client had a rather large design that needed to simply go "3-times faster." A data-path design tool was employed to re-write several of the modules. This data-path tool automatically inserted pipe-lining to accomplish its speed goals. The new and improved design was emitted in both as gate-level and behavioral Verilog modules.

The behavioral output of the tool was placed in parallel with the original design. The original design's output was delayed by the depth of the pipeline and the two vectors were compared at each clock. The test suite was run against the parallel design and any problems encountered were corrected. This comparison method not only assisted in the initial debug, but was an additional comfort factor in illustrating the correctness of the new design since the test suite hadn't been used to produce working silicon yet. Eventually the translated design became the "golden" design base, and the original Verilog was discarded.

A twice tested tale of success

We've used this method twice now on very different sized designs. It has the advantage of being simple and "cheap" to use. It is also quite good about giving you a feel for how you're progressing with the debug of the new design since you know how far you're getting through the test suite before errors are encountered.

We're sure that we'll use this methodology again in future designs.

Yuri Tatarnikov is a technical manager at Intrinsix Corp working at the Fremont design center. He was founder and director of the VHDL Users Group in Russia.

Steve Wilson is a principal consulting engineer at Intrinsix Corp working at the Fremont design center. Steve has helped develop SCSI host adapters and high-end graphics chips.

To voice an opinion on this or any other article in Integrated System Design, please e-mail your comments to mikem@isdmag.com.