Incremental Compilation in the VCS Environment
V. Kripa Sundar, Ashish V. Naik, Debashis Roy Chowdhury
Synopsys, Inc.
Abstract
Viewlogic's1 Chronologic VCS TM is an industry
standard simulator for Verilog HDL. This paper describes
Incremental Compilation in VCS. Incremental compilation
is a general compiler optimization technique that improves
turnaround time of the typical develop-test-debug-edit
cycle of software development. It provides the user with
the ability to make small changes to a design, while
guaranteeing that the re-compilation time will be
proportional to the change in the design.
The compiled code simulation environment in Verilog
poses unique challenges and opportunities for incremental
compilation. The paper describes the issues in
determining whether a design unit is unchanged since the
previous compilation, or whether it needs to be
re-compiled. It also addresses the specifics of incremental
compilation in single-user and multiple-user
environments. Finally, results are presented that
demonstrate the benefits of incremental compilation in
VCS.
1. Introduction
1.1. What is incremental compilation?
VCS from Viewlogic Systems, Inc. is the industry
leader in Verilog simulation. The compiled code
simulation approach in VCS allows extremely fast
simulation. For a real life design, however, the compilation
time itself can be significant. When a user makes an
incremental change to an existing design, the compilation
time can be improved appreciably through the use of
incremental compilation techniques. This paper presents
an overview of incremental compilation in the VCS
environment, and provides insight into how to reap
maximum benefit from this feature.
Incremental compilation is a technique used to
determine which portions of a design, if any, need to be
re-compiled since the previous compilation run. VCS
generates C code, assembly code, or direct object code,
depending on the platform and user options. The
incremental compilation code supports all three generation
1. Viewlogic Systems, Inc. has merged with
Synopsys, Inc.
styles in making its re-compilation decision for each
Verilog module or user-defined primitive (UDP).
VCS also takes incremental compilation beyond its
traditional role in code-management tools such as
Makefiles and dependency checks. These tools simply
check for file modification times maintained by the
underlying operating system. In contrast, VCS's
Incremental Compilation ignores “insignificant” changes
to modules, and performs automatic inter-module
dependency analysis. The addition, deletion, or editing of
comments, white space, etc., when this does not affect the
tokenization of the source code, is a prime example of an
insignificant change. The inter-module dependencies
introduced in the design by module instantiations,
hierarchical references, and parameter change
specifications (‘defparam’) are automatically captured
by VCS. This dependency analysis is completely
transparent to the user. It thus obviates the need for
creating or editing any explicit dependency specification.
1.2. Why is incremental compilation needed?
Incremental compilation allows the user to take
advantage of the considerable simulation time speedup
offered by a compiled code simulator, without sacrificing
fast compilation turnaround times in a typical design
development/testing environment. By minimizing
run-to-run re-compilation time, incremental compilation
provides the user with the ability to make small changes to
a design, while guaranteeing that the re-compilation time
will be proportional to the change in the design.
VCS's Shared Incremental Compilation further
allows the user to “freeze” portions of the design, and treat
these as pre-compiled modules that will not need
re-compilation from run to run. For example, in a typical
system design environment a team of designers may work
on a shared set of ASIC’s. Each such ASIC can be
pre-compiled into a library directory. More than one
designer can share these pre-compiled ASIC’s, which
facilitates re-use of compiled code. Shared incremental
compilation also results in significant space savings for the
whole team, because it avoids replication of generated
code.
Figure 1 illustrates a typical design environment for
Shared Incremental Compilation.
 Incremental Compilation in the VCS Environment

Test Bench 1.1

Design 1 ASIC 1

Test Bench 1.2 ASIC 2

Test Bench 2.1 ASIC 3

Design 2
Test Bench 2.2 ASIC 4

TB1.1.v Design1.v ASIC1.v

module TB1_1; module D1; module asic1

... ... (in1,in2,out);
$monitor(D1.a1.x, // Children. ...
D1.a3.y); asic1 a1(p,q,r); // Declarations.
// Apply stimulus. asic3 #(5) a3(...); wire x;
... ... ...
endmodule // TB1_1 endmodule // D1 endmodule // asic1

Figure 1. Use Model of Shared Incremental Compilation.

2. Incremental compilation use models re-compilation is based on the contents of this single
2.1. Single-user environment directory.

VCS's Incremental Compilation is invoked by the

