As design complexity increases, design verification becomes increasingly difficult. In fact, it is not uncommon for project teams to spend more time verifying that a design will work than creating the actual design in the first place.
Project teams invest in a variety of tools to increase verification efficiency, including both formal analysis and functional simulation. Formal analysis performs useful checks to verify static and sometimes dynamic properties of a design. Functional simulation exercises a design empirically to verify its response to external and sometimes internal stimulus and data. However, verification by simulation requires testbenches – and creating good testbenches for a complex design is a challenging endeavor. Issues such as growing chip complexities, hardware/software integration, and module- to system-level design requirements have made it even more difficult to manually create a testbench that achieves higher levels of functional coverage.
The need for more efficient testbench development has resulted in considerable investment by the EDA industry, with a major emphasis on improving the languages used by engineers. Custom languages have been developed to provide more programming capabilities for testbench development, and standards efforts are in place to promote common testbench languages such as SystemVerilog or SystemC. While these languages do provide more power and flexibility for the testbench programmer, they do not reduce the amount or complexity of time necessary to program the testbench.
An approach is needed that not only leverages the benefits of these new testbench languages, but applies a new layer of technology to provide a steep functional gain in productivity and coverage.
Algorithmic testbench generation enables design teams to leverage the benefits of common testbench languages while providing a next-generation level of automation that increases functional coverage, which in turn, reduces overall testbench programming. This new technology uses algorithms to automate generation of simulation sequences, data, and checks from a concise behavioral description of a design's specifications. Algorithmic testbench generation achieves a higher level of functional coverage at the module, sub-module, and system level and finds more bugs faster than traditional methods. When algorithmic testbench technology is employed, project teams design with a higher level of confidence, design quality improves in a fraction of the time, and manufacturing respins are dramatically reduced.
Algorithmic testbench technology is based on rule-sets. Rule-sets show how high-level testing activities can be performed as a series of lower-level testing activities. For example, one rule in a router testbench might be "Packet-> Preamble-> MainHeader-> ExtentionHeader-> DataPayload-> Checksum." Other rules might show how "Preamble," "MainHeader," and the other components of "Packet" could be tested in terms of even lower-level testing activities. The result is a highly layered testbench architecture that is easy to write, simple to understand, and highly reusable. At the bottom of the rule hierarchy are individual "actions" which are no longer defined by rules. Instead, each action corresponds to a task written in a standard testbench language such as SystemVerilog or SystemC, which implements the action within a test.
When taken together, a modest number of rule sets can describe a very large set of tests. In fact, a well-chosen rule set can compactly define how to run every test scenario for simulation, even when designs become large and complex. While the application of rule sets, or Rules-Based Verification, is new to hardware design verification, it is actually an established, time-proven technology. IBM pioneered the use of Rules-Based Verification in the late 1970's for compiler design and verification. Compilers are an excellent application for this verification technology, as they can be concisely expressed in Backus Naur Form (BNF), which today are known as rule sets. First IBM, and then many companies thereafter, successfully used rule sets to verify compilers and some types of software programs.
However, several aspects of Rules-Based Verification prevented serious consideration of its application to hardware testing. First and foremost, the technology used to synthesize test sequences from rule sets was limited to deterministic systems and expressions, hence the excellent application for compiler verification. But complex hardware designs are non-deterministic in nature with behavior that cannot be modeled or predicted by deterministic expressions. In addition, Rules-Based Verification was not supported in languages familiar to hardware designers.
Now, with more than 20 years of research and development in this technology, algorithmic testbench generation is ready for mainstream usage. This new technology applies concise rule sets to the non-deterministic behavior of complex VLSI designs and is implemented in common testbench languages such as SystemVerilog and SystemC, in addition to Verilog and C/C++.
Fundamental to algorithmic testbench technology is that every simulation run has a purpose, which is captured as a "verification goal." A verification goal makes references to relevant parts of a rule set to specify a particular verification objective. When simulation begins, a seed-testbench starts up along with the simulator and begins generating tests per the verification goal. As the simulation proceeds, the algorithms monitor the progress towards the verification goal and intelligently adapt the testbench to synthesize tests to achieve the desired coverage. Engineers no longer need to write hard constrains to prevent unwanted illegal tests or soft constraints to prevent duplicative testing. The rule sets guide the testbench synthesis process to create only legal (or wanted illegal) sequences, and the algorithms progress towards completion of the verification goal without repeating tests (unless repeated tests are desired).
The verification goal also allows the engineer to focus the testbench synthesis process on producing whatever type of test is currently required. This capability, known as "testbench redirection," is important because a project team may need different tests at different times during the verification process. At one moment the team may want to investigate a problem report, and they'll need a specific test sequence. Next, they are trying to give quick feedback on a design fix and need to concentrate testing on a particular function. Minutes later, the team needs to run a regression test so they can thoroughly test a wide variety of functionality. Each time the team runs a different test they only need to modify the verification goal. The rest of the testbench does not change or need to be changed. This not only saves editing time, but eliminates a significant source of testbench bugs.
In addition to testbench redirection, algorithmic testbench technology offers "testbench retargeting." For example, it is increasingly more critical during the verification process to test complex designs at the module, subsystem, and system level. Usually, subsystem level and system-level testing require completely new (or at least, heavily edited) testbench code.
Because the rule sets are declarative in nature, they accurately describe the functional behavior of an interface or bus protocol independent of that function's environment. The intelligent nature of the algorithms can adapt to different design environments and simulation needs without requiring changes to the rule sets. As a result, the same testbench modules can be used for verifying a module, subsystem, and complete system-level design.
Click here for Fig. 1
1. Unlike traditional testbenches, algorithmic testbenches can be used across different design projects, retargeted at different levels of a design's hierarchy, and redirected to generate different tests based on the verification engineer's goals for the next simulation run.
|
