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

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