RE: [sv-ec] compilation unit - class static variables

Daniel,

I agree with Dave's and Gord's responses, and I'll add one other comment
that may help explain this choice for class static properties. Consider
the following change to your example:

<c.svh)
int n;
class C;
    function void set( int i ); n = i; endfunction
endclass
 
<top.v>
`include "c.svh"
module top;
    C c1 = new();
    initial c1.set(123);
endmodule
 
<top1.v>
`include "c.svh"
module top1;
    initial #0 $display(n);
endmodule 

Note that in this example, the function is not even static,
nevertheless, the set() method in each class refers to a different
static variable 'n'. As a result, the effect is the same as in your
example - The $display statement prints 0.

Now, the only two alternatives for dealing with the above code are (1)
keep the $unit variables separate (similar to C/C++ static global
variables), or (2) alias the two 'n' variables into one (similar to
C/C++ non-static global variables). SV implements the 1st alternative,
primarily to avoid symbol clashes across separate compilation units. As
Dave wrote, a key motivation for packages were motivated to provide as
safe mechanism to support types and variables sharing across separately
compiled units. The behavior of class static variables naturally falls
out of this behavior.

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Tuesday, July 15, 2008 8:46 AM
To: Daniel Mlynek
Cc: 'SV-EC'; 'Piotr Winter'; 'Mirek Forczek'; 'Bartek Konik'
Subject: Re: [sv-ec] compilation unit - class static variables


Daniel,

There are many aspects that go into how a standard evolves.  This
is particularly true when you have deep legacy issues (for the
"Verilog" aspects) composed with donated approaches that are then
refined in committee.  The resulting definitions are not always
"the best" in terms of what a single person would define but are
a reflection of best effort consensus among committee participants.
The best way to understand that is to actively participate at the
committee level and offer to write parts of the standard.

The definition of compilation unit and how naming works is one
very deep set of compromises along many facets.  Personally,
I would love to kill $unit completely.  Unfortunately, I don't
think that is a possible solution.  There are also multiple
ways in which to compose compilation and the $unit boundaries;
the standard requires implementations to support at least two
(every file is a compilation unit and "all files" form one
compilation unit).  But there are still tool interactions with
the definitions on multiple levels.  And there are still aspects
of naming of compilation unit artifacts in terms of vpi that
are less than ideal.  That's (committee) life.

Gord


Daniel Mlynek wrote:
> well, - yes you can workaround this by using packages
> But dont you think that this is quite odd aproach and completly 
> different than ie  C++ one - and for sure can make a lot of confusion 
> among SV users?
> I was quite suprised when I realized that - and finding solution take
me 
> some time.
>  
> DANiel
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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


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