How Tensilica verifies processor cores

How Tensilica verifies processor cores
By Dhanendra Jani and Steve Leibson, EEdesign
April 4, 2003 (7:51 p.m. EST)
URL: http://www.eetimes.com/story/OEG20030404S0039

Thanks to the relentless enforcement of Moore's Law by semiconductor vendors, system-on-chip (SoC) design is now stuck in a messy verification quagmire. Most estimates place verification at around 50-80% of the overall design effort for mega-gate SoC designs. Custom-built RTL hardware blocks require custom-built verification tools. Millions of gates on an SoC lead to dozens, hundreds, or thousands of RTL blocks that all require the creation of verification test suites.

Writing verification suites for every IP block in an SoC is like testing every purchased component before soldering it to a circuit board. This once-common manufacturing method is no longer considered good practice. No company except Intel can completely test a Pentium microprocessor before putting it on a board -- and no company does. They rely on Intel's testing and verifying the processor before shipping it to customers.

Similarly, requiring design teams to verify every block of RTL for every project can no longer be considered good design practice. Unless legions of inexpensive verification engineers suddenly appear on the horizon, SoC design must switch to a more efficient development model.

To crawl out of the SoC design-verification quagmire and profitably exploit those millions of available gates, companies must acquire pre-verified IP blocks in the same way they buy pre-tested chips. To do this, SoC design teams must have the same faith in the functional abilities of IP blocks that systems manufacturers have in the ICs they purchase from reputable chip vendors.

For many non-configurable IP blocks such as fixed-ISA (instruction-set architecture) microprocessor cores and for some configurable IP blocks, we're already there. Microprocessor cores are categorized as “star IP,” in part because these complex blocks come pre-verified from the IP vendor.

Pre-verification represents a significant part of the value supplied by the star IP vendor. Pre-verifying an IP core saves design teams a significant amount of time. In addition, an SoC design team, if it so wishes, can easily re-verify these star IP blocks using verification scripts generally included with the IP RTL.

The software programmability of fixed-ISA microprocessor IP cores allows them to accomplish many tasks on the SoC with no need to alter the hardware. Unfortunately, all fixed-core microprocessors run out of processing power at some point. Generally, SoC designers must then resort to RTL hardware coding to create hardware accelerators and coprocessors that can meet higher performance targets, and that's when design teams tumble into the above-mentioned RTL verification morass.

Configurable microprocessor cores can meet higher performance targets than fixed-ISA processors by giving designers the ability to tailor the processor's execution pipeline so that the processor can execute complex inner program loops in just a few instructions (or one instruction, in many cases). However, customizing a process or core can eliminate the verification advantages of purchased IP unless the product is designed to easily allow verification of the customized core. Fortunately, it's possible to create customizable IP while still providing the full benefits of pre-verification enjoyed by fixed IP blocks.

Tensilica's verification flow

Tensilica has developed a robust and flexible methodology encompassing checkers and monitors for the verification of its configurable and extensible Xtensa microprocessor core. The methodology generates a customized verification suite and a test bench for each configured processor. Using this approach, Tensilica is able to pre-verify a very large number of Xtensa processor configurations before delivering even one configuration to a customer.

To verify the large number of processors developed with its processor generator, Tensilica developed a simulation-based verification environment (Figure 1) that is automatically tai lored to a particular processor configuration.

This approach differs from conventional IP verification environments in its use of configurable verification components and automatic customization of verification programs. Tensilica implemented this customizable verification environment by combining internally developed and standard EDA verification tools such as simulators, formal verification tools, and hardware verification languages (HVLs).

Figure 1 -- Tensilica's simulation-based verification environment

Architectural verification programs (AVPs) check each instruction's execution within the processor's ISA, and micro-architecture verification programs (MVPs) check pipeline control and data hazards as well as the processor's actual RTL implementation. AVPs and MVPs employ Perl scripts that use the processor configuration information to generate high quality tests tailored to a specific Xtensa configuration.

The scripts add blocks of diagnostic code to the diagnostic program, or omit them, depending on the selected processor configuration. The scripts also change the parameters within the diagnostic code as it's assembled into a tailored diagnostic program. In addition, each script employs a database entry to specify the run-time conditions necessary to trigger each diagnostic block.

