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

>Gord's segmenting idea describes the only technique I know for this
that
>is consistent with LALR(1) one-pass parsing.

You could require forward typedefs, as in this example from  

                http://www.eda-stds.org/sv-bc/hm/6003.html

          typedef T2;
          module mod(input T2 in, output T2 out);
             assign out = in;
          endmodule:mod
          typedef T2 byte;

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg
Jaxon
Sent: Monday, June 04, 2007 12:57 PM
To: Gordon Vreugdenhil
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] Root cause --- $unit is as broken as could be --
maybe too late to standardize it?

Gordon Vreugdenhil wrote:
> 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.

I agree.

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

$Unit should _not_ be wildcard imported into the modules and interfaces
it may contain!  Doing this will cause other "explicit" wildcard imports
from better defined packages to be blocked by the random cruft that
might appear outside the module's declaration.  This is the same
complaint I make about the implicit wildcarding of the "std" package -
for which I still think the LRM needs a lower priority of wildcard
importation.  I believe nested scope access to $unit is more than
adequate!

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

I agree with this version of the segmented $unit concept.
Any version where the $unit scope is reset between modules would be
wrong...

Notice that, in this form of segmenting, although foo cannot refer
directly to T2, nor access it by $unit::T2, he might still receive a
type parameter bound to $unit::T2.  If for example, T2 is a struct with
a field of type T1, foo will recognize that that field's type matches
his $unit::T1.
In other words, foo has to recognize that the scope he calls $unit might
have things in it for which he has no known name binding.

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

BAH! Your $unit_part_2 needs to import & re-export all of $unit_part_1.
Probably you've got a typo above.
It will need things from $unit_part_1 to declare its functions and
structs.
> 
>    module foo2;   // gets to see T and T2
>       import $unit_part_2::*;
>       T x;
>       T2 y;
>    endmodule

But this is still a broken model.  What if the original code was:
  package malicious;
     typedef enum{ ZERO } T;
  endpackage
  module foo2;   // shadows T, but uses T2
     import malicious::*;
     T x;
     T2 y;
  endmodule

Gord's segmenting idea describes the only technique I know for this that
is consistent with LALR(1) one-pass parsing.  Requiring implementers to
use more sophisticated scanners, also requires SV users to scan more
code using a more sophisticated mental model of how it will be parsed.

Greg


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