SV Macros : Basic with some Interesting facts!!

Dear Readers,

Recently I found very interesting thing about ‘macro’, Let me discuss this in detail. First let's understand what is macro and how is it useful for us ?

What is Macro ?

A macro is a literal name used in a program that is substituted by some value before the program is compiled. Macros are useful as an alias, they are not variables. Almost all modern languages supports macros ! An interesting feature which helps helps engineers in making some complex thing easy (However, clubbing information in macro itself is tough and challenging in some situation ;))

Now, lets discuss on How & Where to use macros?

Where : Macros are used in various places during the implementation, some places like:

1. Interface instantiation in test bench
2. Functional Coverage
3. Assertion/Checker 

These are some of the major places where people mostly use macros to reduce the number of code lines and to understand and utilize same piece of logic in test bench.

How : Explaining a how part is always easy with example, engineers understand things quickly with examples, right ?

Example :

`define XYZ (i) i``_suffix

This expands:

`XYZ(bar) to bar_suffix

Let's take an one more example:

`define DATA_TYPE(A) A

Using this macro we can do following.

Instead of writing integer a, we can write `DATA_TYPE(integer) a;

Above mention examples are basic and simple to understand but in complex test benches we might end up having an requirement where we need macro which can hold hundreds of code lines information

For example, my RTL has an interface, where hundreds of signals defined but signals are repetitive in nature with respect to number of client/hosts etc...

So during the instantiation of these kind of DUT, I would suggest to use macros for these kind of signals and try to club in to one macro which can hold an argument, based on argument passed, it will generate sets of signals for each client/hosts and make and instantiation.

For example:

RTL has signals given below

write_0_host, write_1_host, write_2_host

while instantiating these signal in test bench, we can use macro mechanism to make it easy and controllable:

`define WRITE_FOR_HOST(i) \

.write_``i``_host   (write_``i``_host)

After defining macro, use these in your port connection

abc  xyz (

   ..... signals port instantiation

   .abc  (abc),

   `WRITE_FOR_HOST(0),

   `WRITE_FOR_HOST(1),

   `WRITE_FOR_HOST(1),

   ......

   .......

   .pqr (pqr)

)

These way you can create a sets of signal instantiation by using macro and is very useful when you have hundreds of this kind of signals.

Some interesting facts:

1. If you have space in between macro name and argument, we need to maintain the space during the call of that macro. In above example WRITE_FOR_HOST(i) does not have space in between macro name and argument "(i)" list. If you use `WRITE_FOR_HOST  (i) then compiler will give you an error. So always take care of space between macro name and its argument.
2. If you have some white space after your end of character "\", compiler gives you an error like ""zero length escaped identifier". While space are not visible. In some cases by mistake we might have left some white spaces after "\", which means "\" is not at the end of line and compiler will shout for this kind of issue. Issues mentioned above are generally hard to debug because both the issues are with white spaces and white space are not visible!!

Wishing you a happy SV writing ! Keep reading, comments and suggestions are always welcome.

Happy Reading,

ASIC With Ankit

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.

Enjoy
ASIC With Ankit

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

Enjoy,
ASIC With Ankit

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.

Enjoy!

ASIC With Ankit

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

Enjoy,
ASIC With Ankit

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 http://www.testbench.in/links.html. My Coverage Post, My Pass/Fail Message Post

Comments, suggestion and questions are always welcome !

Enjoy!

ASIC With Ankit

Polymorphism: One of the most important feature for Test Bench Development.

Dear Readers,

Here I would like to share basic and most important fundamental of OOP (Object Oriented Programing) language 'polymorphism'. Polymorphism is one of the most important feature used in Test Bench development using System Verilog. Understanding of this fundamental is very important if you are planing to work with System Verilog with any kind of methodology (AVM, VMM, OVM, UVM).

Definition of Polymorphism :
As per the SV LRM "Polymorphism allows the use of the variable in the superclass to hold sublcass object and to reference the methods of those subclasses directly from the superclass variable."
 Which means, A single task can be implemented using the same name and implemented differently as each type in object hierarchy requires. Later when polymorpic object (whose type is not known at compile time) executes the virtual method and the correct implementation is chosen and executed at run time.

To achieve polymorphism the 'virtual' identifier must be used when defining the base class and method(s) within that class.

Let me give you a brief example to understand polymorphism in detail which helps you in your test bench development:

Example:

Note: Click on the image to see example with big fonts

When you run above example you will see below result:

Output :
send Method from class 'Base'
send method from class 'Ext_Base'

You will see in example line number 30 where Extended class from base class 'ext_b' has been allocated a memory by doing new and then on line number 31 we assigned a memory between two objects (b and ext_b). Now when we called b.send(), it will call extended class method. This is called polymorphism.

Hope this example, with explanation gives you a better idea on polymorphism. I am sure this will helps you in your test bench development.

Enjoy !
ASIC With Ankit

Is VHDL is gearing up with new methodology called OS VVM??

Dear Readers,

Recently Aldec, Inc has announced in collaboration with SynthWork Design, Inc on Open Source VHDL Verification Methodology (OS-VVM) !! Isn't it interesting !!!

From last couple of years experts have been coming up with lots of new methodology, I have heared about RVM, VMM, OVM, UVM, AVM now its VVM.....!!!!

The way methodology are coming up in market, it indirectly forcing engineers to get ready themselves with up to date with new methodologies !! Companies might accept any available methodology based on their need and other so many factors !! Having knowledge of such methodology definitely helps individuals to jump in to any time !!

Now coming back to VHDL methodology, it seems companies are trying to keep alive the VHDL world !! From last couple of years it has been noted that new language standards such as System Verilog, System C has captured market so quickly and leaving VHDL Designers with dilemma of learning a new languages !!

It seems VHDL methodology is a try to keep alive VHDL world and engineers ! This may open a hope for VHDL Engineers for upcoming new opportunities with VHDL. Now that it is an announcement of openly available methodology, let's see how it goes and how it get success to capture market or companies confidence !!

I haven't started reading these methodology but I am damn sure System Verilog with its methodology would be definitely better than this one at least for verification !! Still I would love to read VVM for VHDL to understand what are the new features they have added for users !!

They said, VVM provides access to advance randomization and functional-coverage capabilities that can be used in any test bench !! I am eagerly waiting to read this methodology to know how they are providing these features with VHDL !!

Don't you think its interesting !!

Enjoy,
ASIC With Ankit

SVA Based Verification

Dear Readers,

In year of 2002, this was called as OVA (Open Vera Assertions). Later on Synopsys Inc had donated the Open VERA language to the Accellera committee to be part of System Verilog language. Several other companies made contributions for the formation of the new Systerm Verolog language. System Verilog language included the assertion language as part of the standard which is called as a “System Verilog Assertions” (SVA).

For verification engineers, main objective is “to verify the design under test (DUT)” thoroughly and make sure there are no functional bugs.

I have seen different approaches to develop test bench:
  1. Directed way of writing a test bench
  2. Constrained random test bench
  3. Semi randomize way of writing test bench

Main points while architecting any verification environments are given below:
- Simulation Generation
- Protocol Checking
- Data Checking
- Protocol Coverage
- Test Plan Coverage

If you see the history and figure it out, you could see, most of the Test benches which were developed before SVA were taking care of all above given categories. Later on when SVA introduced in System Verilog language and two categories, first Protocol Checking, second Protocol Coverage addressed by SVA. These two categories are closer to the design signals and can be managed more efficiently within SVA than by the testbench.

By connecting these assertions directly to the design, the performance of the simulation environment increases tremendously as does the productivity. Using this approach we can share information dynamically during the simulation.
We can not say that without SVA protocol and test plan coverage is not doable. People were doing those things when SVA was not invented!! I can say those parts are easy and effective using the SVA because of its strong constructs and features. For more details on coverage model and brief on Assertion please refer http://asicwithankit.blogspot.com/2011/01/coverage-model-in-system-verilog-test.html

References : A practical guide for system Verilog assertions, By Srikanth Vijayaraghavan, Meyyappan Ramanathan

Enjoy!
ASIC With Ankit

Ohh God ! Would this triggers a ‘Recession Blast 2011-12'?

Dear Reader's

Many of you might be knowing the recent hot news..... Any way let me give you a brief on it. "Recently John Chambers a CEO of CISCO has announce that they are going to fire 10,000 people from his organization from which thousands of them were expected to be gone at the end of August and rest of them would accept the buyouts". Isn’t it a shocking news?


I was shocked after hearing this news and end up with a deep though that “Would this action leads the industry towards the Recession?” We just came out from the global recession. We know that it went so bad that most of the people in this industry were affected one way or other way.

If we go and see the history of CISCO, we can easily see the growth and revenue of organization. Since talking over as CEO of Cisco in 1995, Chambers has grown the company’s revenue from $1 billion to more than $40 billion which shows his capabilities and business quality.

To me, revenue growth would not create the shareholder’s value. Anyone can ‘grow revenue’, especially through acquisitions. All you have to do to grow revenue is buy companies. Important part to create stakeholder’s value is ‘Grow earning per share’. If such kind of action would be taken by few giant companies, then surely our industry will be in crunch!

At the same time I was wondering when I saw few opening on Cisco’s career site. I was just wondering, at one side management is announcing firing and at the same time we can see hiring on its web page! It seems there is nothing to do with industries bad time. It just that organization might have taken some bad decision in past. So I don’t see any problem with current Industry.

If you see recent ASIC industry growth, engineers’ engagements with their clients, and consumer demands, I could see no problem for at least next two years. As we know electronics consumer demands are high now a days, companies has enough work and projections for at least next few years.

I would say this action would not lead this industry towards the Recession! what do you say ?

Enjoy,
ASIC With Ankit

Modelsim Vs Questa Features

Dear ASIC Readers,

We as an ASIC Engineer are frequently using different simulators for our simulation activity. At present time we are frequently using modelsim/Questa and vcs. These are the industry popular and well proven simulators.

I have seen people who are using modelsim / Questa simulator from Mentors but dont really know the exact difference between them.

I have captured some difference between Questa and Modelsim. Though both are simulators from the Mentor Graphics there are some differences between them

Below are the differences I captured :

ModelSim is Mentor Graphics HDL simulator. Questa is Mentor Graphics advanced verification platform that uses ModelSim as its core simulation engine.

Features of the two tools can be grouped into five categories and compared as follows:

1. Language Support
- ModelSim supports SystemVerilog IEEE 1800 for Design only, as well as VHDL (1987, 1993, 2002), Verilog (1995, 2001, 2005), as well as options for mixed language and language neutral licensing and support for SystemC 2.2 IEEE 1666/OSCI 2.2.
- Questa supports all of this as well as SystemVerilog IEEE 1800 for Verification, mixed language licensing (Questa is by default language neutral), PSL IEEE 1850, and SystemC 2.2 IEEE 1666/OSCI 2.2 as standard features.

2. Simulation
- ModelSim supports a single-kernel simulation engine, Verilog RTL & gate level performance optimizations, VHDL RTL & VITAL performance optimizations, performance and memory profiler, separate elaboration, waveform management tool set, VCD and extended VCD support, VCD re-simulation, batch mode simulation, integrated simulation, checkpoint & restore,

- Questa’s simulation support is identical to ModelSim’s

3. Design Entry, Debug, and Analysis
- ModelSim supports an HDL editor, integrated project manager, source code templates and wizards, interactive and post-simulation debug, dataflow graphical and textual causality traceback, source annotation, memory window, extra standalone viewer, multiple waveform windows, waveform compare, C Debugger and transaction viewing for SystemC.

- Questa supports all of this and the C debugger and transaction viewing for SystemC and SystemVerilog are standard parts of the product.

4. Advanced Verification Methods
- ModelSim does not support any advanced verification features.
- Questa supports assertion-based verification (including a library of pre-written assertions called Questa Verification Library or QVL, and an assertion thread debugger), automated test stimulus generation via a constraint solver engine, and PowerAware RTL verification supporting both CPF and UPF formats.

5 Verification Management and Coverage
- ModelSim supports Code Coverage (it is included in ModelSim SE, and an option to other versions of ModelSim).

-Questa supports code coverage along with functional coverage, a unified coverage database (UCDB), coverage viewing, test ranking, and test plan tracking

Hope you find this information useful.

Enjoy reading...!
ASIC With Ankit

Coverage model in System Verilog Test Bench

Dear All,

I am back after a long time ! Here I would like to share my experience on coverage model in System Verilog..

There are different ways to define verification plans, I have worked with different organization where I have been involved in verification activities with different approaches. There are two main questions which each verification engineer needs to take care, which are “What to verify” and “How to verify”. I would try my level best to explain it in details with my experiences. Hope you enjoy this technical writeup.

Success of a verification relies heavily on the completeness and accurate implementation of a verification plan. A good verification plan contains resource usage and estimated schedule.There are different ways to define verification plans, such as a spreadsheet, a simple document or text file in some cases. It depends on company to company as way of following a process may be different.

What to verify and how to verify are the major two things which each verification engineer has to think before starting actual verification.

First of all engineer has to clearly defined features to verify in feature extraction phase. And then after defining what exactly need to be verified, engineer has to define how to verify them.

There are two approaches in current industries to make sure that verification is done using Assertions and Functional Coverage. You might have heard about the different methodologies like CDV, RVM, VMM, AVM, OVM and UVM etc... Methodologies are nothing but a flexibility for verification engineers. Using methodologies engineer can reuse and and utilize the power of base classes and the features in a different way. Its a beauty of each methodologies we have been using. I am not denying the that without methodologies we could not make sure on confidence of verification environment, we could. As we know now a days SoCs and ASICs are becoming complex and complex each day, verification engineers ending up with thousands of scenarios with complexity of environment, so in this case methodologies have helped us in utilizing the power of features and functionality of methodologies. I have worked on RVM, VMM and OVM too... I have realized that each methodologies have their own strong features and re-usability. Any way, I would try my best to come up with an detail writeup on methodologies ! Hope I should be able to come up soon :-)

As I have mentioned there are two approaches in current industries to make sure that verification is done. Those are 1. Assertions 2. Coverage. Thats where AIPs (Assertion IPs) and VIPs (Verification IPs) came in to picture.

1. Assertions :

Assertions are primarily used to validate the behavior of a design. ("Is it working correctly?") They may also be used to provide functional coverage information for a design ("How good is the test?"). Assertions can be checked dynamically by simulation, or statically by a separate property checker tool – i.e. a formal verification tool that proves whether or not a design meets its specification. Such tools may require certain assumptions about the design’s behavior to be specified. There are two types of Assertions:

Immediate Assertions:

Immediate assertions are procedural statements and are mainly used in simulation. An assertion is basically a statement that something must be true, similar to the if statement. The difference is that an if statement does not assert that an expression is true, it simply checks that it is true, e.g.:

Concurrent Assertions :

Concurrent assertions are used to check behaviour such as this. These are statements that assert that specified properties must be true. 

2. Coverage Model :

As I have explaing above that SoCs and ASICs are becoming complex and complex each day ! The main concerns for industries are :

1. How do they close verification ?
2. How can they say , they are done ?
3. How can they make sure they have stimulated each possibilities ?

To answers these questions, they came up with languages called system verilog with the concept of functional coverage. This concept is mainly used to make sure accurate configuration.

All our current day methodologies have brought in the concept of re-usability of the agents such as BFM’s and monitors across projects. An engineer also creates a coverage model in order to provide the management with a picture of the verification activity status.

Using the strong constructs called covergroup, coverpoint, bins, cross coverage and class concept engineers are easily develops coverage model to generate functional covergare report after they run each simulation. Coverage reports gives us a lot of information in detail in pictorial view as well as in text formate too (based on the tools which you are using).

Its very important and individual should write functional coverage very accurately. I have mentioned some tips on writing functional coverage. Please read my article http://asicwithankit.blogspot.com/2010/03/dont-rely-on-illegalbins-for-checking.html (has been published by two most popular websites testbench.in and asicguru.com)

Hope you have enjoyed this article ! Please shoot me an email or post a comment if you have good thought on this point or you have any questions which you want to discuss.

Enjoy !

ASIC With Ankit

My Articles published by popular websites

Dear All,

Finally my article published by some popular technical websites called http://www.testbench.in/art.html and http://www.asicguru.com/articles/verification/70/.


These are the two popular websites for ASIC Engineers. You can find my articles on these websites from below given links :

1. http://www.testbench.in/colorfull_messages_from_systemverilog.html
2. http://www.testbench.in/Do_not_rely_on_illegal_bins.html
3. http://www.asicguru.com/articles/verification/70/
4. http://www.asicguru.com/articles/verification/do-not-rely-on-illegal_bins/157/


Enjoy with Ankit !!!
ASIC with Ankit

disable fork will disable the respected fork threads

Dear ChipMates,

Here I came across interesting exercises with fork join, I was using fork join thread in my complex verification environment where I was playing with so many fork join threads. I was having child forks inside parent forks.

System Verilog has a strong construct called 'disable fork' through which engineer can control the fork processes. SV has three different fork processes, 1. fork-join 2. fork-join_none 3. fork-join_any. From which fork-join_none and fork-join_any needs process control because normal fork-join will comes out only when all the processes will be executed and done. But join_any will comes out when any of the process will finish its job. These places some times we need process control and we may need to disable fork thread once perticular process is done.

I have made simple exercises (given below) which will give you idea how to control fork-join with disable fork construct in System Verilog.

program test ;
class A ;
   task fork_join ();
      int temp = 1;
      fork
         begin
            fork
               begin
                  if (temp == 1)
                 $display ("Inside first Begin...end thread \n");
               end
               begin
                  # 100ns;
                  $display ("Inside second Begin...end therad\n");
               end
            join_any
           disable fork; // This will disable only child fork
        end
        begin
           # 50ns;
           $display ("Inside Second thread of main fork \n");
        end
    join
   endtask
endclass


initial
begin
   A aa = new ;
   aa.fork_join();
end
endprogram

From the above given will pring below given messages :

OUTPUT:
Inside first Begin...end thread

Inside Second thread of main fork

From the messages it seems, it has disabled the child fork proecess not the mail fork process, and as a result we are able to see second message called "Inside Second thread of mail fork"

Hope this was a useful sharing for all.

Happy Reading,
ASIC with Ankit

SIA Forecast Projects Industry Will Grow to $290.5 Billion in 2010

Dear Chipmates,

As we all know consumer demands on electronics has been increased and because of that reason semiconductor industries are booming now..! They are doing good and most of the semiconductor companies have released good financial results in last quarter.

Recently I came across the article from SIA (Semiconductor Industry Association) on world wide sales on Chips.

The Semiconductor Industry Association (SIA) today released an updated industry forecast that projects worldwide chip sales will grow by 28.4 percent to $290.5 billion in 2010. The forecast projects 6.3 percent growth in 2011 to $308.7 billion, followed by 2.9 percent growth in 2012 to $317.8 billion.

“Healthy demand in all major product sectors and in all geographic markets drove sales of semiconductors to record levels in the first four months of 2010,” said SIA President George Scalise. “While the year-on-year growth rate will moderate through the remainder of the year, we expect modest sequential sales growth in line with historic seasonal patterns. The industry began the year with inventories in balance and we do not see evidence of excess inventory accumulation at this time.

“Economic forecasts project global economic growth rates of 4.6 percent in 2010 and 4.4 percent for 2011, with the fastest growth expected to be in emerging economies. These emerging markets – especially China and India – are creating demand for Information Technology products, which in turn fuels demand for semiconductors,” Scalise concluded.

From the above article it looks like for next at least 3-5 years are good..! So Cheers with Ankit..!

Happy Reading,
ASIC with Ankit

Finally Google recommendes my blog in its search engine if you type key word called "ASIC with"...!

Finally Google allows my blog in its search engine...! :)

It has been a couple of months I am writing a blogs on technical things, on inspiration and on funny things as well. "ASIC with Ankit" is a brand which I have made and now Google has accepted in its search engine as well because of number of hits on this blog.

Now if you search with a key word called "Finally I Google allows my blog in its search engine...!" and you will find only one recommendation from Google and that is "ASIC with Ankit"...!

Thanks to the readers who are reading this blog and posting their comments to make it more useful for ASIC Engineers.

Enjoy,
ASIC with Ankit

PASS and FAIL Messages with Colors...!

How many among you know that you can actually display color messages using Verilog and SystemVerilog?

You can implement a logic in your testbench to have nicely colored display messages at the end of your simulation which will give you a PASS/FAIL messages. I have written a piece of code given below and you can refer the same. I have captured a snapshot of output which you can see at the top.

program clr_display();
class color ;
   task display ();
      $write("%c[1;34m",27);
      $display("***************************************");
      $display("*********** TEST CASE PASS ************");
      $display("***************************************");
      $write("%c[0m",27);

      $display("%c[1;31m",27);
      $display("***************************************");
      $display("*********** TEST CASE FAIL ************");
      $display("***************************************");
      $display("%c[0m",27);
   endtask
endclass

initial begin
   color clr;
   clr = new ();
   clr.display ();
end
endprogram

With an above example you can have a display messages with colors. So this way you can have nicely and colored messages on your terminal.

Enjoy...!
ASIC with Ankit

Don't rely on illegal_bins for checking perpose....

Dear Readers,

Do not rely on illegal_bins for checking perpose. If you rely on covergroup where you have written illegal_bins, what happens when you turn off the coverage??

That is where Assertions coming in picture...! If you really want to ignore values then use ignore_bins. If you really want to throw errors then use an assertions checkers.

While illegal_bins removes values from coverage calculations, it also throws errors.
Philosophically, you need to ask yourself the questions,

(1) “Should a passive component like a covergroup be actively throwing errors?” and
(2) “If you rely on the covergroup for checking, then what happens when you turn coverage off?”

From the example given above, you can see 3'b100 is an illegal opcode and as per protocol if that value occurs then its an error.So here instead of writting and illegal_bins you can have a assert property with coverage to check specifically this scenarion.

So usually I would prefer to have an assertions (with cover property) where strong protocol check requires instead of writting illegal_bins.

Happy Reading,
ASIC with Ankit

VCD dumping from VCS command line?

Dear Readers,

Dumping of signal value changes in VCD format can be enabled
in verilog by including the $dumpvars system task.

In addition to this method, VCS provides a way to enable
VCD dumping at compile time.

This can be achieved by including the following switch
at compile time: "+vcs+dumpvars[+filename]"

For example, consider the following case:

% cat test.v
module test;
reg clk;

initial begin
clk = 1'b0;
forever #5 clk = ~clk;
end

initial begin
#100 $finish;
end
endmodule

% vcs test.v -V -l logfile -R +vcs+dumpvars+test.vcd

The $dumpvars system task is not specified in the verilog code above. Instead,
VCD dumping is enabled with the addition of the compile time switch "+vcs+dumpvars+test.vpd".

The result is equivalent to calling the following system tasks:

$dumpvars;
$dumpfile("test.vpd");

If the filename is not specified (ie. only +vcs+dumpvars is used), then the
filename defaults to "verilog.dump".

If both the system task ($dumpvars) and the compile-time switch (+vcs+dumpvars)
are specified, then the compile-time switch takes precedence.

No additional verilog code is needed when enabling VCD dumping using the compile
time switch.

Having compile time switch reduces little bit of code and makes life easy :-)

Enjoy....
ASIC With Ankit

Is it really possible to develop relatively complex functional coverage model using SVA (System Verilog Assertions)??

Dear Readers,

Is it really possible to develop relatively complex functional coverage model using SVA (System Verilog Assertions)??

Yes, SystemVerilog Assertions (SVA) can be used to implement relatively complex functional coverage models under appropriate circumstances:

I would say using strong construct of SVA we can develop a functional coverage model too. The point here is using SVA construct you need to do some work around while in functional coverage there are some constructs using which we can simply write a cover points to cover the functionality.

Let me take an example and try to explain:

Let say we have a verification scenario where we have to cover state transitions.

It should cover

1. states transition A-B and
2. State transition B-C

This can be covered using functional coverage construct “=>” like A=>B and B=>C so basically code would be given below in functional coverage model:

covergroup state_trans_cg @ (posedge clk);
   coverpoint state_trans_cov
{
   bins A_to_B = (A => B);
   bins B_to_C = (B => C);
}
endgroup

Same functionality we can cover using SVA constructs as well:

If we try to cover the same functionality using SVA then code would be:

sequence seq_A_B;

@(posedge clk)

`A ##1`B;

