See how r? Results of control and test? T? add? s? la v? rification P
Verification tools and methodologies have both evolved and undergone revolutionary changes, and both are equally as important to stay abreast of Moore¡¯s law. Complex SOC designs can be implemented by acquiring third-party intellectual property (IP), a divide and conquer approach within development teams, and, of course, by adding more designers. Verification, on the other hand, must deal with the large designs as a whole. This burden falls on the underlying verification tools and associated methodologies that must be able to "simulate" a model of the design, often at different levels of abstraction.
Fortunately, assertion-based verification enables a revolutionary methodology change that addresses this ever-increasing burden by adding ¡®observability¡¯ (result checking) and testing (development of actual tests) into the verification environment.
Methods for result checking
Traditionally, several methods have been employed to determine if the simulated model behaves as expected ¨C some that check for correctness during simulation and others as a post-simulation batch process. Some examples:
*Check against a reference model (simulation run-time). A reference model, usually at a higher abstraction level, is run in parallel with the design model and operation is compared in real-time.
*Comparison with expected operation (post-simulation). This assumes that ¡°golden¡± results have been previously saved, most likely from another simulation run, and possibly from a simulation of a model at a higher level of abstraction.
*Assertions (post-simulation or simulation run-time). Assertions are pieces of code that concisely express desired or undesired behavior, often written in specialized language such as SystemVerilog Assertions (SVA) and PSL. Simulators read these descriptions along with the model and perform the checks at run-time. Post-simulation checkers are most efficient when deployed in batch-mode.
Introduction to assertions
Assertions provide a concise description of the design specification separate from the RTL design implementation. Assertions can be coded using traditional languages such as Verilog, VHDL, or C and have been for a number of years. But traditional languages can require many lines of code as well as burdensome "software techniques" for programming. For example, the explicit use of Verilog "fork" blocks would be required to describe an assertion that must be checked on all clock cycles, since a particular assertion can and often does span multiple clock cycles. Specialized languages such as SVA are designed to describe such assertions more concisely.
Writing assertions
Like designs coded using hardware description languages (HDLs), assertions are best described hierarchically. This promotes ease of coding, ease of understanding, and reuse, among other things.
*At the lowest level are Boolean expressions of design signals that become the building-block "components" for sequences.
*Next come Sequences that are a list of Boolean expressions in a linear order of increasing time.
*On top of sequences are Properties that combine the sequences in various ways.
*At the top-most level are Directives (e.g. assert) that indicate what to do with the properties.
Below is an example that shows this hierarchical building-block approach.
sequence c_l;
@(posedge clock) (bus_mode == ¡®INCA) %26%26 PC_load;
endsequence
property e_INC;
@(posedge clock) e_l |-> e_r;
endproperty
CF_COVER: cover property (add_overflow);
INCPC: assert property (e_INC);
Efficient assertion methodology
While assertions can be checked dynamically or statically (formally), let¡¯s focus this discussion on dynamic (simulation) checking. Most commercial simulators already support or are close to supporting standard assertion languages. While simulators generally fare well with simple assertion checking, the run-time acquisition of "support" data (data required for debug and analysis) can have a severe impact on simulator performance. The temporal nature of assertions can spawn multiple attempts and threads in parallel, significantly increasing the run-time and memory consumption of the simulation in order to capture the support data necessary for later debug and analysis. Shifting the bulk of the work to the debug system, which, in turn, can be optimized to calculate only the relevant data can alleviate the run-time burden. In this way, the debug system automatically generates the support data as needed, and the simulator can perform the checks much more efficiently. Ideally, the debug system also checks the assertions against the signal data captured during simulation, so the simulator doesn¡¯t need to perform additional work in support of assertion checking.
This capability can also be very useful during the assertion development process when assertions can be quickly checked in real-time as they are coded. The alternative is to repeatedly run simulations after every small change in the assertion code, which can be very time-consuming.
Tag
