SoCs: Supporting Socketization -> Developing a configurable testbench

Developing a configurable testbench
By Marines Puig-Medina, Member of the Technical Staff, Tensilica Corp., Santa Clara, Calif, EE Times
January 3, 2000 (3:20 p.m. EST)
URL: http://www.eetimes.com/story/OEG20000103S0051

Designing and providing high-quality intellectual property (IP) to customers should mean more than just having a high-performance, reliable core. It should also mean providing the tools necessary to ensure that the IP is easily incorporated and verified in the customer's design.

Essentially, the Xtensa testbench includes the core, which is an RTL model, and other behavioral models implemented using RTL, C and Vera. Each of these components is automatically tailored to provide a customized testbench for a given configuration, which then is distributed to an Xtensa user.

The configurable nature of Xtensa posed several challenges to our verification team. The verification environment had to be flexible enough to include or exclude verification elements for various design components. For example, the Xtensa core may or may not be used with caches, implying respective changes in the final testbench.

This flexibili ty must also be reflected in the in-house tools that generate Vera testbenches distributed to an Xtensa core user. Generating innumerable legal instruction sequences and real-time self- checking testbenches were some of the other challenges that our verification team had to address.

A methodology was developed to verify all possible combinations of Xtensa cores and any new designer-defined instructions. The simulation-based approach uses fully configurable directed diagnostics and two families of pseudorandom diagnostics generators. One family was developed internally using object-oriented Perl, and the other family is based on the stream generator, part of the Vera hardware verification language. The Vera stream generator was used to generate assembly programs of elaborate legal sequences of Xtensa instructions. Rules for generating random sequences of these instructions were specified as constraints in Vera.

The sequences were then run on an Xtensa instruction set simulator (ISS) and the RT L in parallel with Cosim, a co-simulation program developed using Vera. Cosim also compares, in real-time, the execution of instructions on the ISS and the RTL and stops simulation on mismatches of architecturally visible states between the two.

Additionally, assertion checkers, written in Vera, continuously monitor a set of RTL signals or conditions (a sequence of events) and stop the simulation when a violation is detected. Tensilica used this environment to ensure that the Xtensa core in any configuration would match the behavior of the ISS reference model.

After the initial verification of Xtensa was complete, Tensilica used Synopsys' Vera Core to create a self-contained system-testbench environment. Designers can reuse and configure this environment to monitor the correct operation of their design with the Xtensa core in the SoC. During this step, the customer-configured processor is run in either a VHDL or Verilog simulator with any new designer-defined instructions.

The Vera "project" mechanism is used to promote reuse of some of the testbench code developed to verify Xtensa. The designer of the SoC can integrate the modules into their own system testbench by simply creating a project file that includes the desired modules and modifying the modules' connectivity information to reflect the new hierarchy. This task is simply accomplished by modifying the provided "vcon" file. Furthermore, when Vera is used for their verification environment, the SoC designers can also add new modules to the project file.

The ISS can run much faster than the RTL because it does not have to model every signal transition for every gate and register in the complete CPU design. The Xtensa ISS is a cycle-count-accurate instruction set reference simulation model. It executes about 300,000 cycles per second for basic simulation on a Solaris 360-MHz workstation.

Instruction set simulation allows programs generated for Xtensa to be executed on a host computer. This technique is useful when p orting native code to an embedded application because the ISS can be used to detect potential problems without downloading the actual code on the real embedded target.

The ISS is flexible and can serve as a back end for Xtensa's symbolic debugger, generate profiling data for the Xtensa profiling tool and interface to an external cache-modeling program. Co-simulation proceeds by running the VHDL or Verilog simulator and the instruction set simulator simultaneously. As part of this co-simulation, the tools check that after each instruction is executed, the architecturally defined state of the processor is the same in the two models.

For example, an instruction in the RTL may need to execute several functions, such as loading a value into a register, updating another register, multiplying two registers and putting the results into yet another register. In the testbench environment, all of these functions occur in both the RTL and the ISS.

All operations are coordinated between the Vera testbench and Cosim, and the simulation can be stopped to check if the appropriate registers are updated properly in RTL as compared to the ISS. This, in effect, compares what the RTL is doing against what it should be doing. Any designer-defined tests will be automatically invoked during the final verification of the processor, and status reports (pass/fail) will be created for the entire set of diagnostics.

Tensilica also uses functional coverage monitors and modules, written in Vera, for checking Xtensa's caches and data to ensure that the design is adequately verified. Some designers try to simplify this step by using RTL line-coverage tools to make sure that all the lines in the RTL have been exercised. The Tensilica environment goes a step beyond. It looks at the microarchitecture specification and finds sequences of events, not just lines of RTL, that need to be executed. This ensures that the critical functions of the microprocessor in the design are verified.

The Xtensa core is used in a variety of applications from telecommunications to consumer electronics. Success with these customers has reinforced the belief of our engineers that it's not enough to provide a high-performance, portable, reliable core. A good IP provider must also supply the technology that gets its product into working silicon. As more engineers begin to design complex devices and rely on IP, this supporting software will only gain in importance. Astute IP consumers must look beyond the functionality of the IP they are evaluating to examine the entire design and verification environment that surrounds it. The result can mean the difference between making or missing a critical market window.