Re: [sv-bc] FW: [sv-ec] Question on compilation units & compiler directives

To address the original question:  Verilog does not bind preprocessor
macros in scopes given by the RTL source code.  P1364 says:

> Once a text macro name has been defined, it can be used anywhere in a source description; that is, there are
> no scope restrictions.

That said; of course there are scope restrictions! Both you and
I use the macro `DEBUG, and I don't pick up your definition...
P1800 uses "compilation unit" to discuss scope boundaries that arise
because of source file processing and the compilation commands.
These /do/ affect the lifetimes of macro definitions.  The LRM
suggests some options for how to group or ungroup multiple files
on a compile command line.  These definitely change the outcome of
macro preprocessing.  The scoping issues Gord brings up can
come into play if you use the "include-just-once" macro guards unwisely.

To deploy a scope-sensitive type system, you need to use
the "generate" feature rather than the preprocessor.


Paul Graham asks:
>> SystemVerilog is *very* different than C++ in terms of what
>> constitutes class assignment legality.  C++ ensures that two
>> files with the same class hierarchy included via #include represent
>> the same types.  Not true in SV.
> 
> Just curious why SV is different in this detail from C++.
> 
> Paul

I don't believe the differences here are so significant.  C++
does not unify two inclusions of a class if they are brought into
distinct scopes.  Depending on the class declaration (base classes,
etc) and the relationship between the two scopes. objects of the
two classes may or may not be assignment compatible, but they /are/
distinct types.

If the class hierarchies are actually duplicated into two separate
files, then, yes, SV distinguishs them and C++ probably doesn't.
Since the SV standard is not concerned with how to distinguish
different files, we expect practical systems to apply this rule
mainly to help designers insure that common headers come from a
common source.

The SV rule won't disrupt the usual case where one file a type
declaration is `included into the "same" scope of two different
compilation units.  This is the essence of separate compilation!

Greg Jaxon

Symons, Tom H wrote:
> There is also the issue of managing a large hierarchy of nested include
> files, as is common in an object-oriented programming environment.
> 
> This is typically done by including the following code at the beginning
> of each include file:
> 
> `ifndef _MY_INCLUDE_FILE_
> `define _MY_INCLUDE_FILE_
> ...
> `endif
> 
> Without having this ability to disable multiple definitions of the body
> of an include file, you would not be able to have each include file
> reference all the other include files needed to use the object.  This is
> because some of those include files may each reference the same include
> file, causing it to be referenced twice. Separate compilation units with
> compiler directives scoped to just the compilation unit allows this
> mechanism to work.
> 
> Just to be clear, consider this example:
> 
> foo1.svh
> `ifndef _include_foo1_
> `define _include_foo1_
> `include "bar.svh"
> ...
> `endif
> 
> foo2.svh
> `ifndef _include_foo1_
> `define _include_foo1_
> `include "bar.svh"
> ...
> `endif
> 
> module1.sv
> `include "foo1.svh"
> `include "foo2.svh"
> 
> module2.sv
> `include "foo1.svh"
> `include "foo2.svh"
> 
> The above code will fail unless module1 and module2 are compiled such
> that the compiler directives are independent within each module.
> 
> One solution to this problem is to use packages instead of include
> files.  That would work, but it seems more a methodology choice.  I
> would think the language should support inclusion of a class object
> hierarchy as well.
> 
> Tom Symons
> 
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Karen Pieper
> Sent: Tuesday, January 24, 2006 11:07 AM
> To: Warmke, Doug; Brad Pierce; sv-bc@eda.org
> Cc: LaFlamme, Jamie; Mehdi Mohtashemi
> Subject: RE: [sv-bc] FW: [sv-ec] Question on compilation units &
> compiler directives
> 
> I disagree that the paragraph was overlooked.  If one would like to use
> multiple files as a compilation unit, a compliant tool must support that
> via option A, and this case is covered.
> 
> Our intent was to move to a model where there was more support for
> separate compilation not requiring the concatenation of all of the
> defines across all compilation units.  This semantics is closer to the
> one required for a synthesis tool to support separate synthesis of each
> module, and for a simulation tool to be able to support separate
> compilation.  A user can achieve the inclusion of the defines by doing a
> #include and having it appear in each file.
> 
> Karen
>  
> 
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Warmke, Doug
> Sent: Monday, January 23, 2006 10:23 PM
> To: Brad Pierce; sv-bc@eda.org
> Cc: LaFlamme, Jamie; Mehdi Mohtashemi
> Subject: RE: [sv-bc] FW: [sv-ec] Question on compilation units &
> compiler directives
> 
>  
> Hello SV-BC,
> 
> As one of the authors of the package and compilation unit areas of
> P1800, I believe that the paragraph mentioned below was overlooked
> during late edits of compilation unit topics.
> 
> Compiler directives have always existed outside the module namespace,
> and their behavior in P1364 is well understood.  If we apply the "one
> file is one compilation unit" semantics to compiler directives
> (described in "b)" early in 19.3), there will be potentially serious
> backwards compatability issues with P1364.
> 
> I propose that 19.3 should be amended to indicate that compiler
> directives always follow the semantics described in "a)" near the
> beginning of the section.
> 
> I can take the action to create a Mantis item and proposal if the group
> is amenable to that.
> 
> Regards,
> Doug
> 
> 
> 
>>-----Original Message-----
>>From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of 
>>LaFlamme, Jamie
>>Sent: Monday, January 23, 2006 5:59 PM
>>To: sv-ec@eda.org
>>Subject: [sv-ec] Question on compilation units & compiler directives
>>
>>The following paragraph in section 19.3 pretty much says that compiler
> 
> 
>>directives only apply to the end of the compilation unit:
>> 
>>    "In Verilog, compiler directives once seen by a tool apply to all
>>    forthcoming source text. This behavior shall be supported within a
>>    separately compiled unit; however, compiler directives from one
>>    separately compiled unit shall not affect other compilation
>>    units. This may result in a difference of behavior between
>>    compiling the units separately or as a single compilation unit
>>    containing the entire source."
>>
>>Given that the default compilation unit is supposed to be separate 
>>compilation units for each source file it seems like a painful 
>>incompatibility with 1364 Verilog.  Given following example files:
>>
>>	file "defines.v":
>>		`define DEBUG
>>
>>	file "top.v"
>>		`ifdef DEBUG
>>		reg enable_debug;
>>		`endif
>>
>>If they are compiled together using separate compilation units for 
>>each file should the DEBUG macro really not be defined in top.v?  What
> 
> 
>>happens if a mix of Verilog 2001 and SystemVerilog source files are 
>>compiled at the same time?
>>
>>Thanks for any input,
>>-Jamie
>>
>>
>>
> 
>