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

Arturo,

The main tool difference discussed on Wednesday was about calls to a
subroutine for which the declaration has not been seen yet in the text,
but which is declared in $unit later on.  The divergence in behavior is
especially a problem when the subroutine is called in a module, but is
declared in $unit after the module declaration.

As I noted in http://www.eda-stds.org/sv-bc/hm/6006.html , the
divergence stems from a change made in 3.1a, in which the old $root
module concept was replaced with the $unit package concept.  

-- Brad     

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Arturo Salz
Sent: Saturday, June 02, 2007 4:46 PM
To: stuart@sutherland-hdl.com; sv-bc@eda.org
Subject: RE: [sv-bc] Root cause --- $unit is as broken as could be --
maybe too late to standardize it?

Stu,

I'm afraid I don't understand how Gord's suggestion would solve the
problem. Since it still leaves open what $unit is, it would seem (to me,
at least) that it only opens the door to even more tool
incompatibilities. Or perhaps I missed some subtlety.

	Arturo

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



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