ASIC with Ankit

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

2012-01-16T01:59:00.002+05:30

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

ASIC With Ankit

SVA Based Verification

2011-10-13T00:52:00.001+05:30

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'?

2011-07-14T02:18:00.001+05:30

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

2011-03-23T12:12:00.005+05:30

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

2011-01-16T11:17:00.007+05:30

Coverage model in System Verilog Test Bench:

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

if (P == Q) ... // Simply checks if P equals Q

assert (P == Q); // Asserts that P equals Q; if not, an error is generated

We can print pass statements using $display, we can print fail statement using $error.

Example:

assert (P == Q) $display ("OK. P equals Q");

else $error("Error Message");

Please note that we can omit the pass statement and still have a fail statement:

Example:

assert (P == Q) else $error("Error Message");

→ Concurrent Assertions :

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

assert property (!(Read && Write));

It means, expression Read and Write is never true at any point during the simulation.
Properties can be build using the sequences too.

Coverage Model :

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

How do they close verification ?
How can they say , they are done ?
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 configurability.

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

2010-09-16T16:50:00.007+05:30

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

2010-08-17T14:23:00.005+05:30

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.

ASIC with Ankit

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

2010-06-11T12:52:00.003+05:30

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

ASIC with Ankit

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

2010-05-13T12:27:00.007+05:30

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.

-ASIC with Ankit

PASS and FAIL Messages with Colors...!

2010-04-13T11:22:00.008+05:30

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

2010-03-30T17:41:00.009+05:30

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

Thats 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.

-ASIC with Ankit

VCD dumping from VCS command line?

2010-03-28T17:29:00.003+05:30

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

-Ankit
ASIC With ANKIT....

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

2010-03-21T02:43:00.002+05:30

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

-ASIC with Ankit

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

2010-01-28T14:54:00.004+05:30

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 limintation 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....

-Ankit Gopani

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

2010-01-18T18:52:00.004+05:30

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 "===".

-Ankit

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

2010-01-16T19:49:00.006+05:30

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.

-Ankit

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

2010-01-16T19:25:00.004+05:30

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.

-Ankit

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

2009-12-31T11:07:00.003+05:30

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.

Who should write Assertion, Designer or Verification Engineer?

2009-10-13T17:28:00.003+05:30

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.

System Verilog Syntax highlighting for power point

2009-10-13T14:56:00.004+05:30

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!

Assertions : What a powerfull feature of System Verilog..

2009-08-27T19:28:00.006+05:30

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 thats 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 Synthesys 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 smulation.

One more strong feature which I have used is Assertion Binding, which is unique and powerfull featuere of System Verilog. Using this feature you can have your all assertion defined (coded) in seperate TB file where you can have all required DUT as well as TB signals and registes with hirarchically from Top file. So that means without touching the RTL we can write assertion in seperate 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.

Interview Questions for ASIC

2009-04-20T11:28:00.003+05:30

Here I am posting some of the interview question which I have discussed with some of my senior persons. These are the questions most of the time interviewer may ask. Here I will also 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. Here I will give you the idea:
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.

JEDEC has announced eMMC4.4 standard

2009-04-16T17:18:00.004+05:30

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.

Seminar at NMG Polytechnic (ASIC with Ankit)

2009-04-09T16:14:00.004+05:30

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, Kanara, Ranpur, I was planing to share my experience on technology in front of NMGP students and that what I did in last week. It was thursday 2nd April when I suppose to go to NMGP for seminar on VLSI and how importance of individual EC subjects in field or industries.

I went there (NMGP) thursday morning with my power point presentation. 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 who are still working with NMGP. Now it almost 11:00 and Seminar hall was ready with projector and my laptop. Students were also ready, taken their place and waiting for me.

Then at 11:00 am, I have started my presentation in front of EC engineering students and staff members of EC department. Agenda of that seminar was to give overview of VLSI technology and how importance is Digital Electronics in Industries. The goal was to create some interest for students on Digital fundamentals keeping in mind the industries requirement.

