Speed compile/verification under Synopsys

VCS
Kerul ModiAkshay Shukla,Nishith Shukla, - September 09, 2015

At the same time as the number of transistors on your average chip doubles every 18 months, the
verification cycle has shrunk from 18 to 12 months, which in the near future will become as low as
six months. In verifying complex designs, the test-bench environment also tends to become bulky,
which means the simulator tool will require more time to compile and elaborate samples on the
design and test bench. Traditional tools like incremental compilers can no longer meet complex
verification requirements. For verification, the compilation time can be methodically controlled
using a very useful tool developed by Synopsys VCS (Verilog Compiler and Simulator) using the
Pre-Compilation IP (PIP) technique.
PIP Flow Overview
The PIP technique can be involved in the complete compilation flow of
the design and the test-bench rooted at the top level and can generate
a shared objects database needed for simulation.

The flow is divided mainly into two phases:

(i) Creation of shared compiled object(s) (like VIP, Behavioral models, RTL etc.)
(ii) Integration of all pre-compiled shared objects at test-bench top compilation/elaboration.
To achieve this, we need to follow a three-step compilation flow: vlogan -> vcs -> simv in given
mentioned order.
For generating shared compiled object(s) (shared_obj1, shared_obj2 as shown in Figure), -genip
command is acted upon at the time of elaboration, after which an object file is created for each
shared object. These object files are integrated with top test-bench modules by providing -integ
command at the time of elaboration, and for simv (executable file) generation.

Implementing PIP in Existing Environment

Implementing PIP in existing environments is easier said than done. Let us enumerate the
challenges one would face during implementation.
It is difficult to define multiple partitions from a developed test bench since it requires more effort
and time. Also the accuracy of modifications (in terms of functionality) needs to be assessed
thoroughly. Partitions can be created only on modules, packages and program blocks.
The syntax to obstruct reuse of module-based compiled objects should be clearly defined. One should
provide global timescale for each shared compiled object, as timescale changes cause recompilation. Shared defines among the partitions should be defined in common file.
Additionally defparam should be used at the top to update parameters of module/interface, which
leads to recompilation instead of reuse. In the same way, the bind should be used for binding module
in test-bench with other modules for re-compilation too.
The Compile time defines the impact of reusability of compiled object/snapshot in Single
Compilation Multiple Simulation flow. The Compile command separation is set between between
vlogan & vcs.
Guidelines for implementation
All shared compiled objects should be for modules, packages or program block. XMRs (Cross Module
References) are not supported within the package. It is recommended to probe RTL/ TOP signal in
test bench using System Verilog interface or UVM (Universal Verification Methodology)
Similarly one should use "-allxmr" option while creating compiled objects and use of XMRs of RTL or
other model(s) in test top is highly recommended. It is also important to have the same global
timescale for all compiled objects so that they can be reused for integration.
Usage of defparam and bind in test-case top leads to change in RTL, which obstructs the reuse
of compiled RTL objects. Similarly, use of "-pvalues" option is recommended for creating compiled
RTL objects to change parameters from test top. It is preferable to take instances of modules in top
and connect ports directly through XMRs instead of using bind.
The overall test-bench code should contain least possible compiler directives like `ifdef or`ifndef, as
compile time argument changes the code resulting in recompilation. To avail maximum advantage of
PIP, use simulation directive $test$plusargs or $value$plusargs instead of compiler directives.
For implementation of PIPs, one should maintain separate macro (`define) files for each shared
object. Accordingly, the test bench shall be based on System Verilog package and/or modules.
Its also important to avoid unnecessary wildcard importation of packages, as minor changes in the
package lead to recompilation of compiled objects in which the package is imported.
Analysis
Pre-compilation IP feature is implemented for the compilation of bulky multi-processor SoCs with
30+ IPs and their respective test bench environments including multiple VIPs, BFMs, RAL model
and sequence libraries. A total of four compiled shared objects are created (i.e. UVM, RTL, VIPs,
RAL model). According to the following analysis, the same test cases are run with both traditional
(i.e. Incremental Compilation) & Pre Compilation IP flow on same SoC with 3 scenarios for each

approach, to capture the resultant compilation time. The significant advantage in compilation time
clearly demonstrates huge reduction in overall regression.

Scenario 1 : (First Run): Running test case for the 1st time with complete database & pre-compiled
package ready.
Scenario 2 : (Re-running the same test with no change): Running same test case with simv
(executable file) already present at run area with no modification in test-bench and RTL.
Scenario 3 : (Re-running the same test with modification/updates): Running same test case with
simv (executable file) already present at run area with modification/update/changes in test-bench
and/or RTL.

Benefits
In a typical SoC verification environment, many reusable components including methodology
packages, VIPs, memory models, behavioral models and similar ones are used. For verification
engineers, RTL is left unchanged for a particular time-cycle and is common for the entire verification
team.
By having more shared object(s) in a verification environment, PIP flow provides the following
benefits:

Reduced compile turnaround time in running a test-case

Reduced disk space usage

Conclusion
Shared compile objects (like RTL, UVM, VIPs) need to be compiled only once. Hence for one test
case, it is required to compile only the project-specific environment, which reduces the overall
compilation time and disk space usage. Preplanning of the implementation can reap the advantages
of PIP flow, with the help of sub-partitions of test-bench components. It also provides relatively more
debugging time by reducing compile turn-around time, and there is more gain in regression run-time

and reduction in disk space usage with the implementation.

The authors are with eInfochips.
Also see:

VCS commands ease coverage efforts & speed simulation