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.