RE: [sv-bc] Root cause --- $unit is as broken as could be -- maybe too late to standardize it?

There are rules given in the LRM for how identifiers are to be 
resolved with $unit. Section 19.3 includes this text:

<quote>
When an identifier is referenced within a scope, SystemVerilog 
follows the Verilog name search rules:
- First, the nested scope is searched (see 12.6 of IEEE Std 1364) 
  (including nested module declarations), including any identifiers 
  made available through package import declarations.
- Next, the compilation-unit scope is searched (including any 
  identifiers made available through package import declarations).
- Finally, the instance hierarchy is searched (see 12.5 of IEEE Std
1364).
</quote>

Now I thought these were clear. First you look in local scopes, 
then you look in $unit, then you look in the instance hierarchy.

The first two of these can usually, but not always, be done at parse 
time, while the last one must wait until elaboration. The argument 
that is being made is that at elaboration you only search in the 
hierarchy. Searching in the hierarchy also includes searching the 
local scopes as in the first rule, but does not include $unit in
the 2nd rule. 

I find this confusing. To get consistent behavior between tools,
you need to define what searches have to be done at parse time
and what searches have to be done at elaboration time, because the
rules for such searches are different. 

There also are questions about classes and the randomize with 
construct. If we allow the base class of a class to be a forward
typedef or a type parameter, then it is completely impossible to
resolve many identifiers in class tasks and functions at parse
time and they must be resolved at elaboration. Already variables
that you apply a randomize with clauses to can have a type which
is a type parameter, making it impossible to resolve variables 
in the with clause at parse time.

I think it will be much more difficult to get agreement between 
implementations when we define one search rule to be used at 
parse time and another search rule to be used at elaboration time.
We will have to unambiguously specify exactly which identifiers are
resolved at parse time and which are resolved at elaboration 
time.  

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Stuart Sutherland
> Sent: Saturday, June 02, 2007 3:37 PM
> To: sv-bc@eda.org
> Subject: RE: [sv-bc] Root cause --- $unit is as broken as 
> could be -- maybe too late to standardize it?
> 
> 
> >From a user's perspective, I would be perfectly fine with the 
> >restriction
> Gord suggests, that:
> 
> > other design units only got to "import" the names defined 
> in the part 
> > of $unit that preceded that design unit.
> 
> It is a reasonable and intuitive restriction, and goes along 
> with rules such as that one must declare a `define macro 
> before referencing it.  The restriction means there is 
> potential file order dependencies in multi-file compilation, 
> but it is the same problem Verilog users are already familiar 
> with from using compiler directives.  Staying with know 
> behavior is far better than the current $unit behavior that 
> doesn't work the same on all tools.
> 
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> Sutherland HDL, Inc.
> stuart@sutherland-hdl.com
> 503-692-0898
>  
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org
> > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil
> > Sent: Saturday, June 02, 2007 12:01 PM
> > To: stuart@sutherland-hdl.com
> > Cc: sv-bc@server.eda.org
> > Subject: Re: [sv-bc] Root cause --- $unit is as broken as 
> could be -- 
> > maybe too late to standardize it?
> > 
> > Stu,
> > 
> > It is not possible to treat $unit visibility in a manner that is 
> > identical to a normal package import.  The reason is that a package 
> > must exist *in its entirety* at the time that an import of that 
> > package occurs.
> > Since $unit is defined in fragments with intervening $unit 
> sections, 
> > it simply can't be identical.
> > 
> > I would emphatically agree with the "import" approach but 
> *only* if we 
> > agreed that $unit is really a "segmented" compilation unit and that 
> > other design units only got to "import" the names defined 
> in the part 
> > of $unit that preceded that design unit.
> > 
> > For example:
> >     typedef int T;
> >     module foo;    // only gets to see "T"
> >        T x;
> >     endmodule
> > 
> >     typedef int T2;
> >     module foo2;   // gets to see T and T2
> >        T x;
> >        T2 y;
> >     endmodule
> > 
> > I think I've suggested this before (long, long ago in a 
> universe far, 
> > far away).
> > 
> > You can describe this model by using import and export (or pretty 
> > closely using multiple imports):
> > 
> >     package $unit_part_1;
> >        typedef int T;
> >     endpackage
> > 
> >     module foo;
> >        import $unit_part_1::*;
> >        T x;
> >     endmodule
> > 
> >     package $unit_part_2;
> >        export $unit_part_2::T;
> >        typedef int T2;
> >     endpackage
> > 
> >     module foo2;   // gets to see T and T2
> >        import $unit_part_2::*;
> >        T x;
> >        T2 y;
> >     endmodule
> > 
> > 
> > This doesn't allow some of the examples that are currently under 
> > discussion, such as:
> > 
> >     module foo;
> >        initial f();
> >     endmodule
> >     function void f;
> >     endfunction
> > 
> > but I'm not too unhappy about that.
> > 
> > The one issue that was brought up (by a user) when this model was 
> > suggested is that forward typedefs would have to be allowed to span 
> > the fragments.  For example:
> > 
> >     typedef T;
> >     module foo;
> >        T x;
> >     endmodule
> >     typedef int T;
> > 
> > I don't like this style, but could live with it if we went in this 
> > direction.
> > 
> > 
> >  From a personal standpoint, I'd love to deprecate $unit -- 
> Mentor's 
> > position originally was that $unit shouldn't exist and that import 
> > statements should work like VHDL's -- an import should be allowed 
> > immediately before a design unit and associate with that 
> design unit 
> > (which solves the port/parameter type problem).
> > 
> > I still think that is a much better approach.
> > 
> > Pragmatically, as an implementor, there is already a fair amount of 
> > client code out there that uses $unit.  I doubt we'd be able to 
> > actually drop support, but at least then from an LRM 
> standpoint we'd 
> > have a much stronger ability to suggest to users that they follow 
> > stronger design practice and not use $unit since they 
> wouldn't be able 
> > to rely on all cases working in the manner that a specific 
> > implementation uses.
> > 
> > Gord.
> > 
> > 
> > 
> > Stuart Sutherland wrote:
> > > I joined Wednesday's conference call just a little late,
> > via cell phone, and
> > > had to drop off shortly before the call finished because my
> > phone batteries
> > > died.  I tried to say something a couple of times during
> > the call, but was
> > > always drowned out by other conversation.  So here's my two
> > cents worth...
> > > 
> > > First, I think there is only one reason to $unit at all,
> > which is to allow
> > > using user-defined types in port declarations without
> > having to name a
> > > package for each and every port.  There was a Mantis item
> > on that problem
> > > with a suggested solution, but it did not make it into 1800-1005.
> > > 
> > > Second, IMHO, any SV construct that runs differently on
> > different tools of
> > > the same type (e.g. different simulators) is worthless.  
> > Even if left in the
> > > language, smart users will never use the construct.  What I
> > tried to say
> > > during the conference call is that I think $unit should be
> > treated 100% the
> > > same as a named package that had been wildcard imported
> > into a scope.  In
> > > other words, make $unit a named package that is predefined
> > in the language,
> > > and follows the same rules as a named package.  The only
> > difference is that
> > > there is an implicit wildcard import of $unit.  Further, 
> I think the 
> > > standard should allow explicit importing and exporting
> > $unit items, just as
> > > with named packages.  
> > > 
> > > This treating $unit the same as a named package extends to 
> > > compilation/elaboration, as well.  The rules for how a tool
> > finds wildcard
> > > imported package items, and what order things must be
> > compiled in, should be
> > > exactly the same for both.  In my opinion, any
> > inconsistencies between using
> > > $unit and a named package is both confusing and
> > unnecessary, ***IF*** there
> > > is a way to import package items before port declarations.  
> > As was evidenced
> > > in last Wednesday's conference call, trying to define
> > special, non-package
> > > rules for $unit will likely never reach consensus.  I say
> > skip the special
> > > rules and make $unit exactly the same as a package.
> > > 
> > > I would also support just deprecating $unit, and moving the
> > description of
> > > it to the appendix on deprecated constructs.  If
> > deprecated, the description
> > > of $unit should state that tools that support $unit shall
> > issue a warning
> > > stating that named packages should be used instead.
> > > 
> > > In any case, doing nothing is not an option in my opinion.  
> > The rules for
> > > $unit must be defined so that all tools do the same thing
> > for single file
> > > compilation and for multi file compilation.
> > > 
> > > Stu
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Stuart Sutherland
> > > Sutherland HDL, Inc.
> > > stuart@sutherland-hdl.com
> > > 503-692-0898
> > >  
> > > 
> > >> -----Original Message-----
> > >> From: owner-sv-bc@server.eda.org
> > >> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
> > >> Sent: Friday, June 01, 2007 9:26 AM
> > >> To: sv-bc@server.eda.org
> > >> Subject: [sv-bc] Root cause --- $unit is as broken as 
> could be -- 
> > >> maybe too late to standardize it?
> > >>
> > >> Gord,
> > >>
> > >> Your discussion and suggestions about the compilation-unit scope 
> > >> ($unit) concept at the 30/May/07 SV-BC teleconference were truly 
> > >> thought-provoking, even though our conversation about
> > $unit seemed to
> > >> eventually fall into an infinite loop.
> > >>
> > >> ---------- Short intro for those not on teleconference
> > >> ---------------------
> > >>
> > >> The LRM doesn't even standardize what a compilation-unit 
> scope is.
> > >> Instead it just throws up its hands and sighs "The exact
> > mechanism for
> > >> defining which files constitute a compilation unit is
> > tool-specific."
> > >> And it vaguely describes two such mechanisms -- the 
> > >> entire-command-line style and the file-at-a-time style.
> > >>
> > >> In practice, there is also a third style which does not
> > even concede
> > >> that "files" are a significant factor nor that there is 
> a unitary 
> > >> $unit.
> > >> In that third style, the $unit is only whatever has been
> > read so far,
> > >> and an explicit reference into the future $unit would be
> > rejected, for
> > >> example,
> > >>
> > >>                 typedef $unit::T1 T2;
> > >>                 typedef byte T1;
> > >>
> > >> Apparently no tools currently allow
> > >>
> > >>                 typedef T1 T2;
> > >>                 typedef byte T1;
> > >>
> > >> but some do and some don't allow
> > >>
> > >>                 typedef T2;
> > >>                 module mod(input T2 in, output T2 out);
> > >>                   assign out = in;
> > >>                 endmodule:mod
> > >>                 typedef T2 byte;
> > >>
> > >> And some tools allow the following only in a module scope,
> > but not in
> > >> $unit, while others allow it in either kind of scope
> > >>
> > >>                 function g(input in);
> > >>                   return f(in);
> > >>                 endfunction:g
> > >>
> > >>                 function f(input in);
> > >>                   return in;
> > >>                 endfunction:f
> > >>
> > >> -------------  End of background
> > >> -------------------------------------------
> > >>
> > >> It's hard for me to believe that a non-consensus 
> solution in this 
> > >> space could really change the "facts on the ground", or even
> > create a solid
> > >> ground for users to stand on -- that it could be 
> anything more than 
> > >> just a "paper tiger".  Yet I also find it hard to believe that 
> > >> there could be a consensus solution when the tools are 
> already so 
> > >> divergent.
> > >>
> > >> We could generate a long list of examples demonstrating 
> the various 
> > >> exotic dimensions of this divergence, and probably for
> > each style and
> > >> decision there is a rationalization that could make it
> > sound sort of
> > >> reasonable on the surface.
> > >>
> > >> The root cause though is that the $unit concept is simply not 
> > >> well-defined or reasonable, and minor patches are not
> > going to make it
> > >> so.
> > >>
> > >> How do we standardize this house that's built on sand?  
> > Should we even
> > >> be trying?
> > >>
> > >> Could we instead expand the list of choices that the LRM 
> explicitly 
> > >> deems "tool-specific"?
> > >>
> > >> -- Brad
> > >>
> > >>
> > >>
> > >> --
> > >> This message has been scanned for viruses and dangerous 
> content by 
> > >> MailScanner, and is believed to be clean.
> > >>
> > >>
> > >>
> > >>
> > > 
> > > 
> > > 
> > 
> > -- 
> > --------------------------------------------------------------------
> > 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.
> 
> 

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