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.