The verification environment also employs pseudo-random program generators to further enhance verification testing. These random program generators create tests that trigger complex interactions across different parts of the processor. The present implementation of the environment employs two configurable pseudo-random diagnostic generators.

One of the pseudo-random diagnostic generators is written in object-oriented Perl and the second generator is based on Synopsys' Vera Stream Generator, which is provided with the Vera HVL. Both generators employ instruction-list templates that are combined in random sequences to create complex diag nostic programs.

A major issue with verifying complex logic designs like microprocessors is ensuring that the diagnostic programs test the entire design. This issue is especially bothersome with randomly generated diagnostic programs that may inadvertently check one part of a design repeatedly while overlooking the rest. Tensilica addressed this problem with a functional coverage methodology based on Forte Design Systems' Perspective results-analysis tool. The results of this analysis help to steer the diagnostic generators in new directions to increase the overall verification test coverage.

At the same time, Vera-based monitors (which help to verify the correct implementation of micro-architectural features) and 0-In Design Automation's assertion-based signal and bus monitors check the processor's internal RTL state. In addition, VCS Coverage Metrics, an HDL-code-coverage utility included with Synopsys' VCS Verilog simulator, checks the verification coverage of the processor's RTL code while FSM (f inite state machine) monitors, also written in Vera, check coverage of state machine operations within the processor by checking each FSM's state and the state transitions triggered by the diagnostic programs. Finally, additional checking is performed by lint tools, Design Compiler synthesis checking, and formal verification using Conformal LEC from Verplex.

The diagnostic checking programs and monitors and the RTL and ISS simulation models run simultaneously within a co-simulation environment. The Vera-based co-simulation environment compares architecturally visible states in the RTL and ISS simulations. Tensilica selected Vera as the test bench tool because it works well with multiple HDLs and simulators. This verification methodology has allowed Tensilica to verify a very large number of Xtensa processor configurations using myriad versions of the verification programs and trillions of simulation cycles, over many months and all in an efficient and automated fashion.

Help for designers

Because SoC designers can add instructions to the Xtensa microprocessor, Tensilica's verification methodology must provide a way for designers to verify the added instructions. Tensilica provides three sets of tools to help designers verify their custom instructions: a framework that automatically generates AVPs using customer-provided test vectors, automatically generated MVPs that verify the operation of both the core and the designer's ISA-extension logic, and Verplex scripts for formal verification of extension semantics against instruction references.

It's not sufficient to verify a processor's operation in the absence of other system components (such as memories and bus interfaces) because a processor is never employed in an SoC without these other components. Consequently, a configured system verification test bench (Figure 2) is also part of this verification methodology. The test bench comprises modules for memory caches, local-memory RAMs and ROMs, a JTAG controller, and a bus interface tha t connects the processor core to other modeled system resources.

Ancillary modules in the test bench include interrupt, bus-error, and random interface stall generators; peripheral models; and a system memory model. Except for the processor models, all of the Xtensa test bench modules are behavioral models implemented in RTL, C, or Vera depending on the abstraction level required. Tensilica also provides a model test bench for post-synthesis, gate-level simulation. This gate-level test bench is used for sanity checking of the synthesized logic and for power estimation.

Figure 2 -- Configured system verification testbench

Automated verification methodologies, such as the one detailed above, offer SoC design teams the possibility of escaping the verification quagmire that's choking their ability to develop increasingly complex SoCs. By coupling these methodologies with configurable and programmable IP, more of the tasks to be per formed on the SoC can be assigned to pre-verified microprocessor cores, which greatly reduces the hardware verification burden by removing the need to manually create individual test suites for each RTL block used in the SoC.

Dhanendra Jani is an Engineering Manager at Tensilica. He joined Tensilica in 1998 and currently manages different hardware and verification projects. Prior to joining Tensilica, Jani spent 10 years at Intel where he held various technical and management positions.

Steve Leibson spent the first 10 years of his career as an engineer, then spent 15 years as an award-winning journalist, publishing over 200 articles and serving as Editor in Chief of both EDN and Microprocessor Report. Now he is the Technology Evangelist for Tensilica.