Sunday, April 29, 2012

SVA : System Verilog Assertion is for Designer too!!

Dear Reader,

I have been hearing one question over SVA is "Is System Verilog Assertion is for Designer too?". Usually the impression is 'System Verilog is for Verification'. I agree with this impression to some extend but there are some strong constructs in SV which adds values for designers too for design coding !

Actually System Verilog is nothing but a extension of Verilog, It has everything to support Verilog with lots of new features for Verification as well as for design!! This is again one important topic to discuss, I will try to cover this in some other blog post. Here I would try to capture question which I have mentioned above "Is System Verilog Assertion is for Designer too?".

Simple answer to this question is "YES" !!

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/should write assertion within a design while the HDL models are being coded. Usually here is where main question/challenges occurred, what type of scenario or assertions designer should provide within design? Answer to this question is : Decision should made before design work begins.

There is no doubt that 'Verilog Checks like assertions can be added into a design using the standard Verilog language' But I would like to point out some drawbacks on writing verilog checks like assertions this way,

1. Complex Verilog checks can require writing complex Verilog code.
2. Checks written in Verilog will appear to be part of the RTL model to a synthesis compiler.
3. Verilog assertion/checks will be active throughout simulation, there are ways to control over it but there is no simple way like SVA does with system functions ($assertoff, $asserton, $assertkill etc..)
Please read my blog post on "SVA Control Methods"

Let me explain some advantages for designer with SVA:

1. SystemVerilog assertions are ignored by synthesis. The designer does not need to include translate_off / translate_on scattered throughout the RTL code.
2. SystemVerilog Assertions can easily be disabled or enabled at any point during simulation, as needed. This is a beauty of SVA!! Don't you think ?

I have covered 2nd advantage in my blog post "SVA Control Method"

These advantages allows designer to add assertions to RTL code and gives a flexibility to disable the assertions for simulation speed later in the design process. Using this control methods we can focus to a specific region of the design by controlling assertions dynamically or disabling respected assertion in the design.

Suggestions and Comments are always welcome.

ASIC With Ankit

Wednesday, April 18, 2012

SVA : System Verilog Assertions - Dynamic Control Methods to control Assertions

Dear AwA Readers,

System Verilog assertions are becoming popular now a days and industries are adopting SVA as part of their verification environment. SVA (System Verilog Assertions) are useful in many areas in design as well as in Verification. There has been a debate going on since long on "Who should write assertion designer or verification engineer ?" This question inspired me to write on blog post to discuss this point, you can refer my blog post on 'Who should write SVA?'

Well, here I would like to discuss SVA control mechanism which will answers your question "How to control SVA dynamically?"

