Thursday, January 28, 2010

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

Monday, January 18, 2010

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

Saturday, January 16, 2010

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