Monday, November 23, 2015

System Verilog Assertion Binding - SVA Binding

Dear Readers,

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? 

Here is where system verilog ‘bind’ comes in picture. Generally you create a SVA bind file and instantiate sva module with RTL module.

SVA bind file requires assertions be wrapped in module that includes port declaration, So now lets understand this with a small example to understand basic things on  how to use SVA bind : 

click on below image to enlarge.. 

DUT_Module - Dummy RTL module to understand this example
SVA_Module - Dummy SVA module with implemented assertion property
TB_Module - Dummy test bench code to see how bind works with module instantiation 

Here, you could see there is DUT instantiation created DUT_u1 instance of DUT_Module. Now point of interest for us would be, how to bind DUT instance to SVA module.

To understand this take a look at line number 50 in image from TB_Module, where you could see 'bind' keyword used with DUT_Module module and SVA_Module. This is the place where we are binding DUT module with SVA module. Thus passing DUT signal information to SVA module. With this we could play around with DUT signal and can check assertion properties using DUT signals available through this instantiation.

If the assertion module uses the same signal names as the target module, the bind file port declarations are still required but the bind-instantiation can be done using the SystemVerilog .* implicit port connections. If signal names are not exactly matching between target and bind file module then we need to expand the instantiation with respected port names.

Hope, this information on SVA binding is useful, stay in touch with me and share your views !


Monday, March 9, 2015

System Verilog : Functional Coverage Guidelines

We have been implementing every possible checks to make sure design is verified but what have we done to check our test bench ? How do we make sure that our test bench has covered everything that needs to be covered w.r.t to specification and test plans ? Here is the place “Functional Coverage” and “SVA” comes in picture!

Before we start on few guidelines to follow while working with functional coverage, I would encourage you to refer various posts on functional coverage and assertions to get high level idea on architecture and usage. Click on 1, 2, 3!

Now, Basic questions can come to mind is, "what is the difference between code and functional coverage?". Let’s understand it at high level and then we will move forward to understand guidelines for functional coverage.

Sr No

Code Coverage

Functional Coverage  and SVA


Derived from design code with the help of simulation tools

It is user specified, controlled approach coverage by test bench


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)

To conclude with few guidelines from various posts on functional coverage and assertions:

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
  1. Your test plan should be based on the functionality you want to verify w.r.t to specification
  2. 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.
  3. Environment should have control mechanism for enabling or disabling coverage and assertions for better control ability in your environment
  4. Don’t enable functional coverage at the beginning of the verification to avoid simulation overhead in the starting phase of verification
  5. 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
  6. Functional coverage plan needs to be updated as verification progresses
  7. As your knowledge of the design and corner case understanding increases, you should keep updating your functional coverage plan
  8. Make effective use of cover group “trigger” and sampling mechanism. (Stay tune for sampling mechanism on upcoming blog post !)
  9. Follow meaningful names of cover group and cover points. This will help when you in debug process
  10. 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
  11. If your tests are keep exercising the same logic in design, start developing the new tests for uncovered coverage part of coverage (coverage holes)
For guidelines on SVA, please refer to this article !

Stay tuned to understand functional coverage sampling mechanism !

ASIC With Ankit

Saturday, December 20, 2014

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

  assign c = ~c;


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

ASIC With Ankit

Tuesday, November 11, 2014

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”

  1. 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.
  2. 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.
  3. 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);



initial begin
    1_byte_display_test  bdt;

     bdt = new ();
     bdt.display ();


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: 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

Monday, October 20, 2014

Semiconductor Acquisistion - Mergers - Takeover and Impacts

Dear Readers,

Mergers and acquisition are common in today’s global market. If you take a history of any successful big companies in the market for more than 10-15 year, you would see the list of companies they acquired. So now two questions comes in mind. "Companies does acquisitions and become successful in the market? Or Successful companies does acquisition to be in market with profitable approach YoY?". There could be a different answers to these question depending upon various factors. I would be pleased to hear answers/views on these questions. Lets share views and experience.