endsequence : seq_A_B

sequence seq_B_C;

@(posedge clk)

`B ##1`C;

endsequence : seq_B_C

trans_A_B : cover property (seq_A_B);

trans_B_C : cover property (seq_B_C);

In this case cover property will cover state transitions which we are covering using transition bin in functional coverage.

Like these there are lot many constructs are there in System Verilog Assertions using which we can cover functionality.

As per my knowledge and experience if you use SVA for your functional coverage then you need to play a little bit with SVA constructs while things would be easy if you use functional coverage instead.

Big Advantage to use SVA Coverage model is, Engineer does not required object oriented programming language knowledge :-)

Happy Reading,
ASIC with Ankit

Tripple Equality operator is not supported in constraint, or in VCS ?

Dear All,

I have been playing with the constrains and and randomization from last couple of years and come to know one thing while using the "thipple equality operator in constraint".

I have posted some interesting stuff on equality operator in my previouse blog called "what should we use == or === ??" One more interesting thing I came across with this operator is, 'These ('===' and '!==') operators are not allowed in System Verilog Constraints in VCS'. I am not sure about the other tools. I would be eager to know whether its a limitation for tool or its an constraint limitation in System Verilog?

I have gone through the LRM and could not able to find this limitation for constraint..!

If you use tripple equality operators in consraints then you will find the compilatin error given below:

Error-[IUORCE] Illegal operator in constraint
The operator !== is not allowed in constraints.
Remove the operator or replace it with an expression allowed in constraints.

Seems interesting...! I am eager and would be pleased to hear some thing on this, suggestions and inputs are always welcome....

Happy Reading,
ASIC With Ankit

what should we use == or === ??

Dear Readers,

I have been using this operator since I have started my career as an ASIC Engineer. So question is what should we use "==" or "===" in if condition.

As per my experience as an ASIC Verification engineer, I would suggest you to use "===". The reason of using "===" is The x and z will be used in comparision and the logical result will be a TRUE and FALSE based on the actual comparision.

NOTE : But please keep in mind "===" is not synthesyzable.

Lets take a simple example :

using "===" operator

if (a === b)
   out1 = a & b ;
else
  out1 = a | b;

In this case a and b are identical, even if they becomes x or z the if clause will be executed and out1 will be driven by AND gate.

But that is not the case if you use "==" for the same logic. In this case, if a or b becomes x or z, else will be executed and out1 will be driven to OR gate.

I hope, this will be useful for you to understand the basic difference between "==" and "===".

Happy Reading,
ASIC With Ankit

Somthing wrong, may be in compiler message or LRM or in my understanding :-)

Dear Readers,

During my experience I have come across one interesting things, with that I was in little bit confuse and could not able to figure it out. I though its an interesting experience and I should share it across:

Here it is:

I have been using VCS tool in my project for verification. As I have been writing functinal coverage and assertion from last couple of months, recently I have found some interesting thing during the compilation warning:

I was using bins range with large value called {[1:65536]} with this value tool is giving and warnning given below. But the interesting thing is not a warning but the message which is comming with that warnning is more interesting.....! Below is the warning

Warning-[CPBRM] Precision or Sign Mismatch
Potential precision or sign mismatch in range values of user defined bin
block_id_illegal of coverpoint i2s_block_id in covergroup
$unit::CoverageCallbacks::static_field_cov
Source info: illegal_bins block_id_illegal = { [1:65536] } ;. Values outside
the valid coverpoint range will either be deleted(singleton values) or
adjusted(ranges) as per the precision semantics.

Please refer SystemVerilog LRM section 18.4.6

So from the message, I could understand the warning that I should not use the large value for bins declaration. But in this warning message it recommenting to refere LRM section 18.4.6 which is not there in LRM, section 18.4 does not have any sub section, and that section is for Top Level Instance not for coverage bins.

So as per my understanding there could be two things: Message might be wrong in compiler or may be there is an interpretation problem :-)

I would be pleased if you share your experience with this kind of warning.

Happy Reading,
ASIC With Ankit

Why are always block is not allowed in program block in System Verilog?

