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!

ASIC With Ankit

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,

ASIC With Ankit

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);
endfunction

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