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

Stu,

Just to complete Gord's discussion. There are two key reasons why $unit
cannot be treated the same as normal, named packages:
1) The contents of $unit change while the scopes (e.g., modules) that
would import the $unit items are being parsed. Gord alludes to this
concept in his examples.
2) Items in $unit are visible to the sub-scopes within the unit of
compilation. This is completely different from named packages, which
require package items to be imported or use an explicit reference to the
package name (package::item).

One final comment is that the intent of the LRM was not to create
tool-specific $unit semantics. What is tool-specific is the particular
mechanism used to specify what constitutes a unit of compilation, such
as command line interfaces, tool options, scripting interfaces, etc...
It's also important to recall that without $unit, the tools would have
to either disallow global declarations (at the outermost scope) or
otherwise resolve in a tool-independent manner all the issues associated
with a single $root that may be accessible from any unit of compilation.
The existing $unit definition is a compromise that allows both separate
compilation and global declarations.

	Arturo

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Saturday, June 02, 2007 12:01 PM
To: stuart@sutherland-hdl.com
Cc: sv-bc@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.