SV-BC Separate Compilation discussion 6/9/03

Attendees
000
654
012
928
000
333
aaa Karen Pieper
aaa Randy Misustin
--a Dennis Brophy
--a Danny Jacobi
aaa Brad Pierce
a-a Dave Rich
-aa Francoise Martinolle
aa- Matt Maidment
a-- Tom Kiley

Today's meeting is a discussion of the proposals that have been made to date
for dealing with the separate compilation issue.

Direct Programming Interface

	Has foreign modules compiled in another language.  Why can't that language be Verilog? 
	
	import DPI <function> prototype to import from outside
     	export DPI <function> prototype to import to outside

	Doesn't address issue of types or variables.  Items declared go into a global symbol 
	table which is different from $root.  How about the idea of using export or input to limit
	external visibility in $root?  This might break backward compatibility.  This might be ok
	if we apply these only to things compiled separately.  May want to limit where something 
	can be exported like to $root or DPI.

	The DPI also allows symbols to be renamed among the two domains.  Useful, but may cause 
	lots of renaming issues to stop collisions.

Extern modules

	Would like to have typing info if possible to improve messaging.  Kevin had the idea of
	including data declarations in the modules.  Randy: that seems like a good idea.  Matt:
	How about interfaces?  Is this the only use of extern?  No.  It is used in classes for out
	of body uses.

Namespace proposal
	
	Modelling after VHDL package.  Wanted the notion that you can create a scope at a globally
	visible level.  $root can lead to unpredictible results depending upon what you mixed and
	matched.  Could try to figure out a way to automatically populate a names space to provide
	some backwards compatibility with Superlog.  In general it is $root with a real name.  
	Matt (for Jay) Why not just put them in a module or interface and solve the problem that way?  
	Randy likes to simply import everything.

	Why didn't the DPI folks use $root rather than the global symbol space.  They were importing
	into the linkers space.  The DPI could be considered a formal namespace....  Dave, do we
	need multiple namespaces?  Matt: one namespace with many scopes?  Either you have to dig into
	modules hierarchically or put things in $root.  Perl namespace is convenient.  

Import directive proposal
	
	This uses the gcc extension of 'ifndef <include file> 'include <include file> 'define <include
	file>.  Randy:  This makes 'include more palatable, but doesn't address any of the issues.

Extern functions and tasks proposal
	
	This is going down C's path.  It is frustrating that there is the export thing in the DPI,
	but there is extern here.  Couldn't do we do export here?  This gives you the C solution.
	You must still rely on informal naming conventions to provide namespaces.

Extern data
	
	Same as above.

Bodies on extern modules

	Discussed in extern modules.

Packages in VHDL

	Similar to the namespaces.  It gets down to what keywords are palatable.

Randy will type up a proposal for the namespaces idea with a few examples.

Does this solve the separate compilation problem?  A tool could enforce that a sparately compiled unit has
a namespace, so it is possible to make the separate compilation problem better.  Matt indicated that they
have a use model where everyone can add things to $root with no contention to edit the global header file
like would exist for namespaces.

The next meeting will be in two weeks.