Dear Readers,

We all know System verilog is becoming hot in verification industry, but still I have seen people who are still arguing on some of the points implemented in System Verilog. The most interesting point which I have come across is "always block is not allowed in program"

To find the reason first thing what I did is, went throug the System Verilog LRM but could not find the reason. LRM has only one line saying that "A program block can contain one or more initial blocks. It cannot contain always blocks, UDPs, modules,interfaces, or other programs." but this statement does not clear the reason and I am not able to find the reason from the LRM.

Then I have started discussion with System Verilog Expert with whom I have been working, I have also went through some of the good websites and some eBooks on System Verilog and found the reason.

Here it is,
SystemVerilog programs are closer to a program in C, with one (or more) entry points, than Verilog’s many small blocks of concurrently executing hardware. In a design, an always block might trigger on every positive edge of a clock from the start of simulation. A testbench, on the other hand, goes through initialization, drive and respond to design activity, and then completes. When the last initial block completes, simulation implicitly ends just as if you had executed $finish. If you had an always block, it would never stop, so you would have to explicitly call $exit to signal that the program block completed.

This is the reason why we can not have always block inside program. Then I am sure you might be thinking on workaround.

So there is a work around, inplace of using always block use "initia forever" to accomplish the same thing.

Happy Informative Reading !!
ASIC With Ankit

Industry's First Low Power Verification Methodology Manual, Authored by ARM, Renesas Technology and Synopsys, is Now Available

Dear Readers,

Industry's First Low Power Verification Methodology Manual, Authored by ARM, Renesas Technology and Synopsys, is Now Available

Low power design techniques have become increasingly complex and have led to an explosion in verification complexity, creating a need for a well-understood, robust, and reusable verification environment to achieve power goals and first-pass silicon success. The VMM-LP book documents the common causes of low power bugs, provides rules and guidelines for low power verification, specifies a SystemVerilog base class library facilitating the setup of a reusable verification environment, and recommends assertions and coverage techniques to accomplish comprehensive low power verification.

The methodology described in the VMM-LP book allows verification teams to attain coverage closure and pinpoint bugs using assertions. It can be implemented using voltage-aware static and dynamic verification tools, such as MVSIM with the VCS(R) simulator and MVRC, which are part of the Ecylpse(TM) low power solution from Synopsys. These tools are capable of checking low power designs for the rules documented in the VMM-LP book. The base classes will enable the infrastructure to create a structured and reusable verification environment based on the VMM-LP.

The VMM-LP book is available today for purchase through the VMM Central web site ( www.vmmcentral.org/vmmlp). Additionally, customers can download a PDF version of the book and register to receive notification about the availability of the source code for the VMM-LP SystemVerilog base classes from VMM Central.

Happy Reading,
ASIC With Ankit

Who should write Assertion, Designer or Verification Engineer?

Dear Readers,

Who should write Assertion, Designer or Verification Engineer?

The short answer is both. Generally, a designer will write assertions that go in the RTL, while the verification engineer will write assertions that are external to the RTL. For example, designers write assertions that are embedded in the RTL, while the verification engineer writes assertions on the interfaces of the design-under-test (DUT) and creates coverage points, checkers and monitors for the testbench. Verification engineers may also add assertions to fill any holes in the RTL checks left by the designer.

Controlling Assertions:

In any given DUT, there can be many assertions each consisting of one or more evaluation threads. Sometimes it is necessary to enable or disable certain sets of assertions. For example, during reset, all assertions not related to reset must be disabled, and during exception testing, the assertions related to the condition being violated must be disabled.

This means that a fine-grained mechanism must be defined for assertion control. One way to do this is to group assertions logically into categories. One or more categories can then be enabled or disabled at a time.

There are many different mechanisms available for assertion control. Each of the mechanisms has different trade-offs. $asserton/$assertoff system tasks are global mechanisms and can be used to control all assertions or specific named assertions. Compiler directives are compile time directives and allow assertions to be enabled or disabled at compile time. They do not allow assertions to be enabled or disabled dynamically during simulation.

SV has many strong construst and features through which engineer can confident and can say verification is nearly finished. But stil there are many questions comes to my mind are : 1. How do you ensure that there are enough assertions written? 2.How do you say that coverage what is written by you is 100% correct and covering correct behaviour or not?