I was also student of the same 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 and that is basic fundamentals of each subject.

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 for individual 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 have worked recetly 1. USB OTG and 2. eMMC Card IP Verification. I have explained the application of those two things and it was really interesting for students because they didn't know about the these but I was glad after sharing this technology to students.

I hope with my efforts of presentation, some students might have started improving interest on individual subject, skills etc.... I would eagerly waiting to see some body as an ASIC Engineer after some year down the road.

I have received some requests to upload that presentation which I have given their. I will try to upload it soon on my blog.

ASIC with ANKIT

Basic Interview Questions for ASIC

2009-03-16T11:31:00.006+05:30

In ASIC field, this is most common question that anybody can ask in interview. This was also asked to me by one of the interviewer. So here I would like to share this type of questions with answers that can be useful to brush up fundamentals for ASIC engineer as well as any person who are usin langaualges 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 with which you can generate clock in Verilog. This peace of code can be useful for clock generation where you have to generate clock.

I will keep updating some more question with answere. Please feel free to shoot me an email if you have any question and suggestions are always welcome.

System Veriog GOTHCA 01

2008-11-30T17:18:00.003+05:30

Types defined in different scopes:

The LRM words this as follows: ―The scope of a data type identifier shall include the hierarchical instance scope. In other words, each instance with a user-defined type declared inside the instance creates a unique type. To have type matching or equivalence among multiple instances of the same module, interface, or program, a class, enum, unpacked structure, or unpacked union type must be declared at a higher level in the compilation-unit scope than the declaration of the module, interface, or program, or imported from a package.

This has several implications. For example,

typedef struct {int A; int B;} AB_t;
typedef struct {int A; int B;} otherAB_t;

defines two different types and you cannot simply assign a variable of one type to a variable of the other, even though the type contents are identical. You must use an explicit type cast. GOTCHA!

Furthermore, if the type declaration of AB_t is found in module m, and m is instantiated twice, as m1 and m2, then the two types m1.AB_t and m2.AB_t are considered different types and again cannot be assigned from one to the other without an explicit cast.

However, if the typedef is found at a higher level, such as in the compilation-unit scope of the module ($unit), or in a package that is imported into the module, then the two module instances are considered to have the same type definition.

An anonymous type declaration also defines its own type. An anonymous type declaration is where the type definition appears as part of the variable declaration, and not as a separate typedef. For example:

struct {bit[15:0] value;} AB4, AB5;
struct {bit[15:0] value;} AB6;

AB4 and AB5 are defined with the same anonymous type declaration, and so they are assignment-compatible, but AB6 has a separate anonymous type definition and thus is not assignment-compatible with AB4 and AB5 without a cast, even though the type definitions are identical.

As stated in the LRM, these restrictions apply to enums, unpacked structures and unions, and classes. So they do not apply, for example, to packed structs or to arrays, packed or unpacked.

So a function can return an unpacked struct, for example, but you won‘t want to define the struct as an anonymous type in the function header, like this:

function struct {bit[15:0] value;} f(args);

because then you will not be able to assign the function return value to another variable in the calling scope, as they will be considered to have different types:

AB4 = f(args); // illegal, different types

Verilog Gotcha 02

2008-11-30T17:13:00.004+05:30

Most of us have gotten used to the idea that numerical operands in an expression are size-extended to the size of the widest operand. We are less used to it with respect to strings, and it can hit us when we least expect it.

One particular case where it is easy to forget size-extension is in the conditional operator. If we write

cond ? expr1 : expr2

then the shorter expression of expr1 and expr2 is extended to the size of the wider one. But suppose we have something like this:

integer file; file = $fopen({"filename", dat1 ? ".dat1" : ".dat"}) ;

In this contrived example, we concatenate a file extension .dat1 or .dat to the given filename, where a variable called dat1 tells us the type of the file. If the variable dat1 is true, there is no problem, we open a file named ―filename.dat1‖, but if dat1 is false, then we try to open a file called ―filename .dat‖, with a space before ―.dat‖, which is extended to the size of ―.dat1‖ before being concatenated to ―filename‖. GOTCHA!

Actually, the shorter string literal is not extended with a space character, which is x20 ASCII, but rather with zeroes (zero-extension), which are null characters.

