RE: [sv-bc] Question on compilation units & compiler directives

From: Steven Sharp <sharp_at_.....>
Date: Wed Jan 25 2006 - 12:44:51 PST
>From: "Warmke, Doug" <doug_warmke@mentor.com>

>But that is in contradiction to the P1800 LRM.
>SystemVerilog designs are required to have one-file is
>one-compilation-unit semantics as the default (See 19.3).

We can get into legalistic quibbling about what "default"
means in that context.  However, the fact is that the
command lines of tools are outside the scope of the LRM.
This is acknowledged explicitly in the section that you are
referencing.  It says that the mechanism for defining which
files constitute a compilation unit is tool specific.  Tools
have to provide both use-models, but how they do so is up to
them.

The statement that one of them is the "default" has no
real meaning, since it doesn't constrain the mechanism
used to get that default.  A tool can require that each
file be compiled with a separate tool invocation as the
mechanism to get the default behavior.  A tool can have a
command-line option to get the default, and have the
mechanism for getting the other use-model be to leave off
the option.  You can claim that this doesn't match what was
meant by "default", but this is outside the scope of the
LRM.

Even if the LRM could somehow require that getting the
other use-model required adding a command-line option
rather than omitting one, there are still ways around
this.  A tool is not required to be compliant with the
P1800 LRM with all possible command-line options.  For
example, a tool might require a -systemverilog command-line
option to make it compile SystemVerilog instead of Verilog.
So clearly a tool can require a particular command-line
option in order to be compliant with the P1800 LRM.

A tool could require the command-line option -file_unit to
be used to get compliant P1800 behavior, and then require
the additional option -no_I_really_meant_all_files to get
the non-default behavior.  And then the tool could say that
without -file_unit, you also get the non-default behavior.
This is OK because that option was required to get P1800
compliance, just like -systemverilog was.  The result is that
the default behavior in P1800-compliant mode is as required by
the LRM, but the behavior with minimal options isn't.  The
tool must still be considered compliant.

Given that such a requirement is easily circumvented, there
is no point in making it in the first place.

I agree that the "stream-of-text" model causes problems, and
it would be good to move away from it.  But as Shalom notes,
users are accustomed to it.  An implementor may decide that this
is a more important consideration, and provide that use-model
under the simplest command line options.  And there is nothing
that the LRM can reasonably say to make that illegal.


>After reading this debate, I would be fine with treating
>compiler directives the same as plain Verilog objects.
>The argument about insulating different parts of large
>designs from surprising interactions applies to compiler
>directives as well as plain Verilog objects.

I think it is a reasonable thing.  And it falls out naturally
if the mechanism used by the tool to cause each file to be
treated as a separate compilation unit is to require them to
be compiled with separate invocations.


Steven Sharp
sharp@cadence.com
Received on Wed Jan 25 12:45:00 2006

This archive was generated by hypermail 2.1.8 : Wed Jan 25 2006 - 12:47:13 PST