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

Stu writes --

  "I think $unit should be treated 100% the same as a named package that
had been wildcard imported into a scope."

The $unit package concept doesn't make sense, because "Packages must
exist in order for the items they define to be recognized by the scopes
in which they are imported."  With $unit, you are using names imported
from the $unit package before you've finished analyzing the package --
before you've seen the implicit 'endpackage' at the close of the
compilation-unit scope.

We made a big mistake in

    http://www.eda-stds.org/sv/Changes_draft2/LRM_Changes_18.html

when we replaced the implicit $root module with the implicit $unit
package.

Subclause 1.2 of IEEE Std 1800-2005 still talks about "Compilation-unit
scope nested modules", but this was much more natural back in the days
when $root was a "top level hierarchy which can have global
definitions".

Before $unit, a module declaration was always nested in the declaration
of its $root module, so a call to a function declared later in the scope
made sense, while the use of a type name declared later in the scope was
illegal.

The early implementations of SV, as well as the legacy SV code developed
with them, use the $root module concept, not the $unit package concept.
 
-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Stuart Sutherland
Sent: Friday, June 01, 2007 11:47 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?


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



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