-M option, and is designed to be used both in single-user
and multi-user environments. The user’s working
directory is called ‘csrc’ by default. This default can
be over-ridden through the -Mdir command-line
option.
In a single-user environment, the user will typically
be working in a develop-test-debug-edit cycle. The
entire generated code is at one location, in the user's
csrc. The “history” of successive compilations is kept
track of in the csrc by incremental compilation. It
compares the history against the current design to make
its re-compilation decisions.
The code generated by VCS as well as the
incremental-specific data written out by incremental
compilation are placed in csrc. All analysis for
2.2. Multi-user environment
In a multi-user environment, different users will
share libraries of pre-generated code. These libraries
function as shared repositories, where pre-compiled
models have been frozen for common use by a team of
designers. The pre-generated code is distributed across
several independent directories. Each designer has
access to their own csrc and to the shared libraries.
The compilation history in a multi-user environment is
the sum total of compilation runs for each of the
libraries as well as for the current csrc. It consequently
requires more sophisticated analysis to determine the
modules which need re-compilation.
Let us consider a typical design environment for
shared incremental compilation, as illustrated in
Figure 1. Here, a set of four ASIC's have been
 Incremental Compilation in the VCS Environment
developed for use by a team of designers. The ASIC's
are used in two designs. Each design is tested
independently by a suite of test benches. The
pre-compiled code for the library modules gets
generated into the respective libraries through the
following command sequence:
$ vcs -Mdir=lib1 Asic1.v
$ vcs -Mdir=lib2 Asic2.v
$ vcs -Mdir=lib3 Asic3.v
$ vcs -Mdir=lib4 Asic4.v
The libraries can then be shared through
commands such as:
$ vcs -Mlib=lib1:lib2:lib3:lib4 \
Asic1.v Asic3.v Design1.v TB1.1.v
$ vcs -Mlib=lib1:lib2:lib3:lib4 \
Asic1.v Asic3.v Design1.v TB1.2.v
The -Mlib option tells VCS to look in the
colon-separated list of libraries for pre-compiled code.
In the first -Mlib command above, the code for the two
ASIC’s get picked up from lib1 and lib3
respectively. The other two libraries, though specified,
remain unused. The code for Design1.v and
TB1.1.v get compiled into csrc, since they are not
available in any of the libraries.
In the second -Mlib command, the code for
Design1.v is picked up from the current csrc,
where it was generated during the previous run. The
ASIC's are picked up from their appropriate libraries, as
before. The test bench TB1.2.v needs to be compiled,
because it was not compiled before. But none of the
other modules in the overall design need to be
re-compiled (except as necessitated by certain
inter-module dependencies -- see Section 3.2).
3. Approach
3.1. Architecture
As defined by the Verilog HDL, VCS treats each
Verilog module or UDP as an independent design unit,
with well-defined communication to other design units
through ports. The exception to this communication
scheme is when the design contains hierarchical
references from one module to another, which needs
special treatment. These inter-dependencies between the
modules in a design are detected and catalogued by
VCS.
Figure 2 gives an overview of the VCS
architecture, with focus on incremental compilation.
VCS first performs a preliminary compilation on the
Verilog source. Based on this, a Global Analysis (GA)
of the design is conducted to resolve inter-module
dependencies, and to perform global optimizations. At
the end of GA, the Incremental Compilation phase
analyzes incremental-specific data from the previous
run. First, relevant token changes in the Verilog source
are detected. Next, inter-module dependencies
(determined through GA) are used to propagate the
effect of the changes to other modules in the design
hierarchy. This results in exact determination of the
modules for which code needs to be re-generated in the
current run.
The three code generation styles (C code, assembly
code, and object code) are taken into account in making
re-compilation decisions. Incremental compilation then
issues directives to the code generator, to generate code
for the appropriate modules. No new code is generated
for modules that do not need re-compilation.
Incremental compilation also writes out new
incremental data, for use in subsequent runs.
Section 3.2 discusses the exact nature of
inter-module dependencies in Verilog HDL. The global
dependencies which simultaneously affect multiple
modules are described in Section 3.3.
 Incremental Compilation in the VCS Environment

Verilog Design Old Incremental Data

(from csrc and libraries)

Compilation

Global Analysis

Incremental
Compilation

Directives to
Code Generator

Code Generation

Generated Code (in csrc) New Incremental Data

and Executable (simv) (in csrc)

Figure 2. The Architecture of Incremental Compilation in VCS.

3.2. Inter-module dependencies named Verilog object can be referenced uniquely in

When a module is modified, it naturally gets
re-compiled. Certain changes to modules can also cause
other modules in the design to be re-compiled. The
following three types of inter-module interactions can
cause this:
1. Parent-child port relationships: A change in the port
specification can cause re-compilation of both the
parent and child modules. Such a change can be due
to addition/deletion of port definition or port connec-
tion, change in the type of the port (input/output/
inout), certain changes in the drivers/loads connected
to the ports, etc.
2. Hierarchical references: The IEEE Standard
describes hierarchical references as follows: “Any
its full form by concatenating the names of the mod-
ules, tasks, functions, or blocks that contain it.”
[LRM; p. 147]. Hierarchical references allows any
module in the design to refer to objects in other mod-
ules without having any explicit port connection for
them. Such objects include signals, parameters, tasks,
functions, etc. Because of their global reach, adding
or modifying hierarchical references can impact the
re-compilation decisions of modules that are seem-
ingly unrelated to the modified module. For example,
a new hierarchical reference in a module will cause
both the referer and referee modules to be re-com-
piled.
3. Module inlining: In certain situations, VCS performs
an optimization that inlines child instantiations into
 Incremental Compilation in the VCS Environment