One of the biggest issue with Verilog type Assertion is that they are either always on or through `defines, set to be always off. They could not be turn ON or OFF dynamically. System Verilog Assertions have resolved this issue by adding system functions called $assertoff, $asserton and $assertkill.

Definition :
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. Isn't it interesting ? It is !! I have used these feature in one of my project years back and realized it's beauty. Using these system tasks you can make your assertions dynamic and based on need and requirement you can make them enable or disable. You can even kill using $assertkill all assertions if you dont want to run them during your simulation. Wow !!!! Isn't it a real beauty?, Engineers are now super flexible to use and control the SVAs :)

Dynamic control of Assertions can be used to turn off assertions during reset and initialization or during simulation erroneous protocol behavior.

I had a situation where I had to shut off all my assertions and let my simulation run to cover some of my interesting and robustness types of scenarios. You might have situations where you might need to shut off your all implemented assertions or some particular assertions during your simulation. SVA allows us to use these system functions and we can play around with these system to have full control on Assertion ON-OFF or event to kill all assertion in some cases.

Have fun with SVA (System Verilog Assertions) and use its super functionality with user friendly control !!

ASIC With Ankit

Monday, April 16, 2012

System Verilog Fork Join : The most important and very useful process control feature!

Dear AwA Readers,

I have been hearing many discussion on fork join (Process Control) Block in System Verilog. In most of the verification environment people are using fork join to control different process/threads in parallel. As a design or verification engineer you will definitely come across a situation where you dont have option other than 'fork... join' !! 

Fork... Join construct of System Verilog actually enables concurrent processes from each of its parallel process/statements. This features is basically came from Verilog language, Its mostly used for forking parallel processes in Test Benches. System Verilog came up with improved and advanced features capability in fork join construct which adds lot of values for test bench implementer. Those are given below: 
  • More Controllability : It has three different ways to control parallel processes.
    1. Normal fork.. join : This type of fork join, waits for completion of all of the threads.
    2. fork...join_any : The parent process blocks until any one of the processes spawned by this fork complete. This means if you have 2 process in your fork block and each needs different times to complete. In this case whichever process completes first, fork join will comes out of the block and will start executing the next statement in simulation. This does not mean that rest of the 2 process will be automatically discarded by simulation. Those process will be running in the background.  
    3. fork...join_none : The parent process continues to execute concurrently with all the processes spawned by the fork. The spawned processes do not start executing until the parent thread executes a blocking statement. This means it does not wait for completion of any threads, it just   starts and then immediately comes out from the fork join loop. This also does not mean that it will not execute threads. It will !! The thing is, it will not block (executes each thread parallel in background) the simulation and will simply move forward and execute next statement in simulation.
  • Process Destruction: SV has different constructs/ in-build methods for destruction of  process.   
  1. wait fork : There is a question on "What will we do, when we need to wait fork threads to finish after some simulation time? which means we does not want to move forward until we finish each thread in fork join. So to solve this problem SV has one more construct called 'wait fork'. 
  2. disable fork : Now suppose you have exited the fork loop by join_none or join_any and after some steps or after some simulation time you want to kill all the threads spanned by the previous fork loop. What will you do ? So dont worry, SV has "disable fork" for the same !! Dot you think its interesting   ?? It is !!
  3. disable _thread : This is a real beauty and value addition for SV fork join block. Now there are some scenarios where you need some kind of controllable constructs through which you can disable particular threads out of your multiple threads running in your fork..join block. For example: you have exited fork loop by join_none or join_any and after some steps you want to kill just one thread (out of many). To solve this problem system verilog has construct/block called "disable". you can have named begin end thread and call 'disable'. If you want to disable only the 2nd thread after exiting the loop via join_any or join_none, then add "disable second_thread" at the point where you want to disable the second thread. 
SV has some fine grain process control methods too !! Using this build in class methods you can add more values and make your solid control over processes ! Don't you think these are the beauties of System Verilog for Verification Environment ? 

Hope this brief explanation on fork join threads and different methods will add some more knowledge and clears the fundamental for its usage in Test Bench development.


Thursday, April 5, 2012

USB 3.0 : Future is here, Its time for Super Speed !!

Dear AwA Readers,

Well, its quite common and usual that a common man knows about USB at least by its name! We as an Engineer at least know what is USB devices and how are they being used in our day to day life.

I was working on USB (USB 1.0/2.0) protocol 2-3 years back, during that time people were working on USB 1.0 and USB 2.0 IPs. USB 1.0 was supporting 12Mbps and 1.5 MBps. The original USB1.0 standard was introduced in 1996 and then USB1.0 technology got matured by 1997 and then first widely used version of USB1.1 introduced since then industry was working on USB1.0 technology. In year 2000 USB2.0 was introduce with higher data transfer rate which was 480MBps Since then industry is working on USB2.0 Technology. This is one of the most popular and successful technology I have ever seen. I am not a old guy with years of experience to say but have been hearing the same from many experience technical person !

USB technology/devices are becoming part of individuals life. People are using USB in their daily life and making their data transfer work faster !! When I get started working on USB 2.0 verification, I realized the concept and efficiency of data transfer with higher data transfer rate. Usage is very easy, its plug and play type device for user but its super tough to design/architect its device enumeration/attachment process !!

I was thinking USB 2.0 is amazing and people are use to this technology with all available devices in market. But as we know "Technology keeps on moving and we too" !! Now they have came up with new version of USB which 3.0 (Super Speed) version with super fast data rate up to 5Gbps !!! Don't you think its super fast ? It is !

It means now we can transfer 16 GB data in 53 seconds where USB2.0 technology was taking 8.9 minutes to transfer the same data !! Dont you think its super fast !!

Our history says, In 2006 alone over 2 billion USB devices were shipped and there are over ~8 billion which have been installed today !! This is for USB2.0. Now think of USB3.0 which is just gearing up. Huge scope and bigger space to grow towards this technology which means Future is here !!

Based on my knowledge and USB popularity, I am expecting 1 billion devices to be shipped by 2014!!

Well, I am super excited to see growth on super speed USB business !! I have already started reading USB3.0 protocol excited to see difference over USB2.0 which I know a little bit :)

ASIC With Ankit

Monday, April 2, 2012

Importance of Constrained Random Verification Approach

Dear All,

As a verification Engineers we must know what technique should be used in Test Bench development to verify IP, FPGA or any ASIC/SoC Verification.

I have been hearing many ideas, techniques and approaches on Directed Testing as well as Constrained Random Verification. Here I would like to share some advantages of CRV (Constrained Random Verification) over Directed Testing/Verification. Let us try to understand in brief on both approaches

First, let me give you an idea on 'What is Directed Testing?'

Directed Verification Environment with a sets of directed tests is extremely time-consuming and difficult to maintain. Directed tests only cover conditions that have been anticipated by the verification team, This can lead to costly re-spins and still there are changes of missing market windows which is extremely painful for any semiconductor company.

In directed Verification testing, Engineers spends good amount of time to understand the functionality of Design and identify different verification scenarios to cover functionality. Once they are done with identifying scenarios, they start defining directed test bench architecture. Traditionally verification IP (VIP) works in a directed test environment by acting on specific testbench commands such as read, write or some other commands to generate transactions for specific protocol testing. This type of directed testing is used to verify that an interface behaves as expected in response to valid/invalid transaction. Bigger risk with this type of testing is that directed tests only test for predicted behavior. So some time it leads to extremely costly bugs found in silicon which they missed during the scenario identification phase !!

Constrained Random Verification Methodology gives effective method to achieve coverage goals faster and most importantly it helps in finding corner case problem. Advantage is, Engineers does not have to write many test cases, smaller set of constrained-random scenario with few full random test scenario are good enough to fulfill coverage goals (functional as well as code coverage).

Based on my experience and understanding, usually people follows layered architecture in constrained random verification. (For better understanding of layered architecture, click on Gopi's Blog or Read VMM User manual by Synopsys) where you will see Test layer controls over whole verification environment and component. Mostly this control will be given to user. So user can run same test suites with different configuration if require to achieve coverage goal. In constrained random approach, scoreboards are used to verify that data has successfully reached to its destination while monitors snoops the interfaces to provide coverage information. New or revised constraints focus verification on the uncovered scenarios to meet coverage goal. As verification progresses the simulation tool identifies the best seeds which are then retained as regression tests to create a set of scenarios, constraints and seeds. In this approach of verification, you will be having less number of test cases which is enough to achieve coverage goals. I have observed one best usage of Directed tests in random verification, Here I am describing the best usage place of directed tests.

Always use directed tests after regression cycles of random verification, Random verification regression cycles gives some corner scenarios which are always left in coverage and you can always identify from functional and code coverage analysis. So identify those kind of scenario and write directed tests with specific constraint to cover specific scenario. This way coverage will be achieved !

Constrained Random Verification is very popular now a days because of so many reason, I have tried to capture couple of differences and advantages over both techniques.

Hope this post adds better understanding over constrained random verification technique.

Note : Special Thanks to Mr Gopi Krishna allowing me to use his webpages as references and posting my couple of interesting posts on his website My Coverage Post, My Pass/Fail Message Post

Comments, suggestion and questions are always welcome !