Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > EDA/IP
?
?
EDA/IP??

Accelerate compile/verification under Synopsys VCS

Posted: 22 Dec 2015 ?? ?Print Version ?Bookmark and Share

Keywords:transistors? Synopsys? VCS? Verilog Compiler and Simulator? Pre-Compilation IP?

While the number of transistors on an average chip doubles every 18 months, the verification cycle has shortened from 18 to 12 months, and in the near future will become as low as six. 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 such as incremental compilers can no longer meet complex verification requirements. For verification, the compilation time can be methodically controlled using a tool developed by Synopsys, VCS (Verilog Compiler and Simulator) that uses 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, Behavioural 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 re-compilation. 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.

1???2?Next Page?Last Page



Article Comments - Accelerate compile/verification unde...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top