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