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

Steven Sharp's comments seem very sensible.

I believe the only issue at hand is whether the LRM should prescribe a
use-mode 

default behavior or not. Steven seems to argue that it should not, thus,
requiring 

the removal of the sentence:

 

The default definition of a compilation unit is defined in case b above,
in which 

each file is a separate compilation unit.

 

I can envision this as a tool specific issue, and agree that we remove
the paragraph.

 

            Arturo

 

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Steven Sharp
Sent: Wednesday, January 25, 2006 12:45 PM
To: sharp@cadence.com; Karen.Pieper@synopsys.COM; sv-bc@eda.org;
shalom.bresticker@intel.com; doug_warmke@mentor.com
Subject: RE: [sv-bc] Question on compilation units & compiler directives

 

 

>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