Let’s assume that acquisition is part and process for successful companies and try to understand what impact does it make on different segments.

These days you might be observing industries’ various deals in terms of either merger, acquisition or takeover with all sets of new brand names. It is a way for companies to acquire technology, products and man power to improve profit and stock price while reducing overall expenses. In last few months, I have heard about many small to big acquisition in 2014. Some of them are given below in table and many more could be in the pipeline or in process.

Some of the recent acquisitions-mergers happened in 2014-15:

LSI - Broadcom
International Rectifier
LSI’s Flash business unit
ON Semiconductor
Aptina Imaging
Wilocity, Black Sand Tech, HP Patents and CSR plc

Lets understand what are the segments where mergers/acquisition could make an impact. There are two major segments where we could see the small to major impact because of acquisition and mergers.

1.       Service/consulting/Contract/Freelance
2.       Employees


Service segments who mostly relies on the product based companies for business revenue may face a challenge to gain business. During the merger/acquisition time most of the companies holds/stops their decisions for outsourcing their work to service companies. There are strong reason behind holding these decisions as they expect man power, technology and product acquisition as a part of merger/acquisition deal. So management has to think and restructure all sets of resources to make sure effective and profitable utilization model in place. Only after concluding this model they can either release, postpone, cancel their decision on outsource/contract the work. This could eventually effects service business revenue, consulting and contracting opportunities for freelancers. Would be happy to hear from experts on their views on real impact on service business !


During the merger acquisition process there are mostly/at-least two group of employees evolved, coming from the organization with different culture. In this transition phase, most of the employees faces challenges, especially on uncertain future, career. They would also be in phase where they think whose job is on critical edge ! This time frame is critical for employees as they need to make sure they are synced with other culture, people, style and way of work along with their individual performance !  Change is always difficult for employees especially they are not engaged in decision that impact their jobs and career. This could lead to a stress for individual and can impact on personal growth.

I had a talk with couple employees who were in same situation and got a smell that employees in this situation may fear losing their jobs or losing opportunities they had. These type of fear can negatively impact on productivity and eventually companies growth engine if continues. One more important point that I realize is “conflict with competitiveness”. When employees are in fear of losing jobs they are more likely to become competitive with others in the same path and eventually can end up having conflict. Competition is good if it is not creating violence !! J These could be major factors where employees gets affected during merger / acquisitions and would be happy to hear views experience from industry experts.

ASIC With Ankit

Monday, August 25, 2014

System Verilog Assertions (SVA) – Types, Usage, Advantages and Important Guidelines!!

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: You can also find the Assertion controlabilty blog post from "SVA Control Method" !

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.



property XYZ (@posedge awa_clk);

a ##2 b;


XYZ_p : assert property (XYZ)

else $fatal (“ERROR : Failed message)


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
Note : Same article is published on and can be found from here

Happy reading !
ASIC With Ankit

Saturday, April 12, 2014

Class - The Classic Feature - Part II

Dear AWA Readers

Here we go with follow up post on ‘Class – The classical feature’ ! In this post I will try to cover different types of classes in brief for better understanding. There are various types of classes that we use in test bench development.  The usage of class is depends on the requirements.  Let’s understand what different types of classes that we use in system verilog.

Different types of classes:
  1. Basic Class
  2. Abstract Class
  3. Parameterised Class
  4. Nested Class
  5. Typedef Class

Basic Class:
Basic class is covered in my last post, you can refer It from here.

Abstract Class:

Classes without intending to create any objects of class are called Abstract classes.  These type of classes exists simply as a base class from which other classes can be derived. Virtual class is a temple or place holder for derived classes, abstract class is declared with a key word virtual

virtual class asic_with_ankit ;
virtual task awa1 ();
virtual task awa2 ();

Methods (tasks/functions) can be declared virtual, if methods are declared as virtual and is overwritten in derived class, return types, numbers and types of its arguments must be same as of virtual method. Virtual method defined in abstract class need not have body, In this case body will have to be defined in non virtual (non abstract) derived class.

