Re: [sv-bc] Assignment compatibility after elaboration

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Tue Sep 04 2007 - 07:01:18 PDT
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.

> 
> Check for the assignments "b1.s = b2.s", where the struct 's' is 
> declared inside the module 'bottom'. Is the assignment correct at run 
> time when the design is elaborated, that means each will have separate 
> master, so the struct will be different. Different simulators behave 
> differently here.
> 
> I have another similar type of e.g.:
> module bottom;
>   parameter type pt = int;
>   pt x;
> endmodule
> 
> module top;
>   typedef struct {int x; int y;} et;
>   bottom #(et) b1();
>   bottom #(et) b2();
>   initial begin
>      b1.x = b2.x;
>   end
> endmodule

This is certainly valid.  There is no "visibility" requirement
in bottom specified by the LRM.  Since the same type propagates
into each module instance, the type of "x" in b1 and b2 is the
same type instance and are therefore identical.  Thus the
assignment is valid.

I don't know why someone would claim that "et" must be in a
visible scope; that certainly isn't an LRM requirement.

Gord

> Is the assignment valid or not? I have got some feedback, that the 
> design is conceptually incorrect. To override "bottom" with "et" through 
> "top", "et" should be visible to both "bottom" and "top", i.e. it should 
> be in compilation unit scope. Though standard simulators pass the case.
> 
> Any expert comment?
> 

-- 
--------------------------------------------------------------------
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.
Received on Tue Sep 4 07:01:37 2007

This archive was generated by hypermail 2.1.8 : Tue Sep 04 2007 - 07:02:07 PDT