Requirements for Separate Compilation In SystemVerilog

Last updated: May 12, 2003

Abstract: Verilog has had some issues exposed by implementations that support separate compilation for a number of years. The addition of $root to SystemVerilog has exacerbated the issue by providing the ability to declare globally visible objects outside of modules. This document explores the issues that supporting separate compilation raise in the language, even beyond those raised by $root, and offers pointers to a number of proposals that have been made to date as to how to address those issues.

$root was added to SystemVerilog to simplify the declaration and use of global objects. The table below describes the features that can be instantiated in $root, when they were added to the language, and how the language approached that functionality prior to the introduction of $root if necessary.

At this point, $root is unlikely to be removed from the language because of two factors. One is the requirement that complex types be able to appear on ports, (and, hence, be visible outside of a module scope). Another is that it has been ratified in the 3.0 standard, and, as such, will not be removed from the language.

That being said, there are still several issues that exist with $root today, especially in the context of separately compiled modules.

• How do objects defined in one compiled component affect another? Can a ‘define compiled in one component be forced to apply to another? How about type definitions?
• If there are two separately compiled modules with data in $root, what happens with name collisions? Hasn’t the problem just gotten a lot worse since it is no longer limited to module names?
• Who owns creating the object? If two components (files) have copies of the same function or task, which one will be chosen if both compile it?
• What constitutes distributable IP?

The desire for separate compilation comes from several different objectives. One is allowing design elements to be provided from a language external to Verilog. The DPI and VPI are attempts at addressing this issue. Another is to decrease compile time in a design by pre-compiling portions of a design that do not change frequently. Another comes from synthesis where individual designers are expected to provide a synthesized netlist for their portion of a design independent of the instantiating or instantiated designs associated with their piece.

To support separate compilation, the primary constraint is that there exist units of compilation that are independent of other units of compilation. Hierarchical reference and compilation directives are two features of Verilog 2001 that create issues for separate compilation. Historically, the issues for compilation directives have been solved by limiting their effect to a compilation unit as opposed to an entire design, or by reparsing the entire simulation unit each time and calculating which of the underlying compilation units have changed. Hierarchical reference has been handled by reparsing the entire design, in which case full information is available, by writing code that can deal with a variety of types, or by disallowing hierarchical reference.

$root complicates the picture because of the presence of data and module declarations within $root. The primary issues associated with this are listed above.

An additional issue that arises in SystemVerilog is the presence of implicitly connected .* ports on a module. The module ports in the instantiating module cannot be known unless the instantiated module is available.

Given the description of the problem environment above, there are several issues a solution should address:

• Type definition for items in $root, hierarchical references, and other external references need to be expressible
  1. The type indication cannot be a requirement because of backwards compatability with existing Verilog designs
• Multiple compilation units must be able to reference an object in $root. A mechanism to resolve those references must exist at elaboration time.
• The number of name conflicts should be minimized.
1. IP will be developed from multiple not necessarily communicating sources
2. The solution needs to have a way of providing types local to a multiple-module separate compilation unit (think IP).
• Any solution should be easy to use and intuitive.
• Backward compatibility with existing Verilog designs must be maintained
• Integration with other languages should be straightforward

Several proposals have been made to address the issues described above: