Re: [sv-bc] Assignment compatibility after elaboration

Greg Jaxon wrote:
> I have a follow-up question...
> 
> Gordon Vreugdenhil wrote:
>>
>> Surya Pratik Saha wrote:
>>> Hi,
>>> As per 1800 SV LRM, there are some restrictions for some complex type
>>> assignment like struct/enum/unpacked array, that assignment can happen
>>> withing two equivalent types. Considering those if we see the
>>> following e.g.:
>>> 1)
>>> module bottom;
>>>   parameter p = 1;
>>>   typedef struct {int x; int y;} st;
>>>   st s;
>>> endmodule
>>>
>>> module top;
>>>   bottom #(2) b1();
>>>   bottom #(3) b2();
>>>   initial begin
>>>      b1.s = b2.s;
>>>   end
>>> endmodule
>> This should be illegal.
>>
>> SV does NOT do structural compatibility -- for a struct, each
>> elaborated struct declaration is a unique type.  Here there are
>> two "instance paths" to the types so the types are distinct
>> and the assignment is illegal.
> 
> The two types "st" can be distinguished in two ways:
> 
>   1) They are declared by different specializations of the module template "bottom".
> 
>   2) They are declared by different instances of the "bottom" module.
> 
> Gordon is faithful to the LRM when he appeals to reason #2 to answer Surya.
> I wonder, though, whether it would be more sensible to rely solely on reason #1.
 >
> Is there any functional dependence a type can have on its "home instance"?
> I suppose classes whose methods have side-effects outside the class members
> would be the canonical example - can this arise in SV?   

Sure.

    module bottom;
       int x;
       class C;
           function void incr();
               x++;
           endfunction
       endclass
    endmodule

"x" here is like a static member.  In fact, a static member
would also be a determinable way of discovering whether
an implementation was compliant to the specs requirements.


 > If so, do all such
> dependences arise from "class" types?

I believe so.


> Working from existing synthesis technology, I see a minor disconnect in the
> type system based on instances.  In practice, designers may specialize a
> module template a few times, but replicate them sometimes hundreds or thousands
> of times.  To keep compile costs down, perfect replicas aren't made unique
> until quite late in the compiler flow - place and route, maybe even later.

There is no concept of "specialization" for modules.  Modules are
instantiated; parameterized classes are specialized.

Implementations may *choose* to optimize by determining how to
safely fold together the behavior from various instantiations
of a module but that is strictly an optimizations.  The LRM view
of the relationship is what matters.

> To insist that we be able to distinguish the replicas during elaboration
> (when type information can influence logic) seems excessive.  Is it really
> necessary?

Again, what an optimization can decide to safely do is up to
the implementation; the LRM conceptualization is based on
instantiations.

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.