the parent's body. This introduces a special type of
inter-module interaction that affects incremental
compilation. This optimization is transparent to the
user. But since such inlining alters the design hierar-
chy for code generation, re-compilation decisions for
an inlined child module affect those of the
non-inlined ancestor module.
3.3. Global dependencies
Several global dependencies also come into play
in influencing the re-compilation decisions of
incremental compilation.
1. Command-line options: Changes in command-line
options can result in changes to generated code. For
instance, global flags such as ‘+nospecify’ will
affect a whole suite of modules sharing the relevant
property (the occurrence of ‘specify’ blocks, in
this case).
2. Compiler directives: Altering a compiler directive
can affect the code generated for several modules. For
instance, changing the timescale/precision for the
design will affect all modules within the scope of that
change. Incremental compilation has to handle such
changes.
3. Platform dependence: VCS supports Verilog simula-
tion on many platforms (such SunOS, Solaris, HP,
NT, etc.). Moving between platforms will naturally
result in re-compilation of the entire design.
and to re-use the generated code for shared portions of
the design.
5. Future scope
Incremental compilation is an area of continuous
improvement in VCS. Enhancements are made to
handle evolving user requirements, and to support new
capabilities in VCS. We also identify design
methodologies that are able to take full advantage of
VCS's architecture.
For instance, if disk space is not a scarce resource,
it is possible to keep architecture-specific copies of
generated code around, and move back and forth
between architectures without the need to re-compile
the design from scratch. As another example, in the
-Mlib context, when an ASIC is used within multiple
test benches, the latter may make hierarchical references
into portions of the ASIC. These references serve to
either probe signals or to modify their values during
simulation. In this situation, one can introduce the
notion of an ASIC Shell, which will in effect provide a
one-module interface to all the test benches, for all of
their hierarchical references. The Shell “insulates” the
rest of the ASIC from the chain reaction in
re-compilation that is inherent to changes in hierarchical
references. Sometimes, existing designs can be modified
to replace hierarchical references with port references,
to provide similar benefits.

4. PLI/ACC/Debug specifications: VCS allows the PLI/

ACC capabilities of individual modules to be speci-
fied through a ‘.tab’ file. If these capabilities are
altered from run to run, this will necessitate re-com-
pilation of the concerned modules.

4. Performance results
The performance figures in Table 1 were obtained
from running an internal benchmark design.They
illustrate the speed-ups and space savings that can be
derived through the use of incremental compilation.
The design consists of 563 modules. It has 372337
lines of Verilog source (8.2 megabytes). The first VCS
run was a full compilation, which took 12 minutes and
19 seconds to compile. Subsequent runs involved
changes to a portion of the design. The table
demonstrates the significant savings in re-compilation
time through incremental compilation.
The use of Shared Incremental Compilation
augments these savings, by its ability to share modules
 Incremental Compilation in the VCS Environment

Table 1: Performance Figures

Number of modules in design: 563

(372K lines of Verilog; 8.2 MB)

VCS Run Modules Modules Compilation time Fraction of full

Number changed affected (MM:SS) compilation (%)

1 (563) (563) 12:19 100%

2 0 0 01:04 08.66%

3 5 7 02:12 17.86%

4 11 17 02:26 21.11%

5 177 295 10:29 85.12%

6. Summary References
VCS's approach to Incremental Compilation offers [LRM] “IEEE Standard Hardware Description Language
the user the advantages of minimal compilation time Based on the Verilog(R) Hardware Description Language”,
during design development while providing fast IEEE Standard 1364-1995.
simulation performance. VCS's Incremental [VCS] “VCS/VCSi & XVCS/XPOST, Version 4.0”, July,
Compilation has been fine-tuned to provide optimal 1997. Copyright, Viewlogic Systems, Inc.
performance for designs specified in Verilog HDL. Our
results quantify the impact of incremental compilation
in typical development scenarios, and demonstrate the
superiority of this approach in Verilog compiled code
simulation.

Acknowledgments
Several members of Viewlogic's engineering and
customer support teams have been instrumental in
testing and improving this capability, during its
development. We are grateful to one and all of them. We
would especially like to thank Eric Zhao, Raghu
Srigiriraju, and Riyaz Puthiyapurayil for their help with
the Incremental Compilation design and development.
Our special thanks go to Phil McGee for his help in
preparing the final draft of this paper.