Re: [sv-bc] Member select or hierarchical name

Surya Pratik Saha wrote:
> Hi Dave/Shalom/Gordon,
> All you mean then, 'member select' or 'hierarchical name' once decided 
> at the time of analysis will never be changed even later it is declared 
> in different way.
> 
> So 'bl.x' will always point to 'x' variable present inside generate 
> block 'bl'. I can think of another similar counter example:
> 
> module top;
>     generate
>         begin:b
>         struct {int x;} bl;
>             initial begin:c
>                bl.x = 1; // will it be converted to hierarchical 
> reference of seq block after the full scope is traversed
>                 begin:bl
>                    int x;
>                 end
>             end
>        end
>     endgenerate
> endmodule
> 
> Here in this case, 'bl.x' should point to 'x' inside struct. But no 
> standard simulators work in that way currently, they all resolve it to 
> 'x' present inside sequential block 'bl' as per their legacy code.

Right, and that resolution is incorrect and needs to be fixed in
the simulators.


 > So
> lots of legacy code already present inside simulators and other tools 
> need to be re-written if we go by LRM. 

Correct.

> I can understand how the code is 
> written - it never considers the first identifier of dotted name as 
> simple identifier and never searches it at the point of reference, then 
> later when it is searched the 'bl' is already declared lexically later. 
> We have then two ways of solution:
> 
> 1) LRM needs to be rewritten to keep the legacy code as it is.

Nope.  This was all discussed in committee and the rules in the
LRM were reached by consensus with all the reps (including
Synopsys, Mentor, and Cadence reps).

> 2) Simulators and other tools code to be re-written, with the risk that 
> lots of designs working fine earlier will not work then.

Yes, that is what is required.

In reality, the kinds of scenarios that you are raising are relatively
rare and the real compatibility risk in actual user designs at this
point is not terribly significant; not zero, but not a show-stopper.

It is certainly in the best interests of the entire community for
the vendors to get these changes implemented as soon as possible,
but there are obviously all sorts of pressures on the implementation
fronts at this point so such roll-out will inevitably take a release
or two to reach customers.

Gord.



> 
> <1> is easy solution, but <2> is ideal solution.
> 
> Regards
> Surya
-- 
--------------------------------------------------------------------
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.