However, when used as a string, this often becomes a space. Note that if we had assigned the concatenation to a variable of string type, this would not occur.

string temp;
temp = {"filename", dat1 ? ".dat1" : ".dat"} ;
file = $fopen(temp) ;

The shorter string literal would still be zero-extended. However, upon assignment to string variables, null-characters are ignored, so ―.dat‖ would still be appended directly to ―filename‖.

Verilog Gotcha 01

2008-11-07T18:28:00.003+05:30

What is a gotcha?

A gotcha is code that looks right, feels right, and smells right ... but isn‘t. If you‘re lucky, it won‘t pass compilation, so that you‘ll know immediately that something is wrong. If you‘re less lucky, it will do something obviously wrong in simulation, like getting stuck in reset. If you‘re really unlucky, it will pass compilation and simulate, but with a subtle error that you‘ll be hard pressed to detect. And in the worst case, it will cause a bug in silicon

GOTCHA Number-01:
This gotcha is already appear in Verilog (1995 or 2001) and are still in SystemVerilog :-)

always @* oscillations (V2K1)
For coding synthesizable RTL in Verilog-2001, we usually recommend to code combinational and latch blocks with always @* and its automatic sensitivity list instead of manually enumerating the sensitivity list in a regular always procedure.

However, there is a case where that can get you into trouble.
Suppose you have two always @* procedures containing for-loops and you use the same loop index variable for both, like this:

integer k; reg [31:0] out1[0:7], out2[0:15], in1, in2;
always @* for (k = 0; k <8; k = k+1) out1[k] = in1 + k ; always @* for (k = 0; k <16; k = k+1) out2[k] = in2 * k ; Why not? In Verilog-1995, we used the same loop index with multiple loops all the time for RTL without problems. Suddenly, in V2K1 (Verilog2001), they find that some simulators get stucked. All they did was change the sensitivity list to @*. Darn those language developers! Can‘t they leave well enough alone?? :-) What happens here is that according to the LRM of V2K1, the first always @* turns into "always @(in1 or k)" and the second turns into "always @(in2 or k)". Note that k appears in both lists. Suppose that in1 changes. This triggers the first always @* procedure. It executes, including the loop, and k changes a number of times. k changes, you said? That triggers the second procedure, even though in2 has not changed. The second procedure executes unnecessarily, wasting simulator time, but that is not the worst of it. When the second procedure executes, it also executes its for-loop, also changing k. This retriggers the first procedure. And so they go on, back and forth, with the simulator stuck in an infinite loop. GOTCHA! Why did this not happen in Verilog-1995? Because then we did not put the loop index into the manual sensitivity list. But in always @*, it is put in automatically. (This problem does not occur with all simulators. Apparently some of them don‘t put the loop index into the sensitivity list even though strict compliance to the LRM would do so.) How can we fix this ? (Solution to avoide this gotcha): Solution 01: We have to use different variables for each of the loops. We can declare two different variables globally, like this: integer k1, k2; reg [31:0] out1[0:7], out2[0:15], in1, in2; always @* for (k1 = 0; k1 <>out1[k1] = in1 + k1 ;

always @* for (k2 = 0; k2 <>out2[k2] = in2 * k2 ;

Solution 02 :
Another way is to declare the loop variables locally within the always @* procedures, like this:

reg [31:0] out1[0:7], out2[0:15], in1, in2;
always @*
begin:loop1
integer k;
for (k = 0; k < k =8; k= k+1) out1[k] = in1 + k ; end always @* begin:loop2 integer k; for (k = 0; k < 16; k = k+1) out2[k] = in2 * k ; end Solution if you are using SystemVerilog: If we can use SystemVerilog, then we can change the always @* to always_comb, which will not put in the sensitivity list any variable that is written to within the procedure. Another solution in SystemVerilog is to declare the loop variables within the for-statement itself, like this: for (int k = 0; k <>

This also makes each loop variable separate. This is the best solution, as using the same variable for the different loops is what caused the problem in the first place.

"Gotcha number 01 was over here, hope you have got the idea on this gotcha and now onwards keep in mind while coding"

Please feel free to discusse this gothcha if you have any question or doubt on ankitgopani83@gmail.com

USB 3.0 : 27GB data transfe can hapens in 70 seconds...

2008-10-08T14:24:00.001+05:30

I am a great fan of USB 3.0, so my views are biased. I just don’t want the critics beating up USB because they expected.
The USB 3.0 Promoters are targeting a 350 Megabytes per second effective throughput for USB 3.0. This is 10x faster than the effective throughput of USB 2.0 (about 32 Megabytes per second).

The actual signalling rate of USB 3.0 is actually higher, something like 600 Megabytes per second, however, because of the protocol overhead, hardware, device, operating system, and driver latencies, the effective throughput lower. This is true of all devices you and I own today, not just USB. It is the reason why USB 2.0 goes at 350 Megabits per second of effective throughput instead of 480 Megabits per second (again the electrical signalling rate). Of course, the USB 3.0 Promoters are doing everything they can to minimize this.

What would be the first Consumer product with USB3.0?
I know what the first USB 3.0 Consumer Products should be.

The Digital Camcorder.
The Camcorder will have a hard drive (like a laptop drive) and will likely shoot high definition. It will have a 80 GB drive minimum, and will sell for $800-$1000. This targets the Prosumer market, the people that are used to paying $800 or more for a camcorder. They are serious enough that, today, these people already either use tapes and take the 1 hour to transfer and another 1 hour to convert these to an MPEG file. Or they do nothing and accumulate the tapes.

With USB 3.0, you will be able to transfer 27GB of data in about 70 seconds.

This makes a new business viable. For example, for digital still cameras, at CostCo or other places, you can plug in you photo memory card, and print pictures. If you want to print all, the process is less than 3 minutes of transfer and checkout. Then you just shop and pick up your photos after you check-out. This is not viable with todays tapes or USB 2.0 speeds.
With Super Speed USB, you will be able to drop off your camera with the attendant, pick you DVD menu, and when you check out you will have a DVD (or Blu-Ray Disk) with your videos. This makes shooting video much, much more compelling that today’s process.

Power in USB2.0 Device

2008-10-08T14:13:00.001+05:30

More devices are doing more things. The best example of devices that have more functions are phones.
Anyone shopping for a mobile phone, will see that the newest phones have more and more functions. Since the introduction of the iPhone, every company is introducing larger screens and touchscreens. The larger screens require more power to operate. More software to run more applications. More software to manage all the applications. More software to manage the power for the applications. More software to manage when the WiFi and Bluetooth are on-and-off. A touch screen that is polling all the time for data from the touch screen. And, in the case of the iPhone, an accelerometer that senses motion (like turning the phone to view pictures in the correct perspective. For a camera phone, an image capture device and maybe even a flash.
All these feature require power. Product makers must manage battery life or be doomed to 30 minutes of talk time. So the choices for managing are:

1) Design the chip hardware to consume less power2) Design the software to manage power usage for each application3) Make the battery bigger to provide more juice4) Accept shorter battery life

3) Bigger batteries - The iPhone is larger both because of the screen, and probably to house a larger battery. Battery life is always relative to some other device. For example, my Blackberry would probably run for 2 weeks as a phone, but once I add data, it’s probably 1 week, and with Bluetooth, maybe 6-7 hours of talk time, and it has to be recharged.

For 1) Change the hardware, we have done some studies with interesting results.Some research indicates that for some companies aggressively implementing hardware features to reduce power are nearing their limits. Phone companies are probably in the lead here.

If you really implement these features, you can squeeze out some extra battery life.
For me, the most interesting thing is that a lot of companies still do not employ these methods. These are consumer devices. There is still room on the hardware side by using our Low Power Methodology Manual. This is absolutely clear, however, you must implement multiple power domains, multiple power rails, and MTCMOS, among other things. Because of the time and effort required, many companies do not even attempt this.

This means
A) Implement simpler hardware options for reducing power

What does this have to do with USB?
The fastest, easiest hardware solution is to use HSIC to implement add-on USB functions. HSIC uses a PHY that is 1/3 the power and area of a standard USB PHY. If you add the USB standard Link Power Management, LPM, you add the hardware capability to use LPM. (This is the USB standard LPM). Add the software for LPM and you can save a lot of power, possibly up to 20% of your battery life can be recovered depending on the kind of USB device you are using.

