Re: FW: [sv-bc] parameterized structures

Greg,

I'm not sure I understand the issue here.

Let's stick with the process/scope case for a moment.

   module top;
     class C #(int p = 1);
        static int x;
     endclass

     always @(clk) begin
         C#(2) c_obj = new;
         c_obj.x++;
     end

     always @(clk) begin
         C#(2) c_obj = new;
         c_obj.x++;
     end
   endmodule


Are we in agreement that there is only one "x" here and that
it is the one that is the member of the specialized type C#(2)?
If we are,  then I am not sure what modification of this you have
in mind.  Can you give a specific example and what you think
should happen?  If we aren't in agreement on my "single x"
contention, then we need to have a different discussion as
I think that is pretty clear from the LRM.

Gord.



Greg Jaxon wrote:

> There is some distance between simulation and synthesis mindsets
> that is not always easy to bridge on a Monday morning.  In the
> guts of a netlisting elaboration, scopes come and go; some of them are
> traversed to elaborate a simulation - these give rise
> to the things you call "instances" - but others come and go as part of
> running the sequential semantics of simulation.  The latter are /not/
> instances, but are still scopes, which have an extent (lexically) and
> a certain number of invocations (dynamically) both of which influence
> the static results of synthesis.  It is these later scopes - such as
> for-loop iterations, sequential function call bodies, and scopes nested 
> within
> processes, that alarmed me.  They should all share their controlling
> instance's specialized classes, but instances cannot share among 
> themselves.
> 
> But I plead newbie insanity because the LRM paragraph just isn't very 
> accurate:
> 
>> All matching specializations of a particular generic class shall 
>> represent the same type. The set of matching
>> specializations of a generic class is defined by the context of the 
>> class declaration. Because generic classes
>> in a package are visible throughout the system, all matching 
>> specializations of a package generic class are
>> the same type. In other contexts, such as modules or programs, each 
>> instance of the scope containing the
>> generic class declaration creates a unique generic class, thus, 
>> defining a new set of matching specializations.
> 
> 
> Indeed there are two kinds of contexts - some "uniquify" the type 
> one-per-instance
> and others do not.  but the breakdown is not non-package vs package.  
> Instead it
> is:   { module, interface, program, or generate block } vs anything else.
> 
> I looked for a definition of "instance" in the LRM, but haven't yet found
> one to match the usage we're giving the word here.
> 
> Greg
> 
> 
> 
> Gordon Vreugdenhil wrote:
> 
>>
>>
>> Greg Jaxon wrote:
>>
>>> I agree that the type universe is statically computable at
>>> elaboration time.  
>>
>>
>> Good.
>>
>>  > I guess the "lifetime" I'm referring to
>>
>>> is the sequential lifetime of scopes during elaboration.
>>>
>>> function automatic string foo();
>>>   typedef struct { int wont_get; } food_again;
>>>
>>>   static food_again new_boss;
>>>
>>>   new_boss.wont_get = 32'shdeadbeef;
>>>
>>>   return $typename( new_boss );
>>> endfunction
>>>
>>> Each time this function is called, we get a new "instance" of its 
>>> scope, right?
>>
>>
>> I don't think so.  You really need to think of "typedef" as being
>> "static typedef".  There are no "automatic" types -- this is implied by
>> the earlier statement that all types are computable at elaboration time.
>> This also allows "static food_again new_boss;" to have a sensible
>> and unsurprising meaning.
>>
>> Gord.
>>
>>> So each new_boss has a different type than the old new_boss, right?
>>>
>>> Greg
>>>
>>> Gordon Vreugdenhil wrote:
>>>
>>>> Greg,
>>>>
>>>> I think that you are assuming something stronger than what the
>>>> LRM requires.  Class specialization requires *constant* values;
>>>> as a result, the *type* universe is computable at elaboration
>>>> time and doesn't grow during simulation.  "static" is useful
>>>> since a type doesn't really come and go -- the local visibility
>>>> does but not the type itself.
>>>>
>>>> Example:
>>>>
>>>>   module top;
>>>>     class C #(int p = 1);
>>>>        static int x;
>>>>     endclass
>>>>
>>>>     function void foo;
>>>>        C #(2) local_obj;
>>>>     endfunction
>>>>
>>>>     C #(2) c_obj;
>>>>   endmodule
>>>>
>>>> The type of "local_obj" in foo is *the same type* as the type
>>>> for c_obj.  Any reference to "x" via either local_obj or
>>>> c_obj always refers to the same "x" that is tied to the specialization
>>>> of the type within the universe of class C.
>>>>
>>>> This means that any recursive call could still only create
>>>> an elaboration time determinable universe of types.  It is an
>>>> implementation issue about when the specializations actually
>>>> occur but the static members never "go away".  The lifetime
>>>> of a static class member conceptually extends from the first
>>>> time the type is specialized until the end of simulation;
>>>> any future specialization has the same static member.
>>>>
>>>> Gord.
>>>
>>>
>>>
>>>
>>
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com