Thank you, AMIQ and Testbench.in for having ASIC With Ankit listed on your recommended list of blogs.
Thank you, AMIQ and testbench.in
System Verilog Array Randomization
System Verilog has different types of arrays that you can randomize to generate interesting scenario for the test bench you are working on. In SV we mainly have static array ,dynamic array and also queues that you can randomize, Lets deep dive in to each one of them to understand how you can use it with system Verilog:
Static Arrays:
class my_static_array;
rand bit [3.0] my_array [8];
endclass
module my_testbench;
my_static_array my_static_array_obj;
initial begin
my_static_array_obj = new ();
my_static_array_obj.randomize();
$display (“my randomize value =%p”,
my_static_array_obj.my_array);
end
endmodule
In above example, we have my_array declared as static array
which is declared as rand so that you array will be randomize when you do class
object.randomize in your module to generate random value for our static array,
You can play around with this example by changing different seed to how it
changes the random value w.r.t to different seed.
Dynamic Array:
As we know, Dynamic arrays are the array for which size will
not be pre-determined during the declaration. Dynamic array declaration will
have square bracket [ ]. Lest deep dive in to example to better understand its
declaration and how you can randomize it:
class my_dynamic_array;
rand bit [7:0] my_array [] //dynamic array
//Adding some constraint to this array so we can constraint
array during randomization
constraint c1 {my_array.size >2 ; my_array_size <=10;}
//Constraint each array index value to be equal to index+1
constraint c2 {foreach (my_array[i])
my_array[i] = i+1;
}
function void print_value ();
foreach (my_array[i])
$display(“my array value
my_array[%0d] = 0x%0h”, i, my_array[i] );
endfunction
endclass
module my_testbench;
my_dynamic_array my_dynamic_array_obj;
initial begin
my_dynamic_array_obj = new(); //create a
memory for the class object
my_dynamic_array_obj.randomize();
//randomize class with constraint provided
my_dynamic_array_obj.print_value (); //calling
function from class to print array value
end
endmodule
Try this example and play around by changing constraint for
index value, array size and seed to see how it changes the value to create
corner scenario.
Queue randomization
We can have a queue declared as rand and then later in test
bench you can randomize the queue to create a random value generate from the
queue elements, We can constraint and limit the queue size in the constraints.
Lets deep dive in to the example to better understand declaration of the queue,
how you can limit and constraint the size of the queue and how you can randomize
the queue to generate random behavior for your test bench:
class my_queue_c;
rand bit [3:0] my_queue [$] // Queue declaration with rand
to randomize it later
//constraint to limit the size of the queue
constraint c1 {my_queue.size() == 5;}
endclass
module my_testbench;
my_queue_c my_queue_c_obj;
initial begin
my_queue_c_obj = new ();
my_queue_c_obj.randomize ();
//Print values
$display(“my queue value =%p”,
my_queue_c_obj.my_queue);
end
endmodule
Try this example and play around by changing constraint to
change size of the queue and seed to see how it changes the value to create
corner scenario.
Hope, this is useful simple example to understand
randomization of arrays. Stay tuned for more simple but exciting post to learn
System Verilog.
Keep reading and keep learning, stay tuned for more simple but exciting learning posts
Future of 5G looks bright!
Dear Readers,
Hope everyone are doing great, staying safe and healthy in this challenging time! The whole world these days are covered with unexpected challenge, we are all in this together and will come out from this together. We are strong together. First of all I would like to express Thanks from bottom of my heart to all the Doctors, Nurses and medical staffs, Paramedics, Police officers, Home care workers, grocery store personnel, Delivery people, transit workers, Airline worker and anyone who works with the public and making everyone's life moving.
We all understand the typical and challenging situation around and we are together fighting strongly against and will come out from this too! We are together moving ahead with the new technologies like, IoT, Automotive, Artificial Intelligence, 5G networking, WiFi-6, Robotics, Health Care, Smart Cities, Connected Cars and many more technologies and applications. These days pretty much everything is very well accessed and in our palm through smart phones, internet and with 4G, LTE and 5G technology.
As 5G technologies have been continuously evolving, it will certainly change the way we spend our lives, our communications will be faster than you can imagine, When you imagine a future powered by 5G, connected factory devices that “talk” to each other, mobile internet-connected to multiple devices at the same time, different vehicles communicating with the roads they travel on, and accessibility of information at unprecedented speeds will come to mind.
Lot of companies are actively and aggressively working towards making 5G technology available for the world to connect quicker and faster. Once 5G is fully operational, there will no need for any kind of cable or wire to deliver entertainment or communications service to your mobile device, some companies have successfully introduced 5G-capable handsets, it might require more time for the proper availability of 5G. But it is expected that the maximum number of 5G connections would exist in the years to come. 5G is the future!!
Thanks,
ASIC With Ankit
System Verilog Assertions (SVA) – Types, Usage, Advantages and Important Guidelines!
There was an article published by SmartPlay Technologies back in 2015 when I was working with them. It has very useful information to understand the usage, advantages, and guidelines about System Verilog Assertions (SVA).
ASICs continue to grow in size and complexities and in this case, traditional verification techniques are not sufficient to achieve verification confidence. In 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 a major role in test bench development which helps to achieve 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 design and verification. An assertion adds an advantage in the debugging process and makes complex simulation debug easy.
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.
Questions are
1. What type of System Verilog Assertions we have?
2. Where to put these assertions in our test bench development?
3. How to implement these assertions?
4. Usage, Advantage
5. What are the important Guidelines for SVA implementation?
To find more details please read this blog post "System Verilog Assertions (SVA) Types, Usage Advantages and Important Guidelines"
Thanks,
Ankit
Happy 2019!!
Happy Diwali & Prosperous New Year!
Diwali is the biggest and the brightest festivals celebrated by families around the world. Deepavali (actual name of Diwali) means "a row of lights." This auspicious day is also known as the "festival of lights. There is a saying “A Happiness can be found from darkest of dark if one knows how to switch on the light”!
The evil need not necessarily come in the form of demons, it can come as depression, desperation, and frustration which can cause more damage. Diwali is a reminder to slay all that is negative to our life.
There is so much happening during this whole week, people start preparing for Diwali, shops (e-shops J) are full of sales and there is light all over. People celebrate Diwali with many other things like firecrackers, visiting friends and family places and having lots of sweets! Well, I miss those days celebrating Diwali with lots of firecrackers and lights on streets with friends. A lot of regulation here, but still we manage to celebrate with some of the crackers in our patio J One of these years, I am going to take a vacation to celebrate Diwali back hometown to renew my Diwali spirit. On Diwali days, people use to do colorful rangoli at their house.
Diwali is the last day of Gujarati Year, Today, Vikram Samvat 2075 begins. So wishing you all a Happy New Gujarati Year. May this new year come with lots of happiness in your life.
Happy Diwali & Happy New Year!
System Verilog UVM Callbacks: Development and Usage
UVM Sequencer and Driver - Basic concept
Generator randomizes arrays of transactions and sequencer controls the generation of random stimulus by executing sequences. The sequence has the meaningful stream of transactions which can contain random data items, parameters and user can also add constraints. A user can combine sequences to create complex traffic streams.
- Derive sequencer from the uvm_sequencer base class and specify request and response type prameters.
- Use `uvm_component_utils and constructor
System Verilog Assertion Binding - SVA Binding
As we all know SV has become so popular in verification industry with its very good features and constructs which helps us verify today's complex designs. Today, I am going to discuss about SVA binding that we use in test bench for SVA properties.
There are VHDL and Verilog model we use to deal with these days. Mostly verification engineers are not allowed to modified these modules. But still SVA addition to these modules are required and easy to verify lot of RTL functionality. How can you add SVA to these modules?
Hope, this information on SVA binding is useful, stay in touch with me and share your views !
System Verilog : Functional Coverage Guidelines
Sr No
|
Code Coverage
|
Functional Coverage and SVA
|
1
|
Derived from design code with the help of simulation tools
|
It is user specified, controlled approach coverage by test bench
|
2
|
Evaluate design code to check whether structure is covered or not
|
Measures functionality part with the help of covergroup, cover point and bins (with the help of luxury feature of System Verilog J)
(With SVA you can capture functional coverage using cover property)
|
Functional coverage and code coverage both are contributing highly on sign off criteria for verification. Verification engineers have to make sure that their test plan and test environment is intelligent enough to satisfy the code/functional coverage closer. Code coverage is generated by tool with the help of the simulations generated by the test environment. So test environment should be random and intelligent enough to make sure design is covered as a part of code coverage and designer should be in agreement while code coverage review. There should be valid comments with reason for all exclusions for code coverage w.r.t to design specification. Functional coverage should be written such a way that it should be able to capture all identified functionality while defining the test plan. Coverage and assertions are very important entity in the verification process and there are few guidelines that would help in verification process.
Few guidelines while working with functional coverage
- Your test plan should be based on the functionality you want to verify w.r.t to specification
- You should have a coverage matrix with the list of cover point details w.r.t to your test plan scenario and there should be link of traceability between test scenario and cover point.
- Environment should have control mechanism for enabling or disabling coverage and assertions for better control ability in your environment
- Don’t enable functional coverage at the beginning of the verification to avoid simulation overhead in the starting phase of verification
- During the initial time of the verification bug ration is typically high, as you move forward to the verification bug ration would start to drop. Here is the time when you should enable coverage and analyze it
- Functional coverage plan needs to be updated as verification progresses
- As your knowledge of the design and corner case understanding increases, you should keep updating your functional coverage plan
- Make effective use of cover group “trigger” and sampling mechanism. (Stay tune for sampling mechanism on upcoming blog post !)
- Follow meaningful names of cover group and cover points. This will help when you in debug process
- Coverage should not be captured on failing simulations. Make sure to gathered coverage for only passing simulation. If few tests are not passing in regression first make sure to fix those issues before come to a conclusion on coverage achievement
- If your tests are keep exercising the same logic in design, start developing the new tests for uncovered coverage part of coverage (coverage holes)
Stay tuned to understand functional coverage sampling mechanism !
Thanks,
ASIC With Ankit
What a 'logic' you have System Verilog !!
Before we understand the “logic” data type for system Verilog, Lets understand verilog data types “reg” and “wire”. Wire is used to connect gates or modules and are physical wire in a circuit and it must be driven by a continues assignment statements. “Reg” in Verilog is a data object that holds its value from one procedural statement to next. When we say "reg (register datatype)" it does not mean the register in the hardware or a physical register in circuit. This is the common mistake or assumption mostly engineers thinks while learning Verilog.
In System Verilog, it improved the classic “reg” data type so that it can also be driven by continues assignments. The name they given for data type is “logic” in System Verilog. It is 4 state (1, 0, X, Z) System Verilog data type.
Let’s take an example to understand the usage of logic data type
Example :
module Asic_With_Ankit (input logic xyz);
parameter DELAY;
logic a, b, c;
initial begin
a = 0;
forever #(DELAY/4) a = ~a
end
assign c = ~c;
endmodule
In above example, you can see statement “a = 0” is procedural assignment while statement “assign c = ~c” is a continues assignment. So the important point to understand here is “SV allowed continuous assignments to logic variables, whereas in Verilog, you can’t use continuous assignments to “reg” variables”
“logic” signal can be used anywhere a “net” used but there is one exception to this, you can not drive logic variable from multiple driver. In these type of cases, variable needs to be a net type such as “wire” so that SV can resolve the multiple values.
Logic type can only have a single drive, it can’t allowed multiple driver. This means we can declare all signal as logic to find if is there any multiple driver issue. Because in this case you should be able to see compilation issue if there is any multiple driver by declaring all signal with type “logic”. Of course for the signal you would like to have multiple drivers shall be declared as net type such as “wire” or “tri”.
So, logic data type is identical to “reg” in every way except in SV it improved reg with logic so that it can also be driven by continues assignment and there would not be any confusion on “reg” data type w.r.t to physical register in hardware J
Enjoy,
ASIC With Ankit
System Verilog Class : No numbers for class name please !
Dear Readers,
Today I am going to share you one limitation with system Verilog class definition. We know Class is the basic feature to understand if we have to learn System Verilog. Class is the basic construct, data type in System Verilog. Some of the class feature I highlighted in my couple of previous blog posts can be found from here and here.
Methodological approach to name system Verilog class and major advantages
As a verification engineer with a mindset of methodological test bench architecture we prefer to name all data types, variables, blocks with meaningful names and their objects so that anybody with little understanding of that environment will be easily able to understand why is that class defined or what is the significant of adding this parameter? Let me give you a small example:
For example, a team of 3-5 engineers have developed a complex SoC or Block level verification environment using system Verilog. Environment is such complex that it has many classes defined to perform certain functional verification. Now with methodological approach usually engineers defined their test environment by classifying various configurable parameters and feature control and transaction based features and they will develop environment to accommodate these features in respected class called configuration class and transaction class respectively. They have given a names for cfg and transaction class to “rx_dma_cntrl_cfg” and “rx_dma_cntrl_tr”. Here “_cfg” represents configuration class while “_tr” represents transaction class which is quite common approach in today’s test bench developments.
Why do we need to follow these type of small-small things?
Well, answer to this question is “there are many advantage of following these type of approach while developing your test environment at the same time it does not cost you much”
Advantages:
- It helps in debugging the complex test environment as we all know “debugging is not free” and it always consumes amount of time and bandwidth in the verification cycles but we can always try to reduce the debugging efforts by following these small steps.
- Helps engineer to understand environment structure. This will be more helpful when new person joins in the team to work on this type of developed environment. It will surely reduce the reamp-up time for engineer and can easily pick up the tasks to update/modify/enhance such type of test bench environments.
- Helps in maintenance, enhancement and for re-usability
Limitation (while naming meaningful name to class)
We cannot name class starting with numeric number like 0,1,2 etc.. ! Class name is not allowed to have numbers as first character. Meaning you can’t give a class name called “8_bit_dma_env” or “8bit_dma_env”. Simulation will throw an error if you use this approach, instead it can be defined like “eight_bit_dma_env” or “dma8_bit_env” this is allowed because you are not using numeric number as first character of class name.
Let’s take an example of small exercises to understand :
program ASIC_With_Ankit;
class 1_byte_display_test;
int a;
byte awa = 8'hA5;
task display ();
$display ("Byte value =%h", awa);
endtask
endclass
initial begin
1_byte_display_test bdt;
bdt = new ();
bdt.display ();
end
endprogram
Solution :
In above example, you can see the class name uses first character as numberic number “1” which is not allowed in system Verilog and when you try compiling this code, you will see an error given below. But if you try the same example with changing a name to “one_byte_display_test” or “byte1_display_test”, you would be able to compile the same exercises without error
#################### ERROR ######################
-- Compiling program ASIC_With_Ankit
** Error: class.sv(3): near "1": syntax error, unexpected "INTEGER NUMBER", expecting "IDENTIFIER" or "TYPE_IDENTIFIER"
################################################
Hope this is useful information, keep reading “ASIC With Ankit” !
Enjoy !
ASIC With Ankit
Semiconductor Acquisistion - Mergers - Takeover and Impacts
Avago
|
LSI - Broadcom
|
Inphi
|
Cortina
|
Infineon
|
International
Rectifier
|
Seagate
|
LSI’s Flash business
unit
|
ON Semiconductor
|
Aptina Imaging
|
Qualcomm
|
Wilocity, Black Sand
Tech, HP Patents and CSR plc
|
Synopsys
|
Coverity
|
System Verilog Assertions (SVA) – Types, Usage, Advantages and Important Guidelines!!
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 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”);
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);
- 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.
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.
Controllability is very important in Assertion design. There are two methods I called to control the assertions: You can also find the Assertion controlabilty blog post from "SVA Control 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.
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
- 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
Happy reading !
ASIC With Ankit