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