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,

ASIC-FPGA Design Verification: Running Short of Business or Resource?

Dear Readers,

As we all know the semiconductor market looks good now days and lots of companies are hiring talents for 2013-14 projection. If we keep this projection in mind, we could say there would be a business for the companies for upcoming years. Now, the billion dollar question: ‘how about the resources’?

We have been observing from last few months that companies are struggling in finding good experienced/skilled resources. Usually product/service companies are playing with smart approach of having hierarchical engineering model where there are few junior/college graduates engineers working under guidance of one senior/Lead engineer. Approach looks smart and efficient to utilize resources appropriately and makes engineering execution cost effective too! At the same time executive and managers always thinks on cost effective and efficient engineering model to fulfill dynamic time to market! Many companies are working with different approach to utilize and manage engineering resources efficiently.

There are cases or project specific critical requirements where you don’t have time to train your junior resources, in this type of requirement; you cannot take a chance of using junior level resource, if you do so, you might lose the schedule, budget and at the end market which is very important! There could be a requirement where you don’t need all your skilled resources to work on. For this type of requirement you can create a hierarchical approach of your engineering model to use the skillset efficiently. (This is where the engineering management comes in picture, Managers; Executives have to take efficient decisions to move forward in this type of situation otherwise in long go, you could see impact on quality and customer)

Now a day, most requirements and needs from the product based companies are for senior engineers, considering the critical project requirement and quick execution to make the products ahead in the market. Companies are feeling shortage of skilled resources. At the same time people don’t move easily! Question here is; Does this create shortage of experienced skillsets?

When market is in good shape, revenue and financial graph is growing mostly all the companies are in need of skilled man power and that’s where competition comes in picture for companies and engineers too! There can be different type of situations where market is not in good shape and companies are struggling to get the business. In these types of situation Smart companies usually starts investing in engineering man power to develop the skillsets keeping projection in mind, by the time skilled requirement comes, company already have skilled/trained resources ready to jump in to!

There can be other type of situation where market might or might not be in good shape. Irrespective of market Situations Company sometime announces on ‘restructuring the engineering force’ which means company directly or indirectly fires engineers as a part re-structuring. Mostly this situation comes because of shortage of business for company (particular business division of company).

These types of situations are still debatable and require dynamic changes based on the market, need, requirements etc… But still the question remains same at any point of time ‘Are Companies Running Short Of Business or Short Of Resource?

Same blog post has been published on EETimes blog portal:

You can read same blog post on EETIndia, click here !

ASIC With Ankit

Sunday, January 27, 2013

The two Door Keepers: An Assertion, to make sure bad thing does not happen and coverage, to make sure Good thing happens!

Dear Readers,

The two Door Keepers: An Assertion, to make sure bad thing does not happen and coverage, to make sure Good thing happens!
As we all know SVA (System Verilog Assertions) and SV Coverage are playing major role in test bench implementation which helps us achieving maximum confidence on bug free design. These components in the test environments are working as a ‘Door Keepers’! Assertions are mainly doing job to make sure bad things does not happen and Coverage is mainly doing job to make sure Good thing happens!!

Assertions are usually connected to the DUT (Design Under Test) through interface and keeps continuous eye on activities per clock. This way it is making sure that nothing bad happens, if so, it will inform user that something went wrong on particular clock.  Simulation tools are also intelligent in different ways (through log dump, GUI dump etc…) to report assertion failures! In SVA there are two types of Assertions, 1.  Immediate and 2. Concurrent Assertion. (For more details on assertions please see blog on ‘coverage model in system verilog’)

Functional Coverage are connected with different entities in the test bench to captures the information from the various places of test bench. Coverage gives us an enough confidence to make sure Good thing happens during the simulation. Functionality of functional coverage is to make sure that functional items, scenarios or stimulus are generated and covered. Functional coverage gives us confidence more on test bench whether all the identified, defined coverage items are generated and covered or not! At some extend functional coverage also makes sure that nothing bad has generated during the simulation. To catch such kind of unexpected behavior we have illegal and ignore bins!! As we know simulation tools are intelligent enough to catch expected and unexpected behavior and dump that in to .ucdb (coverage) files.
Assertions and Coverage are doing such a great job in test simulation and making sure nothing bad happens and also makes sure Good simulations happens! These Door Keepers are giving heads up at the end of the simulation if something went wrong during the simulation.
As a conclusion, we should not see assertion message at the end of the simulation message and should see lots of coverage information in successful simulation!
We, the engineers have to always make sure that ‘Door Keepers’ are intelligent and efficient!!
Happy Reading! Enjoy!

Sunday, January 13, 2013

Most of the re-spins are due to Functional defects?

Dear Readers,
I have been hearing on re-spins of chips. Many companies have gone through this painful phase because of several reason/defects. Nobody likes re-spin for chip as it is expensive and time consuming! Companies have a fear to loose time to market for their products because of this reason.
Let us understand the various factors which could cause re-spin for chips. If you ask industry experts or Semiconductor veterans they could share their experience. I have been discussing this topic with couple of people and have concluded few factors which could cause re-spin.
  1. Firmware Issues
  2. Power Issues
  3. Mixed-Signal Interface related Issues
  4. Race Condition Issues
  5. Clocking domain Issues
  6. Functional Issue etc...
From the experience and discussion it looks like most of the time Function Issues/defects have triggered a re-spin for the Chips. When we talk about functional issues, attention comes to our mind is for functional logic verification part. Considering complexities in the ASICs companies have started investing time and money for the functional verification part of the Chips to reduce the chances of re-spin.
To reduce the chances of re-spin for chips, people have started using various precautions like
-        A reusable and scalable verification
-        More effective block (IP) level verification
-        Verification reuse from block level to System level
-        Architecture of test bench using reusable methodologies
-        Constraint Random Verification approach (Refer: Blog post on Constraint Random Verification)
Random functional verification is giving us a enough confidence on functional defects. Random verification generates corner scenarios, stress testing on functional scenarios and logical permutation for configuration.
Random verification just gives us a confidence on functional defects but not giving us confirmation that Chip will not have to go through re-spin because of any of the functional issue.
Share your experience on Chip re-spin.
Happy Reading-Sharing,

Sunday, January 6, 2013

System Verilog : Ignoring function's return value!

Dear Readers,

functions and tasks are the very useful features in Verilog/System Verilog. We have been using these features since long in our test  bench development.

Though 'function' is available in verilog as well as in System Verilog, there is difference! Now you may want to know what is that difference.

Let me first explain you the differences between task and functions for Verilog language :

  1. Tasks can consume time while a function can not which means
  • tasks can have delays #50 while functions can not have.
  • tasks can also have blocking statements such as @(posedge clock) or wait (xyz) while functions can not have.
  • tasks can call functions while reverse case is not allowed (function can not call task)
Now let us understand what is the difference between usage of function in verilog and system verilog?

Verilog must return a value and a value must be used but In System Verilog If you want to call a function and ignore its return value, you can cast the result to void.

Conclusion :

If you have System Verilog task that does not uses or consume time, we should make it a void function. If you do this, you are free to use this this functions from any task or functions. This is the reason people are using debugging routine as void function rather than a task so that it can be called from any task or function:

For Example:

function void print_value (...........);
   $display ("Value of A=%h B=%h C=%h", $time);

Here we can see the syntax of usage, $display is not a time consuming feature and at the same time we don't have any other time consuming statements as discussed earlier like delays, blocking statement... This type of function does not need return value to be used. This will ignores returns value.

Hope this is a useful post to understand basic difference between functions and tasks in System Verilog.

Keep Reading & Sharing,
ASIC With Ankit