I am eager to have some inputs on these questions, please share your views.

Happy Reading,
ASIC With Ankit

System Verilog Syntax highlighting for power point

Dear Readers,

Wouldn't it be great if we could colorize the code? would not it be a great if we could save .vim file in to .html with colors?

Many people migh know that we can store our current butter in .vim file with color and save it with the .html extension. If you still dont know how to do that, please do this: Run the following command in a syntax highlighted buffer:

:runtime! syntax/2html.vim

After typing this command, you’ll get a split window with your source in HTML. You can now save it to a file. This command saves the current buffer with a .html extension. Now you can open that extension in your favorite browser and you can copy the colorized text directly into PowerPoint!

Hope this is useful information.

Happy Learning,
ASIC With Ankit

Assertions : What a powerfull feature of System Verilog..

Dear Readers,

SystemVerilog Assertions (SVA) are getting lots of attention in the verification community: Assertions are primarily used to validate the behaviour of a design. They may also be used to provide functional coverage information for a design..!

There are two types of Assertions in System Verilog :
1. Immediate Assertion
2. Concurrent Assertion

Both types have their own strong features, That all depens on our requirement which will decide which type of assertion we should use in our environment. But friendly speaking I would prefer Concurrent assertion most of the time as I found some of the advantages compare to Immediate assertion. And those advantage always encouraged me to use this type of assertions. Here I am listing down the advantages as per my experience:

1. Coverage statements (cover property) are concurrent and that's the reason we have used concurrent assertion as a part of our Test Bench. So it will be easy to dump a final coverage using this type of assertion with the strong System Verilog feature

2. The implication construct (|->) allows a user to monitor sequences based on satisfying some criteria, e.g. attach a precondition to a sequence and evaluate the sequence only if the condition is successful. There are two forms of implication: overlapped using operator |->, and non-overlapped using operator |=>.
3.User can use sequence to build complex properties.

These are the advantages which I came across so far in my experience on Assertions. I would be pleased if somebody can provide advantages of Immediate Assertion over Concurrent Assertions.

Assertions are providing strong verification features with which verification engineer can confident on his verificatoin environment and coverage using cover property with concurrent assertions.

Now you must be having a question that how assertions are effective with System Verilog?

In Verilog complex check requires complex verilog code, which will appear to be a part of RTL model to a Synthesis compiler, and one more disadvantage with Veriog is Assertion will active through out the simulation there is no simple way to disable all or some of the assertion during the simulation which is there in System Verilog, Now you should realize how effective it is Right ....? Means Asserstions can be controlled using system Verilog during the simulation.

One more strong feature which I have used is Assertion Binding, which is unique and powerful feature of System Verilog. Using this feature you can have your all assertion defined (coded) in separate TB file where you can have all required DUT as well as TB signals and registers with hierarchically from Top file. So that means without touching the RTL we can write assertion in separate file and that file will be included in our Test Environment.

As a Verification Engineer, I like Assertion, its strong and powerful in terms of Verification.

I would be pleased and thankful to you if you can share your experience on Assertions.

Happy Learning,
ASIC With Ankit

Interview Questions for ASIC

Dear Readers,

Here I would like to post some of the interview question which I have discussed with some senior engineers and industry experts. These are the questions most of the time interviewers asks. Here I will try to explain those all.

Que 1. What is setup and hold time? What will happen if there is setup and hold time violation?
[This question can also asked like "what is metastable state or what is metastability?"]

Ans 1.
Set up time is the amount of time before the clock edge that the input signal needs to be stable to guarantee it is accepted properly on the clock edge.

Hold time is the amount of time after the clock edge that same input signal has to be held before changing it to make sure it is sensed properly at the clock edge.

Whenever there are setup and hold time violations in any flip-flop, it enters a state where its output is unpredictable: this state is known as metastable state (quasi stable state); at the end of metastable state, the flip-flop settles down to either '1' or '0'. This whole process is known as metastability

Que 2. What is the difference between latch and flipflop?
[This is the very basic question that most of the interviewer would like to ask to check basic fundamental of digital electronics]

Ans 2.
The main difference between latch and FF is that latches are level sensitive while FF are edge sensitive. They both require the use of clock signal and are used in sequential logic. For a latch, the output tracks the input when the clock signal is high, so as long as the clock is logic 1, the output can change if the input also changes. FF on the other hand, will store the input only when there is a rising/falling edge of the clock.

Que 3. Build a 4:1 mux using 2:1 mux
[This is also a very basic question most interviewer would like to ask]

Ans 3. I would try to explain
Let say we have three 2:1 mux called A'B and C, So here we use two inputs of mux A and two input of mux B (total 4 input, which is the requirement to build 4:1 mux) and output of these two mux (A and B) will be 2 lines which will be input for third mux C. So we will be having 1 output from mux C. Now remaining thing is select line. We will hard wired selection line of A and B and called it as S0 and one select line will be used for mux C called S1. This way we can make a 4:1 mux using 2:1 multiplexer.

Que 4. Implement an AND gate using mux.

Ans 4. For AND gate give one input as select line. Incase if you are using B as a select line connect one input to logic 0 and one input to A.

Oue 5. In pure combinational Ckt, its necessary to mention all the inputs in sensitivity list? Is yes, Why?
Ans 5. Yes in a pure combinational circuit is it necessary to mention all the inputs in sensitivity disk other wise it will result in pre and post synthesis mismatch.

Hope this questions and answers are useful for the interested readers.

