Automated verification of configurable IP blocks

Configurable microprocessor cores meet higher performance targets than fixed-ISA processors by allowing designers to tailor the processor's execution pipeline so that the configured processor executes complex inner program loops using fewer instructions. However, customizing a processor core can nullify the verification advantages of star IP unless the configurable product is designed to easily allow verification of the customized core.

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

To verify the large number of processors developed with its processor generator, Tensilica developed a verification environment that is automatically tailored to a particular processor configuration. This approach differs from conventional IP verification environments in its use of configurable verification components and automatic program customization. Tensilica implemented this customizable verification environment by combining internally developed and standard verification tools including simulators, formal verification tools, and hardware ve rification languages.

Architectural verification programs (AVPs) check each instruction's execution and micro-architecture verification programs (MVPs) check pipeline control, data hazards, and the processor's actual RTL implementation. AVPs and MVPs employ Perl scripts based on processor configuration information to generate tests tailored to a specific Xtensa configuration. The scripts add blocks of diagnostic code to the diagnostic program, or omit them, depending on the configuration. Scripts also change the parameters within the diagnostic code as it's assembled into a program. Each script employs a database entry specifying run-time conditions needed to trigger diagnostic blocks. Pseudo-random program generators further enhance verification coverage.

A major issue with verifying complex logic designs like microprocessors is ensuring that diagnostic programs test the entire design. This issue is especially bothersome with randomly generated diagnostic programs that may inadvertently chec k one part of a design while overlooking the rest. Tensilica addressed this problem with a functional coverage methodology based on Forte's Perspective results-analysis tool, which steers the diagnostic generators to increase overall test coverage.

At the same time, Vera-based monitors and 0-In Design Automation's assertion-based signal and bus monitors check the processor's internal RTL state. In addition, VCS Coverage Metrics, a code-coverage utility included with Synopsys' VCS Verilog simulator, checks coverage of the processor's RTL code while FSM (finite state machine) monitors, also written in Vera, check coverage of internal state machine operations. Lint tools, Design Compiler's synthesis checker, and Verplex's Conformal LEC formal verifier perform additional checks. Diagnostic checking programs and monitors and the RTL and ISS simulation models all run simultaneously within a co-simulation environment.

This verification methodology allowed Tensilica to verify a very large number of Xtensa processor configurations using myriad verification programs running on simulated processors, which consumed trillions of simulation cycles and many months in an efficient, automated fashion.

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 embedded in an SoC must work with other components on the SoC. Consequently, a configured system verification test bench (see accompanying figure) is also part of this verification methodology.

See related chart