IP Verification : HDL advances bolster complete system verification
HDL advances bolster complete system verification
By Tom Fitzpatrick, Director, Technical Marketing,Peter FlakeChief Technical Officer, Co-Design Automation, Inc., Los Altos, Calif.(fitz@co-design.com), EE Times
May 28, 2002 (9:56 a.m. EST)
URL: http://www.eetimes.com/story/OEG20020524S0101
There is no escaping the fact that while hardware and SoC devices have increased dramatically in size and complexity over the last few years, verification tools and methodologies have barely managed to keep pace. Problems are many ranging from the sheer number of scenarios to be verified, to management and communication issues across multiple design and verification teams. Gone are the days of throwing code "over the wall" to another group. Productive verification requires tearing down the wall between design and verification and between hardware and software. The major focus of any verification process is to eliminate bugs in the hardware design, and it is always better to find bugs earlier rather than later. True methodology gains require designers to become active participants in verification. Design teams are already under enough pressure, so the addition of verification to the design process must be as painless as po ssible. Since any reasonable methodology requires hardware blocks to be tested before being checked into the system, more thorough block-level tests will improve the quality of each block. Traditionally, the RTL designer creates a straightforward Verilog test to exercise the basic functionality of a particular block. Often, the Verilog test is not sophisticated enough to discover corner-case bugs in the block, and it becomes much harder to find such bugs once the block is checked into the system. Current methodologies attack this problem by using a separate language or tool to specify more complex tests leading to additional cost and complexity. It also requires a verification engineer to write these tests, since the design engineer has neither the time nor the inclination to learn the new testbench language. Since the test is in a new language, check-in tests cannot build upon the basic Verilog test that the designer will often write anyway. This overloading of resources is unfortun ate. The alternative of trying to detect the bug at the system level a notoriously difficult task could require a much more complex system-level test environment, if the bug could be caught at all. Hardware designers know the most about blocks they implement, so the key is to enable them to do better block-level verification themselves, without requiring them to change much of how they currently do things. Co-Design Automation's engineers set out to address this issue by using the Superlog HDL to give designers access to common verification features together with the Verilog that they already know. Superlog is a superset of Verilog so designers can code at RTL like always, while incrementally improving the power and quality of their block-level tests, adding features like constrained random data generation, expected output queuing, and other techniques, without having to start from scratch. Another way to improve verification is to create fewer bugs in the first plac e. Superlog also includes all of Accellera's "SystemVerilog" which offers a viable approach by incorporating advanced design constructs in Verilog. In addition to the generate statement and multi-dimensional arrays from Verilog-2001, Superlog and SystemVerilog add data structures, user-defined types, encapsulated interfaces and other features that enable a more concise and powerful RTL modeling style. Thus, making it easier to describe and debug complex designs. Another useful aspect of SystemVerilog is the Design Assertion Subset (DAS), providing a non-intrusive procedural method for the designer to embed behavior specifications directly in the design code. These assertions automatically trigger when the design fails to meet the specification, and can be used to provide more verification-specific visibility into the design from the testbench, allowing a more effective and efficient test. Assertions can also be used by formal property checking tools to prove that the block adheres to the specificati on. When blocks get handed off to the verification team, they are higher quality and include verification-specific information, via assertions, that the verification team can use to enhance their testbench efforts. Since the designer has improved the block-level testing, the verification engineer is freed from writing block-level tests and can focus on functional scenarios that must be verified. The addition of self-checking assertions in the design can simplify system-level tests. Further productivity gains accrue through the use of compatible HDLs and simulators. In our case, users have the advantage of a single-kernel platform that runs both the design and testbench together. This yields a performance benefit, since there is no PLI overhead in communicating between the two, and a productivity benefit since the design and testbench can be debugged using a single debugger. The methodology improvement is that now the verification and design teams can communicate and share code, allo wing each to become more productive. When embedded software is included in the system, one of the key parts of the co-development methodology is partitioning, as it is important to be able to analyze and make tradeoffs between various implementation choices of the design. The encapsulation offered by the SystemVerilog interface construct enables building a platform. An interface encapsulates the physical interconnect and protocol between modules, and can also be used to shield one module from differences in abstraction in another. The basis for embedded software is the decision that at least one function of the system is best performed as software running on a processor core. The decision to run as software is likely to be made before the physical core is chosen, making it important to test the software directly as part of the system. Once the choice of processor core is made, the design block, that was C code, is replaced by the processor core model which can execute the compiled C code and execute the bus instructions accordingly. It is difficult to develop and debug software at this level, since the designer only has debug access to memory locations in the hardware, not a full software debug environment. The blending of C and HDL provided by Systemsim allows a C model of the processor to drive the simulation, providing improvements in performance while still giving users access to the source level debugging environment. True productivity requires all members of the team, whether they think of themselves as hardware, software or verification engineers, to become active participants in the verification process. Through the use of next-generation HDLs and simulators the hardware design and verification process is improved, making it easier to design complex blocks concisely. The verification effort begins as a natural extension of the design effort, allowing the verification team to build on existing infrastructure and add powerful features to the system level environment. Then, this hardware-specific effort can be encapsulated for the software developers to get a head start in developing embedded software applications using their existing debug and development environments. Taking full advantage of the flexibility next-generation HDLs and simulators offer allows alternatives in implementation to be explored along the way, giving higher quality on the current design and an infrastructure that can be reused on future designs.
Related Articles
- System on Modules (SOM) and its end-to-end verification using Test Automation framework
- Automating C test cases for embedded system verification
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- Improving Performance and Verification of a System Through an Intelligent Testbench
- ACE'ing the verification of a cache coherent system using UVM
New Articles
Most Popular
E-mail This Article | Printer-Friendly Page |