Happy Reading,
ASIC With Ankit

JEDEC has announced eMMC4.4 standard

Dear Friends,

Here I would like to inform you regarding the Multimedia Card's new version specification as JDEC has now announced 4.4 on 14th April 2009. I am very excited to read the specification. I know now you might be surprised why I am so excited to read the same. The reason is I worked on verification of eMMC4.3 card IP.

JEDEC Announces Publication of new MMC v4.4 specification

* New Standard Features Performance and Security Features for Embedded Mass-Storage Flash Memory
* Widely Used in Mobile Phones, GPS, MP3 Players and Other Portable Electronic Devices

ARLINGTON, Va., USA – April 14, 2009 – JEDEC Solid State Technology Association, the global leader in standards development for the microelectronics industry, today announced the publication of JESD84-A44 MMC Version 4.4 standard. Continuing the evolution of e.MMC as an industry-leading memory technology, the new standard offers designers numerous enhancements including a doubling of the memory interface performance, flexible partition management and improved security options.

You can find this article from below given link:
http://www.design-reuse.com/news/20484/mmc-v4-4-specification.html

From this link you can also download the standard specification provided by JDEC.

Hope this is useful information for interested readers.

Enjoy,
ASIC With Ankit

Seminar at NMG Polytechnic (ASIC with Ankit)

After a long time I got chance to represent myself as an presenter of technology in front of engineering students. As I have been in this field from more than 3 years I was exited to share my experience and importance of technology to the engineering students.

As I have finished my Diploma Engineering from N.M.G.P Institute (An ISO 9001:2000 certified), Kanara, Ranpur, http://www.nmgp.co.in/. I was planing to share my experience on technology in front of NMGP students and that's what I did in last week. It was thursday 2nd April when I suppose to go to NMGP for seminar on 'VLSI' and 'Importance of individual EC subjects in field or industries'.

I went there (NMGP) thursday morning with my power point presentation on my Lappy. As seminar timing was around 11:00 am, I had a time to visit NMGP building and recalled my old memories. I spent some time with old staff members and respected lectures who are still working with NMGP. At 11:00 am Seminar hall was ready with projector and my laptop setup. Students were also ready, taken their place and waiting for my presence on the stage with excitement !! I was too excited since it was my first presentation in front of 100s of engineering student !

I have started my presentation in front of EC engineering students and Sr/Jr Staff members (Lectures) of EC department. Agenda of that seminar was to give overview of VLSI technology and Importance of Digital Electronics in Industries. The goal was to create some interest for students on Digital fundamentals keeping in mind the industries requirement and technology growth !

Dear Readers,

Here I would like to share my some experience on my first seminar given to the polytechnic collage where I did my Diploma studies.

I was a student of the this polytechnic and I know most of the student's goal is to get good marks in the examination. But what I realized at this point is apart from mark there are something which each students should understand which is more important when you go for Job.

I explained the importance of Digital electronics in Chip Design and Verification. I have also explained latest VLSI Chip Technology with Transistor fundamentals by some examples and snap shots of some Chips. With this presentation I was trying to create self inspiration and motivation for engineering students. What I believe is "If you do things with your interest, things will be very easy and you can do it with smooth way".

Most interesting stuff of the seminar was two technology on which I worked in my past 1. USB OTG (USB On The Go) and 2. eMMC (Embedded Multimedia Card) Card IP (Intellectual Property) Verification. I have explained the application of those two technology and it was really interesting for students because they didn't know about these. I was glad after sharing this technology to students. Thanks to all those students who attended my session. It was full of excitement with lots of basic question answers session with students !

I hope with my efforts of presentation, some students might have started improving interest on engineering subjects, skills etc.... I have been receiving a many questions from students and answering their questions which could help them move ahead with their career. I would eagerly waiting to see somebody as an ASIC Engineer after some year down the road.

Thanks to NMGP Management, Sr/Jr Staff Members, Lecturers and students for their support and co-ordinations.

Visit their website (http://www.nmgp.co.in/) for Institute details.

Enjoy,
ASIC with Ankit

Basic Interview Questions for ASIC

Dear Readers,

In ASIC field, these are the most common questions people use to ask in interviews. So here I would like to share these type of questions with answers that can be useful to brush up fundamentals for ASIC engineer as well as any person who are using languages like Verilog, SystemVerilog, Vera etc...

Que : What is difference between Task and Function in Verilog?

Ans : The following rules distinguish tasks from functions:

• A function shall execute in one simulation time unit;
• A task can contain time-controlling statements.
• A function cannot enable a task;
• A task can enable other tasks or functions.
• A function shall have at least one input type argument and shall not have an output or inout type argument;
• A task can have zero or more arguments of any type.
• A function shall return a single value; a task shall not return a value.

Que : How will you generate clock in Verilog?
Ans : There are many ways to generate clock in Verilog we could use one of the following:

Method1:
initial
   begin
     clk = 0;
   end
   always begin
     #5 clk =~clk ;
end

Method2:
initial
   begin
      clk = 0;
      forever begin
         #5 clk =~clk ;
      end
   end

Method3:
initial
   begin
      clk = 0;
   end
always begin
   #5 clk =0;
   #5 clk =1;
end

These are the ways which I know, there can be some other ways through which you can generate clock in Verilog. This peace of code can be useful for clock generation where you would like to generate clock.

I will keep updating some more question with answers. Please feel free to shoot me an email if you have any question and suggestions are always welcome. You can drop me an email with your feedback on asicwithankit@gmail.com

Happy Reading,
ASIC With Ankit