- Open Access
- Authors : Sushan Patel , Sujatha Hiremath
- Paper ID : IJERTV11IS070196
- Volume & Issue : Volume 11, Issue 07 (July 2022)
- Published (First Online): 28-07-2022
- ISSN (Online) : 2278-0181
- Publisher Name : IJERT
- License: This work is licensed under a Creative Commons Attribution 4.0 International License
Design Verification Flow and System Verilog based Assertions for Verification
Sushan A Patel Student, Department of ECE,
RV College of Engineering, Bangalore,
Sujatha Hiremath Assistant Professor, Department of ECE,
RV College of Engineering, Bangalore.
Abstract: Design Verification is a very vast process and involves a lot of steps in order to ensure the RTL design is bug-free. Majority of verification flow is divided into 3 steps
Generating Stimulus, Writing assertions to verify the design, and generating cover points to ensure the hit scenarios of the design. Stimulus and assertions for the same play a significant role in order to hit a high coverage ratio. Using Assertions along with the RTL design helps to ensure that the functionality implemented in the design is in coherence with the stimulus provided with the same. This paper describes various assertion scenarios and how to implement assertions to verify different functionalities of the design. This paper discusses 5 different varieties ofassertions that can be implemented according to the requirement.
The role of any design verification person is basically divided into 3 steps . (As shown in Figure 1.1):
To generate a stimulus for the given RTL design
Write assertions to validate the stimulus
Generate cover points to check if the scenario is hitor not.
Figure1.1 Design Verification Flow
Stimulus plays a very important role in the design verification as it ensures how to play with the input of the RTL design. Stimulus helps to generate better coverage based on how robust and randomized the stimulus is. Verification done using directed test cases is not a vital or correct method of verifying a design. There should be enough randomization in the stimulus that is provided to the design so that the design can withstand with the logic even with the scenarios that were not included earlier. It can so happen that the design doesnt support that feature that the stimulus has generated. This is also a good way to
understand the limitation of the design and what all features the RTL design supports. This can turn otherwise as well so it is very important to randomize the stimulus as per the requirement and not blindly randomize the complete flow. 
Assertions come into the picture after the stimulus is generated. It takes the generated stimulus and verifies whether the given logic is correct or not. So for Example, if input signals A and B goes through an AND gate to give output as signal C, then with the stimulus of both A and B as 1 and 0 respectively, the assertion will check whether the value of signal Cis 0 or 1. So if the value is 1, the assertion fails and returns as an error in the RTL design. There is a lot of variety in assertions and they mainly fall into 2 different categories i.e. Immediate Assertions and Concurrent Assertions.
Figure 2.1 Flow of Immediate Assertion
Figure 2.2 Flow of Concurrent Assertion
The third and most important part of any Verification is to check coverage. It is impossible to hit 100% coverage for any design because there will always bescenarios that will never be hit but the design will never support that. Coverage basically means that all features the stimulus generates are randomized i.e. it helps to check which all cases of the design are being hit. The reason for the coverage being most important is that it can so happen that some portion of the design is never checked at all . There
will be noassertions failing in that because the stimulus has never generated anything for that particular case. So that could be a big disaster if something like that happens.  The only way to ensure the Verification result of the RTL design is to have assertions for all the logic of the design and to have enough coverage around thesame.
RTL Design Specification:
Before Jumping into the different types of Assertions, it is must to have complete understanding of the RTL design and how it will behave in different situations. Here I am considering an example of a simple RTL design that has 4 blocks named as A, B, C, D. . As shown in Figure 3.1
Figure 3.1 Request Ack handshake Concept
Block A interacts with block B, and C that works like a 4 way handshake mechanism of request and Acknowledge.
Block B provides Acknowledgement back to block A Acknowledgement provided to block A should be
immediately as soon as the request comes from blockA.
Block C provides Acknowledgement back to block A (after 5us). Acknowledgement provided to block A shouldnt come before 5us of time period.
Block D interacts with block B, and C that works like a 4 way handshake mechanism of request and Acknowledge.
Block D provides Acknowledgement back to block B.Acknowledgement provided to block B should be within 10us of time duration and it shouldnt cross this time.
Block D provides Acknowledgement back to block
C. Acknowledgement provided to block C should be immediately as soon as the request comes from blockC.
3. ASSERTION IMPLEMENTATION:
Based on this RTL design functionality described, this paper will discuss about the major 5 assertion categories. Note that there can be a lot of other assertion category that can be implemented but this paper focuses only on these 5 categories..
Assertions to check whether the given signal doesnt go unknown in the given entire duration (signal = X)
Assertions to check whether the given test_expr is 0 or 1 (concept of Always and Never)
Assertions to check the one-hot condition of the signal (Remaining completely 1 or 0 during the entire duration)
Concept of checking whether the requested signal is provided with the Acknowledgement signal in a given duration of time
Concept of checking whether the requested signal should not be provided with the Acknowledgement signal until a given duration of time
This Assertion type checks for any of the signal in theRTL design should never be X. As seen in the image below the Ack signal is remaining X for the complete duration, even when the Request is being received.
So this should never happen. The assertion for this logic is very simple and it should fail every time the signal is Driving X and not toggling at all.
Figure 4.1 Ideal behavior of category 1
Figure 4.2 Wrong Behavior of Category 1
Category 2: (This is the case where Ack did not come immediately once the block receives theReq)
This Assertion case is also very simple wherein once the block A sends Req to another block B for a particular operation. At this time block B should send Ack back to block A immediately in the next cock cycle otherwise its a design bug. So the assertion here will check for the Ack signal as soon as the Req gets deasserted and wait for the Ack for 1 clock pulse otherwise return the status of assertion as failure.
Figure 4.3 Ideal behavior of category 2
case we have to check that the block D provides Ack back to block B within 10us. In order to implement this, a counter is required. This counterwill count for the duration of clock cycles. Now the main point is we are required to check for the Ack before the ounter expires. So here we will have to use the category 3 wherein the output signal to be polled will be the counter_expired one. So the assertion should be enabled when block B send a Reqto block D and check for only when the counter_exp = 0 and within this duration the Ack should come.
Below is the implementation of the followingassertion.
COUNTER_MACRO( .counter_exp(), .counting(),
.rst(rst) , .en() , .counter_value() )
Lets assume the Frequency of clk = 100MHz
Next step is to convert the 10us into the no of clockcycles based on the frequency of clk
Counter_value = 1000 clock cycles
Figure 4.4 Wrong Behavior of Category 2
BLOCK_D_CNTR ( .counter_expired(), .counting(),
.reset() , .en(Req) , .counter_value(1000) )
This Assertion will check whether a particular signalis not remaining completely 1 or 0 for the entire duration of the test case. This is very similar to category 1 but here the issue is that the design will go into hang state as the complete logic would be driving only 1 value i.e. 0 or 1 for the entire duration. This case is not as easy to identify like the case of Category 1. It might not even fail in certain situations as the logic would satisfy the conditions sometimes.
Figure 4.5 Ideal behavior of category 3
So here the counter will start down counting from1000 to 0 once the block B sends Req to Block D.
ASSERTION_CHECK_0 ( .MSG (Ack didnt come within 10us of Req)) BLOCK_D_ACK_ASSERT(.clk(clk), .rst(), .en(Req), . (test_expr(Ack &
The assertion macro ASSERTION_CHECK_0 will show error whenever the value of test_expr becomes 1 otherwise it works fine.This following BLOCK_D_ACK_ASSERT will print the msg as defined if the assertion fails. Now here the assertion will enable when the Req from Block C is received. So if the Ack comes within this time frame and the value of counter_expired=0 then the assertion is valid, if it comes after the counter_expired=1, the assertion willfail and show error.
Figure 4.6 Wrong Behavior of Category 3
Figure 4.7 Ideal behavior of category 4
Wrong Behavior :
This case is a complex case wherein the combination of a counter and an assertion of category 3 is required. In this
Figure 4.8 Wrong Behavior of Category 4
Figure 4.9 Ideal behavior of category 5
This case is also a complex case wherein the combination of a counter and an assertion of category 3 is required. In this case we have to check that the block C provides Ack back to block A within 5us. In order to implement this also, a counter is required. This counter will count for the duration of clock cycles. Here also we are required to check for the Ack but not before the counter expires. Here we need to wait for 5us and then only provide the Ack signal to block A. So here we will have to use the category
3 wherein the output signal to be polled will be the counter_expired one. So the assertion should be enabled when the Req comes and wait for the counter_exp = 1 and then only the Ack should come. Below is the implementation of the following assertion.
COUNTER_MACRO( .counter_exp(), .counting(),
.rst(rst) , .en() , .counter_value() )
Lets assume the Frequency of clk = 100MHz
Next step is to convert the 5us into the no of clockcycles based on the frequency of clk
Counter_value = 500 clock cycles
BLOCK_C_CNTR ( .counter_expired(), .counting(),
.reset() , .en(Req) , .counter_value(500) )
So here the counter will start down counting from500 to 0 once the block A sends Req to Block C.
ASSERTION_CHECK_0 ( .MSG (Ack didnt come within 10us of Req)) BLOCK_C_ACK_ASSERT(.clk(clk), .rst(), .en(Req), . (test_expr(Ack &
The assertion macro ASSERTION_CHECK_0 will show error whenever the value of test_expr becomes 1 otherwise it works fine.This following BLOCK_C_ACK_ASSERT will print the msg as defined if the assertion fails. Now here the assertion will enable when the Req from Block A is received. So if the Ack comes after the 5us time frame and the value of counter_expired=1 then the assertion is valid, if it comes before the counter_expired=1, the assertion will fail and show error.
Figure 4.10 Wrong Behavior of Category 5
This paper discussed how useful assertions are in thedesign verification environment. They help to make the design Bug free and more robust to withstand in the market. Deploying Assertions has several advantages which can be summarized below:
Debug time can be reduced drastically.
Bugs can be found along with the timestamp andeven during which particular scenario.
Verbosity can be controlled along with writing assertions.
Assertions go handy with C++ functions.
Deep understanding of the Specification and Functionality of the design can be developed.
Assertions are used for writing Coverage as well.
As I mentioned before as well, assertion can be written based on the requirement of the verifier and the design specification. An individual can modify the assertion and play with it according to the need. 
2018. V. Jusas, T. Neverdauskas, Stimuli generator for testing processes in VHDL, NORCHIP, pp.1-4, 2017.  Y. N. Yun, J. B. Kim, N. D. Kim and B. Min, Beyond UVM for practical SoC verification, International SoC Design Conference, pp. 158-162, November 2018.