[sv-bc] Re: Ballot issue 9 / Mantis 2663 - hierarchical names in compilation unit contexts

This proposal doesn't entirely remove the problem as described in the ballot comment, because 3.12.1 would remain misleading when it says

    "The compilation-unit scope can contain any item that can be defined within a package."

$unit can also contain items that a package could not, such as a bind directive (23.11).  The sentence in 3.12.1 doesn't say otherwise, but it would be easy for the reader to make that wrong inference.

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Francoise Martinolle
Sent: Tuesday, May 05, 2009 10:59 AM
To: Gordon Vreugdenhil
Cc: SV_BC List
Subject: [sv-bc] RE: Ballot issue 9 / Mantis 2663 - hierarchical names in compilation unit contexts



I think I am ok with the proposal.

I think the modified description in 23.7 makes the following comp unit
code legal, right?

task t;
  $display (a.b.c); // dotted name not hierarchical name
endtask

class B;
  int c;
endclass

class A;
  B b;
endclass

A a;

module a;
  task b;
      reg c;
  endtask

endmodule



-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Monday, May 04, 2009 10:50 PM
To: Francoise Martinolle
Cc: SV_BC List
Subject: Re: Ballot issue 9 / Mantis 2663 - hierarchical names in
compilation unit contexts

Design elements are defined directly in the LRM in 3.2.  The definition
is as follows:

   A design element is a SystemVerilog module (see Clause 23),
   program (see Clause 24), interface (see Clause 25),
   checker (see Clause 17), package (see Clause 26),
   primitive (see Clause 28) or configuration (see Clause 33).
   These constructs are introduced by the keywords module, program,
   interface, checker, package, primitive and config, respectively.

So I think using that terms captures precisely the situations that we
want to treat hierarchically and allows all the other things (such as
bind statements, tasks, functions, initializers,
etc) to all behave in the $root manner described.  This avoids having to
define all the special contexts since the normal instance like elements
are already defined by the term "design element".

Gord




Francoise Martinolle wrote:
>
> Gordon,
>
> I have a hard time understanding the essense of the rule " when it is
> not in a design element".
> What is a design element? Everything is a design element. Is this a
> new term that you define?
> Is a module a design element?
>
> Francoise
>     '
>
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Monday, May 04, 2009 5:52 PM
> To: SV_BC List
> Subject: Ballot issue 9 / Mantis 2663 - hierarchical names in
> compilation unit contexts
>
>
> I haven't seen any responses regarding Mantis 2663 on the reflector.
> This is regarding whether hierarchical names are legal in a
> compilation unit.
>
> I would propose to change step (4) in 23.7 as follows:
>
> FROM
>     4) The name is not found. The dotted name shall be considered
>     to be a hierarchical name.
>
> TO
>     4) The name is not found.  If the dotted name is not within a
>     design element, the dotted name shall then be considered to
>     be a hierarchical name with an additional $root prefix.  If
>     the name is within a design element, the dotted name shall be
>     considered to be a hierarchical name.
>
> I think this captures the consensus of the discussion when this came
> up in the meetings.
>
> Explanation -- the "not within a design element" means that you only
> apply this rule for names in tasks, functions, bind statements, and
> the like within the compilation unit.  You do NOT apply this rule for
> modules, interfaces, programs, configurations, packages, etc.
> Packages have a separate rule for disallowing hierarchical names and
> that is not weakened by this additional statement.
>
>
> If there is general agreement on this, I'll formalize it and attach it

> to mantis 2663.
>
> Gord.
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
>
>

--
--------------------------------------------------------------------
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.



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