SONY was started with $190 only, in 1946

2008-09-15T16:20:00.001+05:30

Can you believe this.. ? SONY Electronics, Japan based company was started with a seed capital of $190. Today Sony Corporation has a market capitalization value of arounf $41 bilion.

Sony's hystory can be credited to Morita's (Akio Morrita) crearivity and innocative ideas. His ideas gave birth to totally new lifestyles and cultures. In 1949 company developed magnatic tape and 1950 they have sold first tape recorder in Japan. In 1957 they have produced a pocket size radio. Then in 1960 Sony produces first transistor television in the world, In 1979 the walkman was introduced to world making it to worlds first portable music player. In 1984 Sony launches the Discman series which extended their Walkman brand to portable CD products.

How Sony was started ?

After studying Physics in college, Akio joined Japanes army during the World War where he met, masura Ibuka. They formed the company which later know as Sony Corporation.

Full ASIC Design Flow

2008-09-13T19:14:00.001+05:30

As an ASIC Engineer, we should have idea about the whole ASIC design and verification flow. Here I have described all the useful steps which must be follow start from the thinking of the Micro architecture to the Fabrication of the Chip.

I hope this information will be useful as an ASIC Engineer. Please leave your comments or question if you have any. I will try my best to reply you soon.

Step 1: Create an Micro-Architecture Document.

Step 2: RTL Design & Development of IP's

Step 3: Functional verification all the IP's/Check whether the RTL is free from Linting Errors/Analyze whether the RTL is Synthesis friendly.
Step 3a: Perform Cycle-based verification(Functional) to verify the protocol behaviour of the RTL
Step 3b: Perform Property Checking , to verify the RTL implementation and the specification understanding is matching.

Step 4: Prepare the Design Constraints file (clock definitions(frequency/uncertainity/jitter),I/O delay definitions, Output pad load definition, Design False/Multicycle-paths) to perform Synthesis, usually called as an SDC synopsys_constraints, specific to synopsys synthesis Tool (design-compiler)

