RE: [sv-ac] 1900 (checkers) and variables types keywords

Hi Yaniv,

 

I understand your concerns, but I am afraid there are also serious
arguments against splitting free variables into different entities. I
will try to address these issues below. If the name "freevar" itself is
confusing, we can consider other suggestions.

 

Thanks,

Dmitry

 

________________________________

From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Fais Yaniv
Sent: Wednesday, November 21, 2007 1:05 PM
To: sv-ac@server.eda.org
Subject: [sv-ac] 1900 (checkers) and variables types keywords

 

Hi,

 

In the current proposal inside checkers all the variables are defined
using the keyword "freevar".

 

It seems to me however that those variables can be differentiated into 3
main categories:

1. non deterministic variables

2. (deterministic) state variables

3. (deterministic) continuous assigned variables

 

I think that giving the same keyword for all those types is confusing
since it makes it difficult to read and understand which variables are
non-deterministic and which aren't (you have to look for all the
assignments and check that a variable isn't assigned anywhere) therefore
I suggest using different keywords for those different types.

 

The first type (non deterministic state variables) can retain the name
"freevar" whereas for the other two I suggest the existing names of
"var" for state variables and "wire" for continuous assigned variables.

 

The semantic should remain the same as in the current proposal only that
the names of those different types should change.

 

variables of type "wire" can only participate in "assign" only (not
always_check assignments).

variables of type "var" can have initial value assignment and be
assigned inside "always_check" using one nonblocking assignment.

 

variables of type wire or var can be assigned freevars,

for example:

checker ck(integer inp1);

  freevar integer f;

  wire integer d = f + inp1;

...

 

[Korchemny, Dmitry] In SV nets and variables have different types. E.g.,
variables may be logic, integer, bit, while nets may be wire, wand, tri,
etc. I am afraid that the notation "wire integer d" may be confusing,
since wire is a type itself, and it is not integer (neither logic, nor
bit).

Using var for "deterministic free variables" may introduce backward
compatibility issues if regular variables become some time legal in
checkers.

 

"d" is still considered deterministic since it simply has the value of
"f" + "inp1", "inp1" in this case can a deterministic signal coming from
another module (sampled) or another freevar from another checker,"f"
however is free (under assumptions).

 

a freevar therefore doesn't participate in always_check assignments but
only in assumptions.

 

There is an issue with uninitialized variables,

for example:

var [3:0] counter;

always_check @clk

  counter <= counter+1;

The above variable has a nondeterministic initial value inside
checkers,I think it should be considered "var" and not "freevar" however
since its next state function is given.

 

[Korchemny, Dmitry] And how to consider initialized unassigned free
variables? Should they be freevar or var? Why should the uninitialized
free variables to be considered "deterministic variables" if their value
depends on their initial value, which is nondeterministic? Also, if to
make "deterministic" and "nondeterministic" free variables different
kinds of variables, it will be impossible to mix them in arrays and
structures, e.g.,

 

freevar bit[2:0] a;

freevar bit[2:0] b;

assign b = ~a;

assign a[2] = a[0] && a[1];

...

 

Another issue is that wires can have only 4 state typed variables in
modules, I don't think this is needed inside checkers so if someone
finds it confusing to remove this limitation inside checkers I suggest
using only "assign" instead of "wire",e.g: "assign integer d = f + inp1;
" so the declaration and continuous assignment are in the same line.

 

[Korchemny, Dmitry] See my comment above. The notion of wire is
absolutely different here than in Subclause 6.6.

 

 What do other people think of this suggested change ? is this worth
changing or am I the only one finding the usage of "freevar" for all
types confusing ?

 

 

Yaniv

 

 

 


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.