Re: [sv-bc] Assignment compatibility after elaboration

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?   If so, do all such
dependences arise from "class" types?

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.

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

Greg Jaxon



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