Re: [sv-bc] Assignment compatibility after elaboration

Greg Jaxon wrote:
> Bresticker, Shalom wrote:
> 
>> I was thinking of this example from Surya:
>>
>> module bottom;
>>    parameter type pt = int;
>>    pt x;
>> endmodule

> OK.  Just keep that line of thought going...
> 
> module middle;
>   typedef struct {int x; int y;} et;
>   bottom #(et) mb();
> endmodule
> 
> module top;
>   middle m[2]();
>   initial begin
>      m[0].mb.x = m[1].mb.x;
>   end
> endmodule
> 
> [T]he hierarchical name resolutions make this unsynthesizable.
> But with a bit more malice, it's not hard to make a synthesizable testcase.

I take that back, Shalom.  You're right, it seems impossible to make
a synthesizable testcase to distinguish MODULE-instance-specific types.
All the examples I have involve INTERFACE-instance-specific types,
to which mock-hierarchical references can be synthesized!

For interfaces, synthesis can and does implement instance-specificity.
For modules, it doesn't, and yet it never matters that it doesn't.
I hadn't noticed that aspect before.

What I did observe is the loss of interoperability between elements
of an interface instance array - whose instances synthesis can address
hierarchically (using constant expression indices), but whose simple
local types (especially enums) are incompatible.

As part of a reset protocol the top design is not able to propagate
state from a master interface instance to its clones in the array unless
the state enum is declared global to the interface declaration.

It seems strange for types to behave so object-like when no actual
objects are involved.  Instance-specificity is also the largest
impediment to accepting dynamic index values in these mock-hierarchical
interface array references - a feature I would like to see the LRM
extended to support someday.

Thanks, Shalom. I appreciate better why this LRM definition has seemed
acceptable so far.  However, it's still a distinction without a
difference that I'd rather eliminate if no one is yet using struct
union, or enum types to carry instance identity info.

Greg






> 
> Homogeneous arrays of instances are an obvious way to form DAGs
> whose nodes are module specializations.  By removing instance-specificity
> from the definition of the struct{int x; int y;}, the two instances
> of bottom share the same module specialization.  Their ability to
> cooperate is increased.
> 
> Greg
> 
> 


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