Step 5: To Perform Synthesis for the IP, the inputs to the tool are (library file(for which synthesis needs to be targeted for, which has the functional/timing information available for the standard-cell library and the wire-load models for the wires based on the fanout length of the connectivity), RTL files and the Design Constraint files, So that the Synthesis tool can perform the synthesis of the RTL files and map and optimize to meet the design-constraints requirements. After performing synthesis, as a part of the synthesis flow, need to build scan-chain connectivity based on the DFT(Design for Test) requirement, the synthesis tool (Test-compiler), builds the scan-chain.

6: Check whether the Design is meeting the requirements (Functional/Timing/Area/Power/DFT) after synthesis.
Step 6a: Perform the Netlist-level Power Analysis, to know whether the design is meeting the power targets.
Step 6b: Perform Gate-level Simulation with the Synthesized Netlist to check whether the design is meeting the functional requirements.
Step 6c: Perform Formal-verification between RTL vs Synthesized Netlist to confirm that the synthesis Tool has not altered the functionality.
Step 6d: Perform STA(Static Timing Analysis) with the SDF(Standard Delay Format) file and synthesized netlist file, to check whether the Design is meeting the timing-requirements.
Step 6e: Perform Scan-Tracing , in the DFT tool, to check whether the scan-chain is built based on the DFT requirement.

Step 7: Once the synthesis is performed the synthesized netlist file(VHDL/Verilog format) and the SDC (constraints file) is passed as input files to the Placement and Routing Tool to perform the back-end Actitivities.

Step 8: The next step is the Floor-planning, which means placing the IP's based on the connectivity,placing the memories, Create the Pad-ring, placing the Pads(Signal/power/transfer-cells(to switch voltage domains/Corner pads(proper accessibility for Package routing), meeting the SSN requirements(Simultaneous Switching Noise) that when the high-speed bus is switching that it doesn't create any noise related acitivities, creating an optimised floorplan, where the design meets the utilization targets of the chip.
Step 8a : Release the floor-planned information to the package team, to perform the package feasibility analysis for the pad-ring .
Step 8b: To the placement tool, rows are cut, blockages are created where the tool is prevented from placing the cells, then the physical placement of the cells is performed based on the timing/area requirements.The power-grid is built to meet the power-target's of the Chip .

Step 9: The next step is to perform the Routing., at first the Global routing and Detailed routing, meeting the DRC(Design Rule Check) requirement as per the fabrication requirement.

Step 10: After performing Routing then the routed Verilog netlist, standard-cells LEF/DEF file is taken to the Extraction tool (to extract the parasitics(RLC) values of the chip in the SPEF format(Standard parasitics Exchange Format), and the SPEF file is generated.

Step 11: Check whether the Design is meeting the requirements (Functional/Timing/Area/Power/DFT/DRC/LVS/ERC/ESD/SI/IR-Drop) after Placement and Routing step.
Step 11a: Perform the Routed Netlist-level Power Analysis, to know whether the design has met the power targets.
Step 11b: Perform Gate-level Simulation with the routed Netlist to check whether the design is meeting the functional requirement .
Step 11c: Perform Formal-verification between RTL vs routed Netlist to confirm that the place & route Tool has not altered the functionality.
Step 11d: Perform STA(Static Timing Analysis) with the SPEF file and routed netlist file, to check whether the Design is meeting the timing-requirements.
Step 11e: Perform Scan-Tracing , in the DFT tool, to check whether the scan-chain is built based on the DFT requirement, Peform the Fault-coverage with the DFT tool and Generate the ATPG test-vectors.
Step 11f: Convert the ATPG test-vector to a tester understandable format(WGL)
Step 11g: Perform DRC(Design Rule Check) verfication called as Physical-verification, to confirm that the design is meeting the Fabrication requirements.
Step 11h: Perform LVS(layout vs Spice) check, a part of the verification which takes a routed netlist converts to spice (call it SPICE-R) and convert the Synthesized netlist(call it SPICE-S) and compare that the two are matching.
Step 11i : Perform the ERC(Electrical Rule Checking) check, to know that the design is meeting the ERC requirement.
Step 11j: Perform the ESD Check, so that the proper back-to-back diodes are placed and proper guarding is there in case if we have both analog and digital portions in our Chip. We have seperate Power and Grounds for both Digital and Analog Portions, to reduce the Substrate-noise.
Step 11k: Perform seperate STA(Static Timing Analysis) , to verify that the Signal-integrity of our Chip. To perform this to the STA tool, the routed netlist and SPEF file(parasitics including coupling capacitances values), are fed to the tool. This check is important as the signal-integrity effect can cause cross-talk delay and cross-talk noise effects, and hinder in the functionality/timing aspects of the design.
Step 11l: Perform IR Drop analysis, that the Power-grid is so robust enough to with-stand the static and dynamic power-drops with in the design and the IR-drop is with-in the target limits.

Step 12: Once the routed design is verified for the design constraints, then now the next step is chip-finishing activities (like metal-slotting, placing de-coupling caps).

Step 13: Now the Chip Design is ready to go to the Fabrication unit, release files which the fab can understand, GDS file.

Step 14: After the GDS file is released , perform the LAPO check so that the database released to the fab is correct.

Step 15: Perform the Package wire-bonding, which connects the chip to the Package.

What is ASIC (Application Specific Integrated Ckt)

2008-09-13T19:06:00.001+05:30

what is ASIC ?

ASIC stands for the abbreviation of Application Specific Integrated Circuits. It means an integrated circuit designed for a specific application. An application could be a microprocessor, cell phone, modem, router, etc., The respective ASIC will have its own architecture, need to support its own protocol requirements . In todays ASIC has a complete system in a single often called as System on a Chip(SOC).

The flow involved to achieve this could be semi custom or full custom. The various cost function for an ASIC chip could be "Area, Timing, Power" Targets.
Basically microprocessor involves full custom. Full custom designs take lot of time to design. Full custom designs are used to achieve high frequency targets.
Where as in a semi custom flow, initially the standard cells are pre designed based on the characterization of the silicon for a specific process.