Re: FW: [sv-bc] parameterized structures

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.
>>
>>
>>
>