RE: [sv-ec] class extension across hierarchical boundaries

Gord,

 

I believe we are talking about two different aspects. Comments below.

 

            Arturo

 

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Friday, October 19, 2007 1:01 PM
To: Arturo Salz
Cc: sv-ec@eda.org
Subject: Re: [sv-ec] class extension across hierarchical boundaries

 

 

 

Arturo Salz wrote:

> Gord,

> 

> I am not suggesting we disallow either use. My detailed response is 

> inlined below.

 

I'm still confused.  See below...

 

 

> I would not disallow this usage. I am not suggesting we disallow
classes 

> from being extended across

 

 

So don't you now have to be prepared to deal with the opaque naming

issues?  How can you separately compile:

     package p;

        class C #(parameter p = 1;);

            static int some_container[p];

        endclass

     endpackage

without resolving the naming rules?

 

[AS ] Because this code (as well as the snippet you intended) represents
a parameterized class so it's clear that the compiler cannot generate
code for such a class until a specific class type is specialized. It
should be evident that parameterized classes depend on parameter
resolution. Hence, this dependency does limit the amount/type work that
a separate compilation tool can do at parse time and how much of the
work must be delegated until after elaboration.

 

 

> Perhaps you missed the subtle point about instantiated hierarchies. An


> important property of packages is

> that they are singletons - that is there is only one copy of all
static 

> data in any package. That is not true

> for modules, which can be instantiated multiple times. 

 

But that also isn't true for the parameterized class case that

I brought up.

 

If you have:

 

     package p;

        class C #(parameter p = 1;);

            static int some_container[p];

        endclass

     endpackage

 

     module tb;

        import p::*;

        for (genvar i = 1; i < 5; i++) begin

            typedef C#(i) some_sized_container;

            DUT #(some_sized_container) my_dut();

        end

     endmodule

 

There are 5 static variables -- one for each variant of C.

Those statics are not known at package compilation time

and are directly related to the instantiations of the

modules.

 

[AS ] Yes, I agree. However, as I wrote above, this is expected of a
parameterized class.

 

So the static data is not a "singleton" for that package -- it

is a singleton per type specialization and the number of

type specializations can certainly have module dependencies.

 

[AS ] Yes. For a parameterized class this is true.

 

Or, using your concerns about methods, if you have the

class C in the package be:

 

        class C #(type T);

            function void f (T foo);

            endfunction

        endclass

 

and then in a module have:

    C #(int) my_int_c;

    C #(real) my_int_c;

I still fail to see how that differs in terms of the

uniqueness of the method code from your examples involving

type parameters.

 

In neither case do you know the universe of final types and what

the final set of method behaviors will be.

 

So why do you think that one is Ok and the other is not?

 

[AS ] I agree with the semantics of every case you describe. Just to
clarify let me re-emphasize the distinction that I'm addressing.

 

Parameterized classes (similar to parameterized modules) evidently
depend on the parameter resolution and thus on the design elaboration.
For such classes, the compiler has no choice but wait until a particular
class specialization is seen before code can be generated for the class.
If we allow extension of classes (with static references) across the
module instantiation hierarchy then all classes become dependent on the
post-elaborated model. As I wrote before, this dependency forces
compilers to either (a) wait until post-elaboration to generate separate
code for classes, or (b) generate generic class code that includes the
static variable lookup. In my opinion, this dependency was not allowed
by the previous LRM. If you believe otherwise then clearly the LRM is
ambiguous and we should explicitly document this on way or the other. 

 

 

 

Gord.

-- 

--------------------------------------------------------------------

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.