SV-BC Separate Compilation discussion 4/28/03

Attendees
0
4
2
8
0
3
a Karen Pieper
a Randy Misustin
a Dennis Brophy
a Danny Jacobi
a Brad Pierce
a Dave Rich
a Francoise Martinolle

DPI proposal, Kevin's proposal, Randy's proposal, Peter's proposal

DPI has a way to say that a function or module is not defined yet, 
i.e. an imported function.

Requirements for separate compilation and $root.

Issues:
1) Ability to know at compile time all of the functions and objects 
we are dealing with
	(type safety)
	A) $root
	B) XMR

2) Name collisions

3) What does it mean to have objects in $root

4) Who owns creating an object

5) What constitutes distributable IP

6) We probably can't remove $root

7) Not having to type root.foo

What was the original requirement for creating $root.  To have 
objects that are globally accessible without requiring that they 
all be in a single module.  Historically, people put them all in a 
module root and reference them hierarchically.  They also would 
include tasks and functions in modules that used them.  The 
difficulty was if they wanted to have only one module.  C provides 
a local $root whereas SV only has a global $root.  The disadvantage 
of using a root module is that everything has to be collected into
one module--everything has to be assembled into one file.  We just 
took the model from C and just by declaring things outside a module.  
C had static though.  Verilog and SV does not have the concept of 
separate compilation.  Some tools do.  Cadence has separate parsing.
ModelSim has separate compilation while staying within the LRM.  
There were some tough issues to solve.  

One idea is create a local $root for a specific compilation unit.  
Could this be a collection of files?  This would change the idea of 
a library because libraries are no longer just modules?  This would 
create a local root module for the compilation unit.  How do you 
module the local root module?  As we change the contents of the root 
module how does it get compiled?  Image multiple compile invocations 
targeting the "library".  How does this local $root get named?  
Erase what was there on recompile?  The local $root would be local 
to only that unit?  How does someone else get access to it?  What 
about global $root access?  

This idea would require a backward compatibility mode because some 
modules are separately compiled today without having $root totally 
linked in.

What is global in Verilog 2K?  Modules, UDPs, compiler directives

The original purpose of $root was to share symbols, especially types.  
'include wouldn't work because you couldn't put a type declaration on 
a port.  Two types declared in two separate places aren't the same 
even if they are identical.

Not solving namespace issues is a disservice to the industry.  
Especially if we move more toward IP or conglomerates designing 
modules to go in one design.

It might be useful to see how other parts of Verilog can help.  
DPI, Configurations and so on.  VHDL has packages (global signals, 
functions, ... accessed by other units).  Can define static and 
global for objects in VHDL.  Modules and primitives need to be 
globally visible everywhere.  Is that sufficient?  This doesn't 
solve the global level module name collision problem.

We should work on creating a requirements document listing the 
issues we have talked about.  

Randy's namespace proposal is http://www.eda.org/sv-bc/hm/0587.html

VHDL does not have the notion of static things in a package.  You 
could if you put it in the package body.  Going to separate package 
header package body is so not Verilog that we may not want to go there.

Are types required for XMRs to do separate compilation.  Because of 
legacy code, it would help, but it can't be required because of legacy 
code.  Dummy modules don't feel right, but they could save some typing 
(Kevin's proposal)

Next step, develop a requirements document, and explore existing 
proposals including configurations.  Francoise would like to have a 
document that describes all known issues and the requirements that 
created $root.  

Karen will take the action item to create a draft problem statement, 
and a list of all the open proposals.  Describe what people do today 
because they don't have a global namespace.

We'll have another discussion in two weeks.