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

Tom,

Just to bring in a small warning here about language expectations.

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.

If you have:
    my_include.svh:
       `ifndef _MY_INCLUDE
       `define _MY_INCLUDE
            class C;
            endclass;
       `endif

and then include "my_include.svh" into two different compilation
units (say "unit1" and "unit2"), you end up with two different and
completely incompatible versions of class C.  Objects of type C within
unit1 are not assignment compatible with objects of type C in
unit2.

This behavior in SystemVerilog makes it more than just a
methodology decision to have class types in packages.  If you
want a class to be usable across different compilation units,
it MUST be in a package and be imported or else the resulting
types will not be the same types.  This severely limits ones
ability to use `include for class type inclusion unless you
want just similar behavior in multiple regions of the design.

Most people on the committees are aware of this kind of issue,
but since I hadn't heard it raised yet, I just wanted to
reinforce that the C++ view of "compilation unit" and type
inclusion does not map into SystemVerilog's `include in a
way that you might expect.

Gord.

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

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com