[sv-bc] RE: [sv-ec] Dotted names within inlined constraints

I have captured this issue in Mantis 3046 (SV-EC) and linked it to Manti 1858 and 2109.

Shalom

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On
> Behalf Of Gordon Vreugdenhil
> Sent: Friday, April 16, 2010 8:38 PM
> To: SV_EC List; SV_BC List
> Subject: [sv-ec] Dotted names within inlined constraints
>
> Sending this to both EC and BC since there is a bit
> of cross-over name resolution interpretation here.
>
> I'd like to clarify a couple of details regarding dotted name
> resolution form inlined constraints. The key sentence
> is in 1800-2009, 18.7:
>
> Then, if a name fails to resolve within the randomize() with
> object class, the name is resolved normally starting in the
> scope containing the inline constraint.
>
> The given text mostly assumes simple identifiers. What are the
> implications for dotted names?
>
>
> Example 1:
>
> Assume we have the following:
>
> module child;
> int x;
> endmodule
>
> module tb1;
> child m();
>
> class A;
> rand int y;
> endclass
> A a = new;
> endmodule
>
> module tb2;
> struct { int x; } m;
>
> initial begin
> m.x = 2;
> tb1.a.randomize() with { y == m.x; };
> $display("%d", tb1.a.y);
> end
> endmodule
>
>
> My assumption is that "m.x" does not "escape"
> out of class A and into a hierarchical resolution from
> the point of declaration of class A. This means
> that "m.x" refers to tb2.m.x and that the output
> of the example is 2.
>
>
> Example 2:
>
> Now assume we have the following:
>
> module tb;
> class A;
> rand int y;
> struct { int zed; } m;
> endclass
> A a = new;
> endmodule
>
> module tb2;
> struct { int x; } m;
>
> initial begin
> m.x = 2;
> tb.a.randomize() with { y == m.x; };
> $display("%d", tb.a.y);
> end
> endmodule
>
> My assumption is that this is an error since "m" as
> a name *is* found in the target object but "x" is not
> found as a selected member within that structure.
> In this case I follow the precedent of 23.7 and interpret
> "the name" as being "the first name in the dotted name".
> So m.x does not resolve to be tb2.m.x; the design as given
> should produce an error at compile/elab time.
>
>
> 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.
>
>
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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