Parameterised class

You might be knowing the parameterised modules in verilog/system verilog. Classes can also be parameterised in the same way that modules are. This type of class definition provides a template of an actual class, definition of actual class will be created at the time of class instantiation.
Placeholder/template for parameterized class

class  asic_with_ankit  # (parameter int A = 1);
     bit [A-1 : data];

Actual class will be created when you instantiate the class with parameter value

asic_with_ankit  #(8)    awa ;

Data type also possible to pass as an parameter.

Class asic_with_ankit  #(type A = bit);
     A   register_bit;
     task register_update  (A  reg_update);

Nested Class:
Definitions appear inside the definitions of another class as it were a member of other class. In system Verilog you are allowed to use class within another class. Class declarations nested inside a class scope are public and can be accessible outside of the class.
Nested class helps increasing encapsulations and lead to more readable and maintainable code.
class A; 
     class B; // Nested class for a node in a linked list. 
          bit [7:0] reg; 
Typedef Class
Sometimes a class variable needs to be declared before the class itself has been declared.

For example,
typedef class ASIC_With_Ankit;
     class  AWA;
          ASIC_With_Ankit   AWA1;

“typedef class ASIC_With_Ankit;”  : typedef of class ASIC_With_Ankit allows compiler to process the class before it uses inside the class  AWA. This will avoid the compilation error otherwise  compiler will flag an error.

Hope this will be useful information on understanding of different classes in system verilog and their usage.

Happy reading ! 

Sunday, August 25, 2013

"Class" - The Classical feature - Part I

Dear Readers,

Let's understand the classical feature of System Verilog 'Class'. Here I would try to explain on class feature, object properties and methods, object instantiation, class methods polymorphism and constructor concept.

What is class and why is it classical :), Lets understand
  • Class is a generalization of the data type concept and central to the Object Oriented Programming. 
  • A class is a type that includes data and subroutines like functions and tasks. 
  • The class properties and methods creates a capabilities of some kind of objects.
Usage of class with example:

class AsicWithAnkit ;
//Data of class properties
     bit [3:0] cmd ;
     bit [7:0] addr;
     int count;
     bit ack;

     function new ();
          cmd = 3'b000;
          addr = 8'h00;

     function display ();
         $display ("Command =%h", cmd );
         $display ("Addresss =%h," addr); 
     endfunction : display

     task clean ();
          cmd = 'h0;
          addr = 'h0;
     endtask : clean

endclass : AsicWithAnkit

Above example gives an idea on how to declare a class and their properties, usage of those properties by instantiating class object is the next step to use properties defined inside class body.

Lets understand how to instantiate class object, we will have to create a memory for class object to use class properties and their methods for further development work.

AsicWithAnkit   AwA;
AwA = new ;

Here we can see class name "AsicWithAnkit" is instantiated with a created ovject name "AwA". in second statement we are creating a memory for class object "AwA". Now we are ready to use class properties using instantiated object. Let's understand how?

Now when you want to access or use the properties described in the class you can use/access those methods using the objects.

AsicWithAnkit   AwA = new ;
AwA.cmd = 'h2 ;
AwA.addr = 'h8 ;  //Accessing a class properties using object
AwA.display ();  //Accessing a class method using object

This way we can access class variables and methods using instantiated objects.  System verilog does not require memory allocation and deallocation.

System verilog gives us a different option/way through which we can assign, re-name and copy the objects.
Class has many system verilog features and will try to cover those feature in separate follow up blog posts.

Note : Same blog has been published on EDACafe and is available from here

Keep Reading....
ASIC With Ankit

Monday, May 27, 2013

What is "this" in System Verilog ?

Dear Readers,

Here I would like to share some understanding on keyword called "this". What is "this" in System Verilog? How does it used? Usage of "this" is simple but important in test bench development.

First of all lets understand What is "this" in System Verilog?

"this" is a key word in System Verilog used to unambiguously refer to class properties or methods of current object. The "this" keyword shall only used within a non-static class methods otherwise an error shall occur.

As example is the best way to understand the most of the things, let me take a example and try to explain.
Example to understand the usage of "this" in System Verilog:


     class ASICwithAnkit ;
        int a ;

        function new (int a);
           this.a = a;
        endfunction : new

     endclass : ASICwithAnkit

//Class instantiation and usage

ASICwithAnkit  AwA = new (123);
$display ("AwA.a = %d,", AwA.a);


In above example we can see that 'a' is a member of class "ASICwithAnkit". When we initialize the memory for class for usage, we have passed a integer value '123' to its constructor (function new). The variable 'a' is local to class instance "AwA and is now 123 as we have passed this from constructor.

Hope this is useful to understand the meaning and usage of "this" in System Verilog.

Note : Same blog is available on EETimes India site.

Happy Reading !
ASIC With Ankit

Saturday, May 18, 2013

System Verilog Queues which can shrink and grow !

Dear Readers,

System Verilog has new data type called ‘queue’ which can grow and shrink. With SV queue, we can easily add and remove elements anywhere that is the reason we say it can shrink and grow as we need. Queues can be used as LIFO (Last In First Out) Buffer or FIFO (First In First Out) type of buffers.

Each element in the queue is identified by an ordinal number that represents its position within the queue, with 0 representing the first element and $ represents the last element.

The size of the queue is variable similar to dynamic array but queue may be empty with zero element and still its a valid data structure.

Lets take a few examples to understand queue operation with different methods we have in system verilog.

int a;
Q[$] = {0,1,2,3};  // Initial queue

initial begin
   //Insert and delete
   Q.insert (1, 1); // This means insert 1 at first element in the queue which becomes {0,1,1,2,3}
   Q.delete(2); // This means delete 2nd element from the queue. {0,1,2,3}

   Q.push_front (6);  //Insert ‘6’ at front of the queue. {6,0,1,2,3}

   a = Q.pop_back; // Poping the last element and stored it to local variable ‘a’,  a = 3 in this case. Resultant Queue = {6,0,1,2}

   Q.push_back(7) // Pushing the element ‘7’ from the back. {6,0,1,2,7}
   a =Q.pop_front; Poping the first element and stored it to local variable called ‘a’, a=6 in this case. Resultant Queue = {0,1,2,7}


When you create a queue System Verilog actually allocates extra space and because this we can add and remove the element based on need in our test bench. This is very useful feature in test bench implementation. System Verilog automatically allocates the additional space so we don't need to worry about the limits and queue will not run out of space.

Queue is very useful data type in System Verilog for developing a test benches. It can be used in development of various entity in the test bench like scoreboard, monitor, transaction class, drivers etc.

Hope this helps in basic understanding of queue and its methods.

Note : Same blog article is also available on EDA Cafe website.

Happy Reading!

Monday, April 29, 2013

Verilog to System Verilog : A Successful journey towards SV

Dear Readers,

We have been using standard languages and methodologies for ASIC/FPGA design and Verification activities. We as an engineer must know on history of verification activities. Today we mostly work on verification standard languages like System Verilog. The whole industry is moving to accept this language with few methodologies (RVM, VMM, AVM, OVM, UVM etc...) as their standards for new and existing product development and verification.

Now since we use the industry standard languages like VHLD, Verilog, and System Verilog, we must know and understand history and importance of Verification languages.

Let’s understand how we reached to a System Verilog usage? What are the other different verification languages engineers were using in past few decades? How did they start their usage from Verilog to System Verilog for verification? Let’s go back to history and understand these questions.

When Verilog first developed in mid-80, main requirement and usage of this language was to develop synthesizable RTL with not much complexity. Revolution started by late 1980s. By late 80s synthesis and simulation triggered a revolution for EDA industry. As time passed, In 90s industry realized a tremendous need to solve complex verification problems due to complex designs. This was the time when EDA Company played a key role in filling the requirement to solve this verification issues. Those days verification languages which become popular and people started using those were proprietary to some companies! Best examples are ‘Open Vera’ and ‘e’ language. Since these languages were proprietary to EDA companies, some people were using the Object Oriented Languages like C++. During those days some users were using Verilog to develop their testbench, looks interesting, Isn’t it!

The problems gets started during 1990s when Verilog become an industry standard.

In 1980s a company called Gateway Design Automation developed a logic simulator called Verilog-XL and Cadence acquired in 1989 with right. Now with a new strategy Cadence put the language in to the public domain with the intention that Verilog should become a standard. After this Verilog HDL is now maintained by Accellera a nonprofit making organization. In 1995 Verilog HDL became IEEE standard.

Accellera came up with revised versions in 2001 and then in 2005 and industry taking this as standard and moved ahead.

Accellera have also developed a new standard called ‘System Verilog’ which extends Verilog with newly added many feature with the concept of Object Oriented Programing. System Verilog then became an IEEE standard (1800-2005) in 2005.

System Verilog is a super set of Verilog plus all the features known to be necessary for traditional verification. System Verilog is being used mostly in Verification activities because of higher level abstraction and user friendly features. Today System Verilog is already became a standard for Verification activities and most of the companies have started accepting his beauty! In addition to System Verilog usage and acceptance people have come up with few methodologies like (RVM, VMM, AVM, OVM, UVM etc…) With the addition of this type of methodologies Verification environments are becoming easy to handle, user friendly and most importantly the environments are becoming re-usable!

Happy Reading!
Ankit Gopani

Sunday, March 17, 2013

System Verilog : Which final is Final ?

Dear Reader,

Recently I posted one blog post “System Verilog Final Means Final !”

As we all know final means final in system Verilog, Final block will get called at the end of the simulation before $finish. Now with this understanding we can have few questions. Recently I have received an request and some question on the same like and thought of answering those questions.
  1. Is multiple final block is allowed in System Verilog?
  2. If yes, what will be the execution order in simulation, which final is final?
Here are the answers to these questions :

Multiple final blocks are allowed in system Verilog, you can define multiple final block in your testbench. Some time you might require to use final blocks in different places of environment. Here we need to understand one most important thing on final block is that, final blocks are called at the end of the simulation before $finish. It is like a calling a function which executes in zero simulation time.

If you have multiple final block in your testbench all final blocks are called at same simulation time before your simulation ends. Let’s take an example to have better understanding:

program ankit_with_ankit;

  class final_test;
     task final_activity();
        $display (“ASIC With Ankit 1 @%t”,$time);
       $display (“ASIC With Ankit 2 @%t”,$time);

  initial begin
     final_test ft;
     ft = new;

  final begin
     $display (“ASIC With Ankit 3 @%t”,$time);

  final begin
     $display (“ASIC With Ankit 4 @%t”,$time);


Simulation Result:

ASIC With Ankit 1 @ 0
ASIC With Ankit 2 @ 10
ASIC With Ankit 3 @ 10
ASIC With Ankit 4 @ 10

Here you can observe that I have used 2 final blocks in this simple exercises. You can have less or more based on your testbench requirement. When you run this with any simulator result will tell you all the final blocks will be called at same simulation time. So you could see all the messages for final blocks will be print at same simulation time. This is the reason you could see printing time for all the messages defined in the final blocks are 10ns.

So answer to question ‘which final is final?’ is ‘All finals are final’!

I hope this will give you a more understanding on final block usage and execution. Comments, suggestions are welcome. This blog post was published in the EDA Cafe .

Happy Reading!
ASIC With Ankit

Wednesday, February 27, 2013

System Verilog : Final means Final !

Dear Readers,

Today I would like to share some basic things on ‘final’ block in System Verilog. This is a newly added feature in System Verilog over Verilog. Final block is good for summary information. You can have summary information printed in log file at the end of simulation.

Final block executes at the end of the simulations without delays. ‘final’ block is like an initial block in SV only difference is that it occurs at the end of the simulations. Final block does not allow delays and time consuming or blocking activities and because of this reason it typically used in display statistical information on simulation result. Final block executes in zero time. Considering this nature of execution it is similar to ‘function’.Function also executes in zero time and does not allow timing related or blocking type of activities.

Lets try to understand this with syntax:

program asic_with_ankit;
   int error, warning;

    initial begin

      //Main program activities…..
   final begin
      $display (“Test is done with %d errors and %d warnings”, error, warning);

Simulation ends means what?

Simulation ends when last initial block ends in the program. When last initial block ends, it implicitly calls $exit which tells particular program is done! When every program is completed (exited) an implicit call to $finish is done. User can call $finish any time whenever he/she wants to end the simulation.

This process does not mean that your simulation is over, a module or program can have one or more ‘final’blocks that contains code to be run just before simulator terminates/finishes.

This is a great place to perform certain activity in your simulation like:
  • Cleaning up tasks such as closing files
  • Printing reports which can have summary of number of warnings, errors etc..
  • Display statistic information about the simulation
final block can only trigger once in a simulations and because of this I name it as ‘final means final! :) you cannot call it again!

Happy Reading,
ASIC With Ankit

Thursday, February 14, 2013

Is Test bench complex and difficult to handle at end of the day?

Dear Readers,

As we all know debugging is not an easy task and requires lots of attentions and effort to figure out the issues! Well, it is not at free of cost! (Debugging is not free!) This is true for both Design as well as Verification engineers.

ASIC/FPGAs are becoming more and more complex day by day and because of that RTL design and Verification environments are becoming super complex! Usually engineers start writing a code with good understanding in mind from defined specification or standards. With the complexity and sometime way of writing code makes design code / verification environment complex and difficult to handle. When debugging comes in picture, sometime discussion makes debugging easy. Thinking of possible scenarios, causes and problem solving ideas varies engineers to engineers! When you stuck with debugging some issue and you don’t get any clue, don’t spend huge amount of time debugging the same issue because “debugging is not free”, instead try discussing the scenario with your team mates, you would mostly get the hint or clue to identify and fix the issues. Obviously your colleague should be supportive in nature :). This is one of the potential places where TEAM work comes in picture!

Why the verification or design code becomes complex to handle at end of the day? What could be potential reason for this?
  1. Written code for Design/Verification itself is complex (because of thousands of functionalities, sometime because of way of writing)
  2. Engineers who have developed the design/verification environment start from scratch and leave the organization (Potential reason for now a day). In this case engineers leave with their all learning, concepts, tricks, algorithms and actual flow!
  3. When you don’t prepare architecture specification (top level as well as micro level). In this case you have to always rely on people who have been working on from years! This creates a solid dependencies for company, if those person leave because of any reason, it becomes very tough to maintain the design and verification environment for somebody who is new.
Customers always in hurry and wants their product ready and bug free! Critical situation comes when customer comes with their problem or with some new requirement support in design and you don’t have experienced person who have worked on this product. In this case engineers might face sleepless nights and will have to put lots and lots of efforts (because, they are not well aware of the design) to fulfill the requirement. Same requirements would have been fulfill with less amount of effort and as per expectation from client if engineers who have worked on this product are working!!
How could we avoid this type of pains?
  1. By making a habit of writing architectural documents with details. There could be different types of documents like top level architectural spec (which is useful for presentation), Micro level architectural documents (useful for engineers who are currently working and who will work in future as reference). Same is applicable for verification engineers for the architecture of verification environments.
  2. By not creating dependencies at certain level on any engineers and making sure that engineers keeps documenting changes/implementation done by them.
  3. By scheduling presentation/discussion on architecture and flow understanding for TEAM so that engineers working on the same product/protocol will gets understanding on flow.
  4. By following the standard verification methodology to reduce the pain of handing environment at certain extend since most of the methodology are user friendly and have many controls to handle complex environments.
Same blog post has been published on EDACafe blog portal, to access the same click here.
Happy Reading,