ASICs continue to grow in size and complexities and in this case, traditional verification techniques are not sufficient to achieve verification confidence. In the complex designs, debugging simulations is an ever increasing challenge. To address these challenges assertion based verification is found. Design and Verification engineers can place assertions in design or bind to design which will be useful to monitor, report and take action when incorrect behavior is detected. Assertions are playing major role in test bench development which helps achieving maximum confidence on bug free design. Moreover it can be used in simulations as well as in formal verification.It enables engineers to leverage the strength for block level, subsystem level and for chip level verification in order to reduce the overall effort and efficient verification closure. System Verilog Assertions are setting up a viable and effective standard in the design and verification. An assertion adds an advantage in debugging process and makes complex simulation debug easy.
Below figure on block diagram gives brief idea on where we put the assertions in test bench development. As we can see assertion are placed on module boundaries to signals to monitor DUT interface
The introduction of SVA added the ability to perform immediate and concurrent assertions for Design as well as for Verification. Assertions are used to validate design whether it is working correctly or not. Assertions can be useful to make sure ‘How good is the test case?’ Furthermore, it provides a means to measure the quality of the verification process through the creation of coverage using cover property feature of System Verilog assertion.
In System Verilog there are two types of assertions:
- Immediate Assertions
Immediate Assertion as name implies, execute immediately, in zero simulation time. It can be used in initial and always procedures, task and functions. This type of assertions performs a true/false. If the test result is true it executes the pass statement and if the test result is false or unknown, it executes false statement. Pass statements are optional; most engineers don’t prefer to specify pass statement as they are more interested on failures.
For example:
assert_xyx : assert (XYZ) $display (“Pass message”);
else $display (“Fail Message”);
- Concurrent Assertions
A concurrent assertion uses a clock to trigger the assertions evaluation. Difference between concurrent and immediate assertions is that concurrent assertions evaluate condition over time, whereas immediate assertions test at the point in time when the assertion is called. This assertions can be specified in initial block, always block or standalone like continues assignment
For example:
property XYZ;
@(posedge clk) disable iff (!rst_n)
ABC |=> ## [0:10] (abc == xyz);
endproperty : XYZ
long_lable_p : assert property (XYZ);
else $error (“Error : failure message”);
long_lable_c : cover property (XYZ);
Assertion Advantages
- Dozens of lines of code can be represented in one line using SVA code.
- Assertions can be controlled and can be disabled at any point during the simulations. SVA can be turned off during the reset or until the simulation reaches the particular event or logic.
- Assertion can have severity levels, failures can be non-fatal or fatal errors.
- SVA can be ignored by synthesis; designer does not need to include translate_on and transalate_off throughout the RTL code.
- Assertions can be used in simulation and formal verification.
- An assertion helps in debugging the complex failure. Debugging using end-to-end checkers requires tracing the error from the external interface back to the source. In complex designs, debugging is almost impossible without the help of intermediate checkers. As assertions pinpoint errors at the source, they can be used as intermediate checkers and debugging can be made much easier and faster.
Who/Where should write assertions?
System Verilog is nothing but an extension of Verilog;it has everything to support Verilog with lots of new features for Verification as well as for design.Usually Verification engineers add assertions to a design after the HDL models have been written which means placing the assertions on module boundaries to signals within the model, or modifying the design models to insert assertions within the code.
Design Engineers can write assertion within a design while the HDL models are being coded. What type of assertions and scenario designer should provide within design need to decide before design work begins. Verification engineer define the assertion scenario during the test bench architecture. System Verilog assertions are mostly hooked up at the DUT interface level where it can continuously check protocol and functional activities.
Assertions controllability and why is it important?
Controllability is very important in Assertion design. There are two methods I called to control the assertions:
- D Method (Dynamic Method)
Dynamic method is very popular where engineers required to control the assertion dynamically based on the test scenario they wants to execute. In today’s complex SoCs and their verification, Dynamic (D) method is popular as we regress the erroneous scenario to make sure DUT behaves accordingly. In this type of simulations engineers can dynamically switch on/off assertions.
System Verilog includes system calls for controlling the execution of assertions during simulations. There are three types of D Method.
1. $assertoff:
This system function is used to disable all assertions but allows currently active assertions to complete before being disabled.
2 $asserton:
This system function is used to turn all assertions back on
3. $assertkill:
This system function used to kill and disable all assertions including currently active assertions.
By using $assertoff, the assertions specified as argument of this function will be turned off until a $asserton is executed. This way you can control assertions dynamically. Using these system tasks you can make your assertions dynamic and based on requirement we can make them enable or disable. Furthermore we can even kill using $assertkill.Dynamic control of Assertions can be used to turn off assertions during reset and initialization or during simulation erroneous protocol behavior.
- S Method (Static Method):
To control assertion statically we can use System Verilog’s pre-processing capabilities. In this method assertions are generally ignored during the compilation phase w.r.t to `ifdef. This way we can build a different model by defining a different defines. Pre-processing defines can be applied to any place of the code and thus we can control the assertion as per need.
Example:
`ifdef XYZ_ASSERTION_ON
property XYZ (@posedge awa_clk);
a ##2 b;
endproperty
XYZ_p : assert property (XYZ)
else $fatal (“ERROR : Failed message)
`endif
SVA proved to be a powerful assertion language; it provides several ways to control assertion. There are various reasons why assertions controllability is important, some important points are mentioned below:
- To turn off assertions during reset and initialization or during simulation of erroneous protocol by doing this expected fails/checks can be turned off
- Static control of assertions is used to speed up simulations time by turning off checks or to select appropriate assertion model for a given scenarios.
- Dynamic method gives a control on when and where to start and stop/kill the assertions. It gives powerful controllability on simulation control
Coding Guidelines for SVA
- Design code shall not repeated in assertions, it will not be efficient. By making sure not repetition concept, we can decide on use of concurrent or immediate assertions for assertion check. This can be done during the architectural phase of assertions.
- Occurrence of “X” shall be checked explicitly, because “X” is implicitly mapped to “0”, which might hide a real assertion failure.
- Make assertions message as clear as possible. This will help in debugging the assertions.
- Disable the assertions during resets. Concurrent and Immediate assertions in combinational logic will begin executing at the start of the simulation, before reset and during reset design might not be in the known, stable state. Hundreds of false assertions can be reported during this phase and these false assertions could hide a real failure.
- Assertion shall use the same clock as the design; otherwise synchronization will not work properly.
- Assertion needs to consider the reset same as the design reset. This will avoid clock cycle offset which mostly produces illegal failure.
- Name each assertion with meaningful naming convention; this will help in debugging the failure from the failure message and from the wave form display. If we don’t provide long meaning full ‘label’ to the assertion, only non-descriptive generic name will be displayed in the waveform. By looking at the wave engineers will be unable to identify the problem until they consult the original source code. By adding the long descriptive label, we can see the label name on wave itself and can be easily identify the assertion failure details.
- Since the long label names are visible in waveform, it is good idea to use a label naming convention for each label with “ERROR_” followed by description of what the error message is if the assertion fails.
- Use sequence layer as much as possible because sequences can be instantiated within the sequences and properties while properties can’t be instantiated in sequences.
- Identify implementation specific corner cases using cover properties, this will help ensure DUT is exercised properly
Conclusion
Assertions are playing major role in test bench development which helps achieving maximum confidence on bug free design. SVA are setting up a viable and effective standard in the design and verification. An assertion adds an advantage in debugging process and makes complex simulation debug easy. Engineers can take care of few coding guidelines mentioned above for effective use of SVA in complex test benches.
