You are on page 1of 598

VCS® MX

User Guide
VCS MX X-2005.06
August 2005

Comments?
E-mail your comments about Synopsys
documentation to sim_supt@synopsys.com
Copyright Notice and Proprietary Information
Copyright © 2004 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary
information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and
may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may
be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise,
without prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.
Right to Copy Documentation
The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only.
Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must
assign sequential numbers to all copies. These copies shall contain the following legend on the cover page:
“This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of
__________________________________________ and its employees. This is copy number __________.”

Destination Control Statement


All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the reader’s responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

Registered Trademarks, Trademarks, and Service Marks


of Synopsys, Inc.
Registered Trademarks (®)
Synopsys, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, CoCentric, COSSAP, CSim, DelayMill,
DesignPower, DesignSource, DesignWare, Eaglei, EPIC, Formality, in-Sync, LEDA, ModelAccess, ModelTools,
PathBlazer, PathMill, PowerArc, PowerMill, PrimeTime, RailMill, RapidScript, SmartLogic, SNUG, Solv-It, SolvNet,
Stream Driven Simulator, Superlog, System Compiler, TestBench Manager, TetraMAX, TimeMill, VCS, and VERA are
registered trademarks of Synopsys, Inc.
Trademarks (™)
BCView, Behavioral Compiler, BOA, BRT, Cedar, ClockTree Compiler, DC Expert, DC Expert Plus, DC Professional,
DC Ultra, DC Ultra Plus, Design Advisor, Design Analyzer, Design Compiler, DesignTime, DFT Compiler SoCBIST, Direct
RTL, Direct Silicon Access, DW8051, DWPCI, ECL Compiler, ECO Compiler, ExpressModel, Floorplan Manager,
FormalVera, FoundryModel, FPGA Compiler II, FPGA Express, Frame Compiler, HDL Advisor, HDL Compiler, Integrator,
Interactive Waveform Viewer, JVXtreme, Liberty, Library Compiler, ModelSource, Module Compiler, MS-3200, MS-3400,
NanoSim, OpenVera, Physical Compiler, Power Compiler, PowerCODE, PowerGate, ProFPGA, Protocol Compiler,
RoadRunner, Route Compiler, RTL Analyzer, Schematic Compiler, Scirocco, Scirocco-i, Shadow Debugger,
SmartLicense, SmartModel Library, Source-Level Design, SWIFT, Synopsys EagleV, Test Compiler, TestGen, TetraMAX
TenX, TimeTracker, Timing Annotator, Trace-On-Demand, TymeWare, , VCS Express, VCSi, VHDL Compiler, VHDL
System Simulator, VirSim, and VMC are trademarks of Synopsys, Inc.
Service Marks (SM)
DesignSphere, SVP Café, and TAP-in are service marks of Synopsys, Inc.

SystemCTM is a trademark of Open SystemC Initiative and is used under license. All other product or company names
may be trademarks of their respective owners.

Printed in the U.S.A

Document Order Number: 36543-000 SB


VCS MX User Guide, X-2005.06

ii
Contents

About This Manual


Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Related Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
SolvNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii

1. Overview
What VCS MX Supports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Setting up VCS MX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Setting Up Your Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Creating the Setup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Global Setup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Library Name Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Using VCS MX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Analyzing Your Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

i
Compiling Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Simulating Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10

2. VCS MX Reference Flows


Mixed-HDL Simulation Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
RTL/Behavioral Level Simulation. . . . . . . . . . . . . . . . . . . . . . . . 2-4
Gate-Level Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
VHDL-Only Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
Verilog-Only Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
VHDL-Top Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Verilog-Top Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14

3. Instantiating Verilog or VHDL in Your Design


Instantiating a Verilog Design in a VHDL Design . . . . . . . . . . . . . . 3-2
Signed and Unsigned Type Support . . . . . . . . . . . . . . . . . . . . . 3-4
Mapping Verilog Parameters to VHDL Generics . . . . . . . . . . . . 3-6
Generic Path Service for MX at Elaboration Time . . . . . . . . . . . 3-7
Mapping Verilog Ports to VHDL Ports . . . . . . . . . . . . . . . . . . . . 3-8
Instantiating a Verilog Module with Parameterized Ports. . . . . . 3-8
Using a Configuration Specification to Resolve Verilog
Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Names and Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Using Extended Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
Module Header Port List Restrictions . . . . . . . . . . . . . . . . . . . . 3-11

ii
Instantiating a VHDL Design within a Verilog Design . . . . . . . . . . . 3-12
Instantiating By Entity Name . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Instantiating By Configuration Name . . . . . . . . . . . . . . . . . . . . . 3-14
Passing Parameter Values to VHDL Generics. . . . . . . . . . . . . . 3-15
Connecting Verilog Signals to VHDL Ports . . . . . . . . . . . . . . . . 3-16
Instantiating A VHDL Design Entity with a
Variable Port Width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
Instantiating a Signed or Unsigned VHDL Design Entity . . . 3-18
Binding the Instance to a Specific VHDL Design Unit . . . . . . . . 3-20
Instantiating Verilog in a VHDL Design within Verilog . . . . . . . . 3-21
Editing The Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21

4. Analyzing Your Design


Introduction to Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Creating a Design Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Analyzing The VHDL Portion Of A Design . . . . . . . . . . . . . . . . . . . 4-3
Using vhdlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Maintaining VHDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Creating a Dependency List File . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Using simdepends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Invoking simdepends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
simdepends Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9
Reanalyzing VHDL Source Files . . . . . . . . . . . . . . . . . . . . . 4-11
Determining Analyzer Options . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Invoking simcompiled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
simcompiled Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
simcompiled Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14

iii
Common vhdlan Analysis Options . . . . . . . . . . . . . . . . . . . . . . . . . 4-15
Analyzing for Simulation Technology . . . . . . . . . . . . . . . . . . . . . 4-15
Modifying Compiled Event Simulation Analysis . . . . . . . . . . . . . 4-17
Optimizing Compiled Code. . . . . . . . . . . . . . . . . . . . . . . . . . 4-17
Passing Options to the C Compiler . . . . . . . . . . . . . . . . . . . 4-18
Specifying a Design Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-19
Checking Synthesis Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
Creating a List File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
Analyzing for Functional VITAL Simulation Mode . . . . . . . . . . . 4-26
Smart Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-28
Using Smart Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29
Analyzing The Verilog Portion Of A Design . . . . . . . . . . . . . . . . . . . 4-29
Understanding Library Directories and Library
Files in Specifying Verilog Source Files . . . . . . . . . . . . . . . . 4-30
Using vlogan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32
Resolving References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36

5. Compiling and Elaborating Your Design


Understanding the VCS MX Compilation Process . . . . . . . . . . . . . 5-2
Using the scs Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Common scs Compilation Options. . . . . . . . . . . . . . . . . . . . . . . 5-4
Compiling for Simulation Mode . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Event-Driven Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5
Mixed Event and Cycle-based Simulation . . . . . . . . . . . . . . 5-6
Full Cycle-based Simulation. . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Creating a Partition File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Modifying Cycle Simulation Compilation . . . . . . . . . . . . . . . . . . 5-16

iv
Compiling for 2-State Simulation . . . . . . . . . . . . . . . . . . . . . 5-17
Compiling for Performance or Debugging . . . . . . . . . . . . . . 5-18
Selecting a C Compiler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21
Passing Options to the C Compiler . . . . . . . . . . . . . . . . . . . 5-21
Generating Static Elaboration Reports . . . . . . . . . . . . . . . . . 5-22
Overriding Generics Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22
Changing the Generic Parameter Default Value . . . . . . . . . 5-23
Assigning Generic Values from a Command File. . . . . . . . . 5-23
Creating Multiple Simulation Executables . . . . . . . . . . . . . . . . . 5-26
Setting Time Base and Time Resolution . . . . . . . . . . . . . . . . . . 5-27
Using Time Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
Event + Cycle + Verilog Elaboration . . . . . . . . . . . . . . . . . . . . . 5-32
Static Cycle Elaboration Reports . . . . . . . . . . . . . . . . . . . . . . . . 5-33
Reading Summary Information. . . . . . . . . . . . . . . . . . . . . . . 5-34
Reading Triggers Information . . . . . . . . . . . . . . . . . . . . . . . . 5-38
Reading Perf_data Information . . . . . . . . . . . . . . . . . . . . . . 5-42
Examples of Various Trigger Types . . . . . . . . . . . . . . . . . . . 5-45
Sensitivity List Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-47
Using the vcs Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-50
Specifying The VHDL Logical Library . . . . . . . . . . . . . . . . . . . . 5-52
Using a Partition File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-54
Compiling To Use VirSim Interactively . . . . . . . . . . . . . . . . . . . . 5-58
Common Verilog Compilation Tasks . . . . . . . . . . . . . . . . . . . . . 5-59
Save and Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-59
Save and Restart File I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-61
Save and Restart with Runtime Options . . . . . . . . . . . . . . . 5-62
Restarting at The CLI Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . 5-63
Specifying A Very Long Time Before Stopping Simulation. . . . . 5-64

v
Passing Values From The Runtime Command Line . . . . . . . . . 5-66
Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-67
Profiling the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-68
The Top Level View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-68
The Module View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-69
The Instance View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-71
The Module to Construct Mapping View . . . . . . . . . . . . . . . 5-72
The Top Level Construct View . . . . . . . . . . . . . . . . . . . . . . . 5-75
The Construct View Across Design . . . . . . . . . . . . . . . . . . . 5-75
How VCS Prevents Time 0 Race Conditions . . . . . . . . . . . . . . . 5-76
Compiling and Elaborating Verilog in a Mixed-HDL Design. . . . 5-78
Resolving References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-79

6. VCS MX Flow Examples


VHDL-Top Mixed Language Flow Example. . . . . . . . . . . . . . . . . . . 6-2
Design Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
Setup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Analyze. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Elaboration/Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7
Verilog-Top Mixed Language Flow Example . . . . . . . . . . . . . . . . . . 6-8
Design Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Setup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
Analyze. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
Elaboration/Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
VCS MX Flows at a Glance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11

vi
7. Simulating Your Design
Running and Controlling a Simulation Using the scsim Executable 7-2
Invoking a Simulation at the Command Line . . . . . . . . . . . . . . . 7-2
Invoking a Simulation From the VCS MX GUI . . . . . . . . . . . . . . 7-3
Common scsim Simulation Options . . . . . . . . . . . . . . . . . . . . . . 7-4
Functional VITAL Simulation . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Switching a Simulation to Full Debug Mode. . . . . . . . . . . . . 7-7
Profiling the Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
Simulating with SDF Backannotation . . . . . . . . . . . . . . . . . . 7-8
License Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Relaxing VHDL LRM Conformance Checking . . . . . . . . . . . 7-11
Using the VCS MX Control Lanaguage Commands . . . . . . . . . 7-12
Running the Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
Interrupting the Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
Restarting the Simulator. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
Quitting the Simulator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15
Reading Simulation Profiler Results . . . . . . . . . . . . . . . . . . . . . 7-15
Simulation Phases Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
Event-based Processes Table . . . . . . . . . . . . . . . . . . . . . . . 7-20
Cycle-based Trigger and Testbench Processes Table . . . . . 7-22
Cycle-based Combinational Processes Table . . . . . . . . . . . 7-25
Comparing Simulation Results. . . . . . . . . . . . . . . . . . . . . . . . . . 7-28
Event Mode Simulation Profile Report . . . . . . . . . . . . . . . . . 7-29
Invoking the Graphical User Interface. . . . . . . . . . . . . . . . . . . . 7-38
Starting VirSim GUI for Interactive Simulation . . . . . . . . . . . 7-39
Starting the VirSim GUI for Post-Processing. . . . . . . . . . . . 7-39
Starting the GUI with the Project Browser Window . . . . . . . 7-40
The scirocco Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-40

vii
Running and Controlling a Simulation Using the simv Executable . 7-41
Running a Mixed-HDL Simulation . . . . . . . . . . . . . . . . . . . . . . . 7-42
Common simv Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . 7-43
Common simv Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-58
Saving and Restarting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-59
Saving and Restarting File I/O . . . . . . . . . . . . . . . . . . . . . . . 7-61
Saving and Restarting with Runtime Options. . . . . . . . . . . . 7-62
Restarting at The CLI Prompt. . . . . . . . . . . . . . . . . . . . . . . . 7-63
Specifying A Very Long Time Before Stopping Simulation . . 7-64
Passing Values From the Runtime Command Line . . . . . . . 7-66
Improving Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-67
Profiling the Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-68
How VCS Prevents Time 0 Race Conditions . . . . . . . . . . . . . . . 7-76
Making a Verilog Model Protected and Portable . . . . . . . . . . . . 7-77
Re-Invoking a Simulation With VirSim . . . . . . . . . . . . . . . . . . . . 7-78
Using Interactive Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . 7-79
Special Rules For Interactive Commands . . . . . . . . . . . . . . 7-80
CLI Changes Caused By The TCL Shell Environment. . . . . 7-81
Switching Command Languages . . . . . . . . . . . . . . . . . . . . . 7-82
Hierarchical Name Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 7-83

8. Debugging and Post-Processing


Interactive Debugging Using the Command Line . . . . . . . . . . . . . . 8-2
Changing Between Command Languages . . . . . . . . . . . . . . . . 8-2
Hierarchical Name Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
After Changing to VCS MX Verilog CLI . . . . . . . . . . . . . . . . . . . 8-4
Interactive Simulation using the GUI . . . . . . . . . . . . . . . . . . . . . . . . 8-6

viii
Post-Processing for VHDL-Only and VHDL-Top Flows . . . . . . . . . . 8-7
VPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7
Delta Dumping Supported in VPD Files . . . . . . . . . . . . . . . . 8-8
eVCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
Line Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Delta Cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Viewing the Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Post-Processing for Verilog-Only and Verilog-Top Flows . . . . . . . . 8-10
Generating EVCD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
VCS MX VHDL Timebase and Time Precision Resolution. . . . . . . 8-11
Cross Module Referencing Between Verilog Hierarchies . . . . . . . . 8-12
Mixed Language XMRs ($hdl_xmr) . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
Verilog Referencing VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
VHDL Referencing Verilog or VHDL . . . . . . . . . . . . . . . . . . . . . 8-14
Comparing VCS CLI and VCS MX VHDL SCL Commands . . . . . . 8-15

9. Discovery Visual Environment


Primary DVE Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Top Level Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-2
Source Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-6
Assertion Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
Wave Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
List Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11
Schematic Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12

ix
10. Using OpenVera Assertions
Introducing OpenVera Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2
Built-in Test Facilities and Functions . . . . . . . . . . . . . . . . . . . . . 10-3
Creating a Temporal Assertion File . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Compiling Temporal Assertions Files . . . . . . . . . . . . . . . . . . . . . . . 10-6
OVA Runtime Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
Using OVA with VHDL-Only and Mixed-HDL Designs . . . . . . . . . . 10-9
Viewing OVA Simulation Results. . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11
Viewing Results with the Report File . . . . . . . . . . . . . . . . . . . . . 10-12
Viewing Results with Functional Coverage . . . . . . . . . . . . . . . . 10-13
Inlining OVA in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-19
Specifying Pragmas in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20
Methods for Inlining OVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-21
Unit Instantiation Using the Unit-Based Checker Library . . . 10-23
Instantiating Context-Independent Full Custom OVA . . . . . . 10-24
Template Instantiation Using the Template-Based
Checker Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-26
Inlining Context-Dependent Full Custom OVA . . . . . . . . . . . 10-28
General Inlined OVA Coding Guidelines . . . . . . . . . . . . . . . . . . 10-29

11. Using SystemVerilog Assertions


Using SVA in a VHDL-Top Design. . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Using SVA in a Verilog-Top Design . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Using the $hdl_xmr System Task . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5

x
Using Standard SVA Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6

12. Using the VCS MX / SystemC Co-Simulation Interface


Usage Scenario Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Supported Port Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Verilog/VHDL Modules and SystemC Leaf Modules in a
Verilog Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Input Files Required. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7
Generating the Wrapper for SystemC Modules . . . . . . . . . . . . 12-8
Instantiating the Wrapper and Coding Style. . . . . . . . . . . . . . . . 12-11
Controlling Time Scale and Resolution in a
SystemC Module Contained in a Verilog Design . . . . . . . . . 12-13
Analyzing Other MX Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14
Compiling a Verilog Design Containing MX and
SystemC Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14
Using GNU Compilers on Sun Solaris . . . . . . . . . . . . . . . . . 12-15
Using GNU Compilers on Linux . . . . . . . . . . . . . . . . . . . . . . 12-16
Compiling on HPUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16
Verilog and VHDL Modules in a SystemC Design. . . . . . . . . . . . . . 12-16
Input Files Required. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17
Generating the Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-18
Generating the Wrapper for Verilog Modules . . . . . . . . . . . . 12-18
Instantiating the Wrapper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-22
Analyzing Other MX Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 12-24
Compiling a SystemC Design Containing MX modules . . . . . . . 12-24
Specifying Run-Time Options to the SystemC Simulation . . . . . 12-25
Using GNU Compilers on SUN Solaris . . . . . . . . . . . . . . . . 12-26

xi
Using GNU Compilers on Linux . . . . . . . . . . . . . . . . . . . . . . 12-27
Compiling on HPUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-27
Verilog/VHDL Modules and SystemC Leaf Modules in a
VHDL Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-27
Required Input Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-27
Generating the Wrapper for SystemC Modules . . . . . . . . . . . . . 12-28
Instantiating the Wrapper and Coding Style. . . . . . . . . . . . . . . . 12-29
Analyzing Other MX Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 12-30
Compiling a VHDL Design Containing MX and
SystemC Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-31
Using GNU Compilers on SUN Solaris . . . . . . . . . . . . . . . . . . . 12-31
Using GNU Compilers on Linux . . . . . . . . . . . . . . . . . . . . . . 12-32
Compiling on HPUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-32
Using a Port Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-32
Using a Data Type Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-35
Debugging a Mixed Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-36
Using the Built-in SystemC Simulator . . . . . . . . . . . . . . . . . . . . . . . 12-38
Using a Customized SystemC Installation. . . . . . . . . . . . . . . . . . . . 12-39

13. Using Synopsys Models


SmartModel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
Before You Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
Setting Up the Environment for SmartModels . . . . . . . . . . . . . . 13-3
Setting the Environment Variables . . . . . . . . . . . . . . . . . . . . 13-3
Creating the SmartModel VHDL Library. . . . . . . . . . . . . . . . 13-4
Modifying the SmartModel Library Name Mapping . . . . . . . 13-10

xii
Using SmartModels in VHDL Source Files . . . . . . . . . . . . . . . . 13-11
Specifying the SmartModel Library. . . . . . . . . . . . . . . . . . . . 13-12
Instantiating SmartModel Components . . . . . . . . . . . . . . . . 13-12
SmartModel Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-13
Using VCS MX Commands on Windows . . . . . . . . . . . . . . . 13-14
SmartModel Window Example . . . . . . . . . . . . . . . . . . . . . . . 13-15
SmartModel Window Precautions . . . . . . . . . . . . . . . . . . . . 13-18
Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-18
Modifying the Timing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-19
LM-Family Hardware Modeler Interface . . . . . . . . . . . . . . . . . . . . . 13-19
Before You Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-20
Interface Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-20
Documentation for Operating the Modeler . . . . . . . . . . . . . . 13-21
Logic Types Requirement. . . . . . . . . . . . . . . . . . . . . . . . . . . 13-23
LM-Family Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-23
Setting up the Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-24
Creating VHDL Model Support Files . . . . . . . . . . . . . . . . . . . . . 13-25
Entity Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-25
Architecture Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-33
Model Package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-34
Input Stimulus and Component Instantiation . . . . . . . . . . . . 13-36
Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-37
Modifying LM-Family Shell Software Files . . . . . . . . . . . . . . . . . 13-38
Shell Software File Restrictions . . . . . . . . . . . . . . . . . . . . . . 13-40
Analyzing and Linking the Design . . . . . . . . . . . . . . . . . . . . . . . 13-50
Compiling the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-50
Simulating the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-51
$LMSI Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-51

xiii
Simulator and LM-Family Modeler Interaction . . . . . . . . . . . . . . 13-51
Initialization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-52
Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-53
Evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-53
Release of Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-54
Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-54
LM-Family Modeler Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-56
VHDL Model Support Files. . . . . . . . . . . . . . . . . . . . . . . . . . 13-58
Entity and Architecture Declarations . . . . . . . . . . . . . . . . . . 13-59
LM-Family Shell Software Files . . . . . . . . . . . . . . . . . . . . . . 13-72
Verifying the Modeler Connection and Shell Software . . . . . 13-73
Analyzing the VHDL Support Files . . . . . . . . . . . . . . . . . . . . 13-75
Compiling the MC68020 Logic Model . . . . . . . . . . . . . . . . . 13-75
Simulating the MC68020 Logic Model . . . . . . . . . . . . . . . . . 13-76

Appendix A. Backannotating with SDF Files


Specifying the SDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Invoking with scsim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3
SDF Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3
Invoking with the Simulator include Command . . . . . . . . . . . . . A-5
SDF Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-5
Examining SDF Header Information . . . . . . . . . . . . . . . . . . . . . . . . A-7
Matching SDF Timing Parameters to VHDL Generics . . . . . . . . . . A-8
Understanding Naming Conventions . . . . . . . . . . . . . . . . . . . . . A-8
Changing the Naming Convention . . . . . . . . . . . . . . . . . . . . . . . A-10
Understanding the DEVICE Construct . . . . . . . . . . . . . . . . . . . . . . A-11
Handling Backannotation to I/O Ports . . . . . . . . . . . . . . . . . . . . . . . A-13

xiv
Using the INTERCONNECT Construct . . . . . . . . . . . . . . . . . . . A-14
Multiple Backannotations to Same Delay Site. . . . . . . . . . . . . . . . . A-14
Annotating Single Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-17
Back-Annotation Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-18
Ignored SDF Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-19
Back-Annotating Structural Library Cells . . . . . . . . . . . . . . . . . . . . . A-20
SDF Back-Annotation for Gate-Level Timing Simulation. . . . . . . . . A-22

Appendix B. Using VITAL Models and Netlists


Validating and Optimizing a VITAL Model . . . . . . . . . . . . . . . . . . . . B-2
Validating the Model for VITAL Conformance . . . . . . . . . . . . . . B-2
Verifying the Model for Functionality . . . . . . . . . . . . . . . . . . . . . B-2
Optimizing the Model for Performance and Capacity . . . . . . . . B-3
Re-Verifying the Model for Functionality . . . . . . . . . . . . . . . . . . B-5
Understanding Error and Warning Messages . . . . . . . . . . . . . . B-5
Distributing a VITAL Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-6
Simulating a VITAL Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7
Applying Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7
Overriding Generic Parameter Values . . . . . . . . . . . . . . . . . . . . B-7
Understanding VCS MX Error Messages . . . . . . . . . . . . . . . . . B-9
System Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-9
Model and Netlist Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . B-9
Viewing VITAL Subprograms . . . . . . . . . . . . . . . . . . . . . . . . . . . B-10
Timing Back-annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-10
VCS MX Naming Styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-11

xv
Negative Constraints Calculation (NCC) . . . . . . . . . . . . . . . . . . B-11
Understanding VITAL Timing Delays and Error Messages . . . . . . . B-13
SDF Back-Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-13
Mixed Versions of SDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . B-14
Naming Styles for Delay Generics . . . . . . . . . . . . . . . . . . . . B-14
DEVICE Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-15
Multiple SDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16
SDF Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-17
SDF Port Names Not Checked . . . . . . . . . . . . . . . . . . . . . . B-17
Back-Annotation at Elaboration Time . . . . . . . . . . . . . . . . . . B-17
Negative Constraint Calculation (NCC) . . . . . . . . . . . . . . . . . . . . . . B-18
Conformance Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-18
Type Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-18
Syntactic and Semantic Checks . . . . . . . . . . . . . . . . . . . . . . . . B-20
Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-21

Appendix C. SAIF Support


Using SAIF files with VCS MX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1
SAIF Calls that can be Used on Verilog or Verilog-Top Designs . . . C-2
SAIF Calls that can be Used on VHDL or VHDL-Top Designs . . . . C-5
Typical Flow to Dump the Backward SAIF File in a Verilog or
Verilog-Top Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-6
Criteria for Choosing Signals for SAIF Dumping . . . . . . . . . . . . . . . C-8
TCL File for MTI Users to Convert Existing SAIF UI Commands . . C-9

xvi
Appendix D. Using VCS MX ESI Adapter
Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-2
Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-3
Setting Up to Run Specman with VCS MX . . . . . . . . . . . . . . . . D-3
VHDL Only Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-5
VHDL-Top Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-6
MX Flow When e Code Accesses Only VHDL . . . . . . . . . . . D-6
MX Flow When e Code Accesses Both VHDL and Verilog . D-7
Verilog-Top Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-10
MX Flow When e Code Accesses Only Verilog . . . . . . . . . . D-10
MX Flow When e Code Accesses Both Verilog and VHDL . D-11
Displaying Specman Elite Objects in VCS MX
VirSim Waveform Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-12
Using Specman Elite with Waveform Viewers . . . . . . . . . . . . . . D-13
Using Specman Elite with the VirSim Waveform Viewer . . . . . . D-14
Setting up the VirSim Waveform Viewer . . . . . . . . . . . . . . . D-14
Invoking Specman Elite with the VirSim Viewer . . . . . . . . . . D-16
Adding a Specman Elite Object to the VirSim Viewer . . . . . D-18
Using Specman Elite with VirSim Waveform Viewer Examples. D-19
Mixed HDL Design with Verilog-Top Testbench Example. . . D-19
Mixed HDL Design with VHDL-Top Testbench . . . . . . . . . . . D-25

Appendix E. Using Extended SystemVerilog Datatypes on MX Boundary


Integer Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-2
Enummerated Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-4
Structures/ Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-6

xvii
Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-7

Index

xviii
About This Manual

This manual contains basic concepts, commands, and usage


information about the VCS MX simulator.

This chapter includes the following sections:

• Audience
• Related Manuals
• SolvNet
• Customer Support
• Conventions

xvii
Audience

This manual is for Synopsys RTL simulation users who want to use
fast functional verification at the RT level.

Users of this manual must be familiar with ASIC design, high-level


design methods, IEEE Standard VHDL1076-1993, and the UNIX
operating system.

Related Manuals

For additional information about VCS MX, see the online


documentation, which is included with the software at

<installation_directory>/doc/online/sim/sc_home.pdf

or Documentation on the Web, which is available through SolvNet on


the Synopsys Web page at

http://www.synopsys.com

The following manuals contain related information about VCS MX:

• VCS MX Reference Guide


A manual that provides reference information for VCS MX, and is
intended to be used in conjunction with the VCS MX User Guide.
• VCS MX Quick Reference
A small booklet that helps you locate reference information quickly
and easily. It contains a summary of the VCS MX invocation and
control commands, and the VirSim GUI commands.

xviii
• VCS / VCX MX Coverage Metrics User Guide
A manual that describes how VCS and VCS MX can monitor and
evaluate the coverage metrics of Verilog, VHDL, and mixed HDL
designs during simulation to determine which portions of the
design have not been tested. The results of the analysis are
reported in a number of ways that allow you to see the
shortcomings in your testbench and improve the tests to obtain
complete coverage.
• VHDL Simulation Coding and Modeling Style Guide
A style guide that contains rules and guidelines for coding your
RTL design.
• VCS MX C Language Interface Reference Guide
A manual that describes the C language interface of VCS MX.
The interface lets you interact, control, and communicate with the
simulation environment and pass information to and from the
internal data structures of the simulator.

• VCSTM/VCSiTM User Guide


A manual that describes how to use the VCS Verilog simulator.
• VirSim Reference Manual
A manual that contains detailed information about the VirSim
graphical user interface. This manual is available from the Help
menu in the main VirSim window.

SolvNet

SolvNet is the Synopsys electronic knowledge base. It contains


information about Synopsys and its tools and is updated daily. You
can access SolvNet through e-mail or through the World Wide Web.

For information about SolvNet, send an e-mail message to

xix
solvitfb@synopsys.com

or go to the Synopsys web page at

http://www.synopsys.com

xx
Customer Support

If you have problems, questions, or suggestions, contact the


Synopsys Technical Support Center in one of the following ways:

• Send e-mail to
support_center@synopsys.com

• Call (800) 245-8005 from within the continental United States or


call (650) 584-4200 from outside the continental United States,
from 7:00 a.m. to 5:30 p.m. Pacific time, Monday through Friday.
• Send a fax to (650) 584-2539.

xxi
Conventions

The following conventions are used in Synopsys documentation.

Convention Description
courier Indicates command syntax.
In command syntax and examples, shows
system prompts, text from files, error
messages, and reports printed by the
system.
courier italic Indicates a user specification, such as
object_name
courier bold In command syntax and examples, indicates
user input (text the user types verbatim).
[ ] Denotes optional parameters, such as pin1
[pin2, . . pinN]
| Indicates a choice among alternatives, such
as
low | medium | high

This example indicates that you can enter


one of three possible values for an option:
low, medium, or high.
_ Connects two terms that are read as a single
term by the system. For example,
design_space.
(Control-c) Indicates a keyboard combination, such as
holding down the Control key and pressing c.
\ Indicates a continuation of a command line.
/ Indicates levels of directory structure.
Edit > Copy Shows a menu selection. Edit is the menu
name and Copy is the item on the menu.

xxii
1
Overview 1
VCS MX enables you to analyze, compile, and simulate Verilog,
VHDL, and mixed-HDL design descriptions, and provides a set of
simulation and debugging features to validate your design. These
features provide capabilities for source-level debugging and
simulation result viewing. VCS MX supports all levels of design
descriptions, but is optimized for the behavioral and register transfer
levels.

VCS MX accelerates complete system verification by delivering the


fastest and highest capacity Verilog, VHDL, and Mixed-HDL
simulation for RTL functional verification. The unique technology of
VCS MX leverages cycle-based techniques with the flexibility of
event-driven simulation to deliver its best performance for designs
optimized for synthesis. The seamless support for mixed language
simulation of VCS MX provides a high performance solution to your
IP integration problems and gate level simulation.

Getting Started
1-1
In addition, VCS MX supports various Synopsys models and tools,
like Synopsys DesignWare Models (SmartModels and LM-family
hardware Modeler), DesignWare Foundation Library, VMC and
VhMC Models, Telecom Workbench Models, MemPro Models, and
VERA Testbench tool.

VCS MX is also integrated with other third-party tools via VHPI (for
VHDL), PLI (for Verilog), and C language interface for VCS MX. The
integration efforts include: testbench tools, memory models
generation tools, acceleration and emulation systems, graphical user
interfaces, and code coverage.

This chapter covers the following topics:

• What VCS MX Supports


• Setting up VCS MX
• Using VCS MX

What VCS MX Supports

VCS MX provides fully featured implementations of the following:

• The Verilog language as defined in the IEEE Standard Hardware


Description Language Based on the Verilog Hardware
Description Language (IEEE Std 1364-1995) and the Standard
Verilog Hardware Description Language (IEEE Std 1364-2001).
• The VHDL Language as defined in the Standard VHDL Hardware
Description Language (IEEE VHDL 1076-1993).
• The SystemVerilog 3.1a language (with some exceptions) as
defined in SystemVerilog 3.1a Accellera’s Extensions to Verilog.

Getting Started
1-2
Setting up VCS MX

You must perfom the following tasks to set up your VCS MX


environment. These tasks need to be performed only once.

• Setting Up Your Environment


• Creating the Setup File

Setting Up Your Environment

This section explains how to set up your VCS MX environment,


including setting your VCS_HOME environment variable, your path to
the simulation executables, and your VCS MX license environment.

To set up your environment, do the following:

1. Set your VCS_HOME environment variable by entering the


following at the command line:
% setenv VCS_HOME VCS_MX_installation_directory

2. Set the path to your simulation executables by entering the


following:
% setenv PATH .:${VCS_HOME}/bin:${PATH}

3. Set your VCS MX license environment by entering the following:


% setenv SNPSLMD_LICENSE_FILE Location_of_License_File
Note: A single VCS MX license (under Synopsys’ Common Licensing
Program) enables you to run Verilog-only, VHDL-only, or mixed-
HDL simulations.

Getting Started
1-3
For additional information on environment variables, see “VCS MX
Environment Variables” in Chapter 2 in the VCS MX Reference Guide.

Creating the Setup File

VCS MX uses several setup files named SYNOPSYS_SIM.SETUP to


set up and configure its environment for VHDL and mixed-HDL
designs. These files map VHDL design library names to specific host
directories, set search paths, and assign values to simulation control
variables.

When you invoke VCS MX, it looks for the SYNOPSYS_SIM.SETUP


files in the following three directories:

• Master setup directory


The SYNOPSYS_SIM.SETUP file in the /bin directory of the VCS
MX installation directory contains default settings for your entire
installation. VCS MX reads this file first.

• Your home directory


VCS MX reads the setup file in your home directory second, if
present. The settings in this file override those in the master setup
directory.

• Your design directory


VCS MX reads the setup file in your design directory last. The
settings in this file override all others. You can use this file to
customize the environment for a particular design. This is the
directory you invoke and run VCS MX from; it is not the directory
where you store or generate your design files.

Getting Started
1-4
Use the show_setup command to check the values assigned to the
setup variables after VCS MX reads all the SYNOPSYS_SIM.SETUP
files.

The following is a sample SYNOPSYS_SIM.SETUP file:

--VCS MX setup file for ASIC


--Mapping default work directory
WORK > work
work : ./work
--Mapping package directories
STATS_PKG : ./stat_work
MEM_PKG : ./mem_work
--Simulation variables
TIMEBASE = ps
CS_ASSERT_STOP_NEXT_WAIT = TRUE
USE = . ./SRC ./SRC/COMMON_PACKAGES \
./SRC/DSP_PKG /SCRATCH/TEMP
The key components of the setup file are the name mappings in the
design libraries, and the variable assignments. These are discussed
in more detail in the following sections.

The following rules pertain to setup files:

• Blank lines are ignored.


• Physical directory names are case-sensitive.
• All commented lines begin with two dashes (--).
• The backslash character (\) is used for line continuation.

Getting Started
1-5
Global Setup File
You can also specify a global setup file to define VCS MX setup
variables. To do this, specify the file you want to use as the global
setup file in the environment variable SYNOPSYS_SIM_SETUP. This
global setup file may have any name, and doesn't have to be
SYNOPSYS_SIM.SETUP or SYNOPSYS_VSS.SETUP. This file takes
precedence over any regular setup file in the current directory, home
directory, or installation directory, and is also searched during
simulation, with the same restrictions as a setup file in the current
directory. If the file name you specify in the SYNOPSYS_SIM_SETUP
variable cannot be opened, VCS MX issues an error message.

Also, within a setup file, a line of the following form may exist:

OTHERS = <filename>

This includes and processes the named file. No environment


substitution is done on this file. If the file cannot be opened, VCS MX
issues an error message and stops, as the simulation may not run
correctly.

Files included in this manner can be nested, with a limit of 8 levels of


nesting.

Library Name Mapping


To use a VHDL design library with VCS MX, you must first map the
VHDL identifier that designates the design library name (logical
name) to the location of the library in the UNIX file system (physical
name). You specify this mapping in the SYNOPSYS_SIM.SETUP file.

Getting Started
1-6
For greater flexibility in library naming, VCS MX provides two-stage
mapping. You can first map the design library (logical name) to an
intermediate name. You can then map the intermediate name to the
physical name (a UNIX path name). This feature allows you to select
different design units by simply changing the logical-to-intermediate
mapping. The syntax is as follows:

logical_name > intermediate_name


intermediate_name : physical_name

For example, consider a case where you want to select between an


8-bit or a 16-bit ALU. You can pre-analyze the VHDL file for each
component into a different physical directory. Then, by changing the
mapping in the SYNOPSYS_SIM.SETUP file, you can choose which
component you want to include in your design. As the following
example illustrates, the design library (logical name) mapping uses
the 8-bit adder instead of the 16-bit adder. The logical-to-intermediate
name mapping is optional. If you specify only an intermediate-to-
physical mapping, VCS MX assumes that the design library (logical)
and intermediate names are identical.

ALU > ALU8


ALU8 : ./alu_8bit
ALU16 : ./alu_16bit

The VCS MX built-in standard libraries have the following default


name mappings:

IEEE : $VCS_HOME/$ARCH/packages/IEEE/lib
SYNOPSYS : $VCS_HOME/$ARCH/packages/synopsys/lib

In these default mappings, $ARCH is either sparcOS5, hpux10, or


linux.

Getting Started
1-7
Use these built-in libraries in your design, whenever possible, to get
maximum performance from the simulator.

Using VCS MX

This section provides an overview of the basic tasks you will need to
do to run VCS MX. The following tasks are covered:

• Analyzing Your Design


• Compiling Your Design
• Simulating Your Design
Note: For information on coverage features, see the VCS /VCS MX
Coverage Metrics User Guide.

Analyzing Your Design

If your design contains VHDL source code, it will need to be analyzed


using the vhdlan utility. This process analyzes VHDL source files,
produces intermediate files for elaboration, and saves these files into
a library directory.

If your VHDL design instantiates a Verilog design within it, you will
need to use the vlogan command.

For details on how to analyze your design, see “Analyzing Your


Design” in Chapter 4.

Getting Started
1-8
Compiling Your Design

The compilation phase compiles your source code into a single


simulation executable. Depending on the components of your design,
there are two different methods you can use for compilation:

• If you are running a simulation containing only VHDL code


(referred to throughout this manual as a "VHDL-only" simulation)
or a mixed-HDL simulation by instantiating Verilog code with
VHDL (referred to throughout this manual as "VHDL-top"), you
will use the scs command to compile your design. The scs
command elaborates your design, performs code generation, C
compilation, and static linking of all objects to generate an
executable binary file (called scsim) for running the simulation.
For a detailed description of how to instantiate Verilog into VHDL,
see the “Instantiating Verilog in a VHDL Design within Verilog” on
page 3-21.
• If you are running a simulation containing only Verilog code
(referred to throughout this manual as "Verilog-only") or a mixed-
HDL simulation by instantiating VHDL code within Verilog
(referred to throughout this manual as "Verilog-top"), you will use
the vcs command to compile your design and create a simulation
executable named simv. The vcs command compiles your code
on a module by module basis, which enables incremental
compilation. For a detailed description of how to instantiate VHDL
into Verilog, see “Instantiating a VHDL Design within a Verilog
Design” on page 3-12.
For details on the various options you can run at the command line
during compilation, see “Compilation Options” in Chapter 4 of the
VCS MX Reference Guide.

Getting Started
1-9
Simulating Your Design

In the simulation phase, at the command line you enter the simulation
executable produced by the complilation phase:

• For VHDL-only or VHDL-top: scsim


• For Verilog-only or Verilog-top: simv.
You can also add various simulation run-time options. For details,
see “Simulation Executables and Options” in Chapter 5 of the VCS
MX Reference Guide.

For details on simulating your design, see “Simulating Your Design”


in Chapter 7.

Discovery Visual Environment (DVE) software is a graphical


verification environment that supports debugging for VCS MX
simulations. DVE allows you to work in post-processing and
interactive mode. We would encourage you to use DVE as a default
GUI for debugging, to view simulations and more. For more details
on DVE, see “Discovery Visual Environment” in Chapter 9

Getting Started
1-10
2
VCS MX Reference Flows 1
Depending on the contents of your design, VCS MX offers a variety
of simulation flows. This section covers the following topics:

• Mixed-HDL Simulation Basics


• VHDL-Only Flow Overview
• Verilog-Only Flow Overview
• VHDL-Top Flow Overview
• Verilog-Top Flow Overview

VCS MX Reference Flows


2-1
Mixed-HDL Simulation Basics

The VCS MX engine can simulate mixed language designs from


within the VCS MX environment, while retaining all existing VHDL
and Verilog tool links and flows.

This section provides a brief overview of the basic flows you can use
in VCS MX, along with information on RTL/Bbehaviorial simulation,
gate-level simulation, and general restrictions.

Figure 2-1 shows a typical VCS MX setup for mixed-HDL simulation.

Figure 2-1 VCS MX Mixed Language Simulation

Mixed Language
Common User Interface and
Debugging Environment

VHDL
Verilog
Verilog VHDL Source
Source
Simulation Simulation
Engine Engine

PLI, Swift, VhPLI, Swift,


and SDF and Cycle

VCS MX Reference Flows


2-2
In general, you can use the following flows for performing to perform
simulations in VCS MX:

• "VHDL-Only" Flow
In this flow, you use a VHDL testbench and VHDL source code.
You will analyze your design using the vhdlan utility, compile
your design using the scs executable, and simulate your design
using the scsim executable. This flow is referred to throughout
this manual as the "VHDL-only" flow. For more information on this
flow, see “VHDL-Only Flow Overview” on page 2-6.

• "Verilog-Only" Flow
In this flow, you use a Verilog testbench and Verilog source code.
You will compile your design using the vcs executable, and
simulate your design using the simv executable. This flow is
referred to throughout this manual as the "Verilog-Oonly" flow.
For more information, see “Verilog-Only Flow Overview” on
page 2-9.

• "VHDL-Top" Flow
In this flow, you use a VHDL testbench, with your VHDL and
Verilog code instantiated in lower levels of hierarchy. You analyze
your VHDL code using the vhdlan utility and your Verilog code
using the vlogan utility, compile your code using the scs
executable and -mhdl command line option, and simulate your
design using the scsim executable. This flow is referred to
throughout this manual as the "VHDL-Ttop" flow. For more
information on this flow, see “VHDL-Top Flow Overview” on
page 2-11.

VCS MX Reference Flows


2-3
• "Verilog-Top" Flow
In this flow, you use a Verilog testbench, with your Verilog and
VHDL code instantiated in lower levels of hierarchy. You analyze
the VHDL portion of your code using the using the vhdlan utility
and the Verilog portion of your design (if itsit is instantiated within
VHDL) using the vlogan utility, compile your code using the vcs
executable and -mhdl command line option, and simulate your
design using the simv executable. This flow is referred to
throughout this manual as the "Verilog-Ttop" flow. For more
information on this flow, see “Verilog-Top Flow Overview” on
page 2-14.

Note:Note that i In VCS MX, the simulation environments needed for


mixed language simulation are the same as those used for Verilog
and VHDL are needed for mixed language simulation. This
eliminates the need for learning a new environment, and you do
not need to generate, modify, compile/analyze, or maintain
additional shells. Instantiation of Verilog design units in VHDL,
and vice versa is seamless.

RTL/Behavioral Level Simulation

In all VCS MX flows, the VHDL and Verilog portions parts of your
designs can be behavioral, RTL, or a mix of both. Both VHDL and
Verilog code can run in event mode, cycle mode, or mixed event and
cycle mode. You can specify various optimizations and code-
generation switches for both VHDL and Verilog portions parts of the
design.

VCS MX Reference Flows


2-4
Performance is improved improves when you use VCS MX RTL event
and cycle simulation for the VHDL part of the design portion and RTL
simulation capabilities for the Verilog part of the design portions. The
VHDL portion part can be run in event mode or mixed event and cycle
mode, depending on how much of itportion is cycle compliant. For
more information on s cycle simulation, see “Compiling and
Elaborating Your Design” in Chapter 5.

Gate-Level Simulation

For VHDL gate-level simulation, VCS MX supports VHDL netlist


simulation using VHDL initiative toward ASIC libraries (VITAL).
However, there is always a performance penalty when using using
VITAL, either (with or without Standard Delay Format (SDF) DF back-
annotation). So, in order to obtain the highest performance, it is
recommended you you should use a VHDL testbench and Verilog
netlist when peforming mixed language simulation. Full timing
simulation with SDF back-annotation is supported for Verilog netlist.

The following section describes the basics of VCS MX simulator for


users who might not be are not familiar with the either simulator
engine.

Restrictions

In the Verilog-only and Verilog-top flows, the following restrictions


apply:
• VCS MX does not cannot handle 64-bit compilation and 64-32 bit
cross-compilation.

VCS MX Reference Flows


2-5
• The Debussy interface only works interactively only on the Verilog
part of the design,. but However, Debussy supports post
processing with fsdb files in both the Verilog and VHDL parts of
the design using the latest Debussy release.
• There are limitations on the data types of the ports and generics
in the top-level VHDL design entity that you instantiate into the
Verilog design,. For details, see See “Instantiating a VHDL Design
within a Verilog Design” in Chapter 3.
• You can’t use the VirSim Logic Browser or Event Origin feature
in the VHDL part of the design.
• You can generate profile reports for both the Verilog and VHDL
parts of the design during the same simulation, generating two
separate reports. However, VCS MX writes the : one report for
the Verilog part written by VCS MX in text format, and the
otherreport for the VHDL part, written by VCS MX in HTML format.
• PLI applications only work only with the Verilog part of a mixed
HDL design.

VHDL-Only Flow Overview

This section explains the VCS MX verification flow that applies if your
design contains only VHDL code.

The basic steps for performing a VHDL-only simulation are as follows:

1. Set up your environment. For details, see “Setting Up Your


Environment” on page 1-3.
2. Create the setup file for VHDL simulation. For details, see
“Creating the Setup File” on page 1-4

VCS MX Reference Flows


2-6
3. Analyze your design. For details, see “Analyzing Your Design” in
Chapter 4.
4. Compile and Eelaborate the entire design. For details, see
“Compiling and Elaborating Your Design” in Chapter 5.
5. Simulate the design. For details, see “Simulating Your Design” in
Chapter 7.
6. Use DVE or VirSim to control and view simulation events
interactively during simulation, or post-process the results using
the simulation history file. Post-process the results using DVE or
VirSim. You can also use DVE or VirSim interactively
See Figure 2-2 below for a VHDL-only flow chart.

VCS MX Reference Flows


2-7
Figure 2-2 Basic "VHDL-only" Analysis, Compilation, and Simulation Flow

Prepare Setup File


Setup
File

Instantiation

VHDL
Code

Analysis
%vhdlan [options] filename_list

Analyzer

Compilation
% scs config

Elaboration, Compilation,
and Code Generation

Interactive
Simulation &
Debugging
% scsim
Command Line
Simulation Interface

DVE
or
Post-Processing VirSim
& Debugging VCS/VPD
Files

VCS MX Reference Flows


2-8
Verilog-Only Flow Overview

This section explains the VCS MX verification flow if your design


contains only Verilog code.

The basic steps for performing a Verilog-only simulation are as


follows:

1. Set up your environment. For details, see “Setting Up Your


Environment” on page 1-3.
2. Compile your design. For details, see “Compiling and Elaborating
Your Design” in Chapter 5.
3. Simulate your design. For details, see “Simulating Your Design”
in Chapter 7.
4. Post-process the results using DVE or VirSim.
See Figure 2-3 below for a Verilog-only simulation flow chart.

VCS MX Reference Flows


2-9
Figure 2-3 Basic Verilog-only Compilation and Simulation Flow

Verilog
Code
(mem.v, cpu.v)

% vcs mem.v cpu.v

Compilation

Interactive Debugging

% simv
Command Line
Interface
Simulation

DVE
or
VirSim

Post-Processing/ VCD/VPD
Debugging Files

VCS MX Reference Flows


2-10
VHDL-Top Flow Overview

This section explains the VCS MX verification flow that applies if your
design contains mixed-HDL code with Verilog code instantiated within
VHDL code. You can, in turn, instantiate a VHDL design in the
instantiated Verilog design.

This flow generates a VCD+ simulation history file that enables you
to use DVE or VirSim after simulation to view the simulation results
from of both the VHDL and Verilog parts of the design. You can also
use DVE or VirSim to interactively simulate and debug this flow.

The basic steps in the VHDL-top flow are as follows:

1. Set up your environment. For details, see “Setting Up Your


Environment” on page 1-3.
2. Create the setup file for VHDL simulation. For details, see
“Creating the Setup File” on page 1-4.
3. Instantiate the Verilog modules in the VHDL design using
component declarations and component instantiations. For
details, see “Instantiating a Verilog Design in a VHDL Design” on
page 3-2.
4. Analyze Verilog and VHDL modules and design units. This
includes including their dependencies. See “Analyzing Your
Design” in Chapter 4 for information on running vhdlan to
analyze your VHDL code.
5. Compile and Eelaborate the entire design using the scs
command and -mhdl flag. For details, see “Compiling and
Elaborating Your Design” in Chapter 5.

VCS MX Reference Flows


2-11
6. Simulate the design using the simv executable. For details, see
“Simulating Your Design” in Chapter 7.
7. Use DVE or VirSim to control and view simulation events
interactively during simulation, or post-process the results using
the simulation history file. Post-process the results using DVE or
VirSim. You can also use DVE or VirSim interactively.
See Figure 2-4 below for a graphic that explains the VHDL-top
simulation flow chartflow.

VCS MX Reference Flows


2-12
Figure 2-4 Basic "VHDL-Top" Compilation and Simulation Flow

Prepare Setup File


Setup
File
Instantiation

VHDL Verilog
VHDL Code Code
Code
Instantiate Verilog
Analysis inside VHDL
%vlogan verilog_source_file
%vhdlan (options) filename_list
Analyzer

% scs -mhdl config

Elaboration, Compilation,
and Code Generation

Interactive
Simulation &
Debugging
% scsim
Command Line
Simulation Interface

DVE
or
Post-Processing VirSim
& Debugging VCS/VPD
Files

VCS MX Reference Flows


2-13
Verilog-Top Flow Overview

This section explains the VCS MX verification flow that applies if your
design contains mixed-HDL code with VHDL code instantiated within
Verilog code. You can, in turn, instantiate a Verilog design in the
instantiated VHDL design.

This flow generates a VCD+ simulation history file that enables you
to use DVE or VirSim after simulation to view the simulation results
of from both the VHDL and Verilog parts of the design. You can also
use DVE or VirSim to interactively simulate and debug this flow.

The steps in the Verilog-top flow are as follows:

1. Set up your environment. For details, see “Setting Up Your


Environment” on page 1-3.
2. Create the setup file for VHDL simulation, see “Creating the Setup
File” on page 1-4.
3. Analyze the VHDL code in the VHDL design that you need to
instantiate in a Verilog design using the vhdlan utility, and
analyze Verilog code instantiated within VHDL using the vlogan
utility. This includes the dependencies. See “Analyzing Your
Design” in Chapter 4 for information on running vhdlan to
analyze your VHDL code.
4. Instantiate the VHDL design entity into a Verilog module definition.
This is done with using a module instantiation statement.
5. If you need it, iInstantiate a Verilog module into a VHDL
architecture if you need to do so. This is done with You can do
this using a component declaration and component instantiation
statement.

VCS MX Reference Flows


2-14
6. Compile the Verilog part of the design, and compile and elaborate
the VHDL part of the design, using the vcs command line and
-mhdl option. For details, see “Compiling and Elaborating Your
Design” in Chapter 5.
7. Run the simulation using a simv command line (see “Simulating
Your Design” in Chapter 7). Steps 6 and 7 can be combined into
a single step with the -R or -RI option.
8. Use DVE or VirSim to control and view simulation events
interactively during simulation, or post-process the results using
the simulation history file. Post-process the results using DVE or
VirSim. You can also use DVE or VirSim interactively.
See Figure 2-5 below for a graphic that explains the flow. for a graphic
that explains the Verilog-Top simulation flow chartflow.

VCS MX Reference Flows


2-15
Figure 2-5 Basic "Verilog-Top" Compilation and Simulation Flow

Instantiation
Verilog
Code VHDL Verilog
Code Code

Instantiate VHDL
Analysis inside Verilog
% vlogan

% vhdlan
Analyzer

% vcs -mhdl

Compilation

Interactive
Simulation &
Debugging
% simv
Command Line
Simulate Interface

DVE
or
Post-Processing VirSim
& Debugging VCS/VPD
Files

VCS MX Reference Flows


2-16
3
Instantiating Verilog or VHDL in Your
Design 2
This chapter describes the following instantiation processes:

• Instantiating a Verilog Design in a VHDL Design


• Instantiating a VHDL Design within a Verilog Design
Note that both of these processes are closely connected to the
analysis process described “Analyzing Your Design” in Chapter 3.
The analysis and instantiation processes overlap in many situations
discussed in the chapter.

Instantiating Verilog or VHDL in Your Design


3-1
Instantiating a Verilog Design in a VHDL Design

You can instantiate a module of a Verilog design into a VHDL design


the same way you instantiate a VHDL component — by using a
component declaration and a component instantiation statement.

Although the port order in the component declaration can be the same
or different than the port declaration order in the corresponding
Verilog module definition, it is highly recommended that you keep it
the same.

Parameters in Verilog modules can be declared as VHDL generics


in corresponding VHDL component declaration (this is suggested but
it is not a required). You can pass actual values to those generics
during actual component instantiation. In case of no mapping, default
values will be used for simulation.

You can use the following data types to specify ports in the component
declaration:

• bit
• std_logic
• std_ulogic
• bit_vector
• std_logic_vector
• std_ulogic_vector
• std_logic_arith
• boolean

Instantiating Verilog or VHDL in Your Design


3-2
• buffer
buffer type is actually supported only when a Verilog module
instanciates a VHDL component.

• User-defined types and subtypes, as long as the basic type of the


element type is in std_nlogic bit and boolean.
• Unconstrained vector VHDL port.
• Function call at VHDL port size expression.
• VHDL signed/unsigned to Verilog wire signed.
You can use vector data types for vector ports in the Verilog module.
VCS MX includes built-in data type conversion for these VHDL data
types to Verilog data types.

In addition, you can instantiate a Verilog module having port of type


signed can be instantiated in a VHDL design unit (architecture). See
“Signed and Unsigned Type Support” on page 2-4.

If the module definition contains parameter declarations, the


corresponding component declaration specifies generics that match
the parameter names as shown in the next example.

Example 3-1 shows a Verilog module definition that can be


instantiated in a VHDL design.

Example 3-1 Verilog Module Definition


module vlogtop(topin,topout);
parameter topdelparam=6;
input topin;
output [7:0] topout;
vlogbot #(topdelparam) vlogbot1(topin,topout);
.
.

Instantiating Verilog or VHDL in Your Design


3-3
.
endmodule

Example 3-2 shows the VHDL component declaration that you use
to instantiate the Verilog module.

Example 3-2 Corresponding VHDL Component Declaration


component vlogtop
generic (topdelparam : integer := 6);
port (topin : in STD_LOGIC;
topout : out STD_LOGIC_VECTOR (7 downto 0));
end component;

After declaring this component, you enter a component instantiation


statement, for example

vlogtopinst1 : vlogtop generic map (7) port map (a,b);

If the Verilog design unit contains parameters, declare them as


generics for corresponding component declaration. Actual mapping
for those generics is optional in instantiation.

Signed and Unsigned Type Support

Mixed-HDL simulation supports signed and unsigned types at the MX


boundary without restriction. This means you can you can instantiate
a Verilog module containing a port of type signed into a VHDL design
unit (architecture). While Verilog does not have any explicit unsigned
types, all wire types are effectively unsigned. VHDL explicitly supports
signed and unsigned types.

Example 3-3 shows a Verilog adder module with signed and unsigned
types followed by the part of the VHDL testbench design instantiating
the Verilog module.

Instantiating Verilog or VHDL in Your Design


3-4
Example 3-3 Instantiating Verilog Signed and Unsigned Types into VHDL
Verilog module:
`timescale 1 ns/ 1ns

module VL_FULL_ADD4(a, b, cin, sum);


input signed [3:0] a;
input [3:0] b;
input cin;
output signed [3:0] sum;

assign sum = a + b + cin;


endmodule

VHDL testbench:

LIBRARY ieee;
USE STD.textio.all;
USE IEEE.STD_LOGIC_TEXTIO.all;
USE ieee.std_logic_1164.all;
use IEEE.std_logic_arith.all;

entity tb is
end tb;

architecture tb_a of tb is

signal A : signed(3 downto 0) := (others => '0');


signal B : unsigned(3 downto 0) := (others => '0');
signal SUM : signed(3 downto 0) := (others => 'Z');
signal cin : std_logic := '0';

component VL_FULL_ADD4
port ( a : in signed(3 downto 0);
b : in unsigned(3 downto 0);
cin : in STD_LOGIC;
sum : out signed(3 downto 0));
end component;

Instantiating Verilog or VHDL in Your Design


3-5
begin

inst1 : vl_full_add4 port map(a, b, cin, sum);

process
begin
wait for 1 ns;
A <= "0001";
wait for 1 ns;
B <= "0011";
.
.
.
end;

Mapping Verilog Parameters to VHDL Generics

The generics specified in the component declaration must match the


parameter names in the module definition. Also the default value of
the generics is the same as that in the Verilog parameter declaration.

In Example 3-1, parameter topdelparam has a value of 6.


Accordingly, the generic specification in Example 3-2 is for a generic
named topdelparam and its default value is 6.

Verilog parameters do not have data types, however, their values


must be constant integer, real number, or string value constants.
Therefore, you must use the integer, real, or string generic types in
the corresponding generic specifications.

Verilog parameter definitions can also be expressions with other


parameters as operands. However, VHDL prohibits the
corresponding practice, using a generic as the default value in
another generic in the same declarative region. Therefore, you must
resolve this expression in the corresponding generic specification.

Instantiating Verilog or VHDL in Your Design


3-6
Table 3-1 Verilog Parameter Definitions and Their Corresponding
VHDL Generic Specifications in Component Declarations
Verilog Parameter Definition VHDL Generic Specification
parameter p1 = 5 + 7; p1 : integer := 5 + 7;
parameter p2 = 5.5 p2 : real := 5.5;
parameter p3 = "init"; p3 : string := "init";
parameter p4 = p1 + p2; p4: real := 17.5;

Generic Path Service for MX at Elaboration Time

You can assign generics at any layer in a design through the


command line. For example:

e (VHDL)
-->uut (VHDL)
-->convert (VHDL instance of Verilog implementation)
-->z_1 (Verilog instance at VHDL implementation
for z_1)

You can specify the value of generic g1 as shown below. Note that
the VHDL portion of the hierarchy is case insensitive, while the Verilog
portion (module, instances) is case sensitive.

assign 1 /e/uut/convert/z_1/G1(valid)
assign 1 /e/uut/convert/z_1/g1(valid)
assign 1 /E/Uut/Convert/z_1/g1(valid)
assign 1 /e/uut/convert/Z_1/g1(Invalid because Verilog
instance z_1 is case
sensitive.)

Instantiating Verilog or VHDL in Your Design


3-7
Mapping Verilog Ports to VHDL Ports

The port names in the VHDL component declaration must match the
port names in the Verilog module definition.

The mode or direction of the in, out, or inout ports in the VHDL
component declaration must match the type of input, output, or inout
port declaration in the Verilog module definition.

The size or bit-width and the bit values used to specify the bit-width,
of the ports in the VHDL component declaration must match the bit-
width and bit values in the port declarations in the Verilog module
definition.

In Example 3-1, port topin is a scalar input port and in Example 3-2,
port topin is also a scalar port of mode in with a scalar data type. In
Example 3-1, port topout is an eight bit vector output port with the bits
numbered from 7 to 0 and in Example 3-2, port topout is also an eight
bit vector port of mode out with the bits numbered from 7 downto 0.

In Example 3-2 port topin has the STD_LOGIC data type because
this is a valid data type for converting values from VHDL to Verilog
and port topin is a scalar port. Also in Example 3-2 port topout has
the STD_LOGIC_VECTOR data type because this also is a valid data
type for converting values from Verilog to VHDL and port topout is a
vector port.

Instantiating a Verilog Module with Parameterized Ports

In Verilog, a port can be parameterized so that its bit-width is specified


using a parameter. This allows you to use parameter passing into an
instance of the module for the bit-width that enables a port to have
different bit-widths in different instances of the same module.

Instantiating Verilog or VHDL in Your Design


3-8
Example 3-4 shows a module definition with a parameterized port.

Example 3-4 Verilog Module With A Parameterized Port


module dev (inport, outport);
parameter portsize = 1;
input inport;
output [portsize + 1 : 0] outport;
.
.
.
endmodule

To instantiate a module with a parameterized port, use a generic in


the component declaration that corresponds to the parameter in the
module definition. This generic must have the integer data type or a
subtype with data type integer. Example 3-5 shows such a
component declaration.

Example 3-5 Component Declaration for a Module With a


Parameterized Port
component dev
generic (portsize : integer := 1);
port (inport : in std_logic;
outport : out std_logic_vector
((portsize + 1) downto 0));
end component

You can then use the generic map in the component instantiation
statement to pass a new value to the generic and thus a new size to
the port.

Instantiating Verilog or VHDL in Your Design


3-9
Using a Configuration Specification to Resolve Verilog
Instances

You can bind the instances of Verilog designs within configuration.


The correct syntax is:

for instance_label : component_name


use entity library.Verilog_Module_indentifier;
end for;

Specifying “configuration” instead of “entity” is not allowed. Also,


since the Verilog design does not have any architecture, there is no
need to specify any architecture along with entity.

For example,

for vlogtopinst1 : vlogtop


use entity LIB.vlogtop;
end for;

You can also assign a value from a Verilog instance to a generic


using a VHDL path in a command file.

Names and Identifiers

The names (formally called identifiers) of design objects such as


components, entities, architectures, ports, or signals are not case
sensitive in VHDL but they are in Verilog. For this reason, in the
Verilog module that you instantiate in the VHDL design, the names
of Verilog modules, ports, and parameters must be unique without
regard to case, unless you use extended identifiers.

Instantiating Verilog or VHDL in Your Design


3-10
For example, in Verilog you can specify the following two input port
names: in1 and IN1, but not in VHDL. Therefore, you must change
one of the port names if the port is in the top-level module of the
Verilog design that you are instantiating in your VHDL design. You
cannot use VHDL keywords as the names of modules, ports, or
parameters in the top-level module, unless you use extended
identifiers.

You must follow the rules for VHDL identifiers in the names of
modules, ports, or parameters in the top-level module. Valid VHDL
identifiers consist of upper or lower case letters, numbers, and the
underscore, the first character must be a letter, and the last character
cannot be the underscore character (_), unless you use extended
identifiers.

Using Extended Identifiers

You can use extended identifiers (similar to Verilog escaped


identifiers) to fulfill the rules for VHDL identifiers, for example,

• You can specify ports \in1\ and \IN1\ in the component declaration.
• You can specify an entity named \component\.
• You can begin a name with a number and end with an underscore,
such as an architecture named \1comparch_\.

Module Header Port List Restrictions

The port list in the module header for the instantiated module cannot
contain either of the following:

• Unconnected ports

Instantiating Verilog or VHDL in Your Design


3-11
• Jumpered ports
An unconnected port is an empty space between commas in the port
connection list, for example,

module vlogtop (portia, , portib);

A jumpered port is a port that appears more than once in the port list,
for example,

module vlogtop (portia, portia);

Instantiating a VHDL Design within a Verilog Design

You can instantiate the top-level design entity (entity and architecture)
of a VHDL design within a Verilog design the same way that you
instantiate a Verilog module: with a module instantiation statement.

In the module instantiation statement you can specify the following:

• The entity name of the top level design entity, see Example 3-1
and Example 3-2.

You don’t specify the architecture when you specify the entity.
During elaboration, the scs compiler uses the most recently
compiled architecture for the entity. VCS MX’s VHDL elaboration
happens when you compile the Verilog part of the design.
• The configuration name of the configuration that specifies the
entity and architecture of the top-level design entity, see
Example 3-3 and Example 3-4.

Instantiating Verilog or VHDL in Your Design


3-12
Note:
The ports declared in the top-level entity are limited to the following
data types:

- The built-in bit and boolean data types


- The IEEE std_logic, std_logic_vector, std_ulogic and
std_ulogic_vector data types
- The IEEE std_logic_arith and numeric_bit defining signed and
unsigned types
The generics in the top-level entity are limited to the integer,
real, string, bit, boolean and time generic data types.

Instantiating By Entity Name

Example 3-1 shows a top-level VHDL entity and architecture to be


instantiated in a Verilog design.

Example 3-1 Top-Level VHDL Design Entity


entity vhdltop is
generic (p1 : integer := 10;
INSTNAME : string := "I1");
port ( a : in bit;
b : out bit);
end vhdltop;

architecture vhdltoparch of vhdltop is


begin
b <= a after p1 * 1 ns;
.
.
.
end vhdltoparch;

Example 3-2 shows the Verilog module instantiation statement to


instantiate the top-level design entity in Example 3-1.

Instantiating Verilog or VHDL in Your Design


3-13
Example 3-2 The Verilog Module Instantiation Statement For The Entity
vhdltop #(15,"myInst") vhdltopinst (rega,wireb);

In Example 3-2 the module identifier vhdltop matched the entity name
of the top-level entity in Example 3-1 and the parameter passing
assignment part passes new values, the integer 15 and the string
“myInst”, to the generics in Example 3-1. Verilog reg rega and wire
wireb attach to the VHDL ports a and b.

Instantiating By Configuration Name

Example 3-3 Configuration For The Top-Level VHDL Design Entity


configuration vhdltop_cfg of vhdltop is
for vhdltoparch
.
.
.
end for;
end configuration;

This configuration is for the entity and architecture in Example 3-1.


Example 3-4 shows the Verilog module instantiation statement to
instantiate this configuration.

Example 3-4 The Verilog Module Instantiation Statement For The


Configuration
vhdltop_cfg #(15,"myInst") vhdltopinst (rega,wireb);

Similar to Example 3-2, in Example 3-4 the module identifier


vhdltop_cfg matched the name of the configuration in Example 3-3.
VCS instantiates the design entity specified by this configuration.

Instantiating Verilog or VHDL in Your Design


3-14
Just like Example 3-2 the parameter passing assignment part passes
new values, the integer 15 and the string “myInst”, to the generics in
Example 3-1 and Verilog reg rega and wire wireb attach to the VHDL
ports a and b in Example 3-1 because in Example 3-3 is a
configuration for the entity and architecture in Example 3-1.

Passing Parameter Values to VHDL Generics

The parameter passing assignment part of the module instantiation


statement, is the part that resembles a delay specification and is
between module identifier and the instance name. It is in this part of
the statement that you can pass new values to the VHDL generics in
the top-level VHDL entity. You pass new values to these generics in
the order in which they are declared in that entity. Passing new values
to these generics is, of course, optional.

You can use a name-based parameter passing to pass a value to a


generic but you must also include the +v2k compile-time option that
enables name-based parameter passing. Example 3-5 shows a valid
name-based parameter passing assignment part.

Example 3-5 A Valid Parameter Passing Assignment Part


vhdltop #(.instname("myInst")) vhdltopinst (rega,wireb);

The top-level entity can have generics of type real, integer,


string, bit, boolean, and TIME.

Pass an integer to bit and boolean generics. A 0 (zero) value is a 0


value to a bit generic and a false value to a boolean generic. Any
other value is a 1 value to a bit generic or a true value to a boolean
generic.

Instantiating Verilog or VHDL in Your Design


3-15
Pass a Verilog string to a TIME generic. The TIME type has both a
value and a unit so include both in the string, for example:

vhdltop #(.myTIME("10 ns")) vhdltopinst (rega,wireb);

You can use integer and real generic types to pass delay values to
the VHDL design. The VHDL design multiplies the integer or real
value with a time value. In Example 3-1 generic p1, of the integer type
with the default value of 10, is used as delay value for a concurrent
signal assignment statement. In the parameter passing assignment
part of the module instantiation statement in Example 3-2, a new
value of 15 is passed to generic p1.

IMPORTANT:
You cannot use a Verilog defparam statement to pass
values to a VHDL generic.

Connecting Verilog Signals to VHDL Ports

You can use name-based or order-based syntax for connecting


signals to the instance of the VHDL design entity. If you used the
order-based syntax, you list the signals that connect to the ports in
the VHDL top-level entity in the order that the ports are declared in
the entity just like you would do to instantiate a Verilog module using
an order based connection list.

If you used the name-based syntax you can connect the Verilog
signals to the VHDL ports in any order.

Example 3-6 shows valid order based and name based connection
lists.

Instantiating Verilog or VHDL in Your Design


3-16
Example 3-6 Valid Order Based and Name Based Connection Lists
vhdltop #(15,"myInst") vhdltopinst (rega,wireb);
vhdltop #(15,"myInst") vhdltopinst
(.pb(wireb),.pa(rega));

In the second, name-based, connection list in Example 3-6, the VHDL


ports are not listed in the order they are declared in the VHDL entity
(although they could also be validly listed in that order).

VHDL isn’t case sensitive so the following name based connection


list would also work:

vhdltop #(15,"myInst") vhdltopinst


(.PB(wireb),.Pa(rega));

Instantiating A VHDL Design Entity with a Variable Port


Width
In VHDL, a port can be of variable width in which its size is specified
using a generic. Doing so enables the VHDL designer to pass a size
to the port in the generic map of a component instantiation statement.
This technique enables a port to have different widths in different
instances of the component. Example 3-7 shows an entity declaration
with a port with a variable width.

Example 3-7 A VHDL Entity With A Variable Port Width


entity dev is
generic (size : integer := 4);
port (inport : in std_logic;
outport : out std_logic_vector(0 to size-1));
end dev;

You can instantiate this design entity like any other design entity and
when doing so you can use the parameter passing assignment part
of the module instantiation statement to pas a new size to the port.

Instantiating Verilog or VHDL in Your Design


3-17
Example 3-8 Parameter Passing A New Port Width
dev #(8)vhdldev1 (reg1, wire8bit);

Instantiating a Signed or Unsigned VHDL Design Entity


You can instantiate VHDL entity having a port or generic of type
signed and unsigned in a Verilog module. VHDL explicitly supports
signed and unsigned types, and Verilog supports arithmetic and
arithmetic shift operations on signed vectors of arbitrary length. .
While Verilog does not hae any explicit unsigned, all wire types are
effectively unsigned. VHDL explicitly supports signed and unsigned
types.

Example shows a VHDL adder design with signed and unsigned


types followed by the part of the VHDL testbench design instantiating
the Verilog module.

Example 3-9 Instantiating Signed and Unsigned VHDL Design Entity


VHDL design:

library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.std_logic_arith.all;

entity FULL_ADD8 is
port (A: in signed(7 downto 0);
B: in unsigned(7 downto 0);
CIN: in std_logic;
SUM: out signed(7 downto 0));
end FULL_ADD8;

architecture FOR_GENERATE of FULL_ADD8 is


begin
process (A, B, CIN)
begin
SUM <= A + B + CIN;
end process;

Instantiating Verilog or VHDL in Your Design


3-18
end FOR_GENERATE;

configuration CFG_fulladder of FULL_ADD8 is


for FOR_GENERATE
end for;
end;
Verilog testbench:

// verilog: signed + unsigned


// vhdl: signed + unsigned
`timescale 1 ns / 1 ns

module top;

wire signed [7:0] SUM;


reg signed [7:0] A;
reg [7:0] B;
reg CIN;

FULL_ADD8 i1(A, B, CIN, SUM);

initial
begin
A = 4'b0;
B = 4'b0;
CIN = 1'b0;
#1 A = -4'sh3;
B = 4'b0011;
#1 A = 4'b0010;
B = 4'sh7;
.
.
.
endmodule

Instantiating Verilog or VHDL in Your Design


3-19
Binding the Instance to a Specific VHDL Design Unit

By default, you instantiate a design entity that is the entity with the
specified name in the WORK logical library, and the most recently
analyzed architecture for that entity, also in the WORK logical library.
We have, however, extended the syntax of the module instantiation
statement so that you can specify the logical library for that entity and
architecture. This extended syntax, that uses an escaped identifier,
is as follows:

\logical_library_name.entity_name[(architecture_name)]|
configuration_name [#(parameter_assignments)]
instance_name (connection_list);

Example 3-10 and Example 3-11 show how this extended syntax
could be used.

Example 3-10 Using The Extended Syntax To Specify Library, Entity, and
Architecture
\mylib.vhdltop(vhdltoparch) #(15,"myInst") vhdltopinst
(rega,wireb);

Example 3-11 Using the Extended Syntax to Specify Library and


Configuration
\mylib.vhdltop_cfg #(15,"myInst") vhdltopinst (rega,wireb);

You can also specify the logical library on the vcs command line with
the +vhdllib compile-time option. However, this option is mainly to
specify the order in which to search logical libraries.

Instantiating Verilog or VHDL in Your Design


3-20
Instantiating Verilog in a VHDL Design within Verilog

You can instantiate a Verilog design in a VHDL design that you


instantiate in a Verilog design. This is commonly called a mixed-HDL
“donut.” There is no limit to the number of layers of VHDL and Verilog
source code in the design.

Figure 3-12 Mixed HDL Donut


Verilog code

VHDL code

Verilog code

To instantiate Verilog in VHDL you do the following:

1. Analyze the Verilog code using the vlogan utility.


2. Edit the VHDL code in the architecture where you are instantiating
the Verilog design, then re-analyze the architecture.

Editing The Architecture


You instantiate a module of the Verilog design the same way you
instantiate a VHDL component, with a component declaration and a
component instantiation statement.

Instantiating Verilog or VHDL in Your Design


3-21
The ports specified in the component declaration match the port
names in the port declarations in the module definition. The data types
you can use to specify ports in the component declaration are as
follows:

bit std_logic std_logic_vector


bit_vector std_ulogic std_ulogic_vector
boolean

You can also use the subtypes of these data types.

Use vector data types for vector ports in the Verilog module. Our
mixed HDL solution includes built in data type conversion for these
VHDL data types to Verilog data types.

If the module definition contains parameter declarations, the


corresponding component declaration specifies generics that match
the parameter names.

Example 3-13 shows a Verilog module definition to be instantiated in


a VHDL design:

Example 3-13 Verilog Module Definition


module vlogtop(topin,topout);
parameter topdelparam=6;
input topin;
output [7:0] topout;
vlogbot #(topdelparam) vlogbot1(topin,topout);
.
.
.
endmodule

Example 3-14 shows the component declaration that you use to


instantiate the Verilog module.

Instantiating Verilog or VHDL in Your Design


3-22
Example 3-14 The Corresponding VHDL Component Declaration
component vlogtop
generic (topdelparam : integer := 6);
port (topin : in STD_LOGIC;
topout : out STD_LOGIC_VECTOR (7 downto 0));
end component;

After declaring this component you enter a component instantiation


statement, for example:

vlogtopinst1 : vlogtop generic map (7) port map (a,b);

Note:
You can only instantiate Verilog modules or macromodules in your
VHDL design. You cannot instantiate a Verilog UDP in your VHDL
design, but you can instantiate a module that instantiates that
UDP.

Mapping VHDL Generics to Verilog Parameters


The generics specified in the component declaration matches the
parameter names in the module definition. Also the default value of
the generics is the same as that in the Verilog parameter declaration.
In Example 3-13 parameter topdelparam has a value of 6,
accordingly, the generic specification in Example 3-14 is for a generic
named topdelparam and its default value is also 6.

Verilog parameters do not have data types, however their values must
be constant integer, real number, or string value constants. Therefore
you should use the integer, real, or string generic types in the
corresponding generic specifications.

Instantiating Verilog or VHDL in Your Design


3-23
Verilog parameter definitions can also be expressions with other
parameters as operands. However VHDL prohibits the corresponding
practice, using a generic as the default value in another generic in
the same declarative region, so here you also must resolve this
expression in the corresponding generic specification.

Table 3-1 Verilog Parameter Definitions and Their Corresponding VHDL


Generic Specifications in Component Declarations
Verilog Parameter Definition VHDL Generic Specification
parameter p1 = 5 + 7; p1 : integer := 5 + 7;
parameter p2 = 5.5 p2 : real := 5.5;
parameter p3 = "init"; p3 : string := "init";
parameter p4 = p1 + p2; p4 : real := 17.5;

Mapping VHDL Ports to Verilog Ports


The port names in the VHDL component declaration match the port
names in the Verilog module definition.

The mode or direction of the ports, in, out, or inout, in the VHDL
component declaration match the type of port declaration, input,
output, or inout, in the Verilog module definition.

The size or bit-width, and the bit values used to specify the bit-width,
of the ports in the VHDL component declaration match the bit-width
and bit values in the port declarations in the Verilog module definition.

In Example 3-13 port topin is a scalar input port, so in Example 3-14


port topin is also a scalar port, of mode in, with a scalar data type. In
Example 3-13 port topout is an eight bit vector output port with the
bits numbered from 7 to 0, so in Example 3-14 port topout is also an
eight bit vector port, of mode out, with the bits numbered from 7
“downto” 0.

Instantiating Verilog or VHDL in Your Design


3-24
In Example 3-14 port topin has the STD_LOGIC data type because
this is a valid data type for converting values from VHDL to Verilog
and port topin is a scalar port. Also in Example 3-14 port topout has
the STD_LOGIC_VECTOR data type because this also is a valid data
type for converting values from Verilog to VHDL and port topout is a
vector port.

Instantiating A Verilog Module With Parameterized Ports


In Verilog a port can be parameterized so that its bit-width is specified
using a parameter. Doing so enables the Verilog designer to use
parameter passing into an instance of the module for the bit-width.
This enables a port to have different bit-widths in different instances
of the same module. Example 3-15 shows a module definition with a
parameterized port.

Example 3-15 Verilog Module With A Parameterized Port


module dev (inport, outport);
parameter portsize = 1;
input inport;
output [portsize + 1 : 0] outport;
.
.
.
endmodule

To instantiate a module with a parameterized port, use a generic in


the component declaration that corresponds to the parameter in the
module definition. This generic must have the integer data type or a
subtype of data type integer. Example 3-16 shows such a component
declaration.

Instantiating Verilog or VHDL in Your Design


3-25
Example 3-16 Component Declaration for a Module With A Parameterized
Port
component dev
generic (portsize : integer := 1);
port (inport : in std_logic;
outport : out std_logic_vector
((portsize + 1) downto 0));
end component

You can then use the generic map in the component instantiation
statement to pass a new value to the generic and thus a new size to
the port.

Names and Identifiers


The names (formally called identifiers) of design objects such as
components, entities, architectures, ports, or signals are not case
sensitive in VHDL but they are in Verilog. For this reason, in the
Verilog module that you instantiate in the VHDL design, the names
of Verilog modules, ports, and parameters must be unique without
regard to case, unless you use extended identifiers.

For example, in Verilog you can have the following two input port
names: in1 and IN1, in VHDL you can’t, so you must change one of
the port names if it is in the top-level module of the Verilog design
that you are instantiating in your VHDL design.

You cannot use VHDL keywords as the names of modules, ports, or


parameters in the top-level module, unless you use extended
identifiers.

Instantiating Verilog or VHDL in Your Design


3-26
You must follow the rules for VHDL identifiers in the names of
modules, ports, or parameters in the top-level module. Valid VHDL
identifiers consist of upper or lower case letters, numbers, and the
underscore, the first character must be a letter, and the last character
cannot be the underscore _, unless you use extended identifiers.

Using Extended Identifiers


You can use extended identifiers (similar to Verilog escaped
identifiers) to circumvent the rules for VHDL identifiers, for example:

• You can have ports \in1\ and \IN1\ in the component


declaration.
• You can have an entity named \component\.
• You can begin a name with a number and end with an underscore,
such as an architecture named \1comparch_\.

Module Header Port List Restrictions


The port list in the module header for the instantiated module cannot
contain either of the following:

•Unconnected ports
An unconnected port is an empty space between commas in the
port connection list, for example:

module vlogtop (portia, ,portib);

•Jumpered ports
A jumpered port is a port that appears more than once in the port
list, for example:

module vlogtop (portia, portia);

Instantiating Verilog or VHDL in Your Design


3-27
Instantiating Verilog or VHDL in Your Design
3-28
4
Analyzing Your Design 3
This chapter describes the analysis phase of mixed-HDL simulation.

It is important to note that the analysis phase can be affected if you


are instantiating either Verilog in a VHDL design, or VHDL code in a
Verilog design. If this is the case, you should also refer to “Instantiating
Verilog or VHDL in Your Design” in Chapter 3.This chapter contains
the following sections:

• "Introduction to Analysis" on page 4-2


• "Analyzing The VHDL Portion Of A Design" on page 4-3
• "Common vhdlan Analysis Options" on page 4-15
• "Analyzing The Verilog Portion Of A Design" on page 4-29

Analyzing Your Design


4-1
Introduction to Analysis

The VCS MX Analyzer analyzes source files, produces intermediate


files for elaboration and saves these files in the design library.

VCS MX uses the vhdlan utility to analyze VHDL-only designs, and


the VHDL portion of VHDL-top or Verilog-top designs. Similarly, VCS
MX uses the vlogan utility to analyze Verilog-only designs, and the
Verilog portion of Verilog-top or VHDL-top designs.

The recommended flow for a mixed language design is to first analyze


all of your Verilog source code using the vlogan command and then
analyze all of your VHDL source code using vhdlan.

For details on the analysis process as it applies to a Verilog design


instantiated within a VHDL design, see “Instantiating a Verilog Design
in a VHDL Design” on page 4-2. For details on the analysis process
as it applies to a VHDL design instantiated within a Verilog design,
see “Instantiating a VHDL Design within a Verilog Design” on page 4-
12.

Creating a Design Library

In the SYNOPSYS_SIM.SETUP file, you can create entries that map


the library logical name WORK to a design library name, and the
design library name to a host system directory. The VCS MX Analyzer
checks the entries in the setup file to determine where to place the
analyzed design library units.

Analyzing Your Design


4-2
For more information about design library mapping in the setup file,
see “Creating the Setup File” on page 1-4. You can use the
-work option with the vhdlan command or vlogan command to
analyze VHDL or Verilog code into different logical libraries. For more
information on using the -work option with the vhdlan command’
see "Specifying a Design Library" on page 4-19.

During analysis, the VCS MX Analyzer places output files in the


physical directory, which is mapped to the logical library. The specific
set of output files that the Analyzer creates, depends on the settings
in the setup file, and the switches you use for analysis.

Analyzing The VHDL Portion Of A Design

For analyzing VHDL source files in a VHDL or mixed-HDL design,


you need to use the vhdlan utility. This utility can be used with
different options to analyze the source files for different types of
simulation. For more information about different vhdlan options, see
“Common vhdlan Analysis Options” on page 4-15. You can also use
utilities such as simdepends and simcompiled to track
dependencies on a source file and determine the list of options that
were used to analyze a module. For more information about these
utilities, see “Maintaining VHDL Designs” on page 4-4.

Using vhdlan

The vhdlan utility performs the analysis process for VHDL-only


designs, and the VHDL portion of VHDL-top designs or Verilog-top
designs. The syntax for the vhdlan command is as follows:

vhdlan [options] filename_list

Analyzing Your Design


4-3
Use filename_list to list the names of one or more files you want
to analyze. A file extension is optional; if none is given, VHDL Analyzer
assumes it to be .vhd.

For example, to analyze the mux.vhd file, enter the following:

% vhdlan mux.vhd
Note:
The maximum identifier name length is 250 for package, package
body and configuration names. The combined length of an entity
name plus architecture name must not exceed 250 characters as
well. All other VHDL identifier names and string literals do not
have a length limitation.

For complete syntax details on the vhdlan command, see “vhdlan


Utility” on page 3-2 of the VCS MX Reference Guide.

Maintaining VHDL Designs

When you modify the VHDL source code for a design unit, you must
analyze the source file again so that the intermediate (.sim, .o,
and .mra) files used by the simulator reflect the current information
in the source files. You must also reanalyze any VHDL source files
that contain design units that instantiate the modified design unit.

In a large design, these source file dependencies can become difficult


to track manually. VCS MX provides utilities to help you do the
following:

• Create a file that contains a list of target dependencies for a design


unit.
• Reanalyze a source file, and automatically reanalyze the source
files for all design units that are affected by that source file.

Analyzing Your Design


4-4
• Determine the options you used when you analyzed a module for
simulation.
When maintaining your design, you cannot run a simulation using a
design library created with a version of VHDL Analyzer that does not
match the version of the simulator you are using. The binary format
of the intermediate files can change from one software release to
another. Therefore, you need to reanalyze all your design library files
after you install a new release of the simulation software.

Creating a Dependency List File

Use the simdepends utility to create a file (makefile) that simplifies


the task of reanalyzing your source files. The simdepends utility has
the following functions:

• Identifies intermediate files for design units that refer to the


modified design unit.
• Creates a list of target dependencies for source files that must be
reanalyzed when you edit a source file. You can then use this list
as input to the UNIX make utility to reanalyze all the files that must
be reanalyzed.
• Records the options you used when you analyzed your source
files. When you reanalyze a source file with the make utility, VHDL
Analyzer uses the same options as it did the last time it analyzed
that file.

Analyzing Your Design


4-5
Using simdepends
Figure 4-1 illustrates how to use the simdepends utility. The process
involves the following steps:

1. Analyze your design files with vhdlan.


2. Run simdepends to create a list of dependencies. Redirect the
output to a file (makefile).
3. Compile your design with scs.
4. Simulate and debug your design with VCS MX.
5. Edit your VHDL source files.
6. Use the UNIX make utility to reanalyze the edited VHDL source
files and all VHDL source files that depend on them.
You have to run simdepends again only if you add new design units
or library units to the simulation or if you change a path to these units.

Analyzing Your Design


4-6
Figure 4-1 Using the simdepends Utility

1. Analyze with
vhdlan.

2. Create makefile Intermediate


makefile with simdepends. Files (.sim)

3. Compile with
VHDL Source scs.
Files (.vhd)

4. Simulate with
scsim.
.

5. Edit VHDL
source code.

6. Re-analyze
with make utility.

Analyzing Your Design


4-7
Invoking simdepends
Run simdepends immediately after analyzing the new design source
files.

To create a dependency list for a single design unit, use the following
syntax:

% simdepends [options] design_unit

To create a dependency list for more than one design unit, use the
-u option to specify additional design units.

% simdepends [options] design_unit -u design_unit

You can use more than one instance of -u design_unit.

Specifying the Design Unit


The design unit you specify must be the name of the top-level design
unit for the simulation, for example, the testbench configuration name.
If you do this, simdepends enters all the intermediate files for the
simulation as target dependencies.

The design unit can be an entity, package, or configuration. To specify


an entity, use the following syntax:

[libname.]entity__archname

libname and archname are optional. libname is a library logical


name that is mapped to a design library in the setup file. If you do not
provide libname, simdepends uses the library mapped to the WORK
variable. If you do not provide archname, simdepends uses the
most recently analyzed architecture.

Analyzing Your Design


4-8
If the design_unit is a package or configuration, do not use
archname.

Specifying an Output File


Invoke simdepends with the -o filename option to send the
output to a file. The output file can have any name; however, it is most
convenient to use the name makefile, the default name for the make
utility. For example, to write the dependency list for the design unit
comparator to the file makefile, enter the following:

% simdepends -o makefile comparator

The -o filename option is the most commonly used simdepends


option.

For complete syntax information on the simdepends utility, see


“simdepends Utility” on page 3-17 of the VCS MX Reference Guide.

simdepends Example
The following example shows the source files for a simple design
used for analysis, the output files produced for mixed event and cycle
simulation, and the use of the simdepends utility to create a makefile.

Source Files
This example uses the following VHDL source files, residing in a
single directory:

• The x.vhd file, which contains


package P is
end P;

• The y.vhd file, which contains

Analyzing Your Design


4-9
use WORK.P.all;

entity E is
end E;

architecture A of E is
begin
end A;

• The z.vhd file, which contains


configuration C of E is
for A
end for;
end C;

Analyzer Output Files


Enter the following command:

% vhdlan -cycle x.vhd y.vhd z.vhd

This creates the following files in the directory mapped to WORK:

C.sim
E.mra
E.sim
E__A.sim
P.sim
cy_version
sparcOS5/E.o
sparcOS5/E__A.o

simdepends Output File


Example 4-1 shows the makefile created when you execute the
following command from the VHDL source file directory:

% simdepends -nc -o makefile C

Analyzing Your Design


4-10
Example 4-1 simdepends Makefile

ANALYZER = vhdlan
ARCH = sparcOS5
CFLAGS = -event -cycle \
-ccpath "/synopsys/scirocco/2002.06/sparcOS5/gcc/gcc-2.6.3/
bin/gcc" \
-ccflags "-c -O"

all : \
work/C.sim

work/P.sim : x.vhd
${ANALYZER} -nc ${CFLAGS} -w DEFAULT x.vhd

work/E.sim work/$(ARCH)/E.o : work/E__A.sim work/$(ARCH)/E__A.o

work/E__A.sim work/$(ARCH)/E__A.o : y.vhd \


work/P.sim
${ANALYZER} -nc ${CFLAGS} -w DEFAULT y.vhd

work/C.sim : z.vhd \
work/P.sim \
work/E__A.sim \
work/E.sim
${ANALYZER} -nc ${CFLAGS} -w DEFAULT z.vhd

Reanalyzing VHDL Source Files


After you run simdepends, you can update your simulation files by
invoking the make utility to use the simdepends output file. For
example, enter the following command from your VHDL source file
directory:

% make all

Analyzing Your Design


4-11
If a design unit intermediate file is out of date, make automatically
reanalyzes the source file and the source files for all design units that
refer to that design unit. When make finishes, all intermediate files
used in the simulation are up to date, and the new simulation is ready
to run.

Determining Analyzer Options

The simcompiled utility provides compiled simulation information


for a design unit. If you analyze a design unit for simulation and later
want to know which analyzer options you used, invoke simcompiled
on the design unit.

Invoking simcompiled
The simcompiled command syntax is:

% simcompiled [options] design_unit [-u design_unit]

You specify the design unit the same way you do for the simdepends
utility (see the “Specifying the Design Unit” section). A second design
unit can be specified by using the -u option.

To redirect the simcompiled output to a file, use the -o makefile


option. For example, enter the command:

% simcompiled -o compfile comparator

This generates a list of options used for compilation of the design unit
comparator and writes it to the file compfile.

Analyzing Your Design


4-12
simcompiled Example
The following example shows the source files for a simple design
used for analysis, the output files produced for simulation, and the
use of the simcompiled utility to list the options you used when you
analyzed the source files.

Source Files
This example uses the following VHDL source files, residing in a
single directory:

• The x.vhd file, which contains


package P is;
end P;

• The y.vhd file, which contains


use WORK.P.all;

entity E is
end E;

architecture A of E is
begin
end A;

• The z.vhd file, which contains


configuration C of E is
for A
end for;
end C;

Analyzing Your Design


4-13
Analyzer Output Files
Enter the following command:

vhdlan -cycle x.vhd y.vhd z.vhd

This generates debuggable and compiled event code and cycle code,
and creates the following files in the directory mapped to WORK:

C.sim
E.mra
E.sim
E__A.sim
P.sim
cy_version
sparcOS5/E.o
sparcOS5/E__A.o

simcompiled Output File


Example 4-2 shows the output file created when you execute the
following command from the VHDL source file directory:

% simcompiled -nc -o compfile C

Example 4-2 simcompiled Output File


Flags common to ALL design units:
-event -cycle
-ccpath "/synopsys/scirocco/2002.06/sparcOS5/gcc/
gcc-2.6.3/bin/gcc"
-ccflags "-c -O"

simcompiled Utility
For complete details on the syntax for the simcompiled utility, see
“simcompiled Utility” on page 3-19 of the VCS MX Reference Guide.

Analyzing Your Design


4-14
Common vhdlan Analysis Options

Some of the more commonly used vhdlan options enable the


following:

• "Analyzing for Simulation Technology" on page 4-15


• "Modifying Compiled Event Simulation Analysis" on page 4-17
• "Specifying a Design Library" on page 4-19
• "Checking Synthesis Policy" on page 4-20
• "Creating a List File" on page 4-22
• "The analyzer names the list file filename.lis and places it in the
same directory as the VHDL source file. Relaxing VHDL LRM
Conformance" on page 4-23
• "Analyzing for Functional VITAL Simulation Mode" on page 4-26
• "Smart Analysis" on page 4-28

Analyzing for Simulation Technology

You can analyze your files for debuggable event-driven, compiled


event-driven, or compiled cycle-based simulation. Table 4-1
summarizes the various codes the analyzer generates based on the
options you specify, either on the command line with the vhdlan
command or with the DEFAULT_ANALYZE_MODE setup variable.

Analyzing Your Design


4-15
Note:
Command line options always override the setup variable
settings.

Table 4-1 Code Generation for Various Analyzer Options


Analyzer Debuggable Event Code Compiled Event Code Cycle Code
Options (.sim files) Generation (.o files) Generation Generation
-event Enabled Enabled
-cycle Enabled Enabled Enabled
-noevent Enabled Disabled
-nocycle Enabled Enabled Disabled

Note:
By default the analyzer is set to -event, so if you do not specify
any options, the analyzer generates compiled event code (.o
files) with the debug code (.sim files).

If you specify conflicting options simultaneously, the enabling option


takes precedence. For example, if you specify both -event and -
noevent on the vhdlan command line, the -event option takes
precedence, enabling compiled event code generation.

After you analyze your design, use simdepends to create a makefile.


The makefile enables you to easily reanalyze a design block with the
same options as you used the last time you analyzed that block. For
more information on simdepends, see “"Analyzing The VHDL
Portion Of A Design" on page 4-3” in this chapter. Note that currently,
simdepends doesn’t work for mixed-HDL designs.

Analyzing Your Design


4-16
Analyzing for Compiled Cycle-based Simulation
For mixed event, cycle mode and full cycle mode simulation, you need
to invoke VHDL Analyzer with the -cycle option to perform
additional checks for cycle based policy violations when it analyzes
your VHDL design files. It checks the VHDL design file against the
VHDL cycle-based subset. If a violation is found, an error is
generated. For information about the VHDL cycle based subset, see
the VHDL Simulation Coding and Modeling Style Guide.

Modifying Compiled Event Simulation Analysis

If you are analyzing a design block for compiled event simulation, you
can use vhdlan command line modifiers to:

• Optimize compiled code


• Pass options to the compiler

Optimizing Compiled Code


By default, VCS MX Analyzer generates optimized compiled code for
running the event simulation. This optimized compiled code
enhances VCS MX performance.

Typically when you are developing your design and are still in the
debugging phase, you want to enforce more checks on the VHDL
source of your design. VHDL Analyzer can perform additional VHDL
checks for:

• Arithmetic overflow
• Constraint checks
• Array size compatibility at assignment

Analyzing Your Design


4-17
• Subscripts out of bounds
• Negative exponents to integer
To switch off optimizations, and make these checks available to you,
use the following option:

-no_opt
Generates updated code which contains embedded run-time
options.

Caution!
You should run your design at least once with the checks enabled,
by using -no_opt. Otherwise, if a VHDL error occurs, and you
have disabled checking, you can get erroneous results or cause
the simulator to fail in an unpredictable way.

Passing Options to the C Compiler


You can use the -ccflags "option_string" to pass options to
the C compiler. Table 4-2 shows the default option string and optimize
option for each platform.

Analyzing Your Design


4-18
Table 4-2 Platform-Specific Flags for vhdlan -ccflags
Platform -ccflags “option_string” Optimize Option
sparcOS5 “-c -O” -O
hpux10 “-c -w -O -Ae” -O
linux “-c -O” -O
rs6000 “-c -qchars=signed -O -O
-qmaxmem=2048000”

Some compilers have trouble compiling large files when the compiler
optimize option is on. By default, the VHDL Analyzer passes the
options specified by the CS_CCFLAGS_$ARCH setup variable to the
C compiler. To lower the optimization level, replace the -O option with
-O1 in the default option string. See “VCS MX Environment Variables”
in Chapter 2 for more information.

For example, on a Sun SPARCOS5 platform, to speed up analysis


by decreasing the C compiler optimization settings, enter:

% vhdlan -ccflags ”-c -O1” filename

Synopsys provides the gcc C compiler for use with the Sun
SPARCOS5 platform. The C compiler flags are already set for
optimized code generation and you should not change them.

Specifying a Design Library

You can direct the VHDL Analyzer output files to a design library you
specify by invoking vhdlan with the -work option. For example,

% vhdlan -work newlib filename

Analyzing Your Design


4-19
This directs the output files to the newlib design library.

The SYNOPSYS_SIM.SETUP file must contain an entry that maps the


design library name to a host system directory. For example,

newlib : /home/joe/lib2

Note: Using the -work newlib option has the same result as the
WORK > newlib entry in the SYNOPSYS_SIM.SETUP file.

You can also specify the physical path name of the logical design
library with the -work option of vhdlan. For example, if the library
mapping in SYNOPSYS_SIM.SETUP file is as follows:

LIB1 = /abc/def/ghi/work

To analyze a file.vhd into logical library LIB1, you can use the
following command:

% vhdlan -work LIB1 file.vhd

With the mapping in SYNOPSYS_SIM.SETUP, it is clear that the


logical library is LIB1. So any source that has "library LIB1; use
LIB1.all;" statements for instantiated components (which were
compiled in /abc/def/ghi/work) gets analyzed without errors.

Checking Synthesis Policy

You can invoke VHDL Analyzer to perform synthesis policy checking


(SPC) when it analyzes your VHDL design files. SPC checks the
VHDL design file against the VHDL subset supported by Synopsys
synthesis tools.

Analyzing Your Design


4-20
Additionally, the -spc option creates post analysis synthesis files
with a .syn suffix. Therefore, you only need to analyze your files
once for both synthesis and simulation as long as you use the same
version for both. You must use the -spc option to analyze all the
design files on which the file you are analyzing depends.

The following example shows how to use the -spc option:

% vhdlan -spc filename

Note: You need have a Synopsys Design Compiler installation and


license to use the -spc option.

Analyzing Your Design


4-21
Creating a List File

An Analyzer list file contains the following details about all the source
files that it analyzes:

• Name of the source file


• Time that the .lis file was created
• VHDL source listing
• Names of the analyzed units
• Warning or error messages generated during the analysis
Use the -list option to create an Analyzer list file. For example, the
command:

% vhdlan -list filename

Creates the following list file:

-- Synopsys 1076 VHDL Analyzer Version 2002.06 -- Apr 14, 2002


--
-- Copyright (c) 1990-2000 by Synopsys, Inc.
-- ALL RIGHTS RESERVED
-- This program is proprietary and confidential information
-- of Synopsys, Inc. and may be used and disclosed only as
-- authorized in a license agreement controlling such use
-- and disclosure.
--
-- Source File: zero.vhd
-- Sat Apr 15 21:28:23 2001

1 library IEEE;
2 use IEEE.std_logic_1164.all;
3 use IEEE.std_logic_arith.all;
4
5 entity ZERO is

Analyzing Your Design


4-22
6 Port (ZERO : out std_logic);
7 end ZERO;
8
9 architecture BEHAVIORAL of ZERO is
10 begin
11 ZERO <= '0';
12 end BEHAVIORAL;
13
14 configuration CFG_ZERO_BEHAVIORAL of ZERO is
15 for BEHAVIORAL
16 end for
17 end CFG_ZERO_BEHAVIORAL;
^
**Error: vhdlan,1081 zero.vhd(17):
Syntax error.
-- "zero.vhd": errors: 1; warnings: 0.

In the example, an error occurred during analysis. There is a missing


semi-colon at the end of line 16 causing a syntax error.

The analyzer names the list file filename.lis and places it in the same
directory as the VHDL source file. Relaxing VHDL LRM Conformance

Using -xlrm option, you can relax various VHDL Language


Reference Manual (LRM) initialization rules and checks that are
performed on your design at analysis time, compiletime, and runtime.
Using the -xlrm option allows you to:

• Use -2147483648 explicitly in the VHDL code.


• Instruct VCS MX to initialize un-initialized inout, out, or buffer ports
of type std_[u]logic[_vector] to ‘Z’ instead of type’left (‘U’).
• Instruct VCS MX to initialize un-initialized variables of type integer
to 0 instead of integer’left.
• Instruct VCS MX to initialize un-initialized objects of type real to
0 instead of real'left.

Analyzing Your Design


4-23
• Instruct VCS MX to initialize un-initialized objects of type time to
0 instead of time'left.
• Read signals during static elaboration.
The following two examples show where you might need this:

....
signal S0 : std_logic := '1';
signal S1 : std_logic : S0;
....

signal preloadfile : string(1 to 6) := “sim.in”;


file INIT_FILE : text is in preloadfile;
....

Use -xlrm for scs and scsim for this kind of case, in addition
to using the option with vhdlan.

• Reference a record type field in an array index definition.


This is the case when you reference a record field directly through
the name of the record type. For example:

TYPE RecOne IS RECORD


MCRS: STD_LOGIC_VECTOR (31-1 DOWNTO 0);
END RECORD;

PROCEDURE modify_trdy_delays (
TempCmdReg: OUT STD_LOGIC_VECTOR (RecOne.MCRS'RANGE));
....

This code is clearly illegal according to the LRM. You can only
reference the field if the prefix to the selected name is a record-
type object or value (see section 6.3 of the LRM). However, to
relax the LRM compliance and use this VHDL code, use -xlrm
for vhdlan.

• Use deferred constants as locally static within a package.

Analyzing Your Design


4-24
This case is better explained by the following example:

PACKAGE MY_PACK IS
CONSTANT token_size : NATURAL := 5;
CONSTANT set_cmd : STRING(1 TO token_size);
CONSTANT read_cmd : STRING(1 TO token_size);
...
END MY_PACK;

PACKAGE body MY_PACK IS


CONSTANT set_cmd: STRING(1 TO token_size):=”SET “;
CONSTANT read_cmd: STRING(1 TO token_size):=”READ “;
....
PROCEDURE proc_1 (
token : IN string (1 to token_size);
....
begin
case token is
WHEN set_cmd =>
.....
END proc_1;

END MY_PACK;

According to section 7.4.1 of the LRM, deferred constants are not


locally static.

According to section 7.3.2.2, a named association of an array


aggregate can have a choice that is not locally static only if the
aggregate includes a single element association and this element
association has a single choice.

According to section 8.8, the simple expression and discrete


ranges given as choices in a case statement must be locally static.

Based on these clauses in the LRM, the VHDL code is not LRM
compliant. However, to relax the LRM compliance and use this
VHDL code, use -xlrm for vhdlan.

Analyzing Your Design


4-25
• Relax conformance checking for implicit IN mode.
If the subprogram header has an IN mode parameter declared as:

function foo (A : integer) return integer;

And the subprogram body redeclares it as:

function foo (A : IN integer) return integer is ...

Analyzing for Functional VITAL Simulation Mode

By default, vhdlan generates code that provides the flexibility of


choosing functional or regular VITAL simulation when simulation is
run. When -novitaltiming option is specified at runtime, you get
functional VITAL simulation; otherwise, you get regular, full timing
VITAL simulation.

By specifying -functional_vital for vhdlan, you get the


equivalent of using the -novitaltiming option at runtime.

By specifying -no_functional_vital for vhdlan, you get full


timing VITAL simulation without the ability to use functional VITAL at
runtime.

Choosing the VITAL simulation mode at analysis time delivers a better


performance than choosing the mode at runtime because it eliminates
the runtime check for the functional VITAL simulation mode. The
trade-off is that you must reanalyze your VITAL sources if you want
to switch between functional and timing simulation. Therefore, you
should add the appropriate option to the vhdlan command line after
you determine which simulation mode gives the best performance
while preserving correct simulation results.

Analyzing Your Design


4-26
Using the -novitaltiming runtime option eliminates all timing-
related aspects from the simulation of VITAL components. Timing-
related aspects that are eliminated include Wire Delays, Path Delays,
and Timing Checks. All outputs are assigned with 0-delay. The
elimination of timing from the simulation of the VITAL components
significantly improves the performance of event simulations.

But if your design depends on one or more of the timing-related


aspects, you can try reanalyzing the VITAL source files with one or
more of the following options, depending on the timing-related or
functional capabilities that need to be preserved:

-keep_vital_ifs
This option turns off some of the aggressive novitaltiming
optimizations related to if statements in Level 0 VITAL cells.

-keep_vital_path_delay
This option preserves the calls to VitalPathDelay. You would use
this switch if non-zero assignments to the outputs are required to
preserve correct functionality.

-keep_vital_wire_delay
This option preserves the calls to VitalWireDelay. You would use
this switch if delays on the inputs are required to preserve correct
functionality.

-keep_vital_signal_delay
This option preserves the calls to VitalSignalDelay. You would
use this switch if delays on signals are required to preserve correct
functionality.

Analyzing Your Design


4-27
-keep_vital_timing_checks
This option preserves the timing checks within the VITAL cell.

-keep_vital_primitives
This option preserves calls to VITAL primitive subprograms.

Smart Analysis

Smart Analysis provides a looser coupling between VHDL design


units, which enables you to modify and reanalyze selected pieces of
a design. LRM rules are retained throughout this process so that
coupling between certain design units and the analysis order are
unaffected.

By following the rules of the LRM, Smart Analysis provides the


following benefits when you create decoupled designs:

• The ordering of analysis invocations is less strict, which allows


you to specify a set of analysis calls leading up to elaboration.
• Fewer files need to be reanalyzed when you make modifications
to architecture design units that are not explicitly named by parent
design units. For an N-level design change, there are N-1 fewer
analysis steps.
• VCS MX requires shorter elaboration time because there are
fewer C code generate/compile steps. For an N-level design
change, there are N-1 fewer generate/compile steps.
• Analysis time is potentially shorter because architectural library
units are bound during elaboration rather than during analysis.
For example

Analyzing Your Design


4-28
mymon : entity mon;
The previous example takes advantage of the loose binding
between the entity and the architecture. Since the architecture
isn't explicitly specified, the most recently analyzed files (*.mra)
for the entity is bound at elaboration time. Without Smart Analysis,
these files for the entity are bound at analysis time.

Using Smart Analysis


Smart Analysis is not enabled by default. To enable this feature, do
one of the following:

• In the SYNOPSYS_SIM.SETUP file, set the SMART_ANALYSIS


variable to TRUE.
• Pass the -smart_analysis option on the command line to all
analysis and elaboration invocations for the design units required
in the design.

Analyzing The Verilog Portion Of A Design

For analyzing Verilog source files in a mixed-HDL design, you need


to use the vlogan utility. This utility specifies all the correct library files
and library directories in order to pick up the correct source code for
lower level (instantiated) Verilog modules.

You can make use of “library files” and “library directories” for
specifying the Verilog source code needed to resolve the Verilog
references. The following sub-section describes the basics of Verilog
“library files” and “library directories”. If you are already aware of the
usage, you can skip the following sub-section and go to the “Using
vlogan" sub-section.

Analyzing Your Design


4-29
Understanding Library Directories and Library Files in
Specifying Verilog Source Files

Verilog libraries contain the source code for all the Verilog modules
that are needed for simulation. VCS MX requires you to specify—in
a particular syntax—the library containing the source code for each
of the modules to be simulated.

Often, ASIC vendors supply these Verilog libraries, to provide Verilog


models for the components they sell. Verilog libraries also often act
as depositories for reused Verilog source code.

Verilog has two types of libraries: library directories and library files.

In library directories, there are usually several Verilog source files.


When you instantiate a Verilog module that is defined in a Verilog
library directory, VCS MX looks in the library directory for a Verilog
source file whose name matches the module name in the module
instantiation statement. Once it finds the matching file name, VCS
MX looks for the corresponding module definition in that Verilog
source file. Note that Verilog is case-sensitive and therefore all these
names are case-sensitive.

For example, if the module instantiation statement is as follows:

dff dff_1 (sig1, sig2, sig3);

Analyzing Your Design


4-30
The module name is dff (the instance name is dff_1, but the
instance name is not used to resolve the instance). You can tell VCS
MX that one of the places to look for the module definition for this
module instance is a Verilog library directory. You can also tell VCS
MX to parse only those source files in the library directory that have
either certain filename extensions or no extension at all. For example,
you can specify that it should parse only those source files in the
directory that have the .v extension.

If you do, given the example module instantiation statement, VCS


MX looks in the Verilog library directory for a source file named
dff.v. VCS MX then parses the dff.v file looking for a module
definition named dff, for example:

module dff (in1,in2,out);


input [31:0] in1,in2;
output [31:0] out;

In Verilog-only simulation, a typical library directory specification


(during Verilog source code compilation) is:

% vcs design_file.v -y lib_dir1 +libext+.v -y lib_dir2


+libext+.V++

Note the following:

• Verilog source file names have to match the name of the module
definition. All names are case-sensitive.
• Extensions of Verilog source files must be specified with correct
syntax.
• All extensions must be specified using +libext+ext
• Multiple extensions can be specified with “+” space between them.
For example,

Analyzing Your Design


4-31
+libext+v+.V+vb

The concept of library files is similar to library directories. The only


difference is that instead of a library “directory” that contains all the
source files, there is a library “file” (single file) that contains the source
code for many Verilog modules. The library file can have any
extension. VCS MX searches the library file for the module definition
that has the same name as the instantiated module. All these names
are case-sensitive.

In Verilog-only simulation, a typical way of specifying the library files


(during Verilog source code compilation) is:

% vcs design_files.v -v library_files.v

The concept of library files and directories helps to specify correct


options at the vlogan command line for searching and resolving all
the Verilog modules referenced in the design.

Using vlogan

The vlogan command parses the Verilog source code and resolves
any references in the Verilog modules. By default, references to
VHDL design units are not resolved.

Note:
vlogan does not actually generate code; so in case you provide
code-generation options with vlogan, VCS MX will ignore the
options and issue a warning message that the options are being
ignored.

Analyzing Your Design


4-32
The vlogan utility performs the analysis process for the Verilog
portion of Mixed-HDL designs. The syntax for the vlogan command
is as follows:

vlogan [options] filename_list


Use a filename_list file to list the names of one or more files you
want to analyze. A filename extension is optional; if you don’t enter
one, vlogan assumes .v.

For example, if you want to analyze the mux.v file, enter the following:

% vlogan mux.v
Note:
If you are using SystemVerilog then, files containing $root
information should be analyzed in one vlogan command, before
analyzing the files that depend on the information in $root.

The following example illustrates the process of analyzing the


SystemVerilog files containing $root information:

//file1.v
typedef int T1;
module M1;
.
.
.
endmodule

//file2.v
typedef float T2;
module M2;
.
.
endmodule
//file3.v
module M3;
.

Analyzing Your Design


4-33
.
.
T1 a;
T2 b;
.
.
.
endmodule

In this example, file file1.v defines module M1 and declares T1 in


$root, and file file2.v defines module M2 and declares T2 in
$root. Source file file3.v defines module M3, which contains
instances of T1 and T2 that are defined in file1.v and file2.v,
and doesn’t declare a data type in $root. You can analyze these
files as shown below:

vlogan -sverilog file1.v file2.v

To analyze file3.v, use:

vlogan -sverilog file3.v

You can also analyze all the files together as shown below:

vlogan -sverilog file1.v file2.v file3.v

Suppose, you want to analyze another file, file4.v which defines


module M4 and declares T3 in $root as shown below:

//file4.v
typedef int T3;
module M4;
.
.
.
endmodule
If you analyze file4.v as:

vlogan -sverilog file4.v

Analyzing Your Design


4-34
The following error will be generated:

Error-[IARI] Illegal addition of $root information


Source files with $root information have to be analyzed
together.
To redefine $root, please
- Cleanup the pre-analyzed database and reanalyze
the necessary source files
(OR)
- Use vlogan -override_root
<all_files_containing_$root>
NOTE: All source files that depend on $root must
be reanalyzed.
constructs outside of modules or primitives
"file4.v", 1
You can overcome this problem in the following two ways:

• Cleanup the pre-analyzed database and reanalyze the


necessary source files as:
vlogan -sverilog file1.v file2.v file4.v

• Use one vlogan command with -override_root option to


analyze all the source files containing $root information as
shown below:
vlogan -override_root -sverilog file1.v file2.v
file4.v

If you reanalyze the files containing $root information, then the files
that use the $root information should also be reanalyzed. Since
file3.v depends on the $root information it has to be reanalyzed
as shown below:

vlogan -sverilog file3.v

For complete syntax details on the vlogan command, see “"vlogan


Utility" on page 3-10” of the VCS MX Reference Guide.Note the
following:

Analyzing Your Design


4-35
• vlogan always tries to find all the instantiated design units in
Verilog logical libraries. If it is not able to find them, it looks in the
VHDL libraries. So for each component, if the name of the module
in Verilog library is the same as the entity in VHDL library, vlogan
chooses the module over the entity.
• The actual compilation and code generation of the Verilog portion
of code is done at a later stage (explained in later sections) and
so VCS MX does not display errors related to the compilation of
Verilog source code during this stage.

Resolving References

By default, vlogan does not resolve references for instantiated


VHDL or Verilog design units. Instance resolution happens at
elaboration time when scs or vcs is used.

If you want to resolve all the references before elaboration, use the
-resolve switch along with vlogan.

Also, if you want to analyze the VHDL and/or Verilog design units in
logical libraries other then “WORK”, specify +vhdllib+LIB for
VHDL units, and +reflib+LIB for Verilog design units during
vlogan step. This way you can make sure VCS MX picks up the
correct design units during elaboration. If you do not specify
+vhdllib or +reflib options, VCS MX searches all the logical
library files in the setup file for resolving references, and it may
erroneously pick up the wrong design units. This may result in wrong
simulation.

If you analyze Verilog design units in different logical libraries, you


need to declare “library” and “use” clauses in the VHDL design units
that instantiate Verilog modules (same as in pure VHDL designs).

Analyzing Your Design


4-36
5
Compiling and Elaborating Your Design 4
The VCS MX compiler compiles and elaborates your design. It can
be run using two different commands:

• For the VHDL-only and VHDL-top flows, the scs command


elaborates your design, generates code,compiles C code, and
statically linkins all objects in order to generate executable binary
file, called scsim, for running the simulation.
• For Verilog-only and Verilog-top flow, the vcs command
generates an executable binary, called simv, for running the
simulation.
Note:
The word “compilation” is used throughout this chapter to mean
elaborate and compile the design.

Compiling Your Design


5-1
This chapter contains the following sections:

• Understanding the VCS MX Compilation Process


• Using the scs Command
• Using the vcs Command

Understanding the VCS MX Compilation Process

The VCS MX compilation process takes place after you’ve analyzed


any VHDL or Verilog source in your mixed-HDL design. If your design
contains only Verilog code, then this is the first step of the simulation
process.

The VCS MX Compiler expands the design hierarchy given a design


root, and produces the executable binary file for simulation.

Either of the following executables are used during the compilation


step:

• For VHDL-only or VHDL-top designs, use the scs executable.


Note that when running VHDL-top, you must also include the
-mhdl flag. Note also that you can pass any Verilog compile-time
options by specifying the -Verilogcomp option and the
appropriate option inside double-quotes.
• For Verilog-only or Verilog-top designs, use the vcs executable.
Note that when running Verilog-top, you must also include the
-mhdl flag. Note also that you can pass any VHDL compile-time
options by specifying the -vhdlelab option and the apppropriate
option inside double-quotes.

Compiling Your Design


5-2
Both the scs and vcs executables are discussed in detail throughout
this chapter:

• For details on scs, see “Using the scs Command,” in the next
seciton.
• For detials on vcs, see the “Using the vcs Command” on
page 4-50.

Using the scs Command

This section describes the process for using the scs command for
compiling and elaborating your design.

The syntax for the scs command is the following:

scs [options] design_root

For example, to compile the entity CPU with the configuration


CPU_cfg, enter the following:

% scs CPU_cfg

To compile the entity MUX using the architecture behavioral, enter


the following:

% scs mux behavioral

To compile the entity E, enter the following:

% scs E

Compiling Your Design


5-3
In the example, since no architecture is specified, the most recently
analyzed architecture for this entity is used.

For VHDL-top designs, both the VHDL top entity/configuration, as


well as dangling Verilog-top modules are supported.

You can specify as many as dangling Verilog top modules at the scs
command line as needed. For example:

scs -mhdl cfg -vltop <dangling verilog top> -vltop <dangling


verilog top> -verilogcomp " ... "

Common scs Compilation Options

Some of the more commonly used scs options enable the following:

• Compiling for Simulation Mode


• Modifying Cycle Simulation Compilation
• Overriding Generics Values
• Creating Multiple Simulation Executables
• Setting Time Base and Time Resolution
For a complete description of all scs options, see the “scs Command
and Options” section in Chapter 4, "Compilation Options" of the VCS
MX Reference Guide.

Compiling for Simulation Mode

After analyzing a design with the proper options, the design can be
partitioned into event and cycle blocks, compiled, and then the design
is ready for simulation.

Compiling Your Design


5-4
VCS MX is highly optimized to deliver the fastest simulation results
possible for most designs. To obtain the fastest simulation with VCS
MX, use the following guidelines:

• Simulate the entire design and testbench in cycle mode.


• In some cases, it might not be possible to simulate everything in
cycle mode. Typically, this is due to a more behavioral style in the
testbench which does not meet the cycle style requirements (see
the VHDL Simulation Coding and Modeling Style Guide). In this
case, the fastest simulation results can be obtained by partitioning
the design between event and cycle simulation modes.
In general, you can compile your design to simulate in one of the
following simulation modes

• Event-Driven Simulation
• Mixed Event and Cycle-based Simulation
• Full Cycle-based Simulation

Event-Driven Simulation
Typically, you use debug mode and compiled mode event simulation
in the early stages of the design when you are making frequent
changes to your VHDL source code. Debug mode event simulation
provides you full access to your code enabling you to do source-line
debugging. Compiled mode event simulation still allows full visibility
into the design and offers you better performance than debuggable
event mode.

For example to compile the CPU design for event simulation, the
command

% scs -nc CPU_TOP

Compiling Your Design


5-5
creates the executable binary file named scsim that you then run to
start the simulation. Note that the -nc option is used to suppress
printing the copyright banner.

Mixed Event and Cycle-based Simulation


VCS MX combines the flexibility of event-driven simulation with
performance of cycle-based simulation. As portions of your design
become stable, you can start to run in compiled event or mixed event
and cycle mode, increasing the simulation speed of those blocks.
Mixed mode simulation provides the maximum performance while
compiled event simulation supports the full VHDL language.

To run a mixed mode simulation, you must create a partition file to


identify the design subtrees or blocks to run in cycle mode. See the
“Creating a Partition File” section in this chapter for information about
how to create this file.

Compiling Your Design


5-6
Figure 5-1 Design example

TB_TOP_CFG

design_top

sub1 sub2

leaf1 leaf2 leaf3 leaf4

Consider the example design in Figure 5-1. To simulate the design


in mixed event and cycle mode, where sub1 and sub2 blocks are
partitioned to run in cycle and the rest of the design to run in event,
a partition file with the partition information is created (part.file).
The top-level of the design, TB_TOP_CFG, is analyzed into the library
work. The command to compile the design is

% scs -partition part.file work.tb_top_cfg

Compiling Your Design


5-7
Multi-Layers of Event and Cycle Partitions
This is also know as event and cycle “donuts”. By default, all design
units are run in event mode. Once a design block is specified to run
in cycle, that entire design block simulates in cycle mode. If there is
a sub-block of behavioral IP or some non-cycle VHDL code in that
design cycle region, you can specify an event partition (event donut)
for that design unit in the partition file. Event partitions are similar to
cycle partitions in that once a design block is identified to run in event,
all design units below that will be in event mode. In general, you can
have multiple layers of event and cycle partitions, but the best
simulation performance is achieved when the whole testbench and
design are running in cycle, or when the design is running in cycle
while the testbench is running in event.

Full Cycle-based Simulation


If the entire design and testbench comply with the cycle modeling and
coding style guidelines and they are compiled for cycle simulation,
the entire simulation can be performed in cycle mode.

Due to the high levels of optimizations performed for cycle simulation,


use this mode only with relatively stable designs as the debugging
capabilities are limited compared to debug event mode.

For a full cycle simulation, a partition file with a single cycle statement
is required to enable full cycle simulation. The top level configuration
for the simulation is identified in the partition file’s cycle statement
(this is the same configuration identified on the scs command line).
See the “Creating a Partition File” section in this chapter for more
information on how to create the partition file.

Compiling Your Design


5-8
Creating a Partition File
The partition file contains all the necessary information to divide a
design into event and cycle blocks. A partition file must be created to
perform mixed event and cycle simulation or full cycle-based
simulation.

When creating a partition file, consider the following guidelines:

1. For each design block that is to run in cycle mode, you must
specify a partition statement in the partition file for the block’s root
design unit, otherwise the entire block runs in event mode.
2. If an error is detected in the partition file, scs quits with an error.
3. To add a comment to the partition file, begin the line with #
character.
4. Line continuation is not allowed.
5. The partition file is case sensitive and all options must be specified
in lower case. The names of the specified library and design unit
are not case sensitive, following VHDL semantics.
6. If the root design unit of a cycle block is specified in the partition
file multiple times, the options of the last occurrence of the root
design unit in the partition file are the one used.
7. In your partition file, you can specify your event or cycle block(s)
as an entity or a configuration. If you have declared a VHDL
configuration for the root design unit of the cycle block and want
to use it when instantiating the block, you must include a "use
configuration" clause in the VHDL configuration of the design
unit that instantiates the partitioned design unit. Be sure to analyze
the configuration VHDL source (and all source that comprises the
cycle block) so that they run in the correct simulation mode.

Compiling Your Design


5-9
With a VHDL configuration declared and "use configuration"
clause in place, VCS MX uses this configuration regardless of
whether you specify an entity or a configuration for the root design
unit of the cycle block in the partition file.

8. If the configuration name of the root of the cycle block is specified


in the partition statement and no use clause is found for that
configuration in the VHDL, VCS MX issues an error and quits.
9. If you have not declared a configuration for the root design unit of
the cycle block, you must specify the entity for that root design
unit in the partition file. If you specify a configuration that is not
declared, VCS MX issues an error and quits.
10. If you have multiple architectures for the root design unit of the
cycle block, a configuration must be specified in the partition file
to allow the determination of the correct architecture (along with
specifying the “use configuration” clause in the VHDL
source).
11. If an entity/arch pair is specified in the partition file, an error occurs.

Compiling Your Design


5-10
Partition Statement Syntax
Cycle Partition
cycle [-2state | -4state] [-perf | -noperf]
[-latch_transparency] [-latch_style style]
[-tbl] [libname.]design_unit

Event Partition
event [libname.]design_unit

Options

-2state
Creates 2-state (0,1) executable code. 2-state code allows Z
values for bus signals. 2-state code is faster than 4-state code.
The -2state option and the -4state option are mutually exclusive.
-4state
Creates 4-state (0, 1, X, Z) code. The -4state option and the
-2state option are mutually exclusive. 4-state code is the default
code generated.
-perf
Creates a version of executable code that is fully optimized and
less observable (limited debugging). This option is on by default.
Code generated using -perf is faster than code generated with
-noperf. The -perf and -noperf options are mutually
exclusive.
-noperf
Creates a version of executable code that is more observable than
with the -perf. Simulating the cycle portion of your design in debug
mode is equivalent to specifying every signal and variable in the
cycle block as read mode in a monsigs file. The -noperf option
and the -perf option are mutually exclusive.

Compiling Your Design


5-11
-latch_transparency
Makes all latch based processes use their sensitivity list as the
trigger instead of the enable. This is a dangerous option, use it
only in flip-flop based designs containing few latches. This option
causes a significant performance degradation.
-latch_style style
Specifies the type of edge to be used as the trigger edge. The
possible choices for style are leading, trailing, or event (which
triggers on both the leading and trailing edge).
-tbl
Enables VCS MX table optimization for the cycle portions of the
design. To enable table optimization and specify how you want
VCS MX to evaluate the tables, you can use the cycle command-
line options listed in Table 5-1.

Compiling Your Design


5-12
Table 5-1 cycle Command-Line Options
Option to cycle Function
-tbl Enables VCS MX’s table optimizations.
-tblmaxlookup N VCS MX uses direct-lookup style evaluation for tables
with, at most, N inputs. The default number for N is 9.
-tblminlooprows N For tables with N or more rows, VCS MX uses loop style
evaluation if lookup table is not suitable. The default
number for N is 5.
-tblnoeqns Does not generate equation-style evaluation for any
tables.
-tblforceeqns Generates equation-style evaluations for all tables.
Warning: on very large tables, this can expose a bug in
the Sunpro C compiler, version 4.0.
-tblnosplit Does not optimize by deleting the computation of unused
outputs. Use this option for debugging.
-tblnoslice Disables slicing of large tables.

[libname.]design_unit
Specifies the configuration or entity of the root design unit of the
block to be compiled for running in cycle mode. An optional logical
library name can also be specified. By default, the library mapped
to the WORK variable is used. Running in cycle mode gives
maximum performance.
If you specify an entity, a default configuration is created and used
for simulation. The simulator always uses the most recently
analyzed architecture.
If you specify the configuration of the root design unit of the cycle
block, you must have a corresponding use clause explicitly stated
in the configuration of the event block where it is instantiated.
Consider the following examples to see how you specify partition
statements for event and cycle. The examples use the design in
Figure 5-2.

Compiling Your Design


5-13
Figure 5-2 Design Example

TB_TOP

design_top

sub1 sub2

leaf1 leaf2 leaf3 leaf4

Example 1
If you want to run the design in mixed event and cycle mode, and you
want to partition the design under test, design_top, to run in cycle
but you want to keep the testbench, TB_TOP_CFG, to run in event,
the partition file content is

cycle -4state -noperf design_top

This means that the cycle portion of the design is compiled to run in
4state noperf mode.

Example 2
If for instance the design unit leaf1 is not cycle friendly then you
need to run it in event mode. Even if it is below a cycle region, you
still can partition it to run in event. The content of the partition file in
this case is

Compiling Your Design


5-14
cycle -4state -noperf design_top_cfg
event leaf1

Note that the partition statement uses the configuration name of the
design under test, design_top_cfg. In this case, the TB_TOP_CFG
configuration must specify to use the configuration of design_top
explicitly.

configuration TB_TOP_CFG of TB_TOP is


for A
for DUT : design_top
-- Explicit use clause to specify the cycle
-- configuration
use configuration WORK.design_top_cfg;
end for;
end for;
end TB_TOP_CFG;

Example 3
If a partition file has multiple partition statements that apply to the
same configuration, the bottom line overrides the previous one.

cycle -2state -noperf design_top_cfg


cycle design_top_cfg

The cycle block is compiled in 4state perf mode (the default), and not
in 2state noperf mode.

Example 4
Consider the partition below

Compiling Your Design


5-15
event sub2
cycle -latch_style leading sub1

Again, multiple partitions are specified. The first partition compiles


the entity sub2 in event. This partition is not necessary unless the
design region above design_root is being simulated in cycle mode.
The second partition compiles the design block under sub1 in cycle.
The -latch_style option is used to tell VCS MX compiler to create
a trigger on the positive edge of any latches instead of on the default
negative edge.

Example 5
Consider the partition below

cycle design_top
event sub2
cycle leaf4

Multiple partitions are specified. The first partition specifies to compile


the design top-level design_top in cycle. The second partition
specifies to compile the design sub-block sub2, which is under
design_top, in event (an event donut). The final partition specifies
to compile the entity leaf4 in cycle.

Modifying Cycle Simulation Compilation

When you compile your design for mixed event and cycle mode or
full cycle-based mode, you can use scs command line modifiers to

• Compile for 2-state simulation


• Compile for performance or debugging
• Select a compiler

Compiling Your Design


5-16
• Pass options to the compiler
• Generating static elaboration reports

Compiling for 2-State Simulation


The -2state option tells the compiler to create code that simulates
in <0,1> (2-state) mode for the cycle blocks. 2-state code is faster
than 4-state code.

You cannot use the 2-state mode if the VHDL code contains explicit
‘X’s. This produces an error. You must then use the default, <0,1,X>
(4-state) mode. The 4-state mode allows unknown values to be
propagated through logic gates.

The Z state is available in both modes. In cycle simulation, Z is treated


as a metavalue associated with the outputs of 3-state devices and
buses (resolved bidirectional ports and the nets associated with
them).

For example,

% scs -2state -partition part.file design_cfg

Note:
Using the -2state option on the scs command line will change
the default code generation to 2-state for all cycle design
partitions. Explicitly using the -4state option in the partition file
overrides this setting.

Compiling Your Design


5-17
Compiling for Performance or Debugging
One of the ways cycle simulation improves performance is by
optimizing away internal variables and signals. VCS MX Compiler
can generate code at two different levels of optimization for cycle
mode, providing a trade-off of runtime performance against ease of
debugging. In the fully optimized -perf (performance) mode,
observability is limited to ports and states (registers). In -noperf
(debug) mode, all objects in the cycle blocks are observable.

To achieve maximum performance, the default optimization level is


the performance mode. You can override this setting by specifying
the -noperf on the scs command line, or in the partition file for each
cycle block.

Creating a Monsigs File


Using the -noperf option makes all objects in the cycle blocks
observable, but it slows the simulation down. But if you are interested
only in few internal objects and you do not want to compromise the
overall performance, you can use the -monsigs option to keep only
those objects visible and still run in performance mode.

Moreover, using the -monsigs option allows you to specify whether


you want to trace and/or assign (write) values to the specified signals
and variables in the monsigs file.

You specify the -monsigs option on the scs command line along
with the -partition option, for example,

% scs -perf -monsigs mon.file -partition part.file design_cfg

When creating a monsigs file, consider the following guidelines:

Compiling Your Design


5-18
1. To add a comment to the monsigs file, begin the line with #
character.
2. Line continuation is not allowed.
3. Wildcarding is not allowed.
4. The monsigs file is not case sensitive.
5. Any additional white space is ignored.
Syntax
[r] [t] [w] : /top_level_design_entity/full_name

Statement Options
r
Keeps the specified signal or variable values visible for reading
and unoptimized tracing. If you plan to trace some specific signals
or variables, use the t option of monsigs for those objects. Using
the r option on all signals and variables in a cycle block of your
design is equivalent to using the -noperf option for partitioning
the block.
t
Keeps the specified signal or variable values visible for reading
and optimized tracing. Using this option to specify signals or
variables to be traced within a cycle region, yields faster simulation
performance than if they are specified with the r option or the
-noperf option for partitioning the block. See the See “dump” on
page 6-62 of the VCS MX Reference Guide for information about
how to automatically generate a monsigs file.

Compiling Your Design


5-19
w
Keeps the specified signal or variable values visible for reading,
unoptimized tracing, and writing. This option lets you assign and
hold values in a cycle region. Specifying w is equivalent to
specifying r and w. Note that this option slows the simulation
performance. Do not use it on a large number of signals. The
-noperf option does not provide write permissions for signals
and variables.
top_level_design_entity
Specifies the name of the top-level entity of the design.
full_name
Specifies the full name of the VHDL signal or variable you want to
remain visible. The full pathname to the object from the top-level
design entity must be specified. If only a path is specified, all signals
and variables in the specified design region remain visible.

Examples
# keep Data_bus readable and traceable
r t : /TB/DUT/U0/Data_bus

# keep Addr_bus readable, writable, and traceable


w t : /TB/DUT/U0/Addr_bus

# keep reset_sig readable and writable


w : /TB/DUT/reset_sig

# keep all objects in U1 instance readable and traceable


t : /TB/DUT/U1

Compiling Your Design


5-20
Selecting a C Compiler
The default compiler used by VCS MX Compiler is defined by the
platform-specific CS_CCPATH_$ARCH setup variable. To select a
different compiler, use the -ccpath "compiler" modifier, for
example,

% scs -ccpath “compiler” -partition part.file design_cfg

Note:
It is recommended that you use the same C compiler for both
event and cycle C compilation. Otherwise, problems may occur
during static linking of the simulation executable binary file.

Passing Options to the C Compiler


Use the -ccflags "option_string" to pass options to the C
compiler. For example, some compilers have trouble compiling large
files when the compiler optimize option is on. To lower the
optimization level, replace the -O option with -O1 in the default option
string. By default, VCS MX Compiler passes the options specified by
the CS_CCFLAGS_$ARCH setup variable.

For example, on a Sun SPARCOS5 platform, to speed up compilation


by decreasing the C compiler optimization settings, enter

% scs -ccflags ”-c -O1” -partition part.file design_cfg

Synopsys provides the gcc C compiler for use with the Sun
SPARCOS5 platform. The C compiler flags are already set for
optimized code generation and we do not recommend that you
change them.

Table 5-2 shows the optimize option for each platform.

Compiling Your Design


5-21
Table 5-2 Platform-Specific Flags for scs -ccflags
Platform -ccflags “option_string” Optimize Option
sparcOS5 “-c -O” -O
hpux10 “-c -w -O -Ae” -O
linux “-c -O” -O
rs6000 “-c -qchars=signed -O -O
-qmaxmem=2048000”

Generating Static Elaboration Reports


You can generate static elaboration report for the cycle block by using
the following option on your scs command line

% scs -perf_data report.txt -partition part.file design_cfg

This report shows detailed information about the optimizations made


to the cycle design block during compilation. See the “Static Cycle
Elaboration Reports” section for more information about how to read
the report.

Overriding Generics Values

A generic can be declared anywhere in the design hierarchy. The


following list shows how you can assign a value to a generic in your
design. It is listed in order of precedence for conflicting assignments:

1. From a command file


2. In the VHDL source code

Compiling Your Design


5-22
An assignment to a generic value from a command file overrides the
assignment from the value defined in the VHDL source code. These
generic assignments must be know by compilation time in order to
correctly determine any variable object sized determined by generic
values.

Changing the Generic Parameter Default Value


You can change the default value of a generic by modifying the
design’s VHDL source file. To apply this value, you must reanalyze
the source file. The next method avoids the necessity of reanalyzing
the file.

Assigning Generic Values from a Command File


After analyzing your design, you can override the default value for
any generic by using a command file specified on the scs command
line, as follows:

% scs -generics cmdfile design_cfg

cmdfile is an include file that contains only simulator assign


commands targeting design generics. The absolute hierarchical path
for the generic whose value is to be reassigned must be provided in
the generics file.

Before compiling the design, scs reads, displays, and applies the
assignments in cmdfile.

Example 1
If you have a top-level generic in the entity TB to define a clock period
declared as

Compiling Your Design


5-23
generic (PERIOD : time := 1000 ns);

We can double the clock speed by cutting the period in half to 500
ns. The command file to assign the new value to PERIOD looks like

assign (500 ns) /TB/PERIOD

Note:
Note the usage of parenthesis for physical units.

To invoke scs using this command file, type

% scs -generics generics.input design_cfg

generics.input is the command file containing the assign


statement.

The resulting output from scs is

GENERIC ASSIGNMENTS FROM FILE "generics_file":


assign (500 ns) /TB/PERIOD

The value of PERIOD is changed to 500 ns.

For top-level generics, generics declared at the top-level in the design


hierarchy, the absolute hierarchical path to the generic is not needed
although providing the absolute path is still recommended. For the
example above, we could have specified simply the generic name like

assign (500 ns) PERIOD

and still have correct results. If PERIOD is not declared in the top-
level design unit, an elaboration error would occur.

Compiling Your Design


5-24
Example 2
You can assign same value to multiple generic targets with one assign
command in the generics file.

assign ‘0’ /TB/TOP/U1/STOP_FLAG /TB/TOP/U2/READY_FLAG

Note that in mixed langauge simulation, the above command needs


to be specified differently to accomodate the mixed language
environment.

assign {“0”} /TB/TOP/U1/STOP_FLAG /TB/TOP/U2/READY_FLAG

Example 3
You can assign same value to multiple generic targets (with same
name) with one assign commands in the generics file without having
to specify the path for each of them.

assign (20 ns) tpd


assign (10 ns) /top/u1/tpd

Here all tpd generics will have 20 ns with the exception of /top/u1/tpd
which will have 10 ns since second more specific assign command
will overwrite the more general first assign command.

The order of assign commands is important!

assign FALSE TimingChecksOn


assign TRUE u2/TimingChecksOn

Here all TimingCheckOn will be FALSE with the exception of all


TimingChecksOn under all components named u2 which are TRUE.

Note that with the above example, you can now control turning on/
off timing checks for VITAL components selectively or for all

Compiling Your Design


5-25
components. This is another way to turn timing checks off in addition
to the already supported way via the variables in the
synopsys_sim.setup file.

Limitation
You cannot use the above method to override the default values for
lower level Verilog parameters.

Example 4
You can assign a value from a Verilog instance to a generic using a
VHDL path in a command file. For the hierarchy:

e (VHDL)
-->uut (VHDL)
-->convert (VHDL instance of Verilog implementation)
-->z_1 (Verilog instance at VHDL implementation
for z_1)

You can specify the value of generic g1 as shown below. Note that
the VHDL portion of the hierarchy is case insensitive, while the Verilog
portion (module, instances) is case sensitive.

assign 1 /e/uut/convert/z_1/G1(valid)
assign 1 /e/uut/convert/z_1/g1(valid)
assign 1 /E/Uut/Convert/z_1/g1(valid)
assign 1 /e/uut/convert/Z_1/g1(Invalid because Verilog
instance z_1 is case
sensitive.)

Creating Multiple Simulation Executables

You can use the -executable option to name the generated


simulation executable binary. Default name for the simulation
executable is scsim.

Compiling Your Design


5-26
For example, to name the simulation executable mysim instead of
the default scsim, type

% scs -executable mysim design_cfg

By default, each generated executable has an associated database


directory (by default scsim.db.dir) that is used to store all
necessary information for that executable to run simulation. The
simulator has no dependencies on any of the VHDL work libraries
that the design VHDL files are analyzed to. This enables you to

• Create multiple executables where each is compiled with different


scs options. For example, one for debug simulation, another for
compiled event simulation, and a third for cycle simulation.
• Relocate running the simulation to another directory as long as
you move both the executable and its database directory together,
and also any other input files needed for running the simulation.
Note:
If you want to rename a simulation executable after it is created,
you must ensure to rename both the simulation executable and
its database directory.

Setting Time Base and Time Resolution

You can use the -time option to set the time base for the simulation.
This option overrides the default TIMEBASE variable value in the
setup file. -time option takes argument, base_time, valid values
for base_time are as follows:

• fs femtoseconds
• ps picoseconds

Compiling Your Design


5-27
• ns nanoseconds
• us microseconds
• ms milliseconds
• sec seconds
The default value for base_time is ns.

For example, to set the simulation time base to ps instead of the


default ns, type

% scs -time ps design_cfg

In addition to setting the time base, you can also specify the simulator
time resolution with the -time_resolution option. Setting the time
resolution basically sets the precision or the number of simulation
ticks per base time unit. The format for using -time_resolution
is as follows:

-time_res[olution] [1 | 10 | 100] [fs | ps | ns | us | ms | sec]

If a value beside 1, 10, or 100 is provided, a warning during scs will


be issued and a default setting of 1 <unit> will be used (where unit is
the specified time unit (fs, ps, etc.)).

Note:
Time resolution value cannot be higher than the time base value.
An error will be issued if this happens.

If no numeric value (1, 10, or 100) is provided, then the default value
is 1. For example:

% scs -nc -time_res ps design_cfg

Compiling Your Design


5-28
To set the simulation time resolution to 10ps instead of the default
1ns, type

% scs -nc -time ns -time_res 10ps design_cfg

The -time_resolution option to the scs command overrides the


TIME_RESOLUTION value in the setup file.

Using Time Resolution


When you specify a time resolution for a simulation, pay attention to
its effect on the values of time objects and delays in the VHDL source,
the simulation user interface (UI), Mixed HDL simulation, and VHPI.

wait for or after statements in the VHDL Source


If the VHDL source contains time delays (using wait for or after
statements) that are smaller than the time resolution value, then the
delays will be rounded up or down to the next closest unit specified
for the time resolution. If time resolution is not set, then time delays
will be compared with time base value.

For example, if the resolution is set to 1 ns, and in the VHDL source
contains:

wait for 1.4 ns;

The delay will be rounded down to 1 ns (equivalent to wait for 1 ns;).


And if the VHDL source contains:

wait for 1.5 ns;

The delay will be rounded up to 2 ns (equivalent to wait for 2 ns;)

Compiling Your Design


5-29
Assertion statements
Time in VHDL assertions will be printed in units of the time resolution.

VCS MX User Interface (TCL/UI)


Values of type time are displayed in VCS MX UI in terms of time
resolution units. This includes displaying the $now simulator variable.

Note:
Displaying $now simulator variable in the UI is changed. The value
is now displayed as a value with a time unit. For example,

# echo $now
100 PS

This is different from previous VCS MX releases. If you have TCL


scripts or procedures that operate/use $now, you may want to
make note of this. If you want to keep the old way of displaying
$now, then you need to set off a variable so you can keep the
backward compatibility. The TCL variable name is
display_now_unit. For backward compatibility, type at the
simulation prompt

# set display_now_unit FALSE

Any specified time unit in the TCL UI that is given without a timebase
(fs, ns, etc) will use units of TIMEBASE. Examples (with TIMEBASE
= NS and TIME_RESOLUTION = 10 PS)

# run 1

Will run for 1 NS (advances the simulation by 1000 PS).

# run 1.1 ns

Compiling Your Design


5-30
Will run for 1.1 NS (advances the simulation by 1100 PS).

# run 5 ps

Will truncates the time to 0 PS and advances the simulation by 0 PS.

# run 102 ps

Will truncates the time to 100 PS and advances the simulation by 100
PS.

# run 1.005 ns

Will truncate the time to 1.000 NS (advances the simulation by 1000


PS).

Mixed HDL Simulation


For Mixed HDL, the simulator precision is set to the highest resolution
needed in either the VHDL or the Verilog. The definition for time unit
and precision for each language is the following:

• For Verilog
`timescale unit/precision

`timescale 1ns/10ps
- 1ns is the unit, 10ps is the precision

• For VHDL:
TIME_RESOLUTION = precision

TIMEBASE = unit

TIME_RESOLUTION = 10ps - this is the time precision

Compiling Your Design


5-31
TIMEBASE = ns - this is the time unit

Event + Cycle + Verilog Elaboration

You can combine VHDL event and cycle simulation with Verilog
simulation. Since VCS MX supports multi-layer event-cycle
simulation, Verilog portion can reside in any partition of the design
(event or cycle). If it resides in cycle partition, you do not have to
declare it specifically as event sub-partition through partition file
(unlike in pure VHDL design). It is automatically considered as event
sub-partition and is simulated along with other event and cycle blocks.

tb_top (VHDL)

top (VHDL) VL (Verilog)

For example, VHDL testbench tb_top instantiates VHDL DUT top


which further instantiates Verilog VL. If your testbench is not cycle
compliant, but the entire DUT is then, you can simulate in such a way
that the testbench will run in event mode and the whole DUT will run
in cycle mode. The partition file will have following statement -

cycle top

Compiling Your Design


5-32
VL will automatically run in event mode.

tb_top(VHDL)

top (VHDL)
VL (Verilog) VH (VHDL)

In case the VL instantiates VH that can be simulated in cycle, you


need to specify a cycle statement for VH in the partition file as -

cycle top
cycle VH

Static Cycle Elaboration Reports

VCS MX provides the highest performance when simulating large


design blocks in cycle mode. VCS MX can generate a static
elaboration report to help you determine where cycle simulation
performance might be improved. This report shows detailed
information about the optimizations made to the cycle design block
during elaboration. See the ““Generating Static Elaboration Reports”
section for more information about how to generate the report.

The same design is used throughout this section as an example of


the various levels of detail shown with each report.

Compiling Your Design


5-33
Reading Summary Information
The most basic data in the cycle static elaboration report is a summary
that contains basic optimization information for the cycle design unit.
The summary shows basic details on various aspects of the cycle
design unit.

The following information are shown in the summary:

• Number of combinational signals


The number of combinational signals in the cycle design unit. A
combinational signal does not have a latched value.

• Number of sequential signals


The number of sequential signals in the cycle design unit. A
sequential signal has a value that is being latched in the design.

• Number of bus signals


The number of bused signals in the cycle design unit. A bused
signal is a signal that has multiple drivers for it.

• Number of seq processes (post-split)


The number of processes in the cycle design unit with state
information. This number is calculated after various optimizations
are done to split synchronous and asynchronous design regions.

• Number of combinational processes


The number of processes in the cycle design unit that do not
contain state information.

Compiling Your Design


5-34
• Number of testbench processes
The number of processes in the cycle design unit that cannot be
optimized or must execute at a specific point in time, usually do
to a ‘wait for time’ statement. Cycle optimizations are not applied
to these processes.

• Number of concurrent assignments


The number of concurrent signal assignments in the cycle design
unit.

• Number of testbench functions (tbf)


The number of testbench functions (tbf) created by VCS MX for
the cycle design unit. A testbench function is created for simulating
any testbench processes. Fewer numbers of testbench functions
results in better simulation performance.

• Number of triggers (tgf)


The number of trigger functions (tgf) created by VCS MX. Tgfs
are used to execute the sequential processes in the cycle design
unit. Multiple sequential processes can be executed by a common
tgf. The ratio of the number of tgfs to the number of sequential
processes is a good indication of the amount of cycle
optimizations occurring. Fewer trigger functions controlling large
numbers of sequential processes result in better simulation
performance.

Compiling Your Design


5-35
• Number of combinational functions (cbf)
The number of combinational logic functions (cbf) created by VCS
MX. Cbfs are optimized functions containing all the combinational
processes and concurrent assignments in the cycle design unit.
The ratio of the number cbfs to the number of combinational
processes is a good indication of the amount of cycle
optimizations occurring. Fewer combinational functions
controlling large numbers of combinational processes result in
better simulation performance.

• Maximum combinational level depth


The maximum depth of the combinational functions. VCS MX
flattens and levelizes combinational logic to improve simulation
performance. Because levelization occurs, delta cycles are not
needed for cycle simulation. The lower the number of
combinational levels, the faster the simulation speed.

• Number of feedback loops


The number of combinatorial feedback loops detected inside the
cycle design unit. Combinatorial feedback loops are broken by
the simulator to perform cycle optimizations and negatively affect
simulation performance.

• Size of data memory


The amount of memory needed (in kilobytes) to store the data for
simulating the cycle design unit.

• Size of code memory


The amount of memory needed (in kilobytes) to store the
executable code needed to simulate the cycle design unit.

Compiling Your Design


5-36
Adding the data memory and code memory sizes gives a good
approximation of the system memory needed to simulation the
cycle design unit.

An example of the elaboration summary data is shown in


Example 5-1. The design unit TOP__SCHEMATIC is small, requiring
only 32.3 Kb of memory to simulate. This design unit contains 15
sequential and 26 combinational signals, 9 sequential processes, 8
combinatorial processes, and 12 concurrent assignment statements.
Based on the coding style, VCS MX was able to optimize this into 3
trigger functions (tgfs) and 20 combinatorial functions (cbfs).

Example 5-1 Static Elaboration Summary Output

CYCLE ELABORATION SUMMARY OF 'TOP__SCHEMATIC'


------------------------------------------------
================== Elaboration Summary ===============

Number of combinational signals = 26


Number of sequential signals = 15
Number of bus signals = 0
Number of seq processes (post-split) = 9
Number of combinational processes = 8
Number of testbench processes = 0
Number of concurrent assignments = 12
Number of testbench functions (tbf) = 0
Number of triggers (tgf) = 3
Number of combinational functions (cbf) = 20
Maximum combinational level depth = 2
Number of feedback loops = 0

Size of data memory = 1.05 KB


Size of code memory = 30.08 KB

===== End of CYCLE ELABORATION Summary for this Design ======

Compiling Your Design


5-37
Reading Triggers Information
Following the summary in the cycle static elaboration report is a table
containing detailed information describing each trigger function (tgf).
Optimizing tgfs is typically the best way to improve simulation
performance of a cycle design unit. Summary Information for each
trigger is presented in columns in the elaboration report, listing the
following information:

No.
The number associated with the trigger. Triggers are listed in order
by the cause of the trigger and how much code they control.
Triggers that are expensive to execute are typically listed first,
followed by triggers that control large numbers of sequential
processes. When trying to improve simulation performance, these
triggers must be investigated first.
id
The identification number associated with the tgf. This
identification number can be used in conjunction with the
-perf_data report to find out which VHDL processes are being
controlled by the tgf.
SeqPr
The number of sequential processes being controlled by the tgf.
The ratio of the number of tgfs to the number of sequential
processes is a good indication of the amount of cycle
optimizations occurring. Fewer trigger functions controlling large
numbers of sequential processes result in better simulation
performance.
Cbf
The number of combinatorial functions (cbfs) that are driven by
the tgf.

Compiling Your Design


5-38
CombPr
The number of combinational processes driven by the trigger
function. These combinational processes are optimized into the
listed cbfs. If a large percentage of the combinatorial processes
are driven by a single trigger, improving the performance of the
tgf has a greater impact on the overall simulation performance
because it is driving most of the design block.
Lev
The maximum levels of the cbfs. A value of -1 means that no cbfs
are being driven by the trigger function.
why
The cause of the trigger function. The following are the four
different types of triggers:
normal triggers
Normal triggers are ones that are recognized by VCS MX cycle
templates and are fully optimized. A typical normal trigger
usually consists of a clock and a reset signal.
sensitivity trigger
Sensitivity triggers are ones that use the sensitivity list of a
process as the trigger for the process. Sensitivity triggers
usually occur when the process is too complex to infer a normal
trigger for. This reduces the number of sequential processes
that can be merged into a single trigger reducing simulation
performance.

Compiling Your Design


5-39
latch trigger
Latch triggers are a special kind of sensitivity trigger created
when VCS MX infers latches in the VHDL source that are not
recognized as one of the VCS MX cycle latch templates. These
typically result from a signal that is not fully assigned in a
conditional statement (such as a case or an if statement). See
the VHDL Simulation Coding and Modeling Style Guide for
more information on recognized latch templates.
loop triggers
Loop triggers are created by the existence of combinational
feedback loops detected in the VHDL code. These triggers are
very expensive and must be removed if possible.
Examples of each of these types of triggers is shown in the
““Examples of Various Trigger Types” section.
trigger_conditions
The conditions on which the trigger function is executed. The
following notation is used:
pe(signal)
pe means simulation of the tgf is executed on the positive or
rising edge of the specified signal.
ne(signal)
ne means the simulation of the tgf is executed on the negative
or falling edge of the specified signal.
~0(signal)
~0 specifies the execution of the tgf when the specified signal
is not 0. This usually occurs for asynchronous active-low reset
signals or latched signals.

Compiling Your Design


5-40
~1(signal)
~1 specifies the execution of the tgf when the specified signal
is not 1. This usually occurs for asynchronous active-high reset
signals or latched signals.
A typical trigger condition consists of a combination of these
conditions. For example, a common trigger condition is
~0(reset) pe(clk)

meaning the specified tgf fires when the reset signal is not equal
to zero and there is a rising edge on the clock signal.
The list of triggers is various statistical information helps you
determine the level of simulation performance to expect from your
design.

An example of the triggers data is shown in Example 5-2. This


information is from the same design as the summary information.
Since all the triggers are normal triggers activated by a simple clock
and reset signals, we can expect good simulation performance from
this design.

Example 5-2 Static Elaboration Triggers Output

===================== Trigger Summary ==================

SeqPr = sequential processes the trigger controls


Cbf = combinational functions (cbf) the trigger drives
CombPr = total number of combinational processes in Cbfs
Lev = maximum levels of the Cbfs (-1 means no cbfs)
loop = trigger due to combinational feedback loop
sensi = trigger due to sensitivity list
normal = regular trigger

Compiling Your Design


5-41
No. id SeqPr Cbf CombPr Lev why trigger_conditions
--- ---- ---- --- ------ --- ------- -------------------
1 1 4 3 61 1 normal pe(RESET)
2 2 4 3 61 1 normal pe(CLK) ~1(RESET)
3 0 1 1 3 2 normal pe(CLK)

Total number of triggers = 3


Total number of sequential processes controlled = 9
Average number of seq processes each trigger controls = 3.00
Average number of cbfs each trigger drives = 2.33
Average number of comb processes each trigger drives = 41.67
Average depth of cbf level of a trigger = 1.33

Reading Perf_data Information


Following the summary and trigger tables are a summary listing of
combinational logic functions (cbfs), and detailed information listing
where in the VHDL source code tgfs and cbfs are being created.

The summary listing of cbfs contains the following information:

No.
The number associated with the combinational logic function.
Cbfs are listed in order by how expensive it is to execute. Cbfs
that control a large number of combinational processes and
concurrent signal assignments are listed first.
id
The identification number associated with the cbf. This
identification number can be used in conjunction with the detailed
cbf information later in the report to find out which VHDL
processes are being controlled by the cbf.
CombPr
The number of combinational processes contained in the
combinational logic function.

Compiling Your Design


5-42
Succs
The number of cbfs that execute after the current cbf.
Preds
The number of cbfs are execute before the current cbf.
SeqDrvs
The number of trigger functions (tgfs) that drive the cbf.
Level
The level in the execution order of combinational functions where
this cbf is executed.
The list of combination logic functions is various statistical information
helps you determine the level of simulation performance to expect
from your design.

An example of the cbf summary data is shown in Example 5-3. For


brevity, only the first four cbfs are shown here along with the statistical
information.

Example 5-3 Static Elaboration Combinational Functions Summary Output

========== Cbf (Combinational Function) Summary ===========

(in descending order of number of comb processes contained)

CombPr = Number of combinational processes the cbf contains


Succs = Number of successor cbfs the cbf has
Prds = Number of predecessor cbfs the cbf has
SeqDrvs = Number of sequential drivers (trigger or testbench)

No. id CombPr Succs Preds SeqDrvs Level


--- ---- ------ ----- ----- ------- -----
1 0 59 1 2 2 1
2 3 4 1 0 0 0
3 2 3 0 2 3 2

Compiling Your Design


5-43
4 9 3 0 0 0 0
...
Total number of combinational functions (cbfs) = 20
Total number of combinational processes contained = 97
Average number of comb processes each cbf contains = 4.85
Average number of successors each cbf drives = 0.50

After the cbf summary listing, detailed information is provided on all


the tgfs, cbfs, and testbench functions (tbfs) in the design. This lists
all the tgfs, cbfs, and tbfs in the design block and shows detailed
information on the VHDL processes contained within each function,
and in what source file and line the process occurs.

An example for a tgf is shown in Example 5-4. The Tgf_id is the same
id listed in the triggers summary report, and the trigger conditions are
relisted. The sequential processes controlled by the tgf are listed,
including the full path from the top-level cycle entity where the design
unit was partitioned. In this example, the process TIME_INC is
controlled by this tgf and is located in the file alarm_counter.vhd on
line 21.

Example 5-4 Static Elaboration Detailed Tgf Information

Tgf_id = 2: conditions [ pe(CLK) ~1(RESET) ] {1 event(s)}

Tgf_name [ TOP__SCHEMATIC_0_tgf_2 ]

Controls 4 sequential process(es):

/TOP/T_BLOCK/TSM/SYNCH$Seq[5] [time_state_machine.vhd:64]

/TOP/A_BLOCK/ASM/SYNCH$Seq[11] [alarm_state_machine.vhd:58]

/TOP/A_BLOCK/ACOUNT/TIME_INC$Seq[8] [alarm_counter.vhd:21]

/TOP/T_BLOCK/TCOUNT/_P0$Seq[2] [time_counter.vhd:23]

Triggers total of 3 Cbf(s):

Compiling Your Design


5-44
cbf_id=0 level=1 name=[ TOP__SCHEMATIC_0_cbf_0 ]

cbf_id=8 level=1 name=[ TOP__SCHEMATIC_0_cbf_8 ]

cbf_id=14 level=1 name=[ TOP__SCHEMATIC_0_cbf_14 ]

The naming convention used for tgfs, tbfs, and cbfs is the entity and
architecture name separated by double underscores followed by the
function name, such as TOP__SCHEMATIC_0_cbf_0. Any
processes that are not specified a VHDL label are given a default
name by the simulator, such as _P0.

Examples of Various Trigger Types


This section provides some examples for the following types of
triggers: normal trigger, sensitivity list trigger, latch trigger, and loop
trigger.

Normal Trigger
Some examples of normal triggers and the elaboration results of the
triggers are shown here.

Example 1
This first example shows the trigger is executed on the positive edge
of the signal CLK, as denoted by pe(CLK).

process(clk,s)
begin
if clk’event and clk = ’1’ then
if s = ’1’ then
q <= "001";
else
q <= "111";
end if;
end if;
end process;

Compiling Your Design


5-45
A perf_data report with this trigger contains the following information:

No. id SeqPr Cbf CombPr Lev why trigger_conditions


--- ---- ---- --- ------ --- ------- -------------------
1 0 1 1 1 0 normal pe(CLK)

Tgf_id = 0: conditions [ pe(CLK) ] {1 event(s)}


Tgf_name [ ENT__RTL_0_tgf_0 ]
Controls 1 sequential process(es):
/ENT/_P0$Seq[1] [2arch.vhd:13]

Triggers total of 1 Cbf(s):


cbf_id=0 level=0 name=[ ENT__RTL_0_cbf_0 ]

Example 2
Another example of normal trigger conditions reported during cycle
elaboration. Two trigger functions are created here. One for the
asynchronous reset and one for the clk when the reset is 1.

process
begin
--if(reset = ’1’) then
if(reset = ’0’) then
q <= "000";
--elsif clk’event and clk = ’1’ then
elsif clk’event and clk = ’0’ then
if s = "001" then
q <= "001";
else
q <= "111";
end if;
end if;
end process;

The triggers reported in the output file are as follows:

No. id SeqPr Cbf CombPr Lev why trigger_conditions

Compiling Your Design


5-46
--- ---- ---- --- ------ --- ------- --------------------
1 0 1 0 0 -1 normal ne(RESET)
2 1 1 0 0 -1 normal ~0(RESET) ne(CLK)

The detailed trigger report for this trigger is shown below.

Tgf_id = 0: conditions [ pe(RESET) ] {1 event(s)}


Tgf_name [ ENT__RTL_0_tgf_0 ]
Controls 1 sequential process(es):
/ENT/_P0$Seq[1] [2arch.vhd:18]

Triggers total of 0 Cbf(s):


None.
These triggers all fit the coding style guidelines listed in the VHDL
Simulation Coding and Modeling Style Guide. Changes can be made
to the source code and re-elaborated to make improvements in the
design by reducing the trigger count. Fewer numbers of triggers
generally result in better simulation performance.

Sensitivity List Trigger


An example of a sensitivity list trigger is shown below.

pr_1: process(clk,reset,b)
begin
if (reset or b) = ’0’ then
q <= ’0’;
elsif (clk’event and clk = ’1’) then
q <= d;
end if;
end process;

VCS MX generates the following warning when this code is


elaborated for cycle simulation:

**Warning: cylab, SplitSeq-Complex-Trigger-


[complex_trig.vhd:16]:

Compiling Your Design


5-47
Sequential Process ’PR_1’ has a sequential region whose
trigger is too complicated. The sensitivity list will be
used as the trigger. This will result in degradation of
simulation performance.

The elaboration summary report contains the following information:

No. id SeqPr Cbf CombPr Lev why trigger_conditions


--- ---- ---- --- ------ --- ------- ------------------
1 0 1 1 1 0 normal ev(CLK) ev(RESET) ev(B)

The trigger generated uses the sensitivity list of the process to


execute the tgf.

Latch Trigger
The elaboration summary report of a latch trigger contains the
following information:

No. id SeqPr Cbf CombPr Lev why trigger_conditions


--- ---- ---- --- ------ --- ------- -------------------
51 21 1 1 12 0 latch ev(SMP_RDV_REG)
ev(SMPDR_REG) ev(SMPRR_REG)
ev(SMP_CDONE_REG) ev(FIB_SMP)
Tgf_id = 21: conditions [ ev(SMP_RDV_REG) ev(SMPDR_REG)
ev(SMPRR_REG) ev(SMP_CDONE_
REG) ev(FIB_SMP) ] {5 event(s)}
Tgf_name [ SIMTOP__SCHEMATIC_0_tgf_21 ]
Controls 1 sequential process(es):
/SIMTOP/SIDE0/I_CMI_CHIP/I_EPP_FB/I_EPP_SMP_FB/
I_EPP_SMP_LOGIC/SMP_CTRL_PROCESS
[epp_smp_logic.vhd:90]

Triggers total of 1 Cbf(s):


cbf_id=610 level=0 name=[ SIMTOP__SCHEMATIC_0_cbf_610 ]

Compiling Your Design


5-48
This latch trigger is generated due to latching of data. From the
information provided by the tgf_id data, you can revisit the source
code and make necessary changes to the source so that latches are
not inferred. See the VHDL Simulation Coding and Modeling Style
Guide for more details.

Loop Trigger
This example code creates a combinatorial feedback loop. VCS MX
breaks this loop and creates a loop trigger to execute the code.

entity fooA is
port(i1,i2,i3 :in integer; o1,o2,o3: out integer);
end fooA;

architecture A of fooA is
begin
P: process(i1,i2,i3)

begin
o1 <= i1 + 1;
o2 <= i2 + 1;
o3 <= i3 + 1;
end process;
end A;

entity E is
end E;

architecture A of E is

signal clk : bit;

signal Ai1 : integer;


signal Ao1,Ao2,Ao3 : integer;
signal Bo1,Bo2,Bo3 : integer;
signal Co1,Co2,Co3 : integer;
begin

Compiling Your Design


5-49
XA: fooA port map(Bo2,Co1,Co2,Ao1,Ao2,Ao3);
XB: fooA port map(Ao1,Ao2,Ao3,Bo1,Bo2,Bo3);
XC: fooA port map(Bo1,Bo2,Bo3,Co1,Co2,Co3);

The elaboration summary report contains the following information:

No. id SeqPr Cbf CombPr Lev why trigger_conditions


--- ---- ---- --- ------ --- ------- --------------------
1 0 1 1 27 0 loop ev(O1)

Removing combinatorial feedback loops improves the simulation


performance of the design. Numerous loop triggers degrade
simulation performance.

Using the vcs Command

This section describes the process for using the vcs command to
compile your design. The vcs command is entered at the command
line, along with a series of options.

For a complete description of the syntax of the vcs command, see


“vcs Command and Options” on page 4-11 of the VCS MX Reference
Guide.

At compile-time, the vcs command has to compile the Verilog code


that needs compilation, while, at the same time, the scs command
has to elaborate and compile the VHDL library units in the design.
There are four special compile-time options for compiling a Verilog
design that instantiates VHDL:

-mhdl
This option specifies mixed HDL simulation. It is required at the
command line for all mixed HDL simulation.

Compiling Your Design


5-50
+vhdllib+logical_libname
This option specifies the VHDL logical library to use for VHDL
design entity instances that you instantiate in your Verilog design.
See “Specifying The VHDL Logical Library” on page 4-52.
-vhdlelab "elaboration and compilation command line
options"
Specifies VCS MX elaboration and compilation options for scs,
the VCS MX compiler. In VCS MX VHDL simulation there are
three separate steps: analysis, elaboration and compilation (in
one step), and simulation. Elaboration and compilation must
happen before simulation so VCS starts the scs during Verilog
compilation.
+reflib+lib
Specifies which logical library to use to resolve Verilog instances
instantiated in the VHDL code. By default VCS MX uses all logical
libraries with a VERILOG directory in them.
For mixed HDL simulation, you can include all compile-time options
on the vcs command line, such as -Mupdate for incremental
compilation or -f for specifying a file listing the Verilog source file
names for your Verilog design and other compile-time options.

You can include the -R option to begin simulation right after


compilation instead of as a separate step, however doing so restricts
your ability to specify, through command line options on the simv
command line, how to simulate the VHDL part of the design.

Note that multiple Verilog top modules are supported.

Compiling Your Design


5-51
IMPORTANT:
For post-processing your design, using DVE or VirSim to
view the simulation results, you include the -PP compile-
time option. Including the -line compile time option
enables line tracing and source debugging. You can also
include the +vpdfile+filename compile-time option for
specifying the name of the output VCD+ file that DVE or
VirSim uses for post-processing.

You can include the -RI option to run VirSim interactively. See
“Compiling To Use VirSim Interactively” on page 4-58.

The following is an example of using the -mhdl option with the vcs
command:

vcs design.v -Mupdate -line -PP +cli+1 -mhdl

This example contains VCS compile time options: -Mupdate for


specifying incremental compilation, -line for enabling stepping
through the Verilog code and setting breakpoint in the Verilog code,
-PP to compile for post-processing, +cli+1 to see the values of
signals, and -mhdl to create a simv executable that can
communicate with VCS MX.

Specifying The VHDL Logical Library

You can use the +vhdllib compile-time option to specify the VHDL
logical libraries for the VHDL design entity instances that you
instantiate in your Verilog design. You use this option if the VHDL
logical library isn’t WORK. The format for this options is as follows:

+vhdllib+logical_library_name[+logical_library_name]

Compiling Your Design


5-52
If you are instantiating more than one VHDL design entity and these
design entities are from different VHDL logical libraries, you can
specify searching both logical libraries, and the order in which to
search, to resolve these instances by entering this option more than
once.

The following is an example of the use of the +vhdllib option:

vcs design.v -Mupdate -line -PP +cli+1 -mhdl +vhdllib+mylib1


+vhdllib+mylib2

This example specifies resolving VHDL design entity instances by


searching VHDL logical libraries mylib1 and mylib2. You can specify
the same thing with the following example:

vcs design.v -Mupdate -line -PP +cli+1 -mhdl


+vhdllib+mylib1+mylib2

Note:
Multiple entries of this option, or specifying multiple logic libraries
with this option, also specifies a search order of the logical
libraries. If there are design units with the same name in different
logical libraries, and you instantiate these design units in your
Verilog design and specify the different logical libraries with
multiple entries of the +vhdllib compile-time option, these
instances are resolved by the first logical library specified with this
option.

If you specify the VHDL logical library in the module instantiation


statement, this option does not override the logical library specified
in the statement.

Compiling Your Design


5-53
Using a Partition File

When you analyzed the source code, you had the option of analyzing
the design units in some or all of the source files to enable them to
be compiled for cycle-based mode (with the -cycle vhdlan
command line option). If you did you can now have these design units
compiled for cycle-based mode.You do this with a partition file.

In the partition file you specify design entities either by their entity
name or their configuration and whether all instances of them, and
unless otherwise specified all design entities hierarchically under the
specified design entities, simulate in cycle-based mode instead of the
default event-driven mode.

If you want some design entities that are instantiated lower in the
hierarchy to simulate in event-driven mode (for debugging) you can
specify that all instances of these design entities, and all those
hierarchically under them, simulate in event-driven mode with similar
entries in the partition file.

The format of a line in the partition file is as follows:

cycle | event entity_name | configuration_name

Consider the example in Figure 5-17:

Compiling Your Design


5-54
Figure 5-17 Hierarchy for a Partition File

entity VHTOP
architecture VHTOPARCH
in source file top.vhd

entity VHMID entity VHMID


architecture VHMIDARCH architecture VHMIDARCH
instance M1 instance M2
in source file mid.vhd in source file mid.vhd

entity VHBOT entity VHBOT entity VHBOT entity VHBOT


architecture VHBOTARCH architecture VHBOTARCH architecture VHBOTARCH architecture VHBOTARCH
instance B1 instance B2 instance B3 instance B4
in source file bot.vhd in source file bot.vhd in source file bot.vhd in source file bot.vhd

If you analyzed the source files as follows:

vhdlan -cycle bot.vhd


vhdlan -cycle mid.vhd
vhdlan -cycle top.vhd

Analyzing, as is always necessary, from the bottom-up and choosing


to include the -cycle option for faster performance.

If you wrote a partition file that contained just the following line:

cycle VHTOP

Then when VCS compiles the Verilog code that instantiates the VHDL
you enter the following:

vcs verilog_source.v -mhdl -vhdlelab "-partition


partition_file"

Compiling Your Design


5-55
The entire design simulates in cycle-based mode.

If the partition file contains the following:

cycle VHTOP
event VHMID

Figure 5-18 shows the parts of the hierarchy in cycle-based and event
driven simulation.

Figure 5-18 Partitioned Hierarchy for Cycle-Based and Event-Driven


Simulation

entity VHTOP
cycle-based architecture VHTOPARCH
in source file top.vhd

entity VHMID entity VHMID


event-driven
architecture VHMIDARCH architecture VHMIDARCH
instance M1 instance M2
in source file mid.vhd in source file mid.vhd

entity VHBOT entity VHBOT entity VHBOT entity VHBOT


architecture VHBOTARCH architecture VHBOTARCH architecture VHBOTARCH architecture VHBOTARCH
instance B1 instance B2 instance B3 instance B4
in source file bot.vhd in source file bot.vhd in source file bot.vhd in source file bot.vhd

If the partition file contains the following:

cycle VHTOP
event VHMID
cycle VHBOT

Compiling Your Design


5-56
Figure 5-19 shows the parts of the hierarchy in cycle-based and event
driven simulation.

Figure 5-19 Another Partitioned Hierarchy

entity VHTOP
cycle-based architecture VHTOPARCH
in source file top.vhd

entity VHMID entity VHMID


architecture VHMIDARCH
event-driven architecture VHMIDARCH
instance M1 instance M2
in source file mid.vhd in source file mid.vhd

cycle-based
entity VHBOT entity VHBOT entity VHBOT entity VHBOT
architecture VHBOTARCH architecture VHBOTARCH architecture VHBOTARCH architecture VHBOTARCH
instance B1 instance B2 instance B3 instance B4
in source file bot.vhd in source file bot.vhd in source file bot.vhd in source file bot.vhd

Some of the most commonly used vcs options are described below:

-PP
Enables post processing. Use this option for debugging only as it
slows down the simulation.
+cli+n (1 =< n =< 4)
Enables user interface.
-line
Enables line tracing. Use this option for debugging only as it
extremely slows down the simulation.

Compiling Your Design


5-57
+vcsd
Enables the Direct PLI interface.
+rad
Enables Radiant optimizations
+race
Enables “race” report generation
+notimingchecks
Specifies no timing simulation (used for parsing only)
+nospecify
Specifies no path delays (used for parsing only)

Compiling To Use VirSim Interactively

You can use VirSim interactively to debug the entire mixed HDL
design.

To use VirSim for interactive debugging include the -RI option on


the vcs command line just like you would for an entirely Verilog design.
This option starts the simulation and VirSim right after compilation.
There is however the following restriction: Do not include the -PP or
-I option to enable post-processing.

IMPORTANT:

• When you start VirSim for interactive simulation There is no way


that you can enter scsim command line options to tell VCS MX
how to simulate the VHDL part of the design.
• You can enter these commands on the simv command line but
you can’t start VirSim with an option on the simv command line.

Compiling Your Design


5-58
• If you need to both interactively simulate with VirSim and also
enter scsim command line options, you will need to interactively
simulate your design twice.
When simulation starts the VirSim windows will display both the
Verilog and VHDL parts of the design. You can enter CLI commands
in the Command field of the Interactive window that apply to both the
Verilog and VHDL part of the design.

Common Verilog Compilation Tasks

This section outlines some of the common tasks performed by the


vcs command.

Save and Restart


VCS provides a save and restart feature that allows checkpoints of
the simulation to be saved at arbitrary times. The resulting checkpoint
files can be executed at a later time, causing simulation to resume at
the point immediately following the save.

Note: Save and restart is not supported on Windows.

Benefits of save and restart include:

• Regular checkpoints for interactively debugging problems found


during long batch runs
• Use of plusargs to start action such as $dumpvars on restart
• Executes common simulation system tasks such as $reset just
once in a regression
Restrictions of save and restart include:

Compiling Your Design


5-59
• Requires extra Verilog code to manage the save and restart
• Must duplicate start-up code if handling plusargs on restart
• File I/O suspend and resume in PLI applications must be given
special consideration

Save and Restart Example


A simple example of save and restart is given below to demonstrate
the basic functionality.

The $save call does not execute a save immediately, but schedules
the checkpoint save at the end of the current simulation time just
before events scheduled with #0 are processed. Therefore, events
delayed with #0 are the first to be processed upon restart.

% cat test.v
module simple_restart;
initial begin
#10
$display("one");
$save("test.chk");
$display("two");
#0 // make the following occur at restart
$display("three");
#10
$display("four");
end
endmodule

Now to compile the example Source file:

vcs -Mupdate test.v

Now run the simulation:

simv

Compiling Your Design


5-60
VCS displays the following:

one
two
$save: Creating test.chk from current state of simv...
three
four

Now to restart the simulation from the state saved in the check file,
enter:

test.chk

VCS displays the following:

Restart of a saved simulation


three
four

Save and Restart File I/O


VCS MX remembers the files you opened via $fopen and reopens
them when you restart the simulation. If no file exists having the old
filename, VCS MX opens a new file with the old filename. If a file
exists having the same name and length at time of save as the old
file, then VCS MX appends further output to that file. Otherwise, VCS
attempts to open a file with filename equal to the old filename plus
the suffix .N. If a file with this name exists, VCS exits with an error.

If your simulation contains PLI routines that do file I/O, the routines
must detect both the save and restart events, closing and reopening
files as needed. You can detect save and restart calls using misctf
callbacks with reasons reason_save and reason_restart.

Compiling Your Design


5-61
When running the saved checkpoint file, be sure to rename it so that
further $save calls do not overwrite the binary you are running. There
is no way from within the Verilog source code to determine if you are
in a previously saved and restarted simulation, so you cannot
suppress the $save calls in a restarted binary.

Save and Restart with Runtime Options


If your simulation behavior depends on the existence of run-time
plusargs or any other run-time action (such as reading a vector file),
be aware that the restarted simulation uses the values from the
original run unless you add special code to process run-time events
after the restart action. Depending on the complexity of your
environment and your usage of the save and restart feature, this can
be a significant task.

For example, if you load a memory image with $loadmemb at the


beginning of the simulation and want to be able to restart from a
checkpoint with a different memory image, you must add Verilog code
to load the memory image after every $save call. This ensures that
at the beginning of any restart the correct memory image is loaded
before simulation begins. A reasonable way to manage this is to
create a task to handle processing arguments, and call this task at
the start of execution, and after each save.

A more detailed example follows to illustrate this. The first run


optimizes simulation speed by omitting the +dump flag. If a bug is
found, the latest checkpoint file is run with the +dump flag to enable
signal dumping.

// file test.v
module dumpvars();
task processargs;
begin
if ($test$plusargs("dump")) begin

Compiling Your Design


5-62
$dumpvars;
end
end
end task
//normal start comes here
initial begin
processargs;
end
// checkpoint every 1000 time units
always
#1000 begin
// save some old restarts
$system("mv -f save.1 save.2");
$system("mv -f save save.1");
$save("save");
#0 processargs;
end
endmodule
// The design itself here
module top();
.....
endmodule

Restarting at The CLI Prompt

The $restart system task has been implemented to allow you to


enter it at the CLI prompt. You enter it with the check file name created
by the $save system task, for example:

C1 > $restart("checkfile1");

Compiling Your Design


5-63
Specifying A Very Long Time Before Stopping
Simulation

You can use the +vcs+stop+time runtime option to specify the


simulation time when VCS MX halts simulation if the time value you
specify is less that 232 or 4,294,967,296. You can also use the
+vcs+finish+time runtime option to specify when VCS not just
halts but ends simulation but also under the proviso that the time
value be less than 232.

for time values greater than 232 you must follow a special procedure
that uses two arguments to the +vcs+stop or +vcs+finish
runtime options. This procedure is as follows:

1. Subtract 2 X 232 from the large time value.

So, for example if you want a time value of 10,000,000,000 (10


billion):

10, 000, 000, 000 – ( 2 • 4, 294, 967, 296 ) = ( 1, 410, 065, 408 )

Compiling Your Design


5-64
This difference is the first argument.

You can let VCS do some of this work for you, in this example
using the following source code:

module wide_time;
time wide;
initial
begin
wide = 64’d10_000_000_000;
$display(“Hi=%0d, Lo=%0d”, wide[63:32],
wide[31:0]);
end
endmodule

VCS displays:

Hi=2,Lo=1410065408

2. Divide the large time value by 232.

In this example:
10, 000, 000, 000
---------------------------------------------- = 2.33
4, 294, 967, 296
3. Round down this quotient to the whole number. This whole
number is the second argument.

In this example, you round down to 2.


You now have the first and second argument, therefore, in this
example to specify stopping simulation at time 10,000,00,000 you
enter the following runtime option:

+vcs+stop+1410065408+2

Compiling Your Design


5-65
Passing Values From The Runtime Command Line

The $value$plusargs system function can pass a value to a signal


from the simv runtime command line using a +plusarg. The syntax is
as follows:

integer = $value$plusargs("plusarg_format",signalname);

The plusarg_format argument specifies a user-defined runtime


option for passing a value to the specified signal. It specifies the text
of the option and the radix of the value that you pass to the signal.

The following code example contains this system function:

module valueplusargs;
reg [31:0] r1;
integer status;

initial
begin
$monitor("r1=%0d at %0t",r1,$time);
#1 r1=0;
#1 status=$value$plusargs("r1=%d",r1);
end
endmodule

If you enter the following simv command line:

simv +r1=10

The $monitor system task displays the following:

r1=x at 0
r1=0 at 1
r1=10 at 2

Compiling Your Design


5-66
Performance Considerations

When you simulate your design you can look for ways to improve the
simulation performance. There are run-time options that enable VCS
to simulate faster or slower. There is also a technique called profiling
that tells you which modules in your design take the most CPU time.

Runtime Options that Accelerate or Impede Simulation


Some runtime options enable VCS MX to simulate your design faster
because they allow VCS MX to skip certain operations. You should
consider using these run-time options. These runtime options are as
follows:

+vcs+dumpvarsoff Suppress $dumpvars system tasks.

+vcs+ignorestop Tells VCS to ignore the $stop system tasks in


your source code.

+notimingcheck Disables timing check system tasks. Using this


option at compile-time results in even faster
simulation than using it at runtime.

The run-time options that specify writing to a file that slow down
simulation. These run-time options are as follows:

-a filename All output of simulation is appended to filename as


well as sent to the standard output.

-l filename All output of simulation is written to filename as well


as to the standard output.

Other run-time options that specify operations other than the default
operations also slow down simulation to some extent.

Compiling Your Design


5-67
Profiling the Simulation

If you include the +prof compile-time option when you compile your
design, VCS MX generates the vcs.prof file during simulation. This
file contains a profile of the simulation. It reports the following:

• The module instances in the hierarchy that use the most CPU time
• The module definitions whose instances use the most CPU time
• The Verilog constructs in those instances that use the most CPU
time
You can use this information to see where in your design you might
be able to modify your code for faster simulation performance.

The profile data in the vcs.prof file is organized into a number of


“views” of the simulation. They are as follows:

• Top Level View


• Module View
• Instance View
• Module Construct Mapping View
• Top Level Construct View
• Construct View Across Design

The Top Level View


This view shows you how much CPU time was used by:

• Any PLI application that executes along with VCS

Compiling Your Design


5-68
• VCS for writing VCD and VCD+ files
• VCS for internal operations that can’t be attributed to any part of
your design
• The constructs and statements in your design.
The following is an example of the top level view:

===========================================================================
TOP LEVEL VIEW
===========================================================================
TYPE %Totaltime
---------------------------------------------------------------------------
PLI 0.00
VCD 0.00
KERNEL 29.06
DESIGN 70.94
---------------------------------------------------------------------------

In this example there is no PLI application and VCS is not writing a


VCD or VCD+ file. VCS used 70.94% of the CPU time to simulate the
design, and 29.06% for internal operations, such as scheduling, that
can’t be attributed to any part of the design. The designation KERNEL,
is for these internal operations.

The designation VCD is for the simulation time used by the callback
mechanisms inside VCS for writing either VCD or VCD+ files.

If there was CPU time used by a PLI application, you could use a tool
such as gprof or Quantify to profile the PLI application.

The Module View


This view shows you the module definitions whose instances use the
most CPU time. Module definitions whose module instances
collectively used less than 0.5% of the CPU time are not listed.

Compiling Your Design


5-69
The following is an example of the module view:

===========================================================================
MODULE VIEW
===========================================================================
Module(index) %Totaltime No of Instances Definition
---------------------------------------------------------------------------
FD2 (1) 62.17 10000 design.v:142.
EN (2) 8.73 1000 design.v:131.
---------------------------------------------------------------------------

In this example there are two module definitions whose instances


collectively used a significant amount of CPU time, modules FD2 and
EN.

The profile data for module FD2 is as follows:

• FD2 has an index number of 1. This index number is used in other


views that show the hierarchical names of module instances. The
index is for associating a module instance with a module definition
because module identifiers do not necessarily resemble the
hierarchal names of their instances.
• The instances of module FD2 used 62.17% of the CPU time.
• There are 10,000 instances of module FD2. The number of
instances is a way to assess the CPU times used by these
instances. For example, as in this case, a high CPU time with a
corresponding high number of instance tells you that each
instance isn’t using very much CPU time.
• The module header, the first ling of the module definition, is in
source file design.v on line 142.

Compiling Your Design


5-70
The Instance View
This view shows you the module instances that use the most CPU
time. An instance must use more than 0.5% of the CPU time to be
entered in this view.

The following is an example of the instance view:

===========================================================================
INSTANCE VIEW
===========================================================================
Instance %Totaltime
---------------------------------------------------------------------------
test.lfsr1000_1.lfsr100_1.lfsr10_1.lfsr_1.en_
1 ( 2 ) 0.73

---------------------------------------------------------------------------

In this example there is only one instance that uses more that 0.5%
of the CPU time.

This instance’s hierarchical name is


test.lfsr1000_1.lfsr100_1.lfsr10_1.lfsr_1.en_1. Long hierarchical
names wrap to the next line.

The instance’s index number is 2, indication that it is an instance of


module EN, which had an index of 2 in the module view.

This instance used 0.73% of the CPU time.

No instance of module FD2 is listed here so no individual instance of


FD2 used more that 0.5% of the CPU time.

Note:
It is very common for no instances to appear in the instance view.
This happens when many instances use some of the simulation
time but none use more than 0.5% of the total simulation time.

Compiling Your Design


5-71
The Module to Construct Mapping View
This view shows you the CPU time used by different types of Verilog
constructs in each module definition in the module view. There are
the following types of Verilog constructs:

• always constructs (commonly called always blocks)


• initial constructs (commonly called initial blocks)
• module path delays in specify blocks
• timing check system tasks in specify blocks
• combinational logic including gates or built-in primitives and
continuous assignment statements
• user-defined tasks
• user-defined functions
• module instance ports
• user-defined primitives (UDPs)
• Any Verilog code protected by encryption
Ports use simulation time particularly when there are expressions in
port connection lists such as bit or part selects and concatenation
operators.

This view has separate sections for the Verilog constructs for each
module definition in the module view.

The following is an example of a module to construct mapping view:

===========================================================================
MODULE TO CONSTRUCT MAPPING
===========================================================================

Compiling Your Design


5-72
___________________________________________________________________________
1. FD2
---------------------------------------------------------------------------
Construct type %Totaltime %Moduletime LineNo
---------------------------------------------------------------------------
Always 27.44 44.14 design.v : 150-160.
Module Path 23.17 37.26 design.v : 165-166.
Timing Check 11.56 18.60 design.v : 167-168.
___________________________________________________________________________

___________________________________________________________________________
2. EN
---------------------------------------------------------------------------
Construct type %Totaltime %Moduletime LineNo
---------------------------------------------------------------------------
Combinational 8.73 100.00 design.v: 137.
___________________________________________________________________________

For each construct the view reports the percentage of “Totaltime” and
“Moduletime”.

%Totaltime
The percentage of the total CPU time that was used by this
construct.
%Moduletime
Each module in the design uses a certain amount of CPU time.
This percentage is the fraction of the module’s CPU time that was
used by the construct.

Compiling Your Design


5-73
In the section for module FD2:

• An always block in this module definition used 27.44% of the


TOTAL CPU time. Of all the CPU time consumed by all instances
of the FD2 module, 44.14% is spent on this construct (44.14% of
62.17% = 27.44%). The always block is in source file design.v
between lines 150 and 160.

If there were another always block in module FD2 that used more
than 0.5% of the CPU time, there would be another line in this
section for it, beginning with the always keyword.
• The module path delays in this module used 23.17% of the TOTAL
CPU time. Of all the CPU time consumed by all instances of the
FD2 module, 37.26% is spent on this construct. These module
path delays can be found on lines 165-166 of the design.v source
file.
• The timing check system tasks in this module used 11.56% of the
TOTAL CPU time. Of all the CPU time consumed by all instances
of the FD2 module, 18.60% is spent on this construct. These
timing check system tasks can be found on lines 167-167 of the
design.v source file.
In the section for module EN, a construct classified as Combinational
used 8.73 of the total CPU time. 100% of the CPU time used by all
instances of EN were used for this combinational construct.

No initial blocks, user-defined functions, or user-defined tasks, ports,


UDPs, or encrypted code in the design used more than 0.5% of the
CPU time. If there were, there would be a separate line for each of
these types of constructs.

Compiling Your Design


5-74
The Top Level Construct View
This view show you the CPU time used by different types of Verilog
constructs throughout the design. The following is an example of the
Top Level Construct View:

===========================================================================
TOP-LEVEL CONSTRUCT VIEW
---------------------------------------------------------------------------
Verilog Construct %Totaltime
---------------------------------------------------------------------------
Always 27.47
Module Path 23.17
Timing Check 11.56
Combinational 8.73
Initial 0.00
Function 0.00
Task 0.00
Port 0.00
Udp 0.00
Protected 0.00

___________________________________________________________________________

This view contains a line for each type of construct, for example, all
the always blocks in the design used 27.47% of the CPU time.

The Construct View Across Design


This view shows you the module definitions that contains a type of
construct that used more that 0.5% of the CPU time. There are
separate sections for each type of construct and a listing in each
section of the modules that contain that type of construct.

The following is an example of the construct view across design:

===========================================================================
CONSTRUCT VIEW ACROSS DESIGN
===========================================================================

Compiling Your Design


5-75
___________________________________________________________________________
1.Always
---------------------------------------------------------------------------
Module %TotalTime
---------------------------------------------------------------------------
FD2 27.44
___________________________________________________________________________

___________________________________________________________________________
2.Module Path
---------------------------------------------------------------------------
Module %TotalTime
---------------------------------------------------------------------------
FD2 23.17
___________________________________________________________________________

___________________________________________________________________________
3.Timing Check
---------------------------------------------------------------------------
Module %TotalTime
---------------------------------------------------------------------------
FD2 11.56
___________________________________________________________________________

___________________________________________________________________________
4.Combinational
---------------------------------------------------------------------------
Module %TotalTime
---------------------------------------------------------------------------
EN 8.73
___________________________________________________________________________

How VCS Prevents Time 0 Race Conditions

At simulation time 0, VCS always executes the always blocks in which


any of the signals in the event control expression that follows the
always keyword (the sensitivity list) initialize at time 0.

For example, consider the following code:

module top;

Compiling Your Design


5-76
reg rst;
wire w1,w2;
initial
rst=1;
bottom bottom1 (rst,w1,w2);
endmodule

module bottom (rst,q1,q2);


output q1,q2;
input rst;
reg rq1,rq2;

assign q1=rq1;
assign q2=rq2;

always @ rst
begin
rq1=1’b0;
rq2=1’b0;
$display("This always block executed!");
end
endmodule

With other Verilog simulators there are two possibilities at time 0:

• The simulator executes initial block first, initializing reg rst, then
the simulator evaluates the event control sensitivity list for the
always block and executes the always block because rst
initialized.
• The simulator evaluates the event control sensitivity list for the
always block, and so far reg rst has not changed value during this
time step so the simulator does not execute the always block, then
the simulator executes the initial block and initializes rst. When
this happens the simulator does not re-evaluate the event control
sensitivity list for the always block.

Compiling Your Design


5-77
Compiling and Elaborating Verilog in a Mixed-HDL
Design

VCS MX supports VCS compilation options for controlling the


compilation Verilog portion of a mixed-HDL design. For default
compilation of Verilog portion (default performance, no debugging or
post-processing capabilities), you can use -mhdl switch at the scs
command line instead of -verilogcomp “ “.

In case you wish to get more performance or enable interactive or


post-processing debug capabilities, you need to specify additional
Verilog compilation/code generation options. You can specify all of
them through the -verilogcomp option. You can specify one or
multiple options between quotation marks. The syntax is -

% scs LIB.cfg -mhdl

Or

% scs LIB.cfg -verilogcomp “VCS_code-gen_options”

More examples,

% scs lib.cfg_design -mhdl


% scs lib.cfg_design -verilogcomp “+rad”
% scs lib.cfg_design -verilogcomp “-PP”

In this step, Verilog portion of the design is compiled and the full
design is elaborated. Errors in Verilog compilation and full design
elaboration are reported. You must fix the errors in case they occur.

By default, eight language layers of VHDL/Verilog are supported. In


case your design has more language layers than eight, use
-maxLayers option to increase the language layers. For example -

Compiling Your Design


5-78
% scs LIB.cfg -maxLayers 10 -mhdl

Note:
Ideally, you should not use any Verilog parsing or reference
resolving options and Verilog source files through
-verilogcomp. But, if you are an advanced mixed language
simulation user, and in case you want to provide all the Verilog
source files during actual code-generation time, you can pass
them within -verilogcomp option. This will have higher
precedence over the already parsed Verilog source files. We do
not encourage using this feature in normal circumstances as there
is a probability of wrong modules getting picked up resulting in
incorrect simulation,

Resolving References

By default, elaboration will look into WORK library for resolving VHDL
and Verilog references within Verilog modules.

Elaboration also automatically searches all the logical libraries in the


order they are specified in the synopsys_sim.setup file to resolve
references.

Note:
This may sometimes result into wrong design units getting picked
up automatically from wrong libraries. If you suspect that you are
running into this case, consider using the options +vhdllib+LIB
and +reflib+LIB either during vlogan (along with -resolve)
or within -verilogcomp.

Compiling Your Design


5-79
Compiling Your Design
5-80
6
VCS MX Flow Examples 1
This chapter provides the following:

• VHDL-Top Mixed Language Flow Example


• Verilog-Top Mixed Language Flow Example
• VCS MX Flows at a Glance

Getting Started
6-1
VHDL-Top Mixed Language Flow Example

The following example illustrates some basic commands used in a


typical VHDL-top multi-layer multi-language design. The source files
can be complied in the “WORK” or other logical libraries. Resolving
the VHDL references in the Verilog modules can be relaxed or
enforced using different options.

TB_TOP (VHDL)

TOP (Verilog)

BETA (Verilog) ALPHA (VHDL)

GHI (VHDL) JKL (Verilog) ABC (VHDL) DEF (Verilog)

MNO (VHDL)

Design Hierarchy
TB_TOP (VHDL)
TOP (Verilog)
ALPHA (VHDL)
ABC (VHDL)
DEF (Verilog)
MNO (VHDL)
BETA (Verilog)
GHI (VHDL)
JKL (Verilog)

Getting Started
6-2
Setup File
Library mappings in the synopsys_sim.setup file -

WORK > DEFAULT


DEFAULT : ./work
L1 : ./lib1
L2 : ./lib2
LIB_ALIB_A : ./a_lib
LIB_B : ./b_lib
TOP_LIB : ./t_lib
TB_TOP_LIB : ./tbt_lib

Analyze
You can analyze VHDL and Verilog source code into the WORK or
different logical libraries.

Scenario 1. In case you want all the source code compiled in WORK:

Analyze all the Verilog source files in WORK

% vlogan DEF.v
% vlogan BETA.v -v JKL.v
% vlogan TOP.v

Next, analyze all the VHDL files in WORK (bottom up)

% vhdlan MNO.vhd ABC.vhd


% vhdlan ALPHA.vhd
% vhdlan GHI.vhd

% vhdlan TB_TOP.vhd

By default, all the intermediate compiled output will go to physical


directory mapped to logical library WORK

Getting Started
6-3
Scenario 2. You can analyze VHDL design units in logical libraries
other than WORK

% vlogan DEF.v
% vlogan BETA.v -v JKL.v
% vlogan TOP.v

% vhdlan -work L1 MNO.vhd ABC.vhd


% vhdlan -work LIB_A ALPHA.vhd
% vhdlan -work L2 GHI.vhd

% vhdlan TB_TOP.vhd

In both the above cases, by default, the VHDL references in Verilog


modules will not be resolved.

In most practical design scenarios, you will need to use only the two
different usage examples shown above. But for some specific
scenarios in which you wish to analyze both VHDL and Verilog in
different logical libraries and need to resolve the references before
final elaboration of the design, you will need to use the following third
usage example:

Scenario 3. In case you want the instantiated VHDL references to


get resolved during vlogan step, you need to analyze lower level
VHDL design units in respective logical libraries and use -resolve
switch along with +vhdllib+LIB.

For example,

% vhdlan -work L1 MNO.vhd ABC.vhd


% vlogan DEF.v -resolve +vhdlib+L1
% vhdlan -work LIB_A ALPHA.vhd

% vhdlan -work L2 GHI.vhd


% vlogan BETA.v -v JKL.v -resolve +vhdllib+L2

Getting Started
6-4
% vlogan TOP.v -resolve +vhdllib+LIB_A

% vhdlan -work tb_TOP_LIB TB_TOP.vhd

You can delay resolving the lower level VHDL design units (the ones
instantiated in Verilog modules) till elaboration/compiltion step.
Please see the example in following section.

Scenario 4. In case you want to analyze Verilog modules in logical


libraries other than WORK, you can use -WORK LIB switch for
vlogan. In this case, you need to declare the library and Use clauses
in the VHDL design units which instantiate Verilog modules.

% vlogan -work L1 DEF.v


% vlogan -work L2 JKL.v
% vlogan -work LIB_B BETA.v
% vlogan -work TOP_LIB TOP.v

% vhdlan -work L1 MNO.vhd ABC.vhd


% vhdlan -work LIB_A ALPHA.vhd

% vhdlan -work L2 GHI.vhd

% vhdlan -work TB_TOP_LIB TB_TOP.vhd

Scenario 5. In case you want the Verilog parser to resolve the


references of instantiated VHDL modules, you need to analyze those
VHDL modules before analyzing Verilog modules and also use
-resolve +vhdllib+LIB as in case of scenario 4 above. For
resolving Verilog modules within within Verilog, if compiled in
separate libraries (BUNIT instantiating JKL and TOP instantiating
BUNIT), you can use -resolve +reflib+LIB along with other
options. For example,

% vhdlan -work L1 MNO.vhd ABC.vhd


% vlogan -work L1 DEF.v -resolve
% vhdlan -work LIB_A ALPHA.vhd

Getting Started
6-5
% vhdlan -work L2 GHI.vhd
% vlogan -work L2 JKL.v
% vlogan -work LIB_B BETA.v -resolve +vhdllib+L2
+reflib+L2

% vlogan -work TOP_LIB TOP.v -resolve +vhdllib+LIB_A


+reflib+LIB_B

% vhdlan TB_TOP.vhd

Note, since you are analyzing DEF.v in library L1 which is same as


where you analyzed instantiated VHDL design unit MNO, you don’t
need to specify +vhdllib+L1 for resolving MNO reference.

Elaboration/Compilation
Depending upon where the top level design unit gets compiled and
whether default verilog compilation options or specific code
generation options need to be used, you can elaborate and compile
the design with following commands -

% scs -mhdl LIB.TB_TOP

or to also specify Verilog compilation options:

% scs TB_TOP -verilogcomp “<VCS Code Generation Options>”

In case you analyzed VHDL and/or Verilog designs into libraries other
than WORK and did not resolve the references using -resolve
+vhdllib+LIB during vlogan pahse, then, you can specify those
libraries within -verilogcomp. For example -

% scs TB_TOP -verilogcomp “+vhdllib+L1+l2+LIB_A


+reflib+L1+L2+LIB_B+TOP_LIB”

Getting Started
6-6
Simulation
The VHDL-top simulation command will be as follows:

% scsim

You can also specify Verilog runtime options, as shown belows:

% scsim -verilogrun “<VCS Runtime Options>”

Getting Started
6-7
Verilog-Top Mixed Language Flow Example

The following example illustrates some basic command sequences


used in a typical Verilog-top multi-layer mixed-HDL design. The
source files can be complied in the “WORK” or other logical libraries.
Resolving the VHDL references in the Verilog modules can be relaxed
or enforced using different options.

TB_TOP (Verilog)

TOP (VHDL)

BUNIT (Verilog) AUNIT (VHDL)

GHI (VHDL) JKL (Verilog) ABC (VHDL) DEF (Verilog)

MNO (VHDL)

Design Hierarchy
TB_TOP (Verilog)
TOP (VHDL)
ALPHA (VHDL)
ABC (VHDL)
DEF (Verilog)
MNO (VHDL)
BETA (Verilog)
GHI (VHDL)
JKL (Verilog)

Getting Started
6-8
Setup File
Library mappings in the synopsys_sim.setup file:

WORK > DEFAULT


DEFAULT : ./work
L1 : ./lib1
L2 : ./lib2
LIB_ALIB_A : ./a_lib
LIB_B : ./b_lib
TOP_LIB : ./t_lib
TB_TOP_LIB : ./tbt_lib

Analyze
You can analyze VHDL and Verilog source code in the WORK or
different logical libraries.

Scenario 1. In case you want all the source code compiled in WORK:

Analyze all the appropriate Verilog source files in WORK:

% vlogan DEF.v
% vlogan BETA.v -v JKL.v

Next, analyze all the VHDL files in WORK (bottom up)

% vhdlan MNO.vhd ABC.vhd


% vhdlan ALPHA.vhd
% vhdlan GHI.vhd
% vhdlan TOP.vhd

By default, all the intermediate compiled output will go to physical


directory mapped to logical library WORK

Scenario 2. You can analyze VHDL design units in logical libraries


other than WORK :

Getting Started
6-9
% vlogan DEF.v
% vlogan BETA.v -v JKL.v
%

% vhdlan -work L1 MNO.vhd ABC.vhd


% vhdlan -work LIB_A ALPHA.vhd
% vhdlan -work L2 GHI.vhd
% vhdlan TOP.vhd

Elaboration/Compilation
Depending upon where the top level design unit gets compiled and
whether default verilog compilation options or specific code
generation options need to be used, you can elaborate and compile
the design with following commands :

% vcs -mhdl LIB.TB_TOP

or to also specify VHDL elaboration options:

% vcs TB_TOP -vhdlelab “<VHDL Elab Options>”

Simulation
The simulation command will be as follows:

% simv

You can also specify VHDL runtime options, as shown belows:

% simv -vhdlrun “<VHDL Runtime Options>”

Getting Started
6-10
VCS MX Flows at a Glance

The following table outlines command sequences for common VCS


MX flows:

VHDL Only VHDL-Top Verilog Only Verilog-Top


Default vhdlan vlogan vcs *.v vlogan
scs vhdlan simv vhdlan
scsim scs -mhdl vcs tb.v -mhdl
scsim -verilogrun simv
" "
Coverage vhdlan vlogan vcs -cm * vlogan
scs -cm * vhdlan simv -cm * vhdlan
scsim -cm * scs -cm * - vcs -cm * -vhdlelab
verilogcomp "-cm" "-cm *" tb.v
scsim -verilogrun simv -cm -vhdlrun
"-cm" "-cm *"

Profiler vhdlan vcs +prof vhdlan


scs vlogan simv vlogan
scsim -profile scs -verilogcomp vcs -mhdl +prof
<filename.html> "+prof" simv -vhdlrun
scsim -profile "-profile
<filename.html> filename.html"
SDF Back- vhdlan vlogan vcs vlogan
Annotation scs +notimingchecks ($sdf_annotate +notimingchecks
scsim -sdf ... vhdlan in src) vhdlan
scs simv vcs
($sdf_annotate ($sdf_annotate
in vlogsrc) in src)
scsim -sdf ... simv

Debug vhdlan vlogan vcs +cli+N-PP -l vlogan


scs vhdlan -line *.v vhdlan
scsim -debug scs -verilogcomp simv vcs +cli+N-PP -l
"-PP +cli+4 -line -line tb.v -mhdl
-l" simv -vhdlrun
scsim -debug_all "- debug_all"
verilog_run " "
Performance vhdlan vlogan vcs +rad *.v vlogan
scs -4s vhdlan -4s simv vhdlan -4s
scsim scs -4s vcs +rad -vhdlelab
-verilogcomp "-4s" tb.v
"+rad" simv
scsim -verilogrun
" "
SVA For details, see For details, see
page 11-2 page 11-4

Getting Started
6-11
VHDL Only VHDL-Top Verilog Only Verilog-Top
OVA ovaan *.ova ovaan *.ova ovaan *.ova ovaan *.ova
vhdlan vhdlan vcs -ova tb.v vhdlan
scs -ova vlogan simv-ovarun vlogan
scsim -ovarun scs -mhdl cfg_tb "ova_runt_flag vcs -ova tb.v
"ova_runt_flags" -ova s" simv -ovarun
scsim -ovarun "ova_runt_flag
"ova_runt_flags"
Specman For details, see For details, see For details, see
page D-6 page D-6 page D-10

Getting Started
6-12
7
Simulating Your Design 2
There are two basic methods you can use to simulate your MX design:

• If you analyzed and compiled your design as VHDL-only or VHDL-


top, you will run a simulation using the scsim executable. For
details on this process, see “Running and Controlling a Simulation
Using the scsim Executable” on page 7-2.
• If you compiled your design as Verilog-only, or Verilog-top, you
will run a simulation using the simv executable. For details on
this process, see “Running and Controlling a Simulation Using the
simv Executable” on page 7-41.

Using scsim to Simulate Your Design


7-1
Running and Controlling a Simulation Using the scsim
Executable

This section explains how to run and control a simulation using the
scsm executable from either the command line or the Graphical User
Interface (GUI). The following topics are covered:

• Invoking a Simulation at the Command Line


• Invoking a Simulation From the VCS MX GUI
• Common scsim Simulation Options
• Using the VCS MX Control Lanaguage Commands
• Reading Simulation Profiler Results
• Invoking the Graphical User Interface

Invoking a Simulation at the Command Line

To invoke scsim, enter the following at the command line:

% scsim [options]

The options are one or more scsim options that enable you to control
how VCS MX executes the simulation. For a complete list of scsim
options, see the “To find the VHDL processes that are combined to
create this function, cross-reference the combinational function name
in the static elaboration report as we did earlier with the trigger
function. section in this chapter.

Using scsim to Simulate Your Design


7-2
After entering scsim, a simulation prompt will appear at the command
line. You control and monitor the simulation by entering VCS MX
VHDL Command Language (SCL) commands at the simulation
prompt (#). Detailed descriptions of these commands are available
in the VCS MX Reference Guide.

Invoking a Simulation From the VCS MX GUI

To start the VCS MX GUI, type the following at the command line

% scirocco &

To invoke the simulator, do the following:

1. Click on Interactive menu button.


The Simulator Invocation Dialog window appears, as shown in
the following figure.

Using scsim to SimulateYour Design


7-3
2. In the simulator invocation dialog window
- Type the scsim invocation command in Simulator Command
Line box as follows:
scsim

- Click OK to open VirSim Interactive window.


The design is loaded into the Virsim Interactive window and a
command prompt appears in the middle of the window to indicate
that the design is ready for simulation.

Common scsim Simulation Options

Some of the more commonly used scsim options enable you to


perform the following tasks:

Using scsim to Simulate Your Design


7-4
• Simulate in functional VITAL mode
• Switch simulation to full debug mode
• Profile the simulation
• Simulate with SDF backannotation
• Queue simulation licenses
• Relax VHDL LRM conformance checking

Functional VITAL Simulation


When simulation your design in event mode, use -novitaltiming
option to enable functional VITAL simulation mode. Using this option
eliminates all timing-related aspects from the simulation of VITAL
components. Timing-related aspects that are eliminated include Wire
Delays, Path Delays, and Timing Checks. All outputs are assigned
with 0-delay. The elimination of timing from the simulation of the
VITAL components significantly improves performance of event
simulations.

To enable functional VITAL for a scsim compiled for event


simulation, type

% scsim -novitaltiming

For cycle mode simulations, VITAL components that are instantiated


in the cycle partitions are automatically simulated using functional
VITAL, there is no need to specify -novitaltiming option.

Note:
Full-timing simulation of VITAL components cannot be performed
using cycle mode simulation.

Using scsim to SimulateYour Design


7-5
Functional VITAL simulation applies to Level 1 compliant
components. When using VITAL Level 0 compliant models, ensure
that the coding style of the architecture closely follows that required
for Level 1 compliant models in any of the timing areas (Wire Delay,
Path Delay, and Timing Checks) that the model includes.

Because there are no rules and guidelines for the architecture's


coding style in a Level 0 compliant model, VCS MX might not correctly
ignore and only ignore the timing aspects of a Level 0 model. It is
recommended that Level 0 architectures follow, as closely as
possible, the style of Level 1 architectures to ensure that VCS MX
correctly identifies the timing aspects of the model.

If you encounter problems in simulating Level 0 compliant VITAL


models in functional VITAL or cycle mode, contact the Synopsys
Technical Support Center for help on the coding style.

Note:
Because all VITAL Level 1 compliant models are also Level 0
compliant, it is important to note that this guideline applies only to
those models which are only Level 0 compliant and not Level 1
compliant.

Because functional VITAL discards all timing accuracy, this capability


results in all SDF information being ignored. As a result, simulation
results may not be correct if the simulation depends on timing
accuracy.

Using scsim to Simulate Your Design


7-6
Switching a Simulation to Full Debug Mode
When you compile your design to run in compiled event mode, mixed
event and cycle mode, or full cycle-based mode, you can switch
running the simulation to full debug mode where source line stepping
is enabled and you have full visibility to all design objects. This most
useful when you run simulation and you hit a bug in the design that
you decide to debug. You do not have to re-compile the design for
debug mode, just use the -debug_all option. Using this option
enables debug mode on the entire design, but simulation
performance is greatly impacted.

If you want to enable debugging for only one or few design units but
not the entire design, use the -debug_unit option. For example,

% scsim -debug_unit lib.ent_name

Profiling the Simulation


To generate the simulation profile report, use the -profile option
on the scsim command line. For example,

% scsim -profile prof_out.html

The -profile option produces a formatted HTML report. This report


is divided into four major sections that contain related information
about the various phases of simulation, event simulation processes,
cycle trigger and testbench functions, and cycle combinational
processes. See “Reading Simulation Profiler Results” section for
more information about how to read the profile.

See the “To find the VHDL processes that are combined to create
this function, cross-reference the combinational function name in the
static elaboration report as we did earlier with the trigger function.”
section for more information about using this option.

Using scsim to SimulateYour Design


7-7
Simulating with SDF Backannotation
You can backannotate timing information from files in Standard Delay
File (SDF) format into your design before simulation. SDF format is
commonly used to communicate timing information among different
simulators, synthesis tools, and layout tools.

To use SDF backannotation in VCS MX, use the -sdf option with
scsim. The syntax to use SDF is

% scsim -sdf [min:|typ:|max:][region:] sdf_file]]

The SDF options allow you to indicate whether to use the minimum,
typical, or maximum SDF values for backannotation. If you do not
specify a value, VCS MX uses the typical timing values. The region
indicates the portion of the design to backannotate using timing
values from the sdf_file.

You can specify one or more SDF files to annotate the entire VHDL
design or any portion of the hierarchy. For example, the following
uses timing data from two different SDF files to annotate two different
portions of a design:

% scsim -sdf /E/UUT/DESIGN1:myfile1.sdf \


-sdf max:/E/UUT/DESIGN2:myfile2.sdf

The above command

• Backannotates the VHDL design, starting from /E/UUT/


DESIGN1, with typical timing values (the default) from the SDF
file myfile1.sdf.
• Backannotates the VHDL design starting from /E/UUT/DESIGN2
with the maximum timing values from the SDF file myfile2.sdf.

Using scsim to Simulate Your Design


7-8
The following example shows how to use two SDF files to
backannotate the same portion of a VHDL design:

% scsim -sdf min:/E/UUT/DESIGN:myfile1.sdf -sdf myfile2.sdf

The above command backannotates the VHDL design starting from


/E/UUT/DESIGN using the minimum timing values from both
myfile1.sdf and myfile2.sdf.

For information about using SDF version 3.0, see “SDF Version 3.0”
in Appendix A of the VCS MX Reference Guide.

License Queueing
License queueing provides you with an effective way to make use of
your purchased licenses. It is a much needed feature for situations
such as mixedHDL and/or a simulation farm environment.

With license queueing, a "Ctrl-Z" or "Ctrl-C" will release the license


immediately, enabling another job to check out the license instead of
terminating. When resuming a job that is suspended by "Ctrl-Z," the
job will re-acquire any available licenses or wait for the next available
license (up until the timeout time specified). In addition, ^C and ^Z
sent through VHPI is also supported by the license queueing feature.
License queueing also works in cases where checkpoint/restore is
used.

Using scsim to SimulateYour Design


7-9
With license queueing enabled, the job(s) can wait for the time
specified by you in hours before timing out. This enables you to queue
up more simultaneous jobs than your total number of licenses, and
be confident that all the jobs will run. You will need to specify a timeout
time long enough for all the jobs to run. This feature is extremely
beneficial in the simulation farm environment. Also, mixedHDL
simulation supports license queueing since both VCS and
VCS MX have support for this feature.

Enabling License Queueing


There are two ways to enable the license queueing feature:

1. To enable license queueing for VCS MX at runtime, use with


scsim the -licwait option along with a timeout time in hours,
which will be the time the simulator will wait until finally giving up.
The timeout time should be an integer greater than zero; any
decimal part of the number will be ignored.

For example, to let the simulation job wait up to 4 hours before


giving up, use
% scsim -licwait 4 -include cmd.input

Using scsim to Simulate Your Design


7-10
2. The second way to turn this feature on is to specify the
LICENSE_WAIT_TIME variable in the synopsys_sim.setup
file and assign it to the ultimate timeout time. If the variable is not
present in the setup file, or if the variable is assigned an integer
less than or equal to zero, license queueing will be off. Once again,
any decimal places will be ignored. Below is the line you would
add to the setup file to enable license queueing.

LICENSE_WAIT_TIME = 4

With the LICENSE_WAIT_TIME variable in the setup file set to


an integer, you do not have to specify the -licwait option as a
runtime option. However, if you do specify the -licwait option
at runtime, this will override the setting in the setup file.

Relaxing VHDL LRM Conformance Checking


You can relax various VHDL Language Reference Manual (LRM)
checks performed on your design. These checks include

• Integer to natural connections


To turn on relaxed checking to allow mapping ports of type integer
to ports of type natural, use the scsim -xlrm option. It is to be
noted that an illegal value could be passed from the integer to the
natural number, resulting in a potential error in your simulation run.

• Driving a slice of a resolved composite signal


Use the scsim -xlrm to allow a process to drive just a slice or
subset of a resolved composite signal. Simulation proceeds by
creating drivers for the undriven subset and initializing them with
the initial value of the subset of the corresponding target signal.
Previously, an error was issued in this situation per the LRM.

Using scsim to SimulateYour Design


7-11
Using the VCS MX Control Lanaguage Commands

You can use basic VCS MX Control Language commands to perform


the following tasks:

• Run the simulator


• Interrupt the simulator
• Restart the simulator
• Quit the simulator
You can also use more advanced programming constructs to control
simulation flow. For information about using command procedures
and programming with simulator commands, see “VCS MX Control
Language” in Chapter 6 of the VCS MX Reference Guide.

The Unified Command-line Interface (UCLI) is for an interactive


simulation or for a post-processing simulation using the UCLI
interactive command language common to and consistent over
multiple Synopsys verification technologies. We would encourage
you to use UCLI as a default VCS MX control language for debugging,
for interactive and post-processing simulations, and more. For more
details on UCLI, see “Unified Command-line Interface” document
available under VCS MX installation directory.

Using scsim to Simulate Your Design


7-12
Running the Simulator
When you run the simulator, you can specify the number of simulation
timebase units you want the simulation to run. The simulation
timebase unit is defined by

• The TIMEBASE variable value in the synopsys_sim.setup file.


• The value specified by the -t base_time option to the scs
command.
To run the simulation for a specific amount of time, enter

# run time [timeunit]

If timeunit is not specified, the command runs the simulation for


time (in simulation base_time units) and stops.

You can also run the simulation until the end of simulation time by
entering either:

# run

Or

scsim -R

Interrupting the Simulator


Interrupting the simulator halts simulator execution immediately. You
can interrupt the simulator by entering Control-c at the simulator
prompt.

To interrupt the simulator from the simulator prompt, use the Control-
c key sequence. The interrupt character Control-c is terminal-
dependent.

Using scsim to SimulateYour Design


7-13
If you are running a compiled simulation, VCS MX displays the
following prompt:

Interrupt detected in compiled code.


Continue until next wait (y), or stop simulation immediately
(n)? [y/n]:

Enter y to stop the simulation at the next wait statement. You can
continue the simulation by entering the run command.

Enter n to stop the simulation immediately. VCS MX displays the


following message:

You will not be able to rerun the simulation.


Are you sure you want to stop immediately? [y/n]:

If you enter y, the simulation terminates and you cannot continue. To


restart the simulation, use the VCS MX restart command, or quit the
simulator and restart the simulator with scsim.

If you enter n, the simulation stops at the next wait statement. You
can continue the simulation by entering the run command.

Restarting the Simulator


Restarting the simulator returns the simulation to time zero.

To restart the simulation from the simulator prompt, enter

# restart

Using scsim to Simulate Your Design


7-14
Quitting the Simulator
Quitting the simulator stops the simulation and returns you to the
operating system. To quit the simulator from the simulator prompt,
enter

# quit

Reading Simulation Profiler Results

VCS MX’s static profiler reports provide detailed information about


cycle elaboration. In addition to the static reports, VCS MX can
generate dynamic simulation profile reports.

The dynamic simulation profiler reports show you all the runtime
statistics necessary to detect any simulation bottlenecks. The
dynamic profiler reports list simulation time spent in each VHDL
process as well as in each phase of simulation and points you to the
line in the source code where the process is located. Additional
information is provided for cycle regions, such as detailed listings of
cycle optimized trigger functions and cycle optimized combinational
functions along with the amount of simulation time spent in each.

The dynamic simulation profiler lets you make changes in your VHDL
source code to yield the most improvement. The dynamic profile
reports in conjunction with the static elaboration reports help to
provide the maximum simulation performance with the least amount
of effort.

See the “Profiling the Simulation” on page 2-7 for more information
about how to generate the profile reports.

Using scsim to SimulateYour Design


7-15
The -profile option produces a formatted HTML report. This report
is divided into four major sections that contain related information
about the various phases of simulation, event simulation processes,
cycle trigger and testbench functions, and cycle combinational
processes.

The first two tables are always present in the report. The last two
tables, related to cycle simulation, are only present if there are cycle
regions simulated in the design.

Simulation Phases Table


The first table in the report lists summary information for major stages
of the simulation executable. The following columns of information
are shown:

• Simulation Phases
Shows the amount of time spent in each stage of compilation and
simulation. The different phases are as follows:

- main program
The amount of time spent invoking the simulator executable.
- reading “.sim” files
The amount of time spent in reading all the analysis information
(.sim files).
- vhdl event elaboration
The amount of time the simulator spends performing
elaboration of the event design regions.

Using scsim to Simulate Your Design


7-16
- vhdl cycle elaboration
The amount of time the simulator spends performing
elaboration of the cycle design regions. You need to perform
this step only once. After elaboration is performed, you can
reuse the object files created for multiple simulations.
- verilog compilation
The amount of time the simulator spends performing
compilation of any verilog design regions.
- simulation
The total amount of time the simulator spends performing actual
simulation of the design. The following regions all combine to
form this total simulation time:
- vhdl signal network update
The amount of time the simulator spends updating signal values
in the design and propagating these values through the design
interconnect. The time spent here is measured in real time only.
- monitor evaluation
The amount of time the simulator spends checking values and
conditions for tracing, breakpoints, and monitors. It also
includes the time for all VhPLI interactions. The time spent here
is measured in real time only.
- vhdl debug evaluation
The amount of time spent simulating all design regions running
in debuggable event mode. Any region simulating in this mode
severely slows down the simulation performance. The time
spent here is measured in real time only.
- vhdl event evaluation
The amount of time spent simulating all design regions running
in compiled event mode. The time spent here is measured in
real time only.

Using scsim to SimulateYour Design


7-17
- vhdl cycle evaluation
The amount of time spent simulating all design regions running
in cycle simulation mode. The time spent here is measured in
real time only.
- vhdl event runtime
It consists of all times in the event kernel other than process
execution (event and debug), signal update and monitor
evaluation. It’s the time spent in any SWIFT model or any time
spent in cycle functions used to propogate event values through
the cycle region for layered E-C-E (up & down the tree). The
time spent here is measured in real time only.
- vhdl cycle runtime
The small overhead cost of simulating in cycle mode. If the time
spent in this stage of simulation exceeds that of the time spent
in vhdl cycle evaluation, than the cycle regions are too small.
The time spent here is measured in real time only.
- verilog evaluation
The amount of time spent simulating Verilog design regions in
the design. The time spent here is measured in real time only.
- TOTAL
The total time spent in the simulation executable. This is the
time used to calculate all real time percentages in the profiler
report.
• Real time
Shows the total elapsed time in seconds spent inside the
simulation executable followed by the percentage of the total
elapsed time spent in each phase of the simulator.

For simulation phases, VCS MX uses macro-measurement of the


system clock to measure real time.

Using scsim to Simulate Your Design


7-18
These measurements are subject to quantization error for short
or infrequent measurements.

Note:
Real time is the measure of time of a UNIX process executed
on a particular machine. You must be the only user of the
machine to make accurate measurements.

• Delta cycle profile


Delta cycle activity is sampled to construct a histogram of the first
nine delta cycles per timepoint. These histograms show whether
a function is executed more than once per timepoint, which can
be the result of feedback or reconvergent fanout.

A dot (.) means no activity in that delta cycle. An asterisk (*)


means 100% of the simulation activity was spent in that delta
cycle. The simulation activity in that delta cycle is reported as a
number n, where n is between 0 and 9, and the simulation activity
of that delta cycle is between n*10 to n*10+9 percent. For
example, a value of 0 means between 0% to 9% of the simulation
time was spent in that particular delta cycle, a value of 8 means
between 80% and 89% percent of the simulation activity was
spent in that particular delta cycle. The ninth delta cycle includes
all activity for circuits with ten or more delta cycles.

......... no delta cycle activity occurred


.*....... all activity in the first delta cycle
.8..2.... 80-89% activity in the first delta cycle;
20-29% activity in the fourth delta cycle

Note that cycle regions collapse multiple event delta cycles into
a single delta cycle.

Using scsim to SimulateYour Design


7-19
• Calls
Lists the number of times a function is called. Only available for
the various simulation phases, and cycle-based trigger and
combinational functions.

• User time
Time spent executing user code (seconds).

• System time
Time spent executing system code (seconds).

• User+Sys time
Sum of user time and system time. This time is independent of
the system load and must be nominally equal to real time when
the system is not loaded.

• Memory
Total memory (megabytes) allocated during a given simulation
phase.

Event-based Processes Table


The second table in the dynamic profiler report lists information for
event processes. The following columns of information are shown:

• Event-based Processes
Event-based processes are listed in the order of highest activity.
The processes are named using the following syntax:

entity_name__architecture_name__process_name

Using scsim to Simulate Your Design


7-20
Only processes that take more than 0.1% of the total time are
displayed.

• Real time
Shows the total elapsed time in seconds spent simulating the
process followed by the percentage of the total elapsed time spent
in each event process.

For event process activity and cycle trigger function and cycle
combinatorial function activity, VCS MX uses micro-
measurements of statistical sampling to measure real time.

These measurements are subject to quantization error for short


or infrequent measurements.

Note:
Real time is the measure of time of a UNIX process executed
on a particular machine. You must be the only user of the
machine to make accurate measurements.

• Delta cycle profile


Delta cycle activity is sampled to construct a histogram of the first
nine delta cycles per timepoint. These histograms show whether
the process is executed more than once per timepoint, which can
be the result of feedback or reconvergent fanout.

Using scsim to SimulateYour Design


7-21
A dot (.) means no activity in that delta cycle. An asterisk (*)
means 100% of the simulation activity was spent in that delta
cycle. The simulation activity in that delta cycle is reported as a
number n, where n is between 0 and 9, and the simulation activity
of that delta cycle is between n*10 to n*10+9 percent. For
example, a value of 0 means between 0% to 9% of the simulation
time was spent in that particular delta cycle, a value of 8 means
between 80% and 89% percent of the simulation activity was
spent in that particular delta cycle. The ninth delta cycle includes
all activity for circuits with ten or more delta cycles.

......... no delta cycle activity occurred


.*....... all activity in the first delta cycle
.8..2.... 80-89% activity in the first delta cycle;
20-29% activity in the fourth delta cycle

• Process type
Shows the simulation mode the process is running in, debug or
event representing debuggable event simulation or compiled
event simulation, respectively.

• Source file
Shows the name of the VHDL source file and the line in the file
where the event process is located. For convenience, this field
provides an HTML link to the file.

Cycle-based Trigger and Testbench Processes Table


The third table in the dynamic profiler report lists information about
cycle simulation trigger and testbench functions. This table is present
only if there are cycle regions being simulated in the design. The
following columns of information are shown:

Using scsim to Simulate Your Design


7-22
• Cycle-based Trigger and Testbench Processes
Cycle simulation trigger and testbench functions are listed in the
order of highest activity. The functions are named using the
following syntax:

entity_name__architecture_name_tgf/tbf_ID

Only trigger and testbench functions that use more than 0.1% of
the total time are displayed.

• Real time
Shows the total elapsed time in seconds spent simulating the
function followed by the percentage of the total elapsed time spent
in each function.

For event process activity and cycle trigger function and cycle
combinatorial function activity, VCS MX-i uses micro-
measurements of statistical sampling to measure real time.

These measurements are subject to quantization error for short


or infrequent measurements.

Note:
Real time is the measure of time of a UNIX process executed
on a particular machine. You must be the only user of the
machine to make accurate measurements.

• Delta cycle profile


Delta cycle activity is sampled to construct a histogram of the first
nine delta cycles per timepoint. These histograms show whether
the process is executed more than once per timepoint, which can
be the result of feedback or reconvergent fanout.

Using scsim to SimulateYour Design


7-23
A dot (.) means no activity in that delta cycle. An asterisk (*)
means 100% of the simulation activity was spent in that delta
cycle. The simulation activity in that delta cycle is reported as a
number n, where n is between 0 and 9, and the simulation activity
of that delta cycle is between n*10 to n*10+9 percent. For
example, a value of 0 means between 0% to 9% of the simulation
time was spent in that particular delta cycle, a value of 8 means
between 80% and 89% percent of the simulation activity was
spent in that particular delta cycle. The ninth delta cycle includes
all activity for circuits with ten or more delta cycles.

......... no delta cycle activity occurred


.*....... all activity in the first delta cycle
.8..2.... 80-89% activity in the first delta cycle;
20-29% activity in the fourth delta cycle

Note that cycle regions collapse multiple event delta cycles into
a single delta cycle.

• Calls
Lists the number of calls made to the function during the simulation
run.

• Size
Size of the executable code of the cycle function (number of
instruction words). Generally, larger sized tgfs take longer to
execute.

• Instructions per call


Average number of instructions executed per function call
(ipc = real time * mips / calls). This metric is useful
for measuring code improvements, however, quantization errors
might result in inflated values.

Using scsim to Simulate Your Design


7-24
• Source processes
Number of sequential VHDL processes that are combined to
create the specified cycle trigger or testbench function.

• Trigger Conditions
The conditions on which the trigger function is executed. For more
information about trigger conditions and how to interpret the
notation used, see “Static Cycle Elaboration Reports” on
page 4-33.

Cycle-based Combinational Processes Table


The fourth table in the dynamic profiler report lists information about
cycle simulation combinational functions. This table is present only if
there are cycle regions being simulated in the design. The following
columns of information are shown:

• Cycle-based Combinational Processes


Cycle simulation combinational functions are listed in the order of
highest activity. See “Static Cycle Elaboration Reports” on
page 4-33 for more information about cycle simulation
combinational functions. The functions are named using the
following syntax:

entity_name__architecture_name_cgf_ID

Only combinational functions that take more than 0.1% of the total
time are displayed.

Using scsim to SimulateYour Design


7-25
• Real time
This total elapsed time in seconds spent simulating the function
followed by the percentage of the total elapsed time spent in each
function.

For event process activity and cycle trigger function and cycle
combinatorial function activity, VCS MX VHDL uses micro-
measurements of statistical sampling to measure real time.

These measurements are subject to quantization error for short


or infrequent measurements.

Note:
Real time is the measure of time of a UNIX process executed
on a particular machine. You must be the only user of the
machine to make accurate measurements.

• Delta cycle profile


Delta cycle activity is sampled to construct a histogram of the first
nine delta cycles per timepoint. These histograms show whether
the process is executed more than once per timepoint, which can
be the result of feedback or reconvergent fanout.

A dot (.) means no activity in that delta cycle. An asterisk (*)


means 100% of the simulation activity was spent in that delta
cycle. The simulation activity in that delta cycle is reported as a
number n, where n is between 0 and 9, and the simulation activity
of that delta cycle is between n*10 to n*10+9 percent. For
example, a value of 0 means between 0% to 9% of the simulation
time was spent in that particular delta cycle, a value of 8 means
between 80% and 89% percent of the simulation activity was
spent in that particular delta cycle. The ninth delta cycle includes
all activity for circuits with ten or more delta cycles.

Using scsim to Simulate Your Design


7-26
......... no delta cycle activity occurred
.*....... all activity in the first delta cycle
.8..2.... 80-89% activity in the first delta cycle;
20-29% activity in the fourth delta cycle

Note that cycle regions collapse multiple event delta cycles into
a single delta cycle.

• Calls
Lists the number of calls made to the function during the simulation
run.

• Size
Size of the executable code of the cycle function (number of
instruction words). Generally, larger sized tgfs take longer to
execute.

• Instructions per call


Average number of instructions executed per function call
(ipc = real time * mips / calls). This metric is useful
for measuring code improvements, however, quantization errors
might result in inflated values.

• Source processes
Number of combinational VHDL processes that are combined to
create the specified combinational function.

Using scsim to SimulateYour Design


7-27
Comparing Simulation Results

VCS MX provides the fastest simulation performance when


simulating your design in cycle mode. You can compare the
simulation performance of a design run in cycle mode versus a design
run in event mode by examining the simulation profile reports.

To explain the information in the profile reports from an event


simulation run and a mixed event and cycle simulation run, an
example design, a JPEG encoder, is used. The block diagram for the
design regions of the JPEG design is shown in Figure 7-1.

Figure 7-1 Top-Level Block Diagram of the JPEG Design

TB_JPEG

JPEG

DCT Quantizer Huffman

TB_JPEG contains one instance of the JPEG component. The main


processes in TB_JPEG are

• File-dump - Captures output and dumps it into a file


• File-read - Reads input vectors from a file and drives the design
• Clock - Generates the design’s clock

Using scsim to Simulate Your Design


7-28
Event Mode Simulation Profile Report
To generate the runtime profile report for event mode simulation, use
the following commands:

% scs TB_JPEG_CFG
% scsim -profile profile_event.htm

The generated profile report is shown in Figure 7-2.

Using scsim to SimulateYour Design


7-29
Figure 7-2 Event Simulation Profile Report

Using scsim to Simulate Your Design


7-30
Reading Simulation Phases
• TOTAL, the total time spent in the simulator, used 170.5 seconds
real time, and 163.2 seconds user+sys time. The real time and
user+sys times are close, signifying a low machine load when the
simulation was run. Whenever comparing the total times for two
designs, use the total user+sys time as it does not vary based on
machine load.
• simulation, the time spent actually running the design, used 168.4
seconds real time, or 98.8% of the TOTAL time spent in the
executable. The total user+sys time was 161.2 seconds, or 98.8%
of the total user+sys time.
• vhdl signal network update used 14.3 seconds real time or 8.4%
of the TOTAL time.
• vhdl event evaluation used 149.3 seconds real time or 87.5% of
the TOTAL time.
• vhdl cycle evaluation and vhdl cycle runtime used 0 seconds,
which is correct since this is design was run in pure event mode.
Reading Event-based Processes
The processes are sorted from the most to the least amount of
simulation time used.

• Process DW02_MULT__SIM__PO, starting at line 85 in the VHDL


source file DWO2_mult_sim.vhd, ran for 29.9 seconds or 17.5%
of the TOTAL time. This event process took the largest amount
of simulation time.
• Process DCT_BUFFER__DCT_BUFFER_A_ELE, starting at line 38
in the VHDL source file dct_buffer_a.vhd, ran for 13.1
seconds or 7.7% of the TOTAL time.

Using scsim to SimulateYour Design


7-31
• Process TB_JPEG__TB_A__FILE_DUMP, starting at line 59 in
the VHDL source file tb_jpeg.vhd, ran for 8.7 seconds or 5.1%
of the TOTAL time.
• Process TB_JPEG__TB_A__FILE_READ, starting at line 108 in
the VHDL source file tb_jpeg.vhd, ran for 1.9 seconds or 1.1%
of the TOTAL time.
This information suggests that you examine the VHDL code for all
processes running for a high percentage of the TOTAL time and if
possible, try to improve the code for better simulation performance.
See the VHDL Simulation Coding and Modeling Style Guide for more
information about how to improve code for better simulation
performance.

The Cycle-based Trigger and Testbench Processes and Cycle-based


Combinational Processes tables are not present in the report as this
design was run in pure event mode.

Mixed Event and Cycle Simulation Profile Report


For mixed event and cycle mode simulation, the design has to be
partitioned. Since the JPEG design is synthesizeable, the entire
design can be accelerated by cycle optimizations and therefore is
partitioned entirely into cycle. Only the testbench is run in event. The
content of the partition file is

cycle -2state -perf JPEG_CFG

For more information about generating the partition file, see section
“Creating a Partition File” on page 4-9.

Using scsim to Simulate Your Design


7-32
To elaborate the design and prepare for simulation, use the following
command:

scs -partition part.file -perf_data static_elab.out


TB_JPEG_CFG

To generate the runtime profile report for mixed event and cycle mode
simulation, the following command is used:

scsim -profile profile_cycle.htm

The generated profile report is shown in Figure 7-3.

Using scsim to SimulateYour Design


7-33
Figure 7-3 Mixed Event and Cycle Simulation Profile Report

Using scsim to Simulate Your Design


7-34
Reading Simulation Phases
• TOTAL used 25.2 seconds real time and 24.4 seconds user+sys
time.
• simulation used 23.0 seconds real time or 91.1% of the TOTAL
time spent in the executable. The total user+sys time was 22.7
seconds, or 92.2% of the total user+sys time.
• vhdl signal network update used 0.9 seconds real time or 8.4%
of the TOTAL time.
• vhdl event evaluation used 10.1 seconds real time or 40.0% of
the TOTAL time.
• vhdl cycle evaluation used 9.6 seconds real time or 38.0% of the
TOTAL time.
• vhdl cycle runtime used 0.9 seconds real time or 3.4% of the
TOTAL time. This number is much smaller than the time spent in
vhdl cycle evaluation indicating suitable cycle partitioning.
To find the gain in simulation performance from running mixed event-
cycle mode over running pure event mode, compare the TOTAL
user+sys times from each reports:

Event TOTAL / mixed TOTAL = speedup

163.2 / 24.6 = 6.6 X

Mixed event-cycle simulation is 6.6 times faster than event. In this


example Real time values also provide similar numbers, but
User+Sys time values are more accurate.

Using scsim to SimulateYour Design


7-35
Reading Event-based Processes
With the design partitioned, only the testbench processes are running
in event mode. the other processes reported in the event simulation
profile report are now being simulated in cycle mode.

• Process TB_JPEG__TB_A_FILE_DUMP, starting at line 59 in the


VHDL source file tb_jpeg.vhd, ran for 8.0 seconds or 31.9%
of the TOTAL time.
• Process TB_JPEG__TB_A_FILE_READ, starting at line 108 in
the VHDL source file tb_jpeg.vhd, ran for 1.7 seconds or 6.8%
of the TOTAL time.
Notice the total simulation times for each event process is similar
between the pure event and the mixed event-cycle simulation run.
However, since the mixed simulation runs so much faster, these
processes now comprise a much larger percentage of the total
simulation time (31.9% and 6.8% for mixed event-cycle simulation
versus 5.1% and 1.1% respectively.)

Reading Cycle-based Trigger and Testbench Processes


The profile information for the cycle-based processes are reported in
a different way from the event-based process. Cycle-based process
information is reported with respect to the cycle trigger and testbench
functions that are generated during cycle elaboration.

• Trigger function (tgf) JPEG__JPEG_A_0_tgf_5 runs for 3.6


seconds or 14.3% of the TOTAL time. This function controls the
evaluation of 175 sequential processes in the design. This trigger
function is called 64211 times during the simulation and executes
30617 machine instructions per call.

Using scsim to Simulate Your Design


7-36
To find the VHDL processes that are combined to create this trigger
function, cross-reference the trigger function name in the static
elaboration report as shown in Figure 7-4.

Figure 7-4 Static Elaboration Report

Tgf_id = 5: conditions [ ~0(RESET) pe(CLK) ] {1 event(s)}


Tgf_name [ JPEG__JPEG_A_0_tgf_5 ]
Controls 175 sequential process(es):
/JPEG/U_HUFFMAN/U_AC_ENCODE/G1(2)/U_AC_ENCODE_NUM/OUTPUT_ACK$Seq[83]
[ac_encode_num_a.vhd:52]
/JPEG/U_HUFFMAN/U_AC_ENCODE/G1(2)/U_AC_ENCODE_NUM/ENABLE1$Seq[86]
[ac_encode_num_a.vhd:71]
/JPEG/U_HUFFMAN/U_AC_ENCODE/G1(2)/U_AC_ENCODE_NUM/AC_CODING$Seq[89]
[ac_encode_num_a.vhd:82]
/JPEG/U_HUFFMAN/U_AC_ENCODE/G1(2)/U_AC_ENCODE_NUM/U_COUNTER1/
COUNTER$Seq[59] [counter_a.vhd:24]
/JPEG/U_DCT/U_DCT_BUFFER_1/ELE$Seq[14] [dct_buffer_a.vhd:38]
/JPEG/U_DCT/U_DCT_MULT_2/U_COUNTER3/COUNTER$Seq[5] [counter_a.vhd:24]
/JPEG/U_DCT/U_DCT_INPUT/U_COUNTER0/COUNTER$Seq[5] [counter_a.vhd:24]
/JPEG/U_DCT/U_DCT_MULT_1_2/PASS2$Seq[44] [dct_mult_1_a.vhd:72]
/JPEG/U_DCT/U_DCT_INPUT/U_SREG_1/P1$Seq[2] [sreg_a.vhd:21]
/JPEG/U_DCT/U_DCT_SUM_1_1/PASS1$Seq[26] [dct_sum_1_a.vhd:33]
/JPEG/U_HUFFMAN/U_AC_ENCODE/G1(3)/U_AC_ENCODE_NUM/OUTPUT_ACK$Seq[83]
[ac_encode_num_a.vhd:52]
/JPEG/U_HUFFMAN/U_AC_ENCODE/G1(3)/U_AC_ENCODE_NUM/ENABLE1$Seq[86]
[ac_encode_num_a.vhd:71]
/JPEG/U_HUFFMAN/U_AC_ENCODE/G1(3)/U_AC_ENCODE_NUM/AC_CODING$Seq[89]
[ac_encode_num_a.vhd:82]
/JPEG/U_HUFFMAN/U_AC_ENCODE/G1(3)/U_AC_ENCODE_NUM/U_COUNTER1/
COUNTER$Seq[59] [counter_a.vhd:24]
/JPEG/U_HUFFMAN/U_DC_ENCODE/ENABLE1$Seq[77] [dc_encode_a.vhd:42]
/JPEG/U_DCT/U_DCT_INPUT/U_COUNTER2/COUNTER$Seq[5] [counter_a.vhd:24]
/JPEG/U_DCT/U_DCT_INPUT/U_SREG_9/P1$Seq[2] [sreg_a.vhd:21]
/JPEG/U_DCT/U_DCT_INPUT/U_SREG_10/P1$Seq[2] [sreg_a.vhd:21]
/JPEG/U_DCT/U_DCT_INPUT/U_SREG_7/P1$Seq[2] [sreg_a.vhd:21]
/JPEG/U_HUFFMAN/U_RUNLENGTH/DC_ENCODING$Seq[71] [runlength_a.vhd:100]
and others.

For more information about how to read the static elaboration report
information, see “Static Cycle Elaboration Reports” on page 4-33.

Using scsim to SimulateYour Design


7-37
Reading Cycle-based Combinational Process
Cycle-based Combinational Process information is reported with
respect to the cycle combinational functions that are generated during
cycle elaboration. For more information, see “Static Cycle Elaboration
Reports” on page 4-33.

• Combinational function (cgf) JPEG__JPEG_A_0_cbf_0 runs for


5.5 seconds or 21.9% of the TOTAL time. This function controls
the evaluation of 792 combinational logic processes in the design.
This combinational function is called 64212 times during the
simulation and executes 46816 machine instructions per call.
To find the VHDL processes that are combined to create this function,
cross-reference the combinational function name in the static
elaboration report as we did earlier with the trigger function.

Invoking the Graphical User Interface

VCS MX uses the DVE or VirSim Graphical User Interface. This GUI
provides a complete suite of tools allowing you complete access to
your design along with a project management tool to make simulation
easier.

For more information on DVE, see "Discovery Visual Environment"


Chapter 9,

The main elements of this graphical interface are as follows:

- Project Browser and Management Tool


- Interactive Window
- Hierarchy Browser

Using scsim to Simulate Your Design


7-38
- Waveform Window
- Source Window
- Register Window
The VirSim GUI lets you run simulations interactively or perform post
processing of your simulation. For complete documentation of the
VirSim GUI, see the VirSim Reference Manual.

Starting VirSim GUI for Interactive Simulation


To use the VCS MX GUI for interactive simulation, start the GUI with
the command line options you want to pass to the simulator. For
example,

% scirocco -nc -i cmd.in &

The command opens the Interactive text box. The scsim command
and all the options you passed to VirSim appear in the Simulator
Invocation Dialog.

Enter any other scsim options you want to use in the Simulator
Command Line window and click on the OK button.

For more information about starting an interactive simulation, see the


“Invoking the Interactive Window” section in the “Interactive Window”
chapter of the VirSim Reference Manual.

Starting the VirSim GUI for Post-Processing


To use the VCS MX GUI for post-processing mode, start the GUI
with -pp command line option.

% scirocco -pp &

Using scsim to SimulateYour Design


7-39
The command opens the Hierarchy window. From the pull-down
menus, select File -> Open or press Ctrl-O. An Open File Dialog
appears. From the Selection window, specify the name of the VCD+
file you want to load.

For more information about opening a file for post-processing, see


“Opening and Closing History Files” section in the “Starting Virsim”
chapter of the VirSim Reference Manual.

Starting the GUI with the Project Browser Window


To bring up the Project Browser window, start the GUI with -pb
command line option.

% scirocco -pb &


The command opens the Project Browser window. For more
information about using the Project Browser, see VirSim Reference
Manual.

The scirocco Command


Syntax
scirocco [options]

Command Options
You can use all valid scsim options in the GUI Interactive Window.
For example, to invoke interactive full debugging session, use

% scirocco -nc -debug_all &

Or it you want to invoke interactive session but debug few design


units from the design, use

Using scsim to Simulate Your Design


7-40
% scirocco -nc -debug_unit \”unit1 unit2 unit2\” &

Note:
For those command line options that require the arguments to be
given in a quote (such as in the second example above), you need
to proceed each quotation mark (“) with a backslash (\) while
invoking scirocco.

Running and Controlling a Simulation Using the simv


Executable

If you compiled your design as Verilog-only, or Verilog-top, then will


run a simulation using the simv executable.

This chapter covers the following topics:

• Running a Mixed-HDL Simulation


• Common simv Runtime Options
• Common simv Tasks
• How VCS Prevents Time 0 Race Conditions
• Making a Verilog Model Protected and Portable
• Re-Invoking a Simulation With VirSim
• Using Interactive Commands

Using scsim to SimulateYour Design


7-41
Running a Mixed-HDL Simulation

You start simulating a mixed HDL design using the simv command
line and VCS runtime options. However, you can also include two
runtime options specific to mixed-HDL simulation:

-vhdlrun "VHDL command line options"


For specifying scsim command line options that tell VCS MX how
to simulate the VHDL part of the design.
+vcs+novhdldump
For telling VCS MX not to record VHDL value changes in the VCD+
file for post-processing.
You can use the -vhdlrun runtime option on the simv command
line.

The most commonly used options are as follows:

-debug_all
Specifies the slower simulating debugging mode.
-profile filename.html
Generates an HTML profile report, with the specified name, about
how VCS MX simulates the VHDL part of the design.
The following is an example of using the -vhdlrun option:

simv -vhdlrun "-profile prof.html"

Using scsim to Simulate Your Design


7-42
Common simv Runtime Options

The runtime options discussed in this section are typically entered at


the simv command line, but some of them can be compiled into the
simv executable at compile-time.

Viewing the Compile-Time Options Used To Create The


Executable
-E program
Starts the program that displays the compile-time options that
were on the vcs command line when you created the simv (or
simv.exe) executable file. For example:
simv -E echo
simv -E echo > simvE.log
You cannot use any other runtime options with the -E option.
Simulating OpenVera Assertions
The following are runtime options for simulation OpenVEra
Assertions:

-ova_quiet [1]
Disables printing results on screen. The report file is not affected.
With the 1 argument, only a summary is printed on screen.
-ova_report [filename]
Generates a report file in addition to printing results on screen.
Specifying the full path name of the report file overrides the default
report name and location.
-ova_verbose
Adds more information to the end of the report including assertions
that never triggered and attempts that did not finish, and a
summary with the number of assertions present, attempted, and
failed.

Using scsim to SimulateYour Design


7-43
-ova_name name | pathname
Specifies an alternative name or location and name for the
./simv.vdb/scov/results.db and ./simv.vdb/reports/ova.report
files. You use this option if you want data and reports from a series
of simulation runs. It is a way of keeping VCS MX from overwriting
these files from a previous simulation.
If you just specify a name the alternatively named files will be in
the default directories. If you specify a pathname, with an
argument containing the slash character /, you specify a different
location and name for these files, for example:

-ova_name /net/design1/ova/run2

This example tells VCS MX to write run2.db and run2.report in the


/net/design1/ova directory.
Runtime options for controlling how VCS MX writes its report on
OpenVera Assertions. You can use them only if you compiled with
the -ova_enable_diag compile-time option.

-ova_filter
Blocks reporting of trivial if-then successes. These happen when
an if-then construct registers a success only because the if portion
is false (and so the then portion is not checked). With this option,
reporting only shows successes in which the whole expression
matched.
-ova_max_fail N
Limits the number of failures for each assertion to N. When the
limit is reached, the assertion is disabled. N must be supplied,
otherwise no limit is set.

Using scsim to Simulate Your Design


7-44
-ova_max_success N
Limits the total number of reported successes to N. N must be
supplied, otherwise no limit is set. The monitoring of assertions
continues, even after the limit is reached.
-ova_simend_max_fail N
Terminates the simulation if the number of failures for any
assertion reaches N. N must be supplied, otherwise no limit is set.
-ova_success
Enables reporting of successful matches in addition to failures.
The default is to report only failures.
Runtime options for functional coverage(enabled by the -ova_cov
compile-time option):

-ova_cov
Enables functional coverage reporting.
-ova_cov_name filename
Specifies the file name or the full path name of the functional
coverage report file.
-ova_cov_db filename
Specifies the path name of the initial coverage file. The initial
coverage file is needed to set up the database.
CLI Command File Options
-i filename
Specifies a file containing CLI commands that VCS MX executes
when simulation starts. After VCS MX reaches the end of that file
it takes commands from the standard input. Normally used along
with the -s runtime option and a +cli+number compile-time
option. A typical file for this option is the vcs.key file.

Using scsim to SimulateYour Design


7-45
-k filename | off
Specifies an alternative name or location for the vcs.key file into
which VCS MX writes the CLI and VirSim interactive commands
that you enter during simulation. The off argument tells VCS MX
not to write this file.
+cliecho
Specifies that VCS MX display the CLI commands in a file that
you specify with the -i option as VCS MX executes these CLI
commands.
Stopping a Simulation
-s
Stops simulation just as it begins, and enters interactive mode.
Use with the +cli+number option.
Specifying VERA Object Files
+vera_load=filename.vro
Specifies the VERA object file.
+vera_mload=filename
Specifies a text file that contains a list of VERA object files.
Coverage Metrics Options
-cm line|cond|fsm|tgl|obc|path
Specifies monitoring for the specified type or types of coverage.
The arguments specifies the types of coverage:
line
Monitor for line or statement coverage.
cond
Monitor for condition coverage.
fsm
Monitor for FSM coverage.
tgl
Monitor for toggle coverage.

Using scsim to Simulate Your Design


7-46
obc
Monitor for observed coverage.
path
Monitor for path coverage.
If you want VCS MX to monitor for more than one type of coverage,
use the plus (+) character as a delimiter between arguments, for
example:

simv -cm line+cond+fsm+tgl+path

Don’t monitor for any other type of coverave when you monitor
for observed coverage.

The -cm option is also a compile-time option and an option on the


cmView command line.

-cm_dir directory_path_name
Specifies and alternative name and location for the simv.cm
directory. The -cm_dir option is also a compile-time option and
a cmView command line option.
-cm_glitch period
Specifies a glitch period during which VCS MX does not monitor
for coverage caused by value changes. The period is an interval
of simulation time specified with a non-negative integer.
-cm_log filename
As a compile-time or runtime option, specifies a log file for
monitoring for coverage during simulation. As a cmView
command line option, specifies a log file for writing reports.
-cm_name filename
As a compile-time or runtime option, specifies the name of the
intermediate data files. On the cmView command line, specifies
the name of the report files.

Using scsim to SimulateYour Design


7-47
-cm_tglfile filename
Specifies displaying at runtime a total toggle count for one or more
subhierarchies specified by the top-level module instance entered
in the file. This option is also a compile-time option.
-cm_zip
Required when using the SWIFT interface to VMC models or
SmartModels or when Undertow dumping is enabled.
Recording Where ACC Capabilities are Used
+vcs+learn+pli
ACC capabilities enable debugging operations but they have a
performance cost so you only want to enable them where you
need them. This option keeps track of where you use them for
debugging operations so that you can recompile your design and
in the next simulation enable them only where you need them.
When you use this option VCS MX writes the pli_learn.tab
secondary PLI table file. You input this file when you recompile
your design with the +applylearn compile-time option.
Suppressing the $stop System Task
+vcs+ignorestop
Tells VCS MX to ignore the $stop system tasks in your source
code.
Enabling and Disabling Specify Blocks
+no_notifier
Suppresses the toggling of notifier registers that are optional
arguments of system timing checks. The reporting of timing check
violations is not affected. This is also a compile-time option.
+no_tchk_msg
Disables the display of timing violations but does not disable the
toggling of notifier registers in timing checks. This is also a
compile-time option.

Using scsim to Simulate Your Design


7-48
+notimingcheck
Disables timing check system tasks in your design. Using this
option at runtime can improve the simulation performance of your
design, depending on the number of timing checks that this option
disables.
You can also use this option at compile-time. Using this option at
compile-time tells VCS MX to ignore timing checks when it
compiles your design so the timing checks are not compiled into
the executable and this results in a faster simulating executable
than one that includes timing checks that are disabled by this
option at runtime.
If you need the delayed versions of the signals in negative timing
checks but want faster performance, include this option at runtime.
The delayed versions are not available if you use this option at
compile-time. .
VCS MX recognizes +notimingchecks to be the same as
+notimingcheck when you enter it on the vcs or simv
command line.
Specifying When Simulation Stops
+vcs+stop+time
Stop simulation at the time value specified. The time value must
be less than 232 or 4,294,967,296.
+vcs+finish+time
Ends simulation at the time value specified.The time value must
be also less than 232.
For both of these options there is a special procedure for
specifying time values larger than 232, see “Specifying A Very
Long Time Before Stopping Simulation” on page 2-64.

Using scsim to SimulateYour Design


7-49
User-Defined Plusarg Options
+plus-options
User-defined run-time options, which can be checked for by the
$test$plusargs system task to perform some operation when
the option is on the simv command line.
Recording Output
-a filename
Specifies appending all messages from simulation to the bottom
of the text in the specified file as well as displaying these
messages in the standard output.
-l filename
Specifies writing all messages from simulation to the specified file
as well as displaying these messages in the standard output.
Usage is letter "l" (lowercase "L") for log file.
Controlling Messages
-q
Quiet mode. Suppress printing of VCS MX header and summary
information.
Suppresses proprietary message at beginning
Suppresses VCS MX Simulation Report at the end (time, CPU
time, data structure size, and date)
-V
Verbose mode. Prints VCS MX version and extended summary
information.
Prints VCS MX compile and run-time version numbers, and
copyright information, at start of simulation.

Using scsim to Simulate Your Design


7-50
+no_pulse_msg
Suppresses pulse error messages, but not the generation of StE
values at module path outputs when a pulse error condition
occurs.
You can enter this run-time option on the vcs command line.
You cannot enter this option in the file you use with the -f compile-
time option.
+sdfverbose
By default VCS MX displays no more than ten warning and ten
error messages about back annotating delay information from
SDF files. This option enables the display of all back annotation
warning and error messages.
This default limitation on back annotation messages applies only
to messages displayed on the screen and written in the simulation
log file. If you specify an SDF log file in the $sdf_annotate system
task, this log file receives all messages.
+vcs+nostdout
Disables all text output from VCS MX including messages and
text from $monitor and $display and other system tasks. VCS
MX still writes this output to the log file if you include the -l option.
VCD+ Files
VCD+ files are simulation history files that VCS MX writes during
simulation and DVE or VirSim reads after simulation to show you the
simulation results. These are the runtime options that specify the size
and contents of the VCD+. You specify these runtime options on the
vcs command line.

Using scsim to SimulateYour Design


7-51
+vpdbufsize+number_of_megabytes
To gain efficiency, VCD+ uses an internal buffer to store value
changes before saving them on disk. This option modifies the size
of that internal buffer. The minimum size allowed is what is
required to share two value changes per signal. The default size
is the size required to store 15 value changes for each signal but
not less than 2 megabytes.
Note:
The buffer size automatically is increased as needed to comply
with the above limit.

+vpdfile+filename
Specifies the name of the output VCD+ file (default is
vcdplus.vpd). You must include the full file name with the .vpd
extension.
+vpdfilesize +number_of_megabytes
Creates a VCD+ file, which has a moving window in time while
never exceeding a specified file size number_of_megabytes.
When the VCD+ file size limit is reached, VCD+ will continue
saving simulation history by overwriting older history.
File size is a direct result of circuit size, circuit activity, and the
data being saved. Test cases show that VCD+ file sizes will likely
run from a few megabytes to a few hundred megabytes. Many
users can share the same VCD+ history file, which may be a
reason for saving all time value changes when you do simulation.
You can save one history file for a design and overwrite it on each
subsequent run.

Using scsim to Simulate Your Design


7-52
+vpdignore
Tells VCS MX to ignore any $vcdplusxx system tasks and
license checking. By default, VCS MX checks out a VCD+ PLI
license if there is a $vcdplusxx system task in the Verilog
source. In some cases, this statement is never executed and
VCD+ PLI license checkout should be suppressed. The
+vpdignore option performs the license suppression.
+vpddrivers
By default, VCD+ records value changes only for the resolved
value for each net. To also report value changes for all its drivers
when there are more than one driver, use the +vdpdrivers
option when simulating. The driver values, for example, enable
the Logic Browser to identify which drivers produce an undesired
X on the resolved net.
This option affects performance and memory usage for larger
designs or longer runs.
+vpdports
By default, VCD+ does not store the port type for each signal, and
the Hierarchy Browser views all signals as internal and not
connected to a port.
The +vpdports option causes VCD+ to store port information,
which is then used by the Hierarchy Browser to show whether a
signal is a port and if so its direction. This option to some extent
affects simulation initialization time and memory usage for larger
designs.
+vpdnocompress
By default, VCD+ compresses data as it is written to the VCD+
file. The user may disable this feature by supplying the
+vpdnocompress command line option.

Using scsim to SimulateYour Design


7-53
+vpdnostrengths
By default, VCD+ stores strength information on value changes
to the VCD+ file. Use of this option may lead to slight
improvements in simulator performance.
Controlling $gr_waves System Task Operations
-grw filename
Sets the name of the $gr_waves output file to the specified
filename.
Default filename is grw.dump.
+vcs+grwavesoff
Suppress $gr_waves system tasks.
VCD Files Options
-vcd filename
Set name of $dumpvars output file to filename.The default
filename is verilog.dump. A $dumpfile system task in the Verilog
source code will override this option.
+vcs+dumpoff+t+ht
Turn off value change dumping ($dumpvars) at time t. ht is the
high 32 bits of a time value greater than 32 bits.
+vcs+dumpon+t+ht
Suppress $dumpvars system task until time t. ht is the high 32
bits of a time value greater than 32 bits.
+vcs+dumpvarsoff
Suppress $dumpvars system tasks.

Using scsim to Simulate Your Design


7-54
Specifying Min:Typ:Max Delays in Your Verilog Code and SDF
Files
+maxdelays
Specifies using the maximum delays in min:typ:max delay triplets
in module path delays and timing check if you compiled your
design with the +allmtm compile-time option.
Also specifies using the maximum timing delays in min:typ:max
delay triplets in an uncompiled SDF file.
If you compiled the SDF file with the +allmtm compile-time
option, the +maxdelays option specifies using the compiled SDF
file with the maximum delays.
Another use for this runtime option is to specify timing for SWIFT
VMC and SmartModels and Synopsys hardware models when
you also include the +override_model_delays runtime
option.
+mindelays
Specifies using the minimum delays in min:typ:max delay triplets
in module path delays and timing check if you compiled your
design with the +allmtm compile-time option.
Also specifies using the minimum timing delays in min:typ:max
delay triplets in an uncompiled SDF file.
If you compiled the SDF file with the +allmtm compile-time
option, the +mindelays option specifies using the compiled SDF
file with the minimum delays.
Another use for this runtime option is to specify timing for SWIFT
VMC and SmartModels and Synopsys hardware models when
you also include the +override_model_delays runtime
option.

Using scsim to SimulateYour Design


7-55
+typdelays
Specifies using the typical delays in min:typ:max delay triplets in
module path delays and timing check if you compiled your design
with the +allmtm compile-time option.
Also specifies using the typical timing delays in min:typ:max delay
triplets in an uncompiled SDF file.
If you compiled the SDF file with the +allmtm compile-time
option, the +typdelays option specifies using the compiled SDF
file with the typical delays.
This is a default option. By default VCS MX uses the typical delay
in min:typ:max delay triplets your source code and in uncompiled
SDF files (unless you specify otherwise with the mtm_spec
argument to the $sdf_annotate system task,), and also by
default VCS MX uses the compiled SDF file with typical values.
Another use for this runtime option is to specify timing for SWIFT
VMC and SmartModels and Synopsys hardware models when
you also include the +override_model_delays runtime
option.
Flushing Certain Output Text File Buffers
When VCS MX creates a log file, VCD file, or a text file specified with
the $fopen system function, VCS MX writes the data for the file in a
buffer and periodically dumps the data from the buffer to the file on
disk. The frequency of these dumps varies depending on many
factors including the amount of data that VCS MX has to write to the
buffer as simulation or compilation progresses. If you need to see or
use the latest information in these files more frequently than the rate
at which VCS MX normally dumps this data, these options tell VCS
MX to dump the data more frequently. How much more frequently
also depends on many factors but the increased frequency will always
be significant.

Using scsim to Simulate Your Design


7-56
+vcs+flush+log
Increases the frequency of dumping both the compilation and
simulation log files.
+vcs+flush+dump
Increases the frequency of dumping all VCD files.
+vcs+flush+fopen
Increases the frequency of dumping all files opened by the
$fopen system function
+vcs+flush+all
Increases the frequency of dumping all log files, VCD files, and
all files opened by the $fopen system function
These options do not increase the frequency of dumping other text
files including the VCDE files specified by the $dumpports system
task or the simulation history file for LSI certification specified by the
$lsi_dumpports system task.

These options can also be entered at compile-time. There is no


particular advantage to entering them at compile-time.

Licensing Options
+vcs+lic+vcsi
Checks out three VCSi licenses to run VCS.
+vcsi+lic+vcs
Checks out three VCS licenses to run VCSi.
+vcs+lic+wait
Wait for network license if none is available when the job starts.
Not supported on Windows.

Using scsim to SimulateYour Design


7-57
Enabling Overriding the Timing of a SWIFT SmartModel
+override_model_delays
Enables the +mindelays, +typdelays, and +maxdelays
runtime options to specify the timing used by SWIFT SmartModels
instead of using the DelayRange parameter definition on the
template file.
Option for the acc_handle_simulated_net PLI routine and MIPD
annotation
+vcs+mipd+noalias
For the PLI routine acc_handle_simulated_net, aliasing of a
loconn net and a hiconn net across the port connection is disabled
if MIPD delay annotation happens for the port. If you specify acc
capability: mip or mipb in the pli.tab file, such aliasing is disabled
only when actual MIPD annotation happens.
If during a simulation run, acc_handle_simulated_net is called
before MIPD annotation happens, a warning message is issued.
When this happens you can use this option to disable such
aliasing for all ports whenever mip, mipb capabilities have been
specified. This option works for reading an ASCII SDF file during
simulation and not for compiled SDF files.

acc_handle_simulated_net is defined on IEEE Std 1364-1995


page 366.

Common simv Tasks

This section covers some of the common tasks you might want to
perform using the simv executable. These tasks include the following:

• Saving and Restarting


• Saving and Restarting File I/O

Using scsim to Simulate Your Design


7-58
• Saving and Restarting with Runtime Options
• Restarting at The CLI Prompt
• Specifying A Very Long Time Before Stopping Simulation
• Passing Values From the Runtime Command Line
• Improving Performance
• Profiling the Simulation

Saving and Restarting


VCS MX provides a save and restart feature that allows checkpoints
of the simulation to be saved at arbitrary times. The resulting
checkpoint files can be executed at a later time, causing simulation
to resume at the point immediately following the save.

Note: Save and restart is not supported on Windows.

Benefits of save and restart include:

• Regular checkpoints for interactively debugging problems found


during long batch runs
• Use of plusargs to start action such as $dumpvars on restart
• Executes common simulation system tasks such as $reset just
once in a regression
Restrictions of save and restart include:

• Requires extra Verilog code to manage the save and restart


• Must duplicate start-up code if handling plusargs on restart

Using scsim to SimulateYour Design


7-59
• File I/O suspend and resume in PLI applications must be given
special consideration

Save and Restart Example


A simple example of save and restart is given below to demonstrate
the basic functionality.

The $save call does not execute a save immediately, but schedules
the checkpoint save at the end of the current simulation time just
before events scheduled with #0 are processed. Therefore, events
delayed with #0 are the first to be processed upon restart.

% cat test.v
module simple_restart;
initial begin
#10
$display("one");
$save("test.chk");
$display("two");
#0 // make the following occur at restart
$display("three");
#10
$display("four");
end
endmodule

Now to compile the example Source file:

vcs -Mupdate test.v

Now run the simulation:

simv

VCS displays the following:

one

Using scsim to Simulate Your Design


7-60
two
$save: Creating test.chk from current state of simv...
three
four

Now to restart the simulation from the state saved in the check file,
enter:

test.chk

VCS displays the following:

Restart of a saved simulation


three
four

Saving and Restarting File I/O


VCS MX remembers the files you opened via $fopen and reopens
them when you restart the simulation. If no file exists having the old
filename, VCS MX opens a new file with the old filename. If a file
exists having the same name and length at time of save as the old
file, then VCS appends further output to that file. Otherwise, VCS MX
attempts to open a file with filename equal to the old filename plus
the suffix .N. If a file with this name exists, VCS exits with an error.

If your simulation contains PLI routines that do file I/O, the routines
must detect both the save and restart events, closing and reopening
files as needed. You can detect save and restart calls using misctf
callbacks with reasons reason_save and reason_restart.

Using scsim to SimulateYour Design


7-61
When running the saved checkpoint file, be sure to rename it so that
further $save calls do not overwrite the binary you are running. There
is no way from within the Verilog source code to determine if you are
in a previously saved and restarted simulation, so you cannot
suppress the $save calls in a restarted binary.

Saving and Restarting with Runtime Options


If your simulation behavior depends on the existence of run-time
plusargs or any other run-time action (such as reading a vector file),
be aware that the restarted simulation uses the values from the
original run unless you add special code to process run-time events
after the restart action. Depending on the complexity of your
environment and your usage of the save and restart feature, this can
be a significant task.

For example, if you load a memory image with $loadmemb at the


beginning of the simulation and want to be able to restart from a
checkpoint with a different memory image, you must add Verilog code
to load the memory image after every $save call. This ensures that
at the beginning of any restart the correct memory image is loaded
before simulation begins. A reasonable way to manage this is to
create a task to handle processing arguments, and call this task at
the start of execution, and after each save.

A more detailed example follows to illustrate this. The first run


optimizes simulation speed by omitting the +dump flag. If a bug is
found, the latest checkpoint file is run with the +dump flag to enable
signal dumping.

// file test.v
module dumpvars();
task processargs;
begin
if ($test$plusargs("dump")) begin

Using scsim to Simulate Your Design


7-62
$dumpvars;
end
end
end task
//normal start comes here
initial begin
processargs;
end
// checkpoint every 1000 time units
always
#1000 begin
// save some old restarts
$system("mv -f save.1 save.2");
$system("mv -f save save.1");
$save("save");
#0 processargs;
end
endmodule
// The design itself here
module top();
.....
endmodule

Restarting at The CLI Prompt


The $restart system task has been implemented to allow you to
enter it at the CLI prompt. You enter it with the check file name created
by the $save system task, for example:

C1 > $restart("checkfile1");

Using scsim to SimulateYour Design


7-63
Specifying A Very Long Time Before Stopping
Simulation
You can use the +vcs+stop+time runtime option to specify the
simulation time when VCS halts simulation if the time value you
specify is less that 232 or 4,294,967,296. You can also use the
+vcs+finish+time runtime option to specify when VCS not just
halts but ends simulation but also under the proviso that the time
value be less than 232.

for time values greater than 232 you must follow a special procedure
that uses two arguments to the +vcs+stop or +vcs+finish
runtime options. This procedure is as follows:

1. Subtract 2 X 232 from the large time value.

So, for example if you want a time value of 10,000,000,000 (10


billion):

10, 000, 000, 000 – ( 2 • 4, 294, 967, 296 ) = ( 1, 410, 065, 408 )

Using scsim to Simulate Your Design


7-64
This difference is the first argument.

You can let VCS do some of this work for you, in this example
using the following source code:

module wide_time;
time wide;
initial
begin
wide = 64’d10_000_000_000;
$display(“Hi=%0d, Lo=%0d”, wide[63:32],
wide[31:0]);
end
endmodule

VCS displays:

Hi=2,Lo=1410065408

2. Divide the large time value by 232.

In this example:
10, 000, 000, 000
---------------------------------------------- = 2.33
4, 294, 967, 296
3. Round down this quotient to the whole number. This whole
number is the second argument.

In this example, you round down to 2.


You now have the first and second argument, therefore, in this
example to specify stopping simulation at time 10,000,00,000 you
enter the following runtime option:

+vcs+stop+1410065408+2

Using scsim to SimulateYour Design


7-65
Passing Values From the Runtime Command Line
The $value$plusargs system function can pass a value to a signal
from the simv runtime command line using a +plusarg. The syntax is
as follows:

integer = $value$plusargs("plusarg_format",signalname);

The plusarg_format argument specifies a user-defined runtime


option for passing a value to the specified signal. It specifies the text
of the option and the radix of the value that you pass to the signal.

The following code example contains this system function:

module valueplusargs;
reg [31:0] r1;
integer status;

initial
begin
$monitor("r1=%0d at %0t",r1,$time);
#1 r1=0;
#1 status=$value$plusargs("r1=%d",r1);
end
endmodule

If you enter the following simv command line:

simv +r1=10

The $monitor system task displays the following:

r1=x at 0
r1=0 at 1
r1=10 at 2

Using scsim to Simulate Your Design


7-66
Improving Performance
When you simulate your design you can look for ways to improve the
simulation performance. There are run-time options that enable VCS
to simulate faster or slower. There is also a technique called profiling
that tells you which modules in your design take the most CPU time.

Runtime Options that Accelerate or Impede Simulation


Some runtime options enable VCS to simulate your design faster
because they allow VCS to skip certain operations. You should
consider using these run-time options. These runtime options are as
follows:

+vcs+dumpvarsoff Suppress $dumpvars system tasks.

+vcs+ignorestop Tells VCS to ignore the $stop system tasks in


your source code.

+notimingcheck Disables timing check system tasks. Using this


option at compile-time results in even faster
simulation than using it at runtime.

The run-time options that specify writing to a file that slow down
simulation. These run-time options are as follows:

-a filename All output of simulation is appended to filename as


well as sent to the standard output.

-l filename All output of simulation is written to filename as well


as to the standard output.

Other run-time options that specify operations other than the default
operations also slow down simulation to some extent.

Using scsim to SimulateYour Design


7-67
Profiling the Simulation
If you include the +prof compile-time option when you compile your
design, VCS MX generates the vcs.prof file during simulation. This
file contains a profile of the simulation. It reports the following:

• The module instances in the hierarchy that use the most CPU time
• The module definitions whose instances use the most CPU time
• The Verilog constructs in those instances that use the most CPU
time
You can use this information to see where in your design you might
be able to modify your code for faster simulation performance.

The profile data in the vcs.prof file is organized into a number of


“views” of the simulation. They are as follows:

• Top Level View


• Module View
• Instance View
• Module Construct Mapping View
• Top Level Construct View
• Construct View Across Design

Top Level View


This view shows you how much CPU time was used by:

• Any PLI application that executes along with VCS MX


• VCS MX for writing VCD and VCD+ files

Using scsim to Simulate Your Design


7-68
• VCS for internal operations that can’t be attributed to any part of
your design
• The constructs and statements in your design.
The following is an example of the top level view:

===========================================================================
TOP LEVEL VIEW
===========================================================================
TYPE %Totaltime
---------------------------------------------------------------------------
PLI 0.00
VCD 0.00
KERNEL 29.06
DESIGN 70.94
---------------------------------------------------------------------------

In this example there is no PLI application and VCS is not writing a


VCD or VCD+ file. VCS used 70.94% of the CPU time to simulate the
design, and 29.06% for internal operations, such as scheduling, that
can’t be attributed to any part of the design. The designation KERNEL,
is for these internal operations.

The designation VCD is for the simulation time used by the callback
mechanisms inside VCS for writing either VCD or VCD+ files.

If there was CPU time used by a PLI application, you could use a tool
such as gprof or Quantify to profile the PLI application.

Module View
This view shows you the module definitions whose instances use the
most CPU time. Module definitions whose module instances
collectively used less than 0.5% of the CPU time are not listed.

The following is an example of the module view:

===========================================================================
MODULE VIEW

Using scsim to SimulateYour Design


7-69
===========================================================================
Module(index) %Totaltime No of Instances Definition
---------------------------------------------------------------------------
FD2 (1) 62.17 10000 design.v:142.
EN (2) 8.73 1000 design.v:131.
---------------------------------------------------------------------------

In this example there are two module definitions whose instances


collectively used a significant amount of CPU time, modules FD2 and
EN.

The profile data for module FD2 is as follows:

• FD2 has an index number of 1. This index number is used in other


views that show the hierarchical names of module instances. The
index is for associating a module instance with a module definition
because module identifiers do not necessarily resemble the
hierarchal names of their instances.
• The instances of module FD2 used 62.17% of the CPU time.
• There are 10,000 instances of module FD2. The number of
instances is a way to assess the CPU times used by these
instances. For example, as in this case, a high CPU time with a
corresponding high number of instance tells you that each
instance isn’t using very much CPU time.
• The module header, the first ling of the module definition, is in
source file design.v on line 142.

Instance View
This view shows you the module instances that use the most CPU
time. An instance must use more than 0.5% of the CPU time to be
entered in this view.

The following is an example of the instance view:

===========================================================================

Using scsim to Simulate Your Design


7-70
INSTANCE VIEW
===========================================================================
Instance %Totaltime
---------------------------------------------------------------------------
test.lfsr1000_1.lfsr100_1.lfsr10_1.lfsr_1.en_
1 ( 2 ) 0.73

---------------------------------------------------------------------------

In this example there is only one instance that uses more that 0.5%
of the CPU time.

This instance’s hierarchical name is


test.lfsr1000_1.lfsr100_1.lfsr10_1.lfsr_1.en_1. Long hierarchical
names wrap to the next line.

The instance’s index number is 2, indication that it is an instance of


module EN, which had an index of 2 in the module view.

This instance used 0.73% of the CPU time.

No instance of module FD2 is listed here so no individual instance of


FD2 used more that 0.5% of the CPU time.

Note:
It is very common for no instances to appear in the instance view.
This happens when many instances use some of the simulation
time but none use more than 0.5% of the total simulation time.

Module to Construct Mapping View


This view shows you the CPU time used by different types of Verilog
constructs in each module definition in the module view. There are
the following types of Verilog constructs:

• always constructs (commonly called always blocks)


• initial constructs (commonly called initial blocks)

Using scsim to SimulateYour Design


7-71
• module path delays in specify blocks
• timing check system tasks in specify blocks
• combinational logic including gates or built-in primitives and
continuous assignment statements
• user-defined tasks
• user-defined functions
• module instance ports
• user-defined primitives (UDPs)
• Any Verilog code protected by encryption
Ports use simulation time particularly when there are expressions in
port connection lists such as bit or part selects and concatenation
operators.

This view has separate sections for the Verilog constructs for each
module definition in the module view.

The following is an example of a module to construct mapping view:

===========================================================================
MODULE TO CONSTRUCT MAPPING
===========================================================================

___________________________________________________________________________
1. FD2
---------------------------------------------------------------------------
Construct type %Totaltime %Moduletime LineNo
---------------------------------------------------------------------------
Always 27.44 44.14 design.v : 150-160.
Module Path 23.17 37.26 design.v : 165-166.
Timing Check 11.56 18.60 design.v : 167-168.
___________________________________________________________________________

Using scsim to Simulate Your Design


7-72
___________________________________________________________________________
2. EN
---------------------------------------------------------------------------
Construct type %Totaltime %Moduletime LineNo
---------------------------------------------------------------------------
Combinational 8.73 100.00 design.v: 137.
___________________________________________________________________________

For each construct the view reports the percentage of “Totaltime” and
“Moduletime”.

%Totaltime
The percentage of the total CPU time that was used by this
construct.
%Moduletime
Each module in the design uses a certain amount of CPU time.
This percentage is the fraction of the module’s CPU time that was
used by the construct.
In the section for module FD2:

• An always block in this module definition used 27.44% of the


TOTAL CPU time. Of all the CPU time consumed by all instances
of the FD2 module, 44.14% is spent on this construct (44.14% of
62.17% = 27.44%). The always block is in source file design.v
between lines 150 and 160.

If there were another always block in module FD2 that used more
than 0.5% of the CPU time, there would be another line in this
section for it, beginning with the always keyword.
• The module path delays in this module used 23.17% of the TOTAL
CPU time. Of all the CPU time consumed by all instances of the
FD2 module, 37.26% is spent on this construct. These module
path delays can be found on lines 165-166 of the design.v source
file.

Using scsim to SimulateYour Design


7-73
• The timing check system tasks in this module used 11.56% of the
TOTAL CPU time. Of all the CPU time consumed by all instances
of the FD2 module, 18.60% is spent on this construct. These
timing check system tasks can be found on lines 167-167 of the
design.v source file.
In the section for module EN, a construct classified as Combinational
used 8.73 of the total CPU time. 100% of the CPU time used by all
instances of EN were used for this combinational construct.

No initial blocks, user-defined functions, or user-defined tasks, ports,


UDPs, or encrypted code in the design used more than 0.5% of the
CPU time. If there were, there would be a separate line for each of
these types of constructs.

Top Level Construct View


This view show you the CPU time used by different types of Verilog
constructs throughout the design. The following is an example of the
Top Level Construct View:

===========================================================================
TOP-LEVEL CONSTRUCT VIEW
---------------------------------------------------------------------------
Verilog Construct %Totaltime
---------------------------------------------------------------------------
Always 27.47
Module Path 23.17
Timing Check 11.56
Combinational 8.73
Initial 0.00
Function 0.00
Task 0.00
Port 0.00
Udp 0.00
Protected 0.00

___________________________________________________________________________

Using scsim to Simulate Your Design


7-74
This view contains a line for each type of construct, for example, all
the always blocks in the design used 27.47% of the CPU time.

Construct View Across Design


This view shows you the module definitions that contains a type of
construct that used more that 0.5% of the CPU time. There are
separate sections for each type of construct and a listing in each
section of the modules that contain that type of construct.

The following is an example of the construct view across design:

===========================================================================
CONSTRUCT VIEW ACROSS DESIGN
===========================================================================

___________________________________________________________________________
1.Always
---------------------------------------------------------------------------
Module %TotalTime
---------------------------------------------------------------------------
FD2 27.44
___________________________________________________________________________

___________________________________________________________________________
2.Module Path
---------------------------------------------------------------------------
Module %TotalTime
---------------------------------------------------------------------------
FD2 23.17
___________________________________________________________________________

___________________________________________________________________________
3.Timing Check
---------------------------------------------------------------------------
Module %TotalTime
---------------------------------------------------------------------------
FD2 11.56
___________________________________________________________________________

Using scsim to SimulateYour Design


7-75
___________________________________________________________________________
4.Combinational
---------------------------------------------------------------------------
Module %TotalTime
---------------------------------------------------------------------------
EN 8.73
___________________________________________________________________________

How VCS Prevents Time 0 Race Conditions

At simulation time 0, VCS always executes the always blocks in which


any of the signals in the event control expression that follows the
always keyword (the sensitivity list) initialize at time 0.

For example, consider the following code:

module top;
reg rst;
wire w1,w2;
initial
rst=1;
bottom bottom1 (rst,w1,w2);
endmodule

module bottom (rst,q1,q2);


output q1,q2;
input rst;
reg rq1,rq2;

assign q1=rq1;
assign q2=rq2;

always @ rst
begin
rq1=1’b0;
rq2=1’b0;
$display("This always block executed!");
end
endmodule

Using scsim to Simulate Your Design


7-76
With other Verilog simulators there are two possibilities at time 0:

• The simulator executes initial block first, initializing reg rst, then
the simulator evaluates the event control sensitivity list for the
always block and executes the always block because rst
initialized.
• The simulator evaluates the event control sensitivity list for the
always block, and so far reg rst has not changed value during this
time step so the simulator does not execute the always block, then
the simulator executes the initial block and initializes rst. When
this happens the simulator does not re-evaluate the event control
sensitivity list for the always block.

Making a Verilog Model Protected and Portable

After a design is successfully verified using VCS, there is a separate


tool available for those who want to make the design portable and
protected. This tool, Verilog Model Compiler (VMC), enables you to
secure your design and distribute it to your partners and internal or
external customers without an NDA.

VMC is a model development tool used to generate portable models,


starting with Verilog source and producing compiled SWIFT models.
SWIFT is a language- and simulator-independent interface that
allows your model to run with any SWIFT-compatible simulators;
more than thirty simulators are now available.

VMC models contain no Verilog source code, so they are able to


protect the intellectual property of the underlying design. This enables
model developers to distribute their models without revealing the
contents, because the models are secure. More importantly, the
models are functionally exact because they are derived from the
original Verilog description of the model

Using scsim to SimulateYour Design


7-77
For more information about VMC, refer to the IP Modeling product or
the following web site: http://www.synopsys.com/products/lm/ip/
ip.html

Re-Invoking a Simulation With VirSim

If you need to both interactively debug your design with VirSim and
enter scsim command line options to control the simulation of the
VHDL part of your design, you can do so but only after the first
interactive simulation. Do the following:

1. Enter the Sim => Invoke Sim menu command in the Interactive
window. This opens the Simulator Invocation Dialog.

Using scsim to Simulate Your Design


7-78
2. Enter additional runtime options in the command line in this
Dialog. Be sure to include the -vhdlrun option followed by scsim
command line options for example:

3. Click the OK button.

Using Interactive Commands

If you included the -s option, VCS halts just before simulation starts
and shows you the CLI (Command Language Interface) prompt:

cli_0>

If VCS executes the $stop system task, simulation halts and VCS
then shows you the CLI prompt.

Using scsim to SimulateYour Design


7-79
This prompt is for entering CLI debugging commands. These
commands allow you to display the values of signals in the current
scope in the hierarchy, change scope, assign values to signals, apply
breakpoints, and other debugging commands. These commands are
described in the VCS User’s Guide.

You can enter CLI commands for both the Verilog and VHDL parts
of your design.

The “Command” field in the VirSim Interactive window is also a prompt


for CLI commands. Button commands in the “User Defined Buttons”
area of the Interactive window are really CLI commands entered by
VirSim.

If you are using VirSim to interactively debug your design, you can
enter CLI commands for both the Verilog and VHDL parts of your
design.

Special Rules For Interactive Commands


For mixed HDL simulation there are these special rules to keep in
mind when entering interactive commands:

• When entering CLI commands to perform and operation on a


signal or to specify a part of the hierarchy, in both the VHDL and
Verilog part of a design, always use the “.” period character as
the delimiter between instance names and before the signal name
in hierarchical names.
• When entering commands for VHDL signals, part selects or slices
are not supported.
• Commands that display drivers or loads do not do so across the
VHDL/Verilog boundary of a mixed HDL design.

Using scsim to Simulate Your Design


7-80
• The oformat CLI command can specify 13 formats
(%b|c|t|f|e|g|d|h|x|m|o|s|v), however only the binary
(b)octal (o), hexadecimal (h or x) are valid in the VHDL part of
the design, so if you set a format that is not b, o, h, or x, VCS
displays a warning message and the previous format is retained
for displaying VHDL values.

CLI Changes Caused By The TCL Shell Environment


A TCL shell environment enables you to use the both the VCS CLI
and the VCS MX Command Language in both the VCS flow and VCS
MX flow for mixed HDL simulation. This TCL shell environment,
however has required a number of changes to the VCS CLI for mixed
HDL simulation.

TCL treats the following as special characters: ’ ‘ " $ space,


newline, and tab. To prevent TCL from attaching special meaning to
these characters, enclose commands and arguments that contain
them in curly braces { }. This section describes some of the
instances when you should use these braces.

If you enter the scope CLI command to change scope to a Verilog


instance names with an escaped identifier, you must enclose the
escaped identifier with curly braces, and include the blank space that
terminates the escaped identifier name inside the curly braces, for
example:

scope {\_scope1.scope2 }

There is a different syntax for entering system tasks at the CLI prompt,
you can’t simply enter the system task, but must include the system
task as an argument, enclosed in curly braces, to the new call
command. The syntax is as follows:

Using scsim to SimulateYour Design


7-81
call { $system_task(arg1,arg2,...)}

For example:

call { $vcdpluson(0,vlogdes1)}

Be sure to leave out the semicolon (;) at the end of the system task.

IMPORTANT:
You can only enter system tasks when your current scope
is in the Verilog part of the design.

The tick character ’ that is used for specifying a radix in some Verilog
values, should be enclosed in curly braces, for example:

assign reg1 = {4’hf}


TCL also interprets certain CLI commands differently and therefore
these commands are renamed.The renamed commands and their
new names are as follows:

• The set command, for assigning values to a signal, is now the


assign command.
• The info command, for displaying time and scope information,
is now the vinfo command.
• The continue command, for resuming simulation, is now the
vcontinue command.

Switching Command Languages


In mixed HDL simulation, VCS MX understands both the VCS
Command Language Interface (CLI) and the VCS MX Control
Language so during simulation you can switch from one to the other
and back again. The command to make this switch and its options
are as follows:

Using scsim to Simulate Your Design


7-82
changemode [-query | -verilog | -vhdl]

The -query option clarifies whether you currently have enabled the
VCS MX Control Language or the VCS CLI.

The -verilog option specifies switching to the VCS CLI.

The -vhdl option species switching to the VCS MX Control


Language.

Entering the changemode command without options toggles the


command language from the current one to the other one.

If you switch to the VCS MX Control Language the special rules


described above for interactive commands also hold true for VHDL
part selects, or slices, and displaying drivers and loads across the
VHDL/Verilog boundary. With the VCS MX Control Language use the
“/” slash character as the delimiter in hierarchical names.

Note:
If you are running VirSim for interactive debugging, you cannot
enter the changemode command. The changemode command
is for the text based interface for the VCS MX Command
Language and the VCS CLI.

Hierarchical Name Syntax


Hierarchical name syntax in both the VCS MX Control Language and
the VCS CLI is different depending on whether VHDL or Verilog is on
top of the design hierarchy of a mixed HDL design.

Using scsim to SimulateYour Design


7-83
Here in the VCS flow, where Verilog is at the top of the hierarchy:

Hierarchical names do not begin with the delimiter.


In The VCS MX Control Language a hierarchical name could be:
top/U1/T1
In the VCS CLI a hierarchical name could be: top.U1.T1

In the mixed HDL flow, where VHDL is at the top of the hierarchy:

Hierarchical names begin with the delimiter.


In The VCS MX Control Language a hierarchical name could be:
/top/U1/T1
In the VCS CLI a hierarchical name could be: .top.U1.T1

Using scsim to Simulate Your Design


7-84
8
Debugging and Post-Processing 3
This chapter covers the following debugging and post-processing
topics:

• Interactive Debugging Using the Command Line


• Interactive Simulation using the GUI
• Post-Processing for VHDL-Only and VHDL-Top Flows
• Post-Processing for Verilog-Only and Verilog-Top Flows
• VCS MX VHDL Timebase and Time Precision Resolution
• Comparing VCS CLI and VCS MX VHDL SCL Commands

Debugging and Post-Processing


8-1
Interactive Debugging Using the Command Line

When a VHDL-only or VHDL-top simulation starts, you are at the VCS


MX command line prompt “#”. You can use almost all the VCS MX
control langauge (SCL) commands used for pure VHDL simulation
in mixed language simulation.

When entering commands to perform an operation on a signal or to


specify a part of the hierarchy, in both the VHDL signal and Verilog
part of a design, always use the / slash character as the delimiter
between instance names and before the signal name in hierarchical
names.

For more information about VCS MX control language, see “VCS MX


Control Language” in Chapter 6 of the VCS MX Reference Guide.

Changing Between Command Languages

In mixed HDL simulation, you can use both the VCS Command
Language Interface (CLI) and the VCS MX Control Language. This
capability lets you change from one command interface to the other
and back again during simulation.

You use the changemode command and its options to go back and
forth between the interfaces. The command syntax and its options
are as follows:

changemode [-query | -verilog | -vhdl]

-query
Displays the currently enable interface.

Debugging and Post-Processing


8-2
-verilog
Enables the VCS CLI.
-vhdl
Enables the VCS MX Control Language.
Using the changemode command without options toggles the
command language from the current one to the other one.

If you change to CLI, the special rules described above for interactive
commands also hold true for VHDL part selects, or slices, and
displaying drivers and loads across the VHDL/Verilog boundary. With
CLI use the ( . ) period character as the delimiter in hierarchical
names.

Hierarchical Name Syntax

The hierarchical name syntax you use in VCS MX Control Language


and VCS MX Verilog CLI is different depending on whether VHDL or
Verilog is on top of the design hierarchy of a mixed HDL design.

In the VCS MX mixed-HDL flow, where VHDL is at the top of the


hierarchy:

• Hierarchical names begin with the delimiter.


• In VCS MX Control Language a hierarchical name can be
/TOP/U1/T1.
• If you change the mode to VCS MX Verilog CLI, then the
hierarchical name will be .TOP.U1.T1

Debugging and Post-Processing


8-3
After Changing to VCS MX Verilog CLI

When you change to VCS MX Verilog CLI, a Tcl shell environment in


VCS MX lets you enter most CLI commands. You enter the
commands as if you are running a Verilog simulation with VCS MX,
however there are a few differences in the Tcl environment. These
differences are described here.

Special Characters
Tcl treats the following as special characters: ’ ‘ " $space, newline,
and tab. To prevent Tcl from attaching special meaning to these
characters, enclose commands and arguments that contain the
special characters in curly braces { }.

Use the braces in the following cases:

• If you enter the scope CLI command to change scope to a Verilog


instance names with an escaped identifier, you must enclose the
escaped identifier with curly braces and include the blank space
that terminates the escaped identifier name inside the curly
braces, for example:
scope {\_scope1.scope2 }

• When you change to CLI, the syntax for entering system tasks at
the CLI prompt is different. You can not simply enter the system
task, but must include the system task as an argument, enclosed
in curly braces, to the new call command. The syntax is as follows:
call { $ system_task( arg1, arg2,...)}

For example,

call { $vcdpluson(0,vlogdes1)}

Debugging and Post-Processing


8-4
Remember not to add the semicolon (;) at the end of the system
task.

Important:
You can only enter system tasks when your current scope is in
the Verilog part of the design.

• The tick character ’ used for specifying a radix in some Verilog


values, must be enclosed in curly braces, for example
assign reg1 = {4’hf}

Renamed Commands
Tcl interprets certain CLI commands differently, therefore they are
renamed.The renamed commands and their new names are as
follows:

• The set command, for assigning values to a signal, is now the


assign command.
• The info command, for displaying time and scope information, is
now the vinfo command.
• The continue command, for resuming simulation, is now the
vcontinue command.
Special Syntax/Requirements
The syntax for assign and hold commands is a little different than the
one in pure VHDL design. Examnple -

assign {“1”} /VHDL_object


hold {“1”} /VHDL_object
assign {1‘b1} /Verilog_object
hold {1’b0} /Verilog_object

Debugging and Post-Processing


8-5
In order to assign and hold Verilog objects, you need to use +cli+2/
3/4 through -verilogcomp depending upon the type (nets/reg
etc.).

Special Requirement for assigning a Verilog net


To be able to use the assign command to write a Verilog net, you
need to use +cli+3 and a tab file. The content of the tab file should
be

acc=wn:*

Interactive Simulation using the GUI

The interactive simulation is supported for the entire design (including


both VHDL and Verilog portions) without any restriction. You can use
all windows for debugging purposes except the Logic browser. The
steps for invoking and using the GUI for simulating mixed language
designs interactively are the same as for pure VHDL interactive
simulation using GUI.

Although you can change to full debug mode for VHDL portion of the
design (using -debug_all at scsim command line) at run-time, you
must enable the interactive GUI simulation capabilities for Verilog
portion of the design during Verilog compilation and code generation
stage by using -I option through -verilogcomp.

For example,

% scs lib.cfg_design -verilogcomp “-I”

For enabling line tracing, you can use -line switch as -

% scs lib.cfg_design -verilogcomp “-I -line”

Debugging and Post-Processing


8-6
Note:
Use interactive simulation through the GUI only for debugging
purposes as it greatly slows the simulation performance.

Post-Processing for VHDL-Only and VHDL-Top Flows

You can generate a post-processing file in three different formats:


VPD (VCD+), VCD, or eVCD. To generate these files, use the dump
command (with various options) during simulation.

Use of the following variables in the setup file is highly recommended


for specifying the post-processing data output file name.

VPD_OUTFILE = filename.vpd
VCD_OUTFILE = filename.vcd
EVCD_OUTFILE = filename.evcd

See Appendix 6, “VCS MX Control Language” of the VCS MX


Reference Guide for more information about using the dump
command and VCS User Guide for $vcdpluson, $dumpvars,
$dumpports/$lsi_dumpports and post-processing options.

VPD

You can create a single VPD (VCD+) file for the entire design (VHDL
plus Verilog) using VCS MX’s dump command. To enable the post-
processing in Verilog portion of the design, use “-PP” switch for
Verilog compilation (through -verilogcomp).

To dump the objects in the entire design excluding Verilog portion,


use the -no_verilog option along with “dump -deep” command.

Debugging and Post-Processing


8-7
Delta Dumping Supported in VPD Files
VCS MX supports delta dumping in VPD files for post-processing
using the $vcdplusdeltacycleon system task.

Syntax:

$vcdplusevent(net_or_reg,"event_name", "<E|W|I><S|T|D>");

This task displays, in VirSim, a symbol on the signal’s waveform and


in the Logic Browser. The event_name argument appears in the
status bar when you click on the symbol. E|W|I specifies severity. E
for error, displays a red symbol, W for warning, displays a yellow
symbol, I for information, displays a green symbol.

eVCD

You can create single eVCD file for the entire design using
dump -evcd command in VCS MX UI.

The -deep option of the dump command is not supported. So in


order to dump various objects at various hierarchy levels, you need
to specify them at the command line.

For example,

dump -evcd -all /tb


dump -evcd /tb/dut/abc
dump -evcd /tb/dut/mod/*

If you wish to dump eVCD data for Verilog portion, you need to use
“+cli+2” option in -verilogcomp.

Debugging and Post-Processing


8-8
You can also use $dumpports or $lsi_dumpports in Verilog source
code in which case, you don’t need to provide “-PP +cli+2” etc.
options through -verilogcomp.

Line Tracing

You can enable line tracing for the entire design (VHDL and Verilog).
For VHDL portion, you need to simulate the design using
-debug_all run-time option and use dump command (dump
-line). You need to use -debug_all run-time option while running
scsim. This greatly degrades the simulation performance and
therefore use it only for debugging.

For Verilog portion, you need to provide “-PP -line” options through
-verilogcomp.

Delta Cycle

Delta Cycle recording for the entire mixed language design is not
supported. It will work on respective portions of the design. You can
get Delta Cycle data using -vpddeltacapture switch for scsim
at run-time.

Viewing the Simulation Results

Once post-processing data is generated, you can use VCS MX GUI


for analysis. VCS MX GUI lets you display the simulation results
saved in the VCD or VPD file.

The steps for invoking and using the GUI for post-processing are the
same as the steps for pure VHDL designs.

Debugging and Post-Processing


8-9
Post-Processing for Verilog-Only and Verilog-Top
Flows

In the Verilog-only and Verilog-top flows, you can generate simulation


history files for viewing the results after simulation using DVE or
VirSim or a third party viewer. This section describes the simulation
history file formats and how you generate them.

VCD+ files (VCD “plus” or VPD files) are generated when VCS
executes the $vcdpluson system task, see the VirSim User Guide.
If you enable it, the VCD+ file can contain simulation results from both
the Verilog and VHDL parts of the design.The $vcdplustraceon
system task specifies recording in the VCD+ file the order in which
the source code lines are executed so that you can see the order in
post processing. If you did not enter these system tasks in your Verilog
source code you can enter them at the CLI prompt using a different
syntax. The default name of the generated VCD+ file is vcdplus.vpd.

You can generate two ASCII text VCD (Value Change Dump) files.
One for the Verilog part of the design with the $dumpvars system
task, and one for the VHDL part with the dump -vcd VCS MX VHDL
control language command.

Post-processing the VHDL part of the design using VCD or VCD+


files requires that signal values be available for recording in the file.
Therefore post-processing the VHDL part is enabled with the -
vhdlrun "-debug_all" runtime option (this option also enables
stepping through the code in VCD+ file post-processing).

You can generate an EVCD file using the $dumpports or


$lsi_dumports system tasks or using the VCS MX VHDL Control
Language (SCL), see the following section.

Debugging and Post-Processing


8-10
Generating EVCD Files

You can use $dumpports or $lsi_dumports system tasks to


generate EVCD files. Using system tasks you can generate multiple
EVCD files for various module instances of the Verilog part of the
design. You can’t use these system tasks for the VHDL part of the
design.

You can use the SCL dump -evcd command and option to specify
recording data in an EVCD file for ports in both the Verilog and VHDL
parts of the design, for example:

VCS MX VHDL Timebase and Time Precision Resolution

If the shortest Verilog timescale time precision specification is shorter


than the VHDL timebase you must reset the VHDL timebase so that
it is the same or a higher resolution.

For example if the shortest Verilog time precision specification was


the following:

`timescale 1ns/1ps

The time precision specification is 1 ps so we must set the VCS MX


VHDL timebase to ps. There are two ways to do this:

• Make the following entry in the synopsys_sim.setup file:


TIMEBASE ps

• Enter the -time = ps scs command line option using the -


vhdlelab compile-time option:

Debugging and Post-Processing


8-11
-vhdlelab "-time ps"

Note:
By default the VCS MX VHDL time base is set to ns.

The VCS MX VHDL timebase is not quite the same as a Verilog time
precision argument to the ‘timescale compiler directive, you can’t
set it to multiples of a time unit, for example 10 ps. If there is a
mismatch between them the simulators attempt to adjust to the higher
resolution but Synopsys recommends that you avoid this situation.

For example, change ‘timescale 1ns/10ps to


‘timescale 1ns/1ps.

Cross Module Referencing Between Verilog Hierarchies

In the VCS MX design flow, you can instantiate more than one Verilog
design or more than one Verilog hierarchy in a VHDL design. If you
do, you can use regular Verilog cross module references between
different Verilog designs or Verilog hierarchies — the same as if your
design is pure Verilog.

Mixed Language XMRs ($hdl_xmr)

You can access/assign objects (signals in VHDL, registers in Verilog)


across the language boundary using the HDL Cross Module
Reference mechanism or the $hdl_xmr system task.

The following two sections explain how to use $hdl_xmr system task
in VHDL and in Verilog.

Debugging and Post-Processing


8-12
Verilog Referencing VHDL

If you want to make cross module references between different


Verilog modules or Verilog hierarchies, use regular Verilog XMR. But
if you want to reference VHDL objects from Verilog modules, use
$hdl_xmr system task.

The procedure to use the $hdl_xmr system task in Verilog is as


follows:

1. Use the $hdl_xmr system task in an initial block in the Verilog


source.
$hdl_xmr("source_object" , "destination_object");

You need an absolute or relative path for the source and


destination objects. For example:

initial begin
$hdl_xmr("vl_tb:vh_top:clk", “vl_tb:vclk”);
$hdl_xmr("vl_tb:vh_top:reset_n", “vl_tb:vreset_n”);
$hdl_xmr("vl_tb:vh_top:state[3:0]",“vl_tb:state”);
end

Note:
- The source and destination objects need to be of same type and
size.

As a result of specifying the the $hdl_xmr system task, each


time an event occurs in the source object, the destination object
will be assigned the new value of the source object. It is important
to note that if the destination object has other sources, like an
assignment statement, the last event value (from $hdl_xmr or
the assignment statement) will be assigned to the destination
object, thus overwriting the previous value.

Debugging and Post-Processing


8-13
2. Analyze the VHDL/Verilog sources with vhdlan/vlogan
3. Compile the design with vcs with +cli+2 and a hdl_xmr tab file
% vcs -mhdl +cli+2 vl_top.v \
-P $VCS_HOME/lib/hdl_xmr.tab \
$SYNOPSYS_SIM/$ARCH/sim/lib/libhdlxmr.so

4. Run simulation with simv.

VHDL Referencing Verilog or VHDL

You can use the $hdl_xmr system taks in VHDL to reference Verilog
objects and also VHDL objects.

You need to make sure that the types and bounds of the objects from
both the languages are compatible else you will get an error at run
time.

The procedure to use the $hdl_xmr system task in VHDL is as


follows:

1. Include the XMR package in your VHDL source code


Library Synopsys;
Use Synopsys.hdl_xmr_pkg.all;

2. Call the procedure concurrently or within a process, with no


sensitivity list and a wait at the end of the process. This is similar
to initial block in Verilog. Note that the procedure call has the
exact same effect as $hdl_xmr in Verilog (it overwrites the values
of different sources).
hdl_xmr ("source_object" , "destination_object");

You need an absolute path for the source and destination objects.
For example:

Debugging and Post-Processing


8-14
hdl_xmr(":vh_tb:vl_top:cout0",":vh_tb:coutin_xmr");
or
hdl_xmr("/vh_tb/vl_top/cout0","/vh_tb/coutin_xmr");

Note:
- The source and destination objects need to be of same type and
size

3. Make sure LD_LIBRARY_PATH is set to include the path to the


libhdlxmr shared library object that is available from
$SYNOPSYS_SIM/{ARCH}/sim/lib/libhdlxmr.so

4. Analyze the VHDL/Verilog sources with vhdlan/vlogan


5. Compile the design with scs with +cli+2 option in
-verilogcomp option
% scs -nc vh_tb -verilogcomp " +cli+2"

6. Run simulation with scsim.

Comparing VCS CLI and VCS MX VHDL SCL Commands

Many VCS CLI and VCS MX VHDL Control Language commands


perform the same function and can be used interchangeably. This
section shows you the commands and their equivalent in the other
command language, organized by tables for functional categories.

Table 8-1 Commands for Browsing and Displaying Values


VHDL Mode Verilog Mode
pwd (current scope) vinfo - displays current scope and time
scope - displays current scope
cd [region] scope (absolute or relative name)
cd /e/uut

Debugging and Post-Processing


8-15
Table 8-1 Commands for Browsing and Displaying Values
cd .. upscope (to parent scope)
ls -v print (show value)
print net_or_reg
ls -m - shows mode: Event or Cycle
ls [-v][-t][VHDL_name] show variables | ports | scopes
e.g. ls -v *;
mon -list * show [break | loads | drivers | ports |
drivers [-e|-d] signal_name_list scopes | variables]

Table 8-2 Simulation Control Commands


VHDL Mode Verilog Mode
run [max_delta_time] ., vcontinue (continue simulation)
next [n] next (Next line)
step [n]
quit quit, finish

Table 8-3 Breakpoint Commands


VHDL Mode Verilog Mode
monitor tbreak
monitor -s always | break net_or_reg
monitor [-c|s] [-at] [-after] always #relative time
monitor -s -expr condExpr always @posedge| @negedge
monitor -after time break | once #relative time
monitor -delete | -disable delete breakpoint
monitor -list show break
once [#relative time | @posedge
| @negedge] net_or_reg
| ##absolute time
monitor -at time once ## absolute time

Debugging and Post-Processing


8-16
Table 8-4 Stimulus Commands
VHDL Mode Verilog Mode
hold force net_or_reg = value
release release net_or_reg
assign [-after delay] (VHDL_expresson) assign reg_or_memory = value
{var_name} {signal_name}
{generic_name}

Debugging and Post-Processing


8-17
Table 8-5 Miscellaneous Commands
VHDL Mode Verilog Mode
help help
history
alias alias
unalias
set base bin | hex | oct oformat %b | c | t | f | e | g | d | h | x | m |
o|s|v
Only the b, h, o, or x selections are valid
in the VHDL part of the design
source filename
line
vtrace
dump

Debugging and Post-Processing


8-18
9
Discovery Visual Environment 4
Discovery Visual Environment (DVE) software is a graphical
verification environment that supports debugging for VCS MX
simulations. DVE allows you to work in post-processing and
interactive mode.

For information on using DVE, see the Discovery Visual Environment


User Guide.

Using DVE, you can perform the following tasks:

• Hierarchically expand and view HDL scope information.


• Debug assertions.
• View log, history, and error/warning information related to your
analysis.

Discovery Visual Environment


9-1
• Perform TCL tasks by executing scripts from the DVE graphical
user interface or executing TCL commands or sourcing scripts
through the command-line interface.

Primary DVE Components

This section provides an overview of the following core components


of DVE:

• Top Level Window


• Source Window
• Assertion Window
• Wave Window
• List Window
• Schematic Window

Top Level Window

The Top Level Window is a frame that can contain the other windows.
A Top Level Window has menus, toolbars and statusbar. From the
Top Level Window, you can:

• Use the Menu bar, Toolbar, and Status Bar to run and interact
with a simulation or open, view, navigate, edit, and close a design
database and set the target for new panes and windows
containing source code, waveforms, schematics, and ASCII data.
You can specify analysis and search parameters, invoke TCL
scripts, run examples, and access Help.

Discovery Visual Environment


9-2
• Use the Hierarchy Browser to view, expand, and select scopes of
interest for display in a Waveform Window.
• View and filter signal information. Double click a signal of interest
to view source code or drag and drop it into another DVE pane or
window. Dragging and dropping is supported in the Data Pane,
Source, Wave, List, and Assertion windows.
• View HDL or Assertion source code in the Source Window or in
multiple Source Windows.
• View assertion failures and history.
• Perform TCL tasks by executing scripts from the DVE graphical
user interface or executing TCL commands or sourcing scripts
through the command-line interface.
• Activate any open DVE window or pane regardless of where it is
in the desktop window stack.
• Access DVE windows, such as the Waveform Window and List
Window, to debug your design.
Figure 9-1 shows an example of the Top Level Window.

Discovery Visual Environment


9-3
Figure 9-1 DVE Top Level Window Initial View
Hierarchy Browser Menu Bar
Data Pane Source Window
Toolbar

Assertion Window Tabs to activate


associate window

TCL Command-line Interface


Tabs
Console (Log tab currently displayed)

Discovery Visual Environment


9-4
Status Bar
The status bar in the lower left corner of the Top Level Window
displays information about your simulation. Figure shows the
information displayed in the status bar boxes.Status Bar

Figure 9-2 Status Bar


The number of
The current scope of the
selected objects in
Hierarchy browser, source
the Hierarchy
window, or schematic browser.
browser, source
window, or
schematic browser. Target window selection
icons.

The name of selected


The current time
objects in the Hierarchy The current status of the design
browser, source code of the simulator
window, or schematic
browser.

Discovery Visual Environment


9-5
Source Window
In addition to viewing source code in the Source Window, you can
open multiple tabs or freestanding Source Windows. You display
HDL, testbench, and assertion source code by double-clicking an
item in a list or by dragging and dropping a signal or assertion from
another DVE window.

Figure 9-3 Source Window


Code Display

Line Attributes

Discovery Visual Environment


9-6
Assertion Window
Use the Assertion Window tabs to view assertions and assertion
failures:

• Assertion Failure Summary tab: Displays a summary of one failed


attempt for every failing assertion. By default the failed attempt is
the first attempt that failed.
• Assertions tab: Totals results for all assertions in a selected block
or scope. Also allows analysis of results of specific assertion
attempts.
Figure 9-4 Assertion Window tabs
Assertion Data Column Headers Assertion Failure Data

Tabs Column Headers Assertion Data

Discovery Visual Environment


9-7
Wave Window
The Wave Window displays

• Waveforms of selected signals in your design.


• Trace information for a particular assertion, along with a waveform
of the signals and expressions associated with the assertion.

Displaying Signals in the Wave Window


Use the Wave Window to view and highlight signals of interest,
advance to various simulation times, and view simulation time deltas.

To view signals in the Waveform Window, you can double click an


an assertion summary item or an attempt, drag and drop an item in
a list or select an item and select Add to Waves from the menu.

Figure 9-5 shows an example of the Waveform Window displaying


signals. Cursor 1 (C1) indicates current time.

Discovery Visual Environment


9-8
Figure 9-5 Waveform Window
Signal group name Signal list Cursor C1 Waveforms

Viewing Assertions and Assertions Attempts


You debug assertions by first displaying information for a particular
assertion failure in the Assertion Window, You can then examine a
waveform of the signals. All trace information is color-coded for easy
readability and analysis.

Typically, you access and view an assertion by double-clicking a


particular assertion in either of the following windows:

• The Assertion Window (located in the Console of the Top Level


Window)
• The Hierarchy Browser by navigating to the assertion.

Discovery Visual Environment


9-9
Or you can drag and drop an OVA assertion unit from the Hierarchy
Browser or an OVA or SVA assertion from the Data Window into the
the Wave Window (double click to display the source code in the
Source Window).

You can then view a trace of a failed assertion by double clicking a


failed attempt (a red up arrow) in the Wave Window.

Figure 9-6 shows an example of the Waveform Window. displaying


a trace of a failed assertion attempt. The cursors mark the start and
end times of the failure and the background color is also different to
indicate the assertion time region. This lighter color persists if the
cursors are moved to make it easy to identify the assertion region.

Discovery Visual Environment


9-10
Figure 9-6 Waveform Window displaying a trace of a failed assertion attempt
Assertion and Start time of
related signals assertion failure
End time of
assertion failure

List Window
Use the List Window to generate ASCII simulation results. The List
Window displays simulation data as shown in the Wave Window but
in tabular format. It is a scrollable window, showing simulation time
on the left.

Discovery Visual Environment


9-11
Figure 9-7 List Window
Signals Simulation Time Results

Schematic Window
Schematic views provide a compact, easy-to-read graphical
representation of a design. There are two types of schematic views
in DVE: design and path.

• A design schematic shows the hierarchical contents of a the


design or a selected instance and lets you traverse the hierarchy
of the design.

Discovery Visual Environment


9-12
Figure 9-8 . Design Schematic

• A path schematic is a subset of the design schematic displaying


where signals cross hierarchy levels. Use the path schematic to
follow a signal through the hierarchy and display portal logic
(signal effects at ports).

Discovery Visual Environment


9-13
Figure 9-9 Path Schematic

Discovery Visual Environment


9-14
10
Using OpenVera Assertions 5
This chapter introduces OpenVera Assertions, and explains how to
compile and run OpenVera Assertions within the various VCS MX
flows.

This chapter cover the following topics:

• Introducing OpenVera Assertions


• Creating a Temporal Assertion File
• Compiling Temporal Assertions Files
• OVA Runtime Options
• Using OVA with VHDL-Only and Mixed-HDL Designs
• Viewing OVA Simulation Results

Using OpenVera Assertions


10-1
Introducing OpenVera Assertions

OpenVera Assertions (OVA) provides a clear, easy way to describe


sequences of events and facilities to test for their occurrence. With
clear definitions and less code, testbench design is faster and easier.
And you can be confident that you are testing the right sequences in
the right way.

OVA is a clear, easy way to describe sequences of events and


facilities to test for their occurrence. With clear definitions and less
code, testbench design is faster and easier, and you can be confident
that you are testing the right sequences in the right way.

As a declarative method, OVA is much more concise and easier to


read than the procedural descriptions provided by hardware
description languages such as Verilog. With OVA:

• Descriptions can range from the most simple to the most complex
logical and conditional combinations.
• Sequences can specify precise timing or a range of times.
• Descriptions can be associated with specified modules and
module instances.
• Descriptions can be grouped as a library for repeated use. OVA
includes a Checker Library of commonly used descriptions.

Using OpenVera Assertions


10-2
Built-in Test Facilities and Functions

OVA has built-in test facilities to minimize the amount of code that
you need to write. In addition, OVA works seamlessly with other
Synopsys tools to form a complete verification environment. OVA
performs the following tasks:

• Tests Verilog, VHDL, and mixed-HDL designs using VCS-MX.


• Automatically tests and reports results on all defined sequences.
You just write the definitions.
• Produces results that can be viewed with DVE or VirSim.
• Can be monitored and controlled as part of a Vera testbench.
For more information on OVA, see the OpenVera Language
Reference Manual: Assertions.

Creating a Temporal Assertion File

Testing starts with a temporal assertion file, which contains the


descriptions of the sequences and instructions for how they should
be tested.

A typical temporal assertion file consists mostly of temporal


expressions, which are the descriptions of the event sequences.

The basic instruction for testing is a temporal assertion. Assertions


specify an expression or combination of expressions to be tested.
Assertions come in two forms: check, which succeeds when the
simulation matches the expression, and forbid, which succeeds when
the simulation does not match.

Using OpenVera Assertions


10-3
The temporal expressions and assertions must also be associated
with a clock that specifies when the assertions are to be tested.
Different assertions can be associated with different clocks. A clock
can be defined as posedge, negedge, or any edge of a signal; or
based on a temporal expression. Also, asynchronous events can use
the simulation time as a clock.

An assertion can be associated with all instances of a specified


module or limited to a specific instance.

Example 10-1 shows an example temporal assertion file. It tests for


a simple sequence of values (4, 6, 9, 3) on the device’s output bus.

Example 10-1 Temporal Assertion File, cnt.ova


/* Define a unit with expressions and assertions (or select
one from the Checker Library).
*/
unit step4
#(parameter integer s0 = 0) // Define parameters
(logic clk, logic [7:0] result); // Define ports

// Define a clock to synchronize attempts:


clock posedge (clk)
{
// Define expressions:
event t_0 : (result == s0);
event t_1 : (result == 6);
event t_2 : (result == 9);
event t_3 : (result == 3);
event t_normal_s: t_0 #1 t_1 #1 t_2 #1 t_3;
}

// Define an assertion:
assert c_normal_s : check(t_normal_s, "Missed a step.");

endunit

/* Bind the unit to one or more instances in the design.


*/
// bind module cnt : // All instances of cnt or
bind instances cnt_top.dut : // one instance.

Using OpenVera Assertions


10-4
step4 start_4 // Name the unit instance.
#(4) // Specify parameters.
(m_clk, outp); // Specify ports.

When the temporal assertion file is compiled and run with a simulator,
the assertions are continuously tested for the duration of the
simulation. New attempts to match each assertion to the simulation’s
values are started with every cycle of the assertion’s associated clock.
Each attempt continues until it either fails to match or succeeds in
matching the complete expression. See Figure 10-1. The up arrow
at clock tick 7 indicates a match that started at tick 4. The down arrows
are failures. The failure or success of each attempt is logged to a file
that can be reviewed later.

Figure 10-1 Assertion Attempts for cnt.ova


posedge m_clk 1 2 3 4 5 6 7 8 9 10 11 12 13 14

outp 06 04 08 04 06 09 03 0d 0e 04 06 09 06

c_normal_s

A Vera testbench can monitor and control the testing. Using built-in
object classes, you can stop and start attempts to match the selected
assertion; monitor attempts, failures, and successes; and
synchronize the testbench with the testing process.

For guidelines on creating OVA assertions, see the OVA Language


Reference Manual: Assertions. For information on using a collection
of temporal expressions and assertions intended for a variety of
commonly needed tests, see the OVA Checker Library Reference
Guide.

Using OpenVera Assertions


10-5
Compiling Temporal Assertions Files

Temporal assertions files are compiled concurrently with Verilog


source files. You can use a set of OVA-specific compile-time options
to control how VCS compiles the temporal assertions files.

Note:
When you use the OVA compile-time options, VCS creates a
Verification Database directory in your current directory (by
default named simv.vdb). VCS writes intermediate files and
reports about OpenVera Assertions in subdirectories within in this
directory.

The following compile-time options are for OVA:

-ova_cov
Enables viewing results with functional coverage.
-ova_cov_events
Enables coverage reporting of expressions.
-ova_cov_hier filename
Limits functional coverage to the module instances specified in
filename. Specify the instances using the same format as VCS
coverage metrics. If this option is not used, coverage is
implemented on the whole design.
-ova_debug | -ova_debug_vpd
Required to view results with DVE or VirSim.

Using OpenVera Assertions


10-6
-ova_dir pathname
Specifies an alternative name and location for the Verification
Database directory. There is no need to specify the name and
location of the new Verification Database directory at runtime, the
simv executable contains this information.

If you move or rename this directory after you create the simv
executable, you include this option at runtime to tell VCS its new
name or location.
-ova_file filename
Identifies filename as an assertion file. Not required if the file name
ends with .ova. For multiple assertion files, repeat this option with
each file.
-ova_enable_diag
Enables further control of result reporting with runtime options.
-ova_inline
Enables compiling of OVA code that is written inline with a Verilog
design.
Note:
You can also use the VCS -f option to specify a file containing a
list of all absolute pathnames for Verilog source files and compile-
time option. You can pass all OVA compile-time options through
this file, except -ova_debug.

Using OpenVera Assertions


10-7
OVA Runtime Options

The following runtime options are available for use with OVA:

-ova_quiet [1]
Disables printing results on screen. The report file is not affected.
With the 1 argument, only a summary is printed on screen.
-ova_report [filename]
Generates a report file in addition to printing results on screen.
Specifying the full path name of the report file overrides the default
report name and location.
-ova_verbose
Adds more information to the end of the report including assertions
that never triggered and attempts that did not finish, and a
summary with the number of assertions present, attempted, and
failed.
A set of runtime options are also available for controlling how VCS
writes its report on OpenVera Assertions. You can use these options
only if you compiled with the -ova_enable_diag compile-time
option.

-ova_filter
Blocks reporting of trivial if-then successes. These happen when
an if-then construct registers a success only because the if portion
is false (and so the then portion is not checked). With this option,
reporting only shows successes in which the whole expression
matched.
ova_filter_past
Ignores assertion subsequences containing past operators that
have not yet eclipsed the history threshold.

Using OpenVera Assertions


10-8
-ova_max_fail N
Limits the number of failures for each assertion to N. When the
limit is reached, the assertion is disabled. N must be supplied,
otherwise no limit is set.
-ova_max_success N
Limits the total number of reported successes to N. N must be
supplied, otherwise no limit is set. The monitoring of assertions
continues, even after the limit is reached.
-ova_simend_max_fail N
Terminates the simulation if the number of failures for any
assertion reaches N. N must be supplied, otherwise no limit is set.
-ova_success
Enables reporting of successful matches in addition to failures.
The default is to report only failures.

Using OVA with VHDL-Only and Mixed-HDL Designs

This section shows you how to run OVA with VHDL-Only and Mixed-
HDL designs. For details on running OVA with Verilog-Only designs,
see the VCS User Guide.

1. In addition to setting up your normal environment, (see “Setting


Up Your Environment” on page 1-3), set the LD_LIBRARY_PATH
environment variable:
setenv LD_LIBRARY_PATH $VCS_HOME/<platform>/lib:$LD_LIBRARY_PATH

Note: For HP configurations, set SHLIB_PATH instead of


LD_LIBRARY_PATH.
2. Make sure you’ve already created an OVA temporal assertons
file or files (see “Creating a Temporal Assertion File” on page 5-3).

Using OpenVera Assertions


10-9
3. Compile the OVA code using the ovaan utility:
ovaan chk_clkgen.ova

Note the following:

- All OVA files must be specified at the same command line.


- For details on the ovaan utility, see “ovaan Utility” on page 3-15
of the VCS MX Reference Guide.
4. Analyze the HDL source code using either the vhdlan utility (for
VHDL) or vlogan utility (for Verilog):
vhdlan design.vhd other_compile_files_and_options

vlogan design.v other_compile_files_and_options

For details on the vhdlan utility, see “vhdlan Utility” on page 3-2
of the VCS MX Reference Guide. For details on the vlogan utility,
see “vlogan Utility” on page 3-10 of the VCS MX Reference Guide.

5. Compile the design and OVA code:


- For VHDL-Only designs, use the scs command and -ova
option.
scs cfg_tb -ova

- For VHDL-Top designs, use the scs command and -mhdl and
-ova options.
scs -mhdl cfg_tb -ova

For details on the scs command, please see


“scs Command and Options” on page 4-2 of the VCS MX
Reference Guide.

Using OpenVera Assertions


10-10
- For Verilog-Top, use the vcs command and -mhdl and
-ova options.
vcs -mhdl -ova tb.v

For details on the vcs command, see “vcs Command and


Options” on page 4-11 of the VCS MX Reference Guide.

6. Run your simulation using the scsim executable and -ovarun


flag for VHDL-Only and VHDL-Top, or the simv executable and
-ovarun for Verilog-Top.
scsim -ovarun "ova_runtime_flags"

simv -ovarun "ova_runtime_flags"

For details on the scsim executable, see “scsim Executable and


Options” on page 5-1 of the VCS MX Reference Guide. For details
on the simv executable, see “simv Executable and Options” on
page 5-11 of the VCS MX Reference Guide.

7. In addition to the simulation’s usual output, you will get a report


of the OVA results. For details on these reports, see “Viewing
OVA Simulation Results” on page 5-11.

Viewing OVA Simulation Results

You can view OVA simulations results in different ways based on the
options you used with the ovaan utility or -ovarun.

Using OpenVera Assertions


10-11
Viewing Results with the Report File

A report file is created when the -ova_report runtime option is


used. The report’s file name is ova.report unless you specified a
different name with -ova_report. The default ova.report file is
stored in directory ova.vdb/report, where the .vdb directory is the root
directory at the same level where the design is compiled and scsim
is stored.

To override this default name and location for the report file, use the
-ova_report runtime option and provide the full path name of the
report file.

The report file is replaced with each simulation run. If you want to
save the results, be sure to rename the file before running the
simulation again.

Assertion attempts generate messages with this format:

Status (succeeded at ...,


File and line with Full hierarchical name failed at ...,
Severity the assertion of the assertion Start time not finished)

Ova [0]: "cnt.ova", 10: cnt.dut.c_normal_s: started at 5ns failed at 9ns,


"Wrong outp sequence.",
Offending 'outp == 4 #1 outp == 6 #1 outp == 9 #1 outp == 3'

Optional user-defined Expression that failed (only with failure of check assertions)
failure message

Using OpenVera Assertions


10-12
Viewing Results with Functional Coverage

After running simulations, you can generate a report summarizing the


coverage of the assertions and expressions. With this report you can
quickly see if all assertions were attempted, how often they were
successful, and how often they failed. Potential problem areas can
be easily identified. The report can cover one test or merge the results
of a test suite. The report is presented in HTML and you can customize
it with a TCL script.

The default report shows the number of assertions and expressions


that:

• were attempted
• had successes
• had failures
Coverage is broken down by module and instance, showing for each
assertion and expression, the number of attempts, failures, and
successes. Because if-then constructs register a success anytime
the if portion is false (and so the then portion is not checked), the
report also shows the number of real successes in which the whole
expression matched. This works with nested if statements too.

Functional coverage can also grade the effectiveness of tests,


producing a list of the minimum set of tests that meet the coverage
target. Tests can be graded on any of these metrics:

• number of successful assertion attempts versus number of


assertions (metric = SN)
• number of failed assertion attempts versus number of assertions
(metric = FN)

Using OpenVera Assertions


10-13
• number of assertion attempts versus number of assertions (metric
= AN)
• number of successful assertion attempts versus number of
assertion attempts (metric = SA)
• number of failed assertion attempts versus number of assertion
attempts (metric = FA)
To generate a report run the following command:

fcovReport [options]

For a description of the command options, see Table 10-1.

Using OpenVera Assertions


10-14
Table 10-1 Options for fcovReport
Option Description
-e TCL_script | - Use this option to produce a custom report using TCL
scripts or an interactive mode. Most of the other
fcovReport options are processed before the TCL scripts
or interaction. The exception is -ova_cov_report, which is
ignored. Its function should be in the TCL.
TCL_script specifies the path name of a TCL script to
execute. To use multiple scripts, repeat this option with
each script’s path name. They are processed in the order
listed.
For CCI interactive mode, add -e -.
-ova_cov_db filename Specifies the path name of the template database. If this
option is not included, fcovReport uses simv.vdb/snps/
fcov/coverage.db.
-ova_cov_grade_instances Generates an additional report, grade.html, that lists the
target, metric [, time_limit] minimum set of tests that add up to the target value for
the metric (see previous page for metric codes). The
grading is by instance.
-ova_cov_grade_modules Generates an additional report, grade.html, that lists the
target, metric [, time_limit] minimum set of tests that add up to the target value for
the metric (see previous page for metric codes). The
grading is by module.
-ova_cov_map filename Maps the module instances of one design onto another
while merging the results. For example, use this to merge
the functional coverage results of unit tests with the results
of system tests. Give the path name of a file that lists the
hierarchical names of from/to pairs of instances with one
pair per line:
from_name to_name
The results from the first instance are merged with the
results of the second instance in the report.
-ova_cov_merge filename Specifies the path name of a functional coverage result
file or directory to be included in the report. If filename is
a directory, all coverage result files under that directory
are merged. Repeat this option for any result file or
directory to be merged into this report. If this option is not
used, fcovReport merges all the result files in the directory
of the template database (specified with -ova_cov_db or
simv.vdb/snps/fcov by default).

Using OpenVera Assertions


10-15
Option Description
-ova_cov_report Specifies the base name for the report.The fcovReport
name | path/name command creates an HTML index file at simv.vdb/reports/
name.fcov-index.html and stores the other report files
under simv.vdb/reports/name.fcov.
If you give a path name, the last component of the path is
used as the base name. So the report files are stored
under path/name and the index file is at path/name.fcov-
index.html.
If this option is not included, the report files are stored
under simv.vdb/reports/report.fcov and the index file is
named report.fcov-index.html.

You can produce a custom report with TCL. See Table 10-2 for extra
TCL commands for functional coverage.

Using OpenVera Assertions


10-16
Table 10-2 TCL Commands for OVA Functional Coverage Reports
Command Return Description
Value
fcov_get_no_of_topmodules int Returns total number of top level modules that
contain at least one assertion under their
hierarchy. (Top level modules are instances.)
fcov_get_topmodules array of Returns an array of handles for the top level
handles modules that contain at least one assertion
under their hierarchy. (Top level modules are
instances.)
fcov_get_no_of_modules int Returns total number of modules that contain
at least one assertion.
fcov_get_modules array of Returns an array of handles for the modules
handles that contain at least one assertion.
fcov_get_handle -module handle Returns a handle for the specified module.
name
fcov_get_no_of_instances int Returns total number of instances that contain
at least one assertion under their hierarchy.
fcov_get_instances array of Returns an array of handles for the instances
handles that contain at least one assertion under their
hierarchy.
fcov_get_handle -instance handle Returns a handle for the instance specified with
name its full hierarchical name.
fcov_get_no_of_instances int Returns total number of instances containing at
-module handle least one assertion under their hierarchy for a
module with the specified handle.
fcov_get_instances -module array of Returns an array of handles for the instances
handle handles that contain at least one assertion under their
hierarchy for the module with the specified
handle.
fcov_get_no_of_children int Returns total number of child instances
-instance handle containing at least one assertion under their
hierarchy. The parent instance is with the
specified handle.
fcov_get_children -instance array of Returns an array of handles for the child
handle handles instances that contain at least one assertion
under their hierarchy. The parent instance is
with the specified handle.
fcov_get_no_of_assertions int Returns total number of assertions for the
-module handle module with the specified handle.
fcov_get_assertions array of Returns an array of handles to the assertions
-module handle handles of the module with the specified handle.

Using OpenVera Assertions


10-17
Command Return Description
Value
fcov_get_no_of_assertions int Returns total number of assertions for the
-instance handle instance with the specified handle.
fcov_get_assertions array of Returns an array of handles to the assertions
-instance handle handles of the instance with the specified handle.
fcov_get_handle -instance | handle Returns the handle to the specified assertion in
-module name1 -assertion the specified instance or module. The assertion
name2 name must follow the convention for the full
name of an assertion.
fcov_get_no_bins -assertion int Returns total bins for the assertion with the
handle specified handle.
fcov_get_bins -assertion array of Returns an array of handles to the bins of the
handle handles assertion with the specified handle.
fcov_get_handle -instance | handle Returns the handle to the specified bin for the
-module name1 -assertion specified assertion in the specified instance or
name2 -bin name3 module. Current names are: “ 1attempts”,
“ 2failures”, “ 3allsuccesses”,
“ 4realsuccesses”, and “ 5events” (note that all
bin names start with a space).
fcov_get_type -bin handle string Returns the type of the bin with the specified
handle. It can be: “bool” or “count”.
fcov_get_flag -bin handle string Returns the flag associated with the bin with the
specified handle. It can be: “illegal”, “ignored”,
or “impossible”.
fcov_set -bin handle -flag empty Set the flag with name for the bin with the
name string ““ specified handle. The flag can be: “illegal”,
“ignored”, or “none”.
fcov_get_coverage -bin int Returns the coverage count associated with the
handle bin with the specified handle. It can be 0 or the
count of the times the bin was covered.
fcov_grade_instances string Returns a list of the minimum set of tests that
-target value1 -metric code add up to the target value for the metric code.
[-timeLimit value2] Each test is accompanied by the accumulated
coverage value including that test. The grading
is by instance.
fcov_grade_modules -target string Returns a list of the minimum set of tests that
value1 -metric code add up to the target value for the metric code.
[-timeLimit value2] Each test is accompanied by the accumulated
coverage value including that test. The grading
is by module.

Using OpenVera Assertions


10-18
Command Return Description
Value
fcov_set -bin handle empty Set the coverage count int for the bin with the
-coverage int string ““ specified handle. It can be 0 or the count of the
times the bin was covered.
fcov_create -bin name -type name Create a new bin with the given name and type.
type The type can be “count” or “bool”. It returns the
name itself.
fcov_get_name -object string Returns the name of the object the specified
handle handle.
fcov_get_type -object handle string Returns the type of the object with the specified
handle. The type can be “module”, “instance”,
“assertion”, or “bin”.
fcov_load_design -file name empty Unloads any existing design and data, including
string ““ all name maps. Then loads a design with the
specified path name. (The search rules are
described in the table for options.)
fcov_load_test -file name empty Loads a test with the specified name. The name
string ““ can be a file name or full path name. (The
search rules are described in the table for
options.)
fcov_load_test_grade -file empty Loads a file with the specified name for
name string ““ coverage grading. The name can be a file name
or full path name. (The search rules are
described in the table for options.)
fcov_map_hier -from empty Maps coverage of instance (and the hierarchy
hier_name -to hier_name string ““ under it) with the specified hierarchical name
hier_name to another instance for all
subsequent merges.
fcov_write_coverage -file empty Writes current coverage to a file with the
name string ““ specified name. The name can be a file name
or full path name. (The search rules are
described in the table for options.)

Inlining OVA in Verilog

Inlined OVA enables you to write any valid OVA code within a Verilog
file using pragmas. In most usage cases, the context is inferred
automatically and the OVA code will be bound to the current module.

Using OpenVera Assertions


10-19
You can use this process with or without regular OVA files. The results
for both inlined and regular (OVA) assertions are reported together.

All Verilog files containing inlined OVAs are passed to the ovaan utility
using the -ova_inline command line switch.

This section covers the following topics:

• “Specifying Pragmas in Verilog


• “Methods for Inlining OVA
• “General Inlined OVA Coding Guidelines

Specifying Pragmas in Verilog


Inlined OVA is specified in Verilog code using pragmas. Several
different forms are accepted, including C and C++ style comments,
and modified C++ multi-line comments.

The general C++ style form is as follows:

/* ova first_part_of_pragma
...
last_part_of_pragma
*/

You can also use the following modified C++ approach:

//ova_begin
// pragma_statement
//...
//ova_end

Using OpenVera Assertions


10-20
For a single-line pragma, you can use the following C form:

// ova pragma_statement;

Assertions can be placed anywhere in a Verilog module and they use


predefined units, including those in the Checker Library.

Note that the following OVA pragmas are not supported

• // ova parallel_case on;


• // ova full_case on;
• // ova inherit_clock;

Methods for Inlining OVA

There are four basic methods you can use to inline OVA within
Verilog:

• Unit Instantiation Using the Unit-based Checker Library


(recommended for using Synopsys-developed OVA checkers)
• Context-Independent Full Custom OVA (uses custom-developed
OVA code that resides in a Verilog file)
• Template Instantiation Using the Template-Based Checker
Library
• Context-Dependent Full Custom OVA
These methods are described in detail throughout this section. The
graphic in Figure 10-2 provides an overview of these methods.

Using OpenVera Assertions


10-21
Figure 10-2 Methods for Inlining OVA within Verilog

Method #1 — Unit-based Instantiation


Verilog File (.v)

module

endmodule OVA Checker Library

Unit-based Template-based
OVA code calls unit-based Checkers Checkers
checkers from Checker Library

Method #2 — Context Independent


Full Custom OVA
Verilog File (.v)
module
Bind statement instantiates
endmodule custom OVA code

Method #3 — Template Instantiation

Verilog File (.v)


module
Method #4 — Context Dependent
Full Custom OVA
endmodule
Verilog File (.v)
module

OVA code calls template-based


endmodule checkers from Checker Library

OVA code (minus the unit def.) is directly embedded in Verilog module.

Using OpenVera Assertions


10-22
Unit Instantiation Using the Unit-Based Checker Library
The easiest and most efficient method to inline OVA is to instantiate
a unit-based checker from the OVA Checker Library (For more
information on the Checker Library, see the OpenVera Assertions
Checker Library Reference Manual). The context of the checker is
automatically inferred based upon the location of the OVA pragma
statement within a module of Verilog code. To use this method, you
must include the bind keyword within a valid OVA pragma statement.

The syntax options for specifying unit-based assertions are as


follows:

C++ Style:

/* ova
bind unit_name [inst_name] [#(param1, ...,paramN)] [(port1,..., portN)];
*/

Modified C++ Style:

/* ova_begin
bind unit_name [inst_name] [#(param1, ...,paramN)] [(port1, ..., portN)];
ova_end
*/

C Style:

// ova bind unit_name [inst_name] [#(param1, ...,paramN)] [(port1, ..., portN)];

Note: In all syntax styles, you can also split a pragma statement into
separate lines as shown below:

//ova bind
//ova unit_name [instance_name]
//ova [#(parameter1, ..., parameterN)]
//ova [(port1, ..., portN)];

Using OpenVera Assertions


10-23
The following example shows how to instantiate a checker, called
ova_one_hot, from the OVA Checker Library:

module test(); Uses a single-line, C style pragma to instantiate the


reg [3:0] x; ova_mutex checker from the Checker Library, and
wire clk; checks for mutual exclusive of a and b.
wire a,b;
wire error;
// other verilog code
// ova bind ova_mutex (1'b1,clk,a,b);
/* ova bind
ova_forbid_bool (error,clk); Uses a multi-line C++ style
*/ pragma to instantiate
// ova_begin bind ova_forbid_bool, and check that
// ova_one_hot an error is never asserted.
// #(0, // strict
// 4) // bit width
// (1'b1, // enable
// clk, // clock
Uses a multi-line modified C++
// x); // data
style pragma to instantiate
// ova_end
ova_one_hot and checks that
// other verilog code
singal x has only 1 bit.
endmodule // module test

Instantiating Context-Independent Full Custom OVA


You can inline OVA within Verilog by instantiating independent
custom OVA code located in the Verilog file but outside a Verilog
module definition. The unit definition associated with the code must
be specified outside a Verilog module.

This method is demonstrated in the following example:

Using OpenVera Assertions


10-24
module test();
reg [3:0] x;
Binding from inside a module
wire clk;
wire a,b;
// ova bind my_mutex(clk,{a,b});
wire error;
// verilog code
endmodule // module test

/* ova
unit error_check (logic clk, logic error);
clock posedge clk {
event e1 : error == 1; Binding from outside a module
}
assert a1 : forbid(e1);
endunit
bind module test : error_check(clk,error) ;

unit my_mutex (logic clk, logic [1:0] x);


clock posedge clk {
event e1 : x != 2'b11;
}
assert a1 : check(e1);
endunit
*/

Two units are defined:


error_check and my_mutext

In the previous example, the bind statement (// ova bind


my_mutex(clk,{a,b});) calls independent OVA code located
outside Verilog module. You can instantiate the independent OVA
code as many times as needed anywhere in the Verilog code. The
context of the OVA code within the Verilog code is automatically
inferred based upon the location of the bind statement.

Using OpenVera Assertions


10-25
Template Instantiation Using the Template-Based
Checker Library
You can instantiate any template-based checker from the Checker
Library in your Verilog code. The context of the checker is
automatically inferred based on the location of the call from within
Verilog.

Note the following construct usages and limitations in Template


Instantiation:

• Clocks must use edge expressions (unit-based checkers use


Verilog style ports)
• You can specify the default clock in conjunction with the
check_bool and forbid_bool checkers, however, it does not
work with other templates or units. The following example shows
a supported default clock:
//ova clock posedge clk;
Note that each sequence or boolean expression is associated
with a clock. The clock determines the sampling times for variable
values.
• Both for loops and nested for loops are supported, as shown
below:
for (name=expr;name op1 expr;
name=name op2 expr)
{
for loop body
}

Using OpenVera Assertions


10-26
• You cannot mix a template instantiation and unit instantiation
within the same OVA pragma using the multi-line C++ and
modified C++ pragma specification formats. You can, however,
specify a template instantiation and a unit instantiation using a
separate single-line C pragmas.
The following example demonstrates how to implement template
instantiation using the template-based checker library:

module test();
reg [3:0] x;
reg [3:0] y;
reg clk;
wire a,b; Default clock specification Uses implicit clock
wire error; expression picked up from
wire req,ack; default clock space
// some verilog code
// ova clock posedge clk;
// ova check_bool(!req || ack,,negedge clk);
/* ova for (i=0;i<4;i=i+1) {
check_bool(x[i]==past(y[3-i]) );
}
*/ Default clock specification
// ova_begin
// clock negedge clk;
// forbid_bool u1 // instance name
// (error, // signal to check
// "ERROR_ASSERTED"); // message to display upon failure
// ova_end
// more verilog code
endmodule // module test Uses default clock
(negedge clock)

The example calls the check_bool template from the OVA checker
library. Note that the default clock, (// ova clock posedge
clk;), must be a local signal, and can be boolean expression. It
works only works for the "check_bool" and "forbid_bool"
templates, and does not work with other templates.

Using OpenVera Assertions


10-27
Inlining Context-Dependent Full Custom OVA
You can directly inline any custom OVA code, except for the unit
definition, within a Verilog module. In this case, the unit and binding
definitions are implicit.

The following example demonstrates this method:

module test();
reg clk;
wire a,b;
// other verilog code
// ova_begin
// clock posedge clk {
Uses modified C++ style pragma to
// event e1 : a #1 b;
specify custom OVA code that defines
// } event e1 and assertion a1.
// assert a1 : forbid(e1);
// ova_end
/* ova
clock posedge clk { Uses C++ style pragma to
event e2 : ended(e1) #2 b; specify custom OVA code
that defines event e2 and
} assertion a2.
assert a2 : forbid(e2);
*/
// more verilog code
endmodule // module test

Using OpenVera Assertions


10-28
General Inlined OVA Coding Guidelines
Note the following guidelines when coding Inlined OVA:

• Since OVA pragmas are declarative in nature, they do not need


to placed within procedural code — for example, within tasks,
functions, and always/initial/forever blocks.
• Cross-module References (XMRs) are not allowed to
concurrently reside within a custom OVA description.
• Template instantiation will be treated as an OVA description (the
XMR restriction also applies).
• Unit binding is allowed inside ‘module endmodule’, but the
keyword ‘bind’ needs to be specifed in order to distinguish it from
template instantiation. Unit binding (with the keyword ‘bind’) can
have XMRs in its connections; however, using XMRs in
connections without the bind keyword will cause a warning
statement. Inlined bindings have the same requirements and
limits as bindings created in an OVA source file.
• XMRs to signals are not supported except in 'bind's for inlined
OVAs.
• Inlined OVA cannot be read directly by third-party simulators.
You can, however, use VCS to produce output files that can be
read by third-party simulators.
• Each instance must be terminated by a “;” (semi-colon).
• Both positional and named (explicit) association of actual
arguments are supported. However, the two styles cannot be
used simultaneously in an instance.

Using OpenVera Assertions


10-29
Using OpenVera Assertions
10-30
11
Using SystemVerilog Assertions 1
This chapter explains the following SystemVerilog Assertions-related
topics:

• Using SVA in a VHDL-Top Design


• Using SVA in a Verilog-Top Design
• Using the $hdl_xmr System Task
• Using Standard SVA Checkers

Using SystemVerilog Assertions


11-1
Using SVA in a VHDL-Top Design

You can write a Verilog module containing SVA properties whose


sequential expressions contain the ports of the module, then
instantiate the module in the VHDL design (Verilog-Top). Name the
ports with names similar to the VHDL signals they connect to. VCS
MX displays messages when the assertions fail and by the similar
names you can see how the VHDL signals behave as predicted by
the SVA code.

The procedure is as follows:

1. Write the a Verilog module containing SVA code. The following is


an example of such code in a file named sva.v:
module checker (input vhdl_clk, vhdl_a, vhdl_b);
property p1;
@(posedge vhdl_clk) vhdl_a ##! vhdl_b;
endproperty

a1: assert property (p1);


endmodule

2. Analyze the file using the vlogan utility, for example:


vlogan sva.v -sverilog

It is important to include the -sverilog option.


3. Instantiate the Verilog module containing the SVA code in an
architecture in your design. It should contain something like the
following:
- A component declaration for the Verilog module
component checker
port (vhdl_clk, vhdl_a, vhdl_b : in std_logic);

Using SystemVerilog Assertions


11-2
end component;

- An instantiation of that component that connects the ports in


the module to the VHDL signals in your design
checkerInst : checker port map(vhdl_clk, vhdl_a,
vhdl_b);

4. Analyze the VHDL file containing the instance using the vhdlan
utility:
vhdlan design.vhd

5. The next step is to compile and elaborate the design, for example:
scs cfg_tb -verilogcomp
6. You can now start the simulation. There are no runtime options
that you need to pass to the Verilog simulation engine:
scsim -i run.do -verilogrun "-cm assert -assert success"

The -cm assert VCS runtime option and keyword argument


tells VCS to monitor for SVA coverage.

The -assert success VCS runtime option and keyword


argument enables reporting of successful SVA matches in
addition to failures.

As an alternative to using the ports of a module, you can use any


signal if you use the $hdl_xmr system task, see “Using the $hdl_xmr
System Task” on page 11-5.

Using SystemVerilog Assertions


11-3
Using SVA in a Verilog-Top Design

You can also use SVA in a Verilog-Top mixed-HDL design. If you


have Verilog code describing the top of the MX design hierarchy, you
can apply or include SVA to that part with no extra steps to follow
because you are using SVA in an MX design.

If, however, you also want SVA in Verilog code that you instantiate
in VHDL code, there are some steps you must follow. If, for example,
you have two source files:

• child.v has SVA code included in with other Verilog code in a


module definition.
• sva.v is a module definition just containing SVA code to apply
SVA to VHDL as described in “Using SVA in a VHDL-Top Design”
on page 11-2.
1. Analyze the files using the vlogan utility, for example:
vlogan child.v sva.v -sverilog

It is important to include the -sverilog option.


2. Instantiate these modules using component declarations and
component instantiation statements.
3. Analyze the VHDL code that instantiates the Verilog code
4. Compile the Verilog source file or files that describe the top of the
hierarchy, for example:
vcs testbench.v -mhdl -sverilog

Use -mhdl because it is an MX design, and use -sverilog


because it contains SVA code.

Using SystemVerilog Assertions


11-4
Using the $hdl_xmr System Task

The $hdl_xmr system task connects a VHDL signal to a Verilog


signal that you can use in SVA code in the Verilog part of the design,
for example:

initial
begin
$hdl_xmr("top:i1:A",temp);
end

Here top:i1:A is a hierarchical name for a signal in the VHDL part of


the design. The colons are delimiters for levels of the hierarchy. This
system task connects top:i1:A to signal temp. You can then use signal
temp in your SVA code, for example:

vector_assert : assert property (@(posedge clk) ((temp ==


4’d1) ##1 (temp ==4’d2)));

You can use this technique instead of using the ports in the SVA code
and then connecting the ports to SVA signals.

This system task requires the following PLI table file: $VCS_HOME/
lib/hdl_xmr.tab.

If your design is Verilog on top, specify the table file using the -P
compile-time option, for example:

vcs testbench.v -mhdl -sverilog -P $VCS_HOME/lib/hdl_xmr.tab

If your design is VHDL on top, use the -verilogcomp scs option to


pass the -P option to VCS, for example:

scs -mhdl cfg_tb -verilogcomp "-P $VCS_HOME/lib/hdl_xmr.tab"

Using SystemVerilog Assertions


11-5
Using Standard SVA Checkers

An SVA checker is SVA code provided by Synopsys that you can use
in a Verilog on top MX design. Descriptions of these checkers are in
the SystemVerilog Assertions (SVA) Checker Library Reference
Manual. This manual contains an example of using a checker in an
MX design.

You instantiate the checker components like you would any VHDL
entity.

The checkers are in the $VCS_HOME/packages/sva directory.

Using SystemVerilog Assertions


11-6
12
Using the VCS MX / SystemC Co-Simulation
Interface 1
The VCS MX / SystemC Co-simulation Interface enables VCS MX
and the SystemC modeling environment to work together when
simulating a system described in the Verilog, VHDL, and SystemC
languages.

VCS MX contains a built-in SystemC simulator that is compatible with


OSCI SystemC 2.0.1. By default, when you use the interface VCS
runs its own SystemC simulator. No setup is necessary.

You also have the option of installing the OSCI SystemC simulator
and have VCS run it to cosimulate using the interface. See “Using a
Customized SystemC Installation” on page 12-39.

Using the VCS MX / SystemC Co-Simulation Interface


12-1
With the interface you can use the most appropriate modeling
language for each part of the system, and verify the correctness of
the design. For example, the VCS MX / SystemC Co-simulation
Interface allows you to:

• Use a SystemC module as a reference model for the VHDL or


Verilog RTL design under test in your testbench.
• Verify a Verilog or VHDL netlist after synthesis with the original
SystemC testbench
• Write testbenches in SystemC to check the correctness of Verilog
and VHDL designs
• Import legacy VHDL or Verilog IP into a SystemC description
• Import third-party VHDL or Verilog IP into a SystemC description
• Export SystemC IP into a Verilog or VHDL environment when only
a few of the design blocks are implemented in SystemC
• Use systemC to provide stimulus to your design.
The VCS MX / SystemC Co-simulation Interface creates the
necessary infrastructure to co-simulate SystemC models with Verilog
or VHDL models. The infrastructure consists of the required build files
and any generated wrapper or stimulus code. VCS MX writes these
files in subdirectories in the ./csrc directory. To use the interface, you
don’t need to do anything to these files.

During co-simulation, the VCS MX / SystemC Co-simulation Interface


is responsible for:

• Synchronizing the SystemC kernel and VCS MX


• Exchanging data between the two environments

Using the VCS MX / SystemC Co-Simulation Interface


12-2
The usage models for the VCS MX / SystemC Co-simulation
Interface, depending on the type of cosimulation you want to perform,
are the following:

• Verilog/VHDL Modules and SystemC Leaf Modules in a Verilog


Design
• Verilog and VHDL Modules in a SystemC Design
• Verilog/VHDL Modules and SystemC Leaf Modules in a VHDL
Design
Notes:

• There are examples of Verilog instantiated in SystemC and


SystemC instantiated in Verilog in the $VCS_HOME/doc/
examples/osci_dki directory.
• The interface supports the following compilers:

Linux: you can use the gnu 3.2.1 or 2.96 compilers.


Solaris: SC 6.2, gcc 2.95.2, gcc 3.2.2
HP: aCC 3.35

Usage Scenario Overview

This section contains a brief overview of the steps involved to create


a simulation for each of the following design scenarios:

• Verilog designs containing SystemC and MX modules


• SystemC designs containing MX modules
• VHDL designs containing SystemC and MX modules

Using the VCS MX / SystemC Co-Simulation Interface


12-3
Analyze the VHDL, SystemC and Verilog modules from the bottom
of the design to the top.

For Verilog designs containing SystemC and MX modules:

• Use the "syscan file.cpp:model" command to analyze


SystemC modules used in the Verilog domain.
• Use the "syscan f.cpp..." command to compile other
SystemC modules in the design.
• Use the "vhdlan" command to analyze VHDL files.
• Use the "vlogan" command to analyze Verilog files.
• Use the "vcs -mdhl -sysc" command to build the simulation.
For SystemC designs containing MX modules:

• Use the "vhdlan -sysc " command to analyze VHDL files


containing modules used in the SystemC domain.
• Use the "vlogan -sysc" command to analyze Verilog files
containing modules used in the SystemC domain.
• Use the "syscan f.cpp..." command to compile SystemC
files.
• Use the "syscsim -mhdl" command to build the simulation.
For VHDL designs containing MX and SystemC modules:

• Use the "syscan file.cpp:model" command to analyze


SystemC modules used in the VHDL domain.
• Use the "syscan file.cpp..." command to compile other
SystemC modules in the design.
• Use the "vhdlan" command to analyze VHDL files.

Using the VCS MX / SystemC Co-Simulation Interface


12-4
• Use the "vlogan" command to analyze Verilog files.
• Use the "scs -mdhl -sysc" command to build the simulation.

Supported Port Data Types

SystemC types are restricted to the sc_clock, sc_bit, sc_bv,


sc_logic, sc_lv, sc_int, sc_uint, sc_bigint, and
sc_biguint data types. Native C/C++ types are restricted to the
uint, uchar, ushort, int, bool, short, char, long and ulong
types.

Verilog ports are restricted to bit, bit vector and signed bit vector
types.

VHDL ports are restricted to bit, bit vector, standard logic, standard
logic vector, signed and unsigned types.

Inout ports that cross the cosimulation boundary between SystemC


and Verilog must observe the following restrictions:

• SystemC port types must be sc_inout_rv<> or


sc_inout_resolved and must be connected to signals of type
sc_signal_rv<> or sc_signal_resolved.
• Verilog port types must be bit_vector or bit.
• VHDL port types must be std_logic_vector or std_logic.
• You need to create a port mapping file, as described in “Using a
Port Mapping File” on page 12-32, to specify the SystemC port
data types as sc_lv (for a vector port) or sc_logic (for a scalar
port).

Using the VCS MX / SystemC Co-Simulation Interface


12-5
Verilog/VHDL Modules and SystemC Leaf Modules in a
Verilog Design

To co-simulate a Verilog design that contains SystemC and Verilog/


VHDL modules, you need to import one or more SystemC instances
into the Verilog design. Using the VCS MX / SystemC Co-simulation
Interface, you generate a wrapper and include it in the Verilog design
for each SystemC instance. Other MX modules are also included in
the design. The ports of the created Verilog wrapper are connected
to signals attached to the ports of the corresponding SystemC
modules.

Figure 12-1 illustrates VCS MX DKI communication.

Figure 12-1 VCS MX DKI Communication of an Verilog Design Containing


SystemC Modules
Managed by the tool

HDL environment DKI SystemC simulator

HDL source code SystemC source code


entity-under-test
SystemC interface to the

clk clk
reset
HDL interface to the

Block 1 Block 2 reset


SystemC simulator

HDL environment

in Block 1
in

rdy_read rdy_read
Block 3
out Block 2

out

Automatically generated by the tool

Using the VCS MX / SystemC Co-Simulation Interface


12-6
Input Files Required

To run a co-simulation with a Verilog design containing SystemC and


MX instances, you need to provide the following files:

• SystemC source code


- You can directly write the entity-under-test source code or
generate it with other tools.
- Any other C or C++ code for the design
• Verilog or VHDL source code (.v, .vhd, .vhdl extensions) including:
- A Verilog or VHDL top-level simulation that instantiates the
interface wrapper and other Verilog/VHDL modules.These
wrapper files are generated by a utility and you don’t need to
do anything to these files (see “Generating the Wrapper for
SystemC Modules” on page 12-8 and “Instantiating the
Wrapper and Coding Style” on page 12-11).
- Any other Verilog or VHDL source files for the design
• An optional port mapping file. If you do not provide this file, the
interface uses the default port mapping definition. For details of
the port mapping file, see “Using a Port Mapping File” on
page 12-32.
• An optional data type mapping file. If you don’t write a data type
mapping file, the interface uses the default one in the VCS
installation. For details of the data type mapping files, see “Using
a Data Type Mapping File” on page 12-35.

Using the VCS MX / SystemC Co-Simulation Interface


12-7
Generating the Wrapper for SystemC Modules

You use the syscan utility to generate the wrapper and interface files
for co-simulation. This utility creates the csrc directory in the current
directory, just like VCS MX does when you include compile-time
options for incremental compilation. The syscan utility writes the
wrapper and interface files in subdirectories in the ./csrc directory.

There is nothing you need to do to the files that syscan writes. VCS
MX will know to look for them when you include the compile-time
option for using the interface, see “Compiling a Verilog Design
Containing MX and SystemC Modules” on page 12-14.

The syntax for the syscan command line is as follows:

syscan [options] filename[:modulename]


[filename[:modulename]]*

Where:

filename[:modulename] [filename[:modulename]]*
Is how you specify all the SystemC files in the design. There is
no limit to the number of of files. The entries for the SystemC files
that contain modules that you want to instantiate also include a
colon : followed by the name of the module. If :modulename is
omitted, the .cpp files will be compiled and added to the design's
database so the final vcs command will be able to bring together
all the modules in the design. You do not need to add
-I$VCS_HOME/include or -I$SYSTEMC/include
[options]
Are any of the following:
[-cflags "flags"] [-cpp path_to_the_compiler]
[-port port_mapping_file][-Mdir=directory_path]

Using the VCS MX / SystemC Co-Simulation Interface


12-8
[-help|-h] [-v] [-o name] [-V] [-vcsi]
[-verilog | -vhdl]

These options are defined as follows:

-cflags "flags"
Passes flags to the C++ compiler.
-cpp path_to_the_compiler
If you omit -cpp path, it is assumed that your environment will
find the following compilers as defaults:

- HP-UX : aCC

- Linux : g++

- SunOS : CC (native Sun compiler)

Note the following:

- See the VCS MX Release Notes for more details on supported


compiler versions.

-You can override the default compilers in your environment


by supplying a path to the g++ compiler, for example:

-cpp /usr/bin/g++
-port port_mapping_file
Specifies a port mapping file, see “Using a Port Mapping File”
on page 12-32.

Using the VCS MX / SystemC Co-Simulation Interface


12-9
-Mdir=directory_path
This option works the same way that the -Mdir VCS compile-
time option works If you are using the -Mdir option with VCS,
you should use the -Mdir option with syscan to redirect the
syscan output to the same location that VCS uses.
-help|-h
Displays the command line syntax, options, and example
command lines.
-v
Displays the version number.
-o name
The syscan utility uses the specified name instead of the
module name as the name of the model. Do not enter this option
when you have multiple modules on the command line, doing
so results in an error condition.
-V
Displays code generation and build details. Use this option if
you are encountering errors or are interested in the flow that
builds the design.
-vcsi
Prepares all SystemC interface models for simulation with
VCSi.
-verilog | -vhdl
indicates which domain the interface models should be
prepared for. -verilog is the default.
Note: You don’t specify the data type mapping file on the command
line, See “Using a Data Type Mapping File” on page 12-35.

The following example generates a Verilog wrapper:

syscan -cflags "-g" sc_add.cpp:sc_add

Using the VCS MX / SystemC Co-Simulation Interface


12-10
The following example generates a VHDL wrapper:

syscan -vhdl sc_add.cpp:sc_add

Instantiating the Wrapper and Coding Style

You instantiate the SystemC wrapper just like a Verilog module. For
example, take the following SystemC module in a file named
stimulus.h:

SC_MODULE(stimulus) {
sc_out<sc_logic> reset;
sc_out<sc_logic> input_valid;
sc_out<sc_lv<32> > sample;
sc_in_clk clk;

sc_int<8> send_value1;
unsigned cycle;

SC_CTOR(stimulus)
: reset("reset")
, input_valid("input_valid")
, sample("sample")
, clk("clk")

{
SC_METHOD(entry);
sensitive_pos(clk);
send_value1 = 0;
cycle = 0;
}
void entry();
};

The VHDL module is fir:

...
entity fir is

Using the VCS MX / SystemC Co-Simulation Interface


12-11
port( reset, input_valid, clk: in std_logic;
output_data_ready: out std_logic;
sample : in std_logic_vector (31 downto 0);
result : out std_logic_vector (31 downto 0) );
end fir;
...

The Verilog model is "display":

File: display.v
module display (output_data_ready, result);
input output_data_ready;
input [31:0] result;

integer counter;

initial
begin
counter = 0;
end

always @(output_data_ready)
begin
counter = counter + 1;
$display("Display : %d", result);
if (counter >= 24)
begin
$finish;
end
end
endmodule

You instantiate the VHDL and Systemc models as follows in the


Verilog part of the design:

File: tb.v

module testbench ();

reg clock;

Using the VCS MX / SystemC Co-Simulation Interface


12-12
wire reset;
wire input_valid;
wire [31:0] sample;
wire output_data_ready;
wire [31:0] result;

// Stimulus is the SystemC model.


stimulus stimulus1(.sample(sample),
.input_valid(input_valid),
.reset(reset),
.clk(clock));

// fir is the VHDL model.


fir fir1(.reset(reset),
.input_valid(input_valid),
.sample(sample),
.output_data_ready(output_data_ready),
.result(result),
.CLK(clock));

// Display is the Verilog model.


display display1(.output_data_ready(output_data_ready),
.result(result));

...
end module

Controlling Time Scale and Resolution in a SystemC


Module Contained in a Verilog Design

To control the time resolution of your SystemC module, create a static


global object that initializes the timing requirements for the module.
This can be a separate file that is included as one of the .cpp files for
the design.

Sample contents for this file:

Using the VCS MX / SystemC Co-Simulation Interface


12-13
#include <systemc.h>

class set_time_resolution
{
public:
set_time_resolution()
{
sc_set_time_resolution(10, SC_PS);
sc_set_default_time_unit(100, SC_PS);
}
};

static int SetTimeResolution()


{
new set_time_resolution();
return 42;
}

static int time_resolution_is_set = SetTimeResolution();

Analyzing Other MX Modules

Note the following when analyzing other MX Modules:

• Use vhdlan to analyze other VHDL modules.


• Use vlogan to analyze other Verilog modules.

Compiling a Verilog Design Containing MX and


SystemC Modules

To compile your MX design, include the -sysc and -mhdl compile-


time options, for example:

vcs -sysc -mhdl tb.v display.v

Using the VCS MX / SystemC Co-Simulation Interface


12-14
When you compile with this option, VCS MX looks in the csrc directory
for the subdirectories containing the interface and wrapper files
needed to instantiate the SystemC design in the MX design.

There are no runtime options needed to run the co-simulation. Start


the simulation with the simv command line and any runtime options
you want to use.

Using GNU Compilers on Sun Solaris


On Solaris the default compiler is Sun Forte CC. You can specify a
different compiler with -cpp and -cc compile-time options. The
interface supports the gcc 3.2.2 and 2.95.2 compilers.

If you use the -cpp g++ option on the syscan command line, you
must also use it on every command line that compiles C++ source,
for example:

syscan -cpp g++ sc_add.cpp:sc_add

syscan -cpp g++ sc_sub.cpp multiply.cpp display.cpp

vhdlan fir.vhd

vcs -cpp g++ -mhdl -sysc top.v dev.v

If you use a full path to a C++ compiler, you will have to supply the
path to the cc compiler on the vcs command line as well:

syscan -cpp /usr/bin/g++ sc_add.cpp:sc_add

syscan -cpp /usr/bin/g++ sc_sub.cpp multiply.cpp


display.cpp

vhdlan fir.vhd

Using the VCS MX / SystemC Co-Simulation Interface


12-15
vcs -cc /usr/bin/gcc -cpp /usr/bin/g++ -mhdl -sysc
top.v dev.v

Using GNU Compilers on Linux


On Linux the default compiler is gcc. You can specify a different
compiler with the -cpp and -cc compile-time options. The interface
supports the gcc 3.2.1 and 2.96 compilers.

Compiling on HPUX
The SystemC library should be compiled with +Z and not the default
+z.

Verilog and VHDL Modules in a SystemC Design

To co-simulate a SystemC design that contains Verilog and VHDL


modules, you import one or more MX instances into the SystemC
design. Using the VCS MX / SystemC Co-simulation Interface, you
generate a wrapper and include it in the SystemC design for each
MX instance. The ports of the created SystemC wrapper are
connected to signals attached to the ports of the corresponding MX
modules.

Figure 12-2 illustrates the VCS direct kernel interface (DKI)


communication.

Using the VCS MX / SystemC Co-Simulation Interface


12-16
Figure 12-2 VCS MX DKI Communication of SystemC Design Containing
Verilog Modules
Managed by the tool

SystemC environment DKI HDL simulator

SystemC source code HDL source code


entity-under-test

SystemC interface to the


clk clk

SystemC environment
HDL interface to the
Block 1 Block 2 reset reset
in Block 1
in

HDL simulator
rdy_read rdy_read
Block 3
out Block 2

out

Automatically generated by the tool

Input Files Required

To run co-simulation with a SystemC design containing Verilog and


VHDL modules, you need to provide the following files:

• Verilog and VHDL source code (.v, .vhd, and .vhdl extensions)
- You can directly write the entity-under-test HDL code or
generate it with other tools. The HDL description represented
by the entity-under-test can be HDL code of any complexity
(including hierarchy) and can use any language feature VCS
MX supports.
- Any other HDL source files necessary for the design.

Using the VCS MX / SystemC Co-Simulation Interface


12-17
• SystemC source code including:
- A SystemC top-level simulation (sc_main) that instantiates the
interface wrappers and other SystemC modules.
- Any other SystemC source files for the design.
• An optional port mapping file. If you do not provide this file, the
interface uses the default port mapping definition. For details of
the port mapping file, see “Using a Port Mapping File” on
page 12-32.
• An optional data type mapping file. If you don’t write a data type
mapping file, the interface uses the default file in the VCS MX
installation. For details of the data type mapping files, see “Using
a Data Type Mapping File” on page 12-35.

Generating the Wrapper

The process for generating the wrapper depends on whether you are
using Verilog or VHDL modules.

Generating the Wrapper for Verilog Modules


You use the vlogan utility with the -sysc option to generate and build
the wrapper and interface files for Verilog modules for co-simulation.
This utility creates the ./csrc directory in the current directory, just like
VCS does when you include compile-time options for incremental
compilation. The vlogan utility writes the wrapper and interface files
in subdirectories in the ./csrc directory.

Using the VCS MX / SystemC Co-Simulation Interface


12-18
There is nothing you need to do to the files that vlogan writes. VCS
will know to look for them when you include the compile-time option
for using the interface, see “Compiling a Verilog Design Containing
MX and SystemC Modules” on page 12-14.

The syntax for the vlogan command line is as follows:

vlogan -sysc -sc_model modulename file.v [-cpp path]


[-sc_portmap port_mapping_file]
[-Mdir=directory_path] [-V]

Where:

-sysc
Specifies generating a SystemC wrapper.
-sc_model modulename file.v
Specifies the module name and its Verilog source file.
-cpp path_to_the_compiler
If you omit -cpp path, it is assumed that your environment will
find the following compilers as defaults:
- HP-UX : aCC
- Linux : g++
- SunOS : CC (native Sun compiler)
Note the following:

- See the VCS MX Release Notes for more details on supported


compiler versions.

-You can override the default compilers in your environment


by supplying a path to the g++ compiler, for example:

-cpp /usr/bin/g++

Using the VCS MX / SystemC Co-Simulation Interface


12-19
-sc_portmap port_mapping_file
Specifies a port mapping file, see “Using a Port Mapping File” on
page 12-32.
-Mdir=directory_path
This option works the same way that the -Mdir VCS compile-
time option works. If you are using the -Mdir option with VCS,
you should use the -Mdir option with vlogan to redirect the vlogan
output to the same location that VCS uses.
-V
Displays code generation and build details. Use this option if you
are encountering errors or are interested in the flow that builds
the design.
To generate the wrapper and interface files for a Verilog module
named adder, in a Verilog source file named adder.v, instantiated in
SystemC code in top.cpp, you would enter the following:

vlogan -sysc -sc_model adder -sc_portmap the.map


adder.v

Generating the Wrapper for VHDL Modules

You use the "vhdlan -sysc" utility to generate and build the wrapper
and interface files for VHDL module for co-simulation. This utility
creates the ./csrc directory in the current directory, just like VCS does
when you include compile-time options for incremental compilation.
The vhdlan utility writes the wrapper and interface files in
subdirectories in the ./csrc directory.

The syntax for the vhdlan command line is as follows:

vhdlan -sysc file.vhd -sc_model modulename


[-cpp path] [-sc_portmap port_mapping_file]
[-Mdir=directory_path ] [-V]

Using the VCS MX / SystemC Co-Simulation Interface


12-20
Where:

-sysc
Specifies generating a SystemC wrapper.
file.vhd
Specifies the VHDL source file.
-sc_model modulename file.v
Specifies the module name and its Verilog source file.
-cpp path
If you omit -cpp path, it is assumed that your environment will
find the following compilers as defaults:

- HP-UX : aCC

- Linux : g++

- SunOS : CC (native Sun compiler)

Note the following:

- See the VCS MX Release Notes for more details on supported


compiler versions.

- You can override the default compilers in your environment by


supplying a path to the g++ compiler, e.g. -cpp /usr/bin/g++
-sc_portmap port_mapping_file
Specifies a port mapping file, see “Using a Port Mapping File” on
page 12-32.

Using the VCS MX / SystemC Co-Simulation Interface


12-21
-Mdir=directory_path
This option works the same way that the -Mdir VCS compile-
time option works. If you are using the -Mdir option with VCS,
you should use the -Mdir option with vlogan to redirect the vlogan
output to the same location that VCS uses.
-V
Displays code generation and build details. Use this option if you
are encountering errors or are interested in the flow that builds
the design.
To generate the wrapper and interface files for a VHDL module named
adder in a VHDL source file named adder.vhd, you would enter the
following:

vhdlan -sysc -sc_model fir -sc_portmap fir.map


fir.vhd

Instantiating the Wrapper

You instantiate an MX module in your SystemC code like a SystemC


module. For example, take the following Verilog module in a file called
adder.v:

module adder (value1, value2, result);


input [31:0] value1;
input [31:0] value2;
output [31:0] result;
reg [31:0] result_reg;

always @(value1 or value2)


begin
result_reg <= value1 + value2;
end

assign result = result_reg;

Using the VCS MX / SystemC Co-Simulation Interface


12-22
endmodule

The module name is adder, so you instantiate in your SystemC code


in top.cpp as follows:

#include adder.h
int sc_main(int argc, char *argv[]){
sc_clock clock ("CLK", 20, .5, 0.0);
sc_signal<sc_lv<32> > value1;
sc_signal<sc_lv<32> > value2;
sc_signal<sc_lv<32> > result;

// Verilog adder module


adder adder1("adder1");
adder1.value1(value1);
adder1.value2(value2);
adder1.result(result);

// VHDL fir module


fir fir1("fir1");
....

sc_start(clock, -1);
}

One of the generated files will be modulename.h, which should be


included in your .cpp file.

For a VHDL module, take the following example fir.vhd:

...
entity fir is
port( reset, input_valid, clk: in std_logic;
output_data_ready: out std_logic;
sample : in std_logic_vector (31 downto 0);
result : out std_logic_vector (31 downto 0) );
end fir;
...

Using the VCS MX / SystemC Co-Simulation Interface


12-23
You instantiate adder and fir in your SystemC code in top.cpp as
follows:

(keep and expand the fir section)


//VHDL fir module
fir fir1( "fir1");
fir1.reset(reset);
fir1.input_valid(input_valid);
fir1.sample(sample);
fir1.output_data_ready(output_data_ready);
fir1.result(result);
fir1.clk(clock.signal());

Analyzing Other MX Modules

Note the following when analyzing other MX Modules:

• Use vhdlan to analyze other VHDL modules.


• Use vlogan to analyze other Verilog modules.

Compiling a SystemC Design Containing MX modules

When you compile your design, you must include the hierarchy path
to the SystemC wrapper instances on your design compilation
command line:

syscsim -mhdl dev.v other_C++_source_files compile-


time_options -sc_inst adder=adder1 -sc_inst
fir=fir1

In this example, dev.v might contain Verilog code utilized by the


adder.v module above.

Using the VCS MX / SystemC Co-Simulation Interface


12-24
When you compile with this option, VCS MX looks in the ./csrc
directory for the subdirectories containing the interface and wrapper
files needed to connect the Verilog and SystemC parts of the design.

There are no runtime options for SystemC cosimulation. Start the


simulation with a simv command line and any runtime options that
you want to use.

Specifying Run-Time Options to the SystemC


Simulation

You start a simulation with the simv command line. You enter
SystemC parameters or arguments (analogous to Verilog runtime
options), to control the simulation of the SystemC part of the design,
on the simv command line, for example:

simv scarg1 scarg2

If you also want to enter a VHDL runtime option, to control the


simulation of the VHDL part of the design, you can do so by preceding
it with the -vhdlrun option on the simv command line, for example:

simv scarg1 -vhdlrun -verb

If you want to enter both Verilog and VHDL run-time options to control
the simulationof the Verilog and VHDL parts of the design, you can
use the -verilogrun and -vhdlrun options, for example:

simv scarg1 -verilogrun -q -vhdlrun "-prof


prof.html"

Using the VCS MX / SystemC Co-Simulation Interface


12-25
Using GNU Compilers on SUN Solaris
On Solaris the default compiler is Sun Forte CC. You can specify a
different compiler with -cpp and -cc compile-time options. The
interface supports the gcc 3.2.2 and 2.95.2 compilers.

If you use the -cpp g++ option on the interface analysis command
line, you must also use it on every command line that compiles C++
source:

vhdlan -sysc -cpp g++ fir.vhd -sc_model fir

vlogan -sysc -cpp g++ display.v -sc_model display

syscsim -cpp g++ -mhdl -sysc main.cpp a.cpp -sc_inst


display=display1 -sc_inst fir=fir1

If you use a full path to a C++ compiler, you will have to supply the
path to the cc compiler on the command line that builds the simulation
as well:

vhdlan -sysc -cpp /usr/bin/g++ fir.vhd -sc_model


fir

vlogan -sysc -cpp /usr/bin/g++ display.v -sc_model


display

syscsim -cc /usr/bin/gcc -cpp /usr/bin/g++ -mhdl -


sysc main.cpp a.cpp
top.v dev.v

Using the VCS MX / SystemC Co-Simulation Interface


12-26
Using GNU Compilers on Linux
On Linux the default compiler is gcc. You can specify a different
compiler with the -cpp and -cc compile-time options. The interface
supports the gcc 3.2.1 and 2.96 compilers.

Compiling on HPUX
The SystemC library should be compiled with +Z and not the default
+z.

Verilog/VHDL Modules and SystemC Leaf Modules in a


VHDL Design

To co-simulate a VHDL design that contains SystemC leaf modules


and Verilog/VHDL modules, you import one or more SystemC
instances into the VHDL design. Using the VCS MX / SystemC Co-
simulation Interface, you generate a wrapper and include it in the
VHDL design for each SystemC instance.

Other MX modules are also included in the design. The ports of the
created VHDL wrapper are connected to signals attached to the ports
of the corresponding SystemC modules.

Figure 12-1 on page 12-6 illustrates VCS MX communication.

Required Input Files

To run co-simulation with a VHDL design containing SystemC,


Verilog and VHDL modules, you need to provide the following files:

Using the VCS MX / SystemC Co-Simulation Interface


12-27
• SystemC source code
- You can directly write the entity-under-test source code or
generate it with other tools.
- Any other C or C++ code for the design.
• HDL source code (.v, .vhd or .vhdl extension) including:
- A Verilog or VHDL module definition that instantiates the
interface wrapper and other MX modules. These wrapper files
are generated by a utility and you don’ t need to do anything to
these files (see “Generating the Wrapper for SystemC Modules”
on page 12-28
• Any other VHDL source files for the design
• An optional port mapping file. If you do not provide this file, the
interface uses the default port mapping definition. For details of
the port mapping file, see “Using a Port Mapping File” on
page 12-32.
• An optional data type mapping file. If you don’t write a data type
mapping file, the interface uses the default one in the VCS
installation. For details of the data type mapping files, see “Using
a Data Type Mapping File” on page 12-35.

Generating the Wrapper for SystemC Modules

You use the syscan utility to generate the wrapper and interface files
for cosimulation. This utility creates the csrc directory in the current
directory, just like VCS does when you include compile-time options
for incremental compilation. The syscan utility writes the wrapper and
interface files in subdirectories in the ./csrc directory.

Using the VCS MX / SystemC Co-Simulation Interface


12-28
There is nothing you need to do to the files that syscan writes. VCS
will know to look for them when you include the compile-time option
for using the interface, see Compiling Your Design on page 12-31.

The syntax for the syscan command line is as described on page 12-8.

The following example generates a Verilog wrapper:

syscan adder.cpp:adder

The following example generates a VHDL wrapper:

syscan -vhdl adder.cpp:adder -o adder_vhdl

Note: the -Mdir option is not supported in this scenario.

Instantiating the Wrapper and Coding Style

Instantiate the Verilog and SystemC modules as you would any VHDL
module:

SystemC module "fir" in fir.h:

...
SC_MODULE(fir) {

sc_in<bool> reset;
sc_in<bool> input_valid;
sc_in<int> sample;
sc_out<bool> output_data_ready;
sc_out<int> result;
sc_in_clk CLK;

SC_CTOR(fir)
{
SC_CTHREAD(entry, CLK.pos());

Using the VCS MX / SystemC Co-Simulation Interface


12-29
watching(reset.delayed() == true);
}

void entry();
};

Verilog module "display" in display.v:

module display (output_data_ready, result);


input output_data_ready;
input [31:0] result;

integer counter;

initial
begin
counter = 0;
end

always @(posedge output_data_ready)


begin
counter = counter + 1;
$display("Display : %d", result);
if (counter >= 24)
begin
$finish;
end
end
endmodule

Analyzing Other MX Modules

Note the following when analyzing other MX Modules:

• Use vhdlan to analyze other VHDL modules.


• Use vlogan to analyze other Verilog modules.

Using the VCS MX / SystemC Co-Simulation Interface


12-30
Compiling a VHDL Design Containing MX and SystemC
Modules

To compile your Verilog design for using the interface include the
-sysc and -mhdl compile-time options, for example:

scs -sysc -mhdl testbench_arch_cfg

When you compile with these options, scs looks in the csrc directory
for the subdirectories containing the interface and wrapper files
needed to instantiate the SystemC design in the Verilog design. There
are no runtime options needed to run the cosimulation. Start
simulation with the simv command line and any runtime options that
you want to use.

Using GNU Compilers on SUN Solaris

On Solaris the default compiler is Sun Forte CC. You can specify a
different compiler with -cpp and -cc compile-time options. The
interface supports the gcc 3.2.2 and 2.95.2 compilers.

If you use the -cpp g++ option on the syscan command line, you
must also use it on every command line that compiles C++ source:

syscan -cpp g++ sc_add.cpp:sc_add

syscan -cpp g++ sc_sub.cpp multiply.cpp display.cpp

vhdlan fir.vhd

scs -cpp g++ -mhdl -sysc testbench_arch_cfg

Using the VCS MX / SystemC Co-Simulation Interface


12-31
If you use a full path to a C++ compiler, you will have to supply the
path to the cc compiler on the simulation build command line as well:

syscan -cpp /usr/bin/g++ sc_add.cpp:sc_add

syscan -cpp /usr/bin/g++ sc_sub.cpp multiply.cpp


display.cpp

vhdlan fir.vhd

scs -ccpath /usr/bin/gcc -cpp /usr/bin/g++ -mhdl -


sysc testbench_arch_cfg

Using GNU Compilers on Linux


On Linux the default compiler is gcc. You can specify a different
compiler with the -cpp and -cc compile-time options. The interface
supports the gcc 3.2.1 and 2.96 compilers.

Compiling on HPUX
The SystemC library should be compiled with +Z and not the default
+z.

Using a Port Mapping File

You can provide an optional port mapping file for the syscan
command with the -port option, and for vhdlan and vlogan by using
-sc_portmap. If you specify a port mapping file, any module port
that is not listed in the port mapping file will be assigned the default
type mapping.

Using the VCS MX / SystemC Co-Simulation Interface


12-32
A SystemC port has a corresponding Verilog or VHDL port in the
wrapper for instantiation. The syscan utility either uses the default
method for determining the type of the HDL port it writes in the
wrapper or uses the entry for the port in the port mapping file.

A port mapping file is an ASCII text file.Each line defines a port in the
SystemC module, using the format in Example x and y. A line
beginning with a pound sign (#) is a comment.

A port definition line begins with a port name, which must be the same
name as that of a port in the HDL module or entity. Specify the number
of bits, the HDL port type, and the SystemC port type on the same
line, separated by white space. You can specify the port definition
lines in any order. You must, however, provide the port definition
parameters in this order: port name, bits, HDL type, and SystemC
type.

The valid Verilog port types, which are case-insensitive, are as


follows:

• bit — specifies a scalar (single bit) Verilog port.


• bit_vector — specifies a vector (multi-bit) unsigned Verilog
port (bitvector is a valid alternative).
• signed — specifies a Verilog port that is also a reg or a net
declared with the signed keyword and propagates a signed value.
The valid VHDL port types, which are case-insensitive, are:

• bit
• bitvector
• std_logic
• std_logic_vector

Using the VCS MX / SystemC Co-Simulation Interface


12-33
• signed
• unsigned
The following examples show port mapping files.

Example 12-3 Verilog Port Mapping File


# Port name Bits Verilog type SystemC type
in1 8 signed sc_int
in2 8 bit_vector sc_lv
clock 1 bit sc_clock
out1 8 bit_vector sc_uint
out2 8 bit_vector sc_uint

Example 12-4 VHDL Port Mapping File


# Port name Bits VHDL type SystemC type
in1 8 std_logic_vector sc_int
in2 8 std_logic_vector sc_lv
clock 1 std_logic sc_clock
out1 8 std_logic_vector sc_uint
out2 8 std_logic_vector sc_uint

SystemC types are restricted to the sc_clock, sc_bit, sc_bv,


sc_logic, sc_lv, sc_int, sc_uint, sc_bigint, and
sc_biguint data types.

Native C/C++ types are restricted to the bool, char, uchar, short,
ushort, int, uint, long, and ulong data types.

Using the VCS MX / SystemC Co-Simulation Interface


12-34
Using a Data Type Mapping File

When running a VCS MX / SystemC simulation, the interface


propagates data through the module ports from one language domain
to another. This can require the interface to translate data from one
data type representation to another. This translation is called mapping
and is controlled by data type mapping files.

The datatype mapping mechanism is similar to that used for port


mapping (see “Using a Port Mapping File” on page 12-32), but is more
economical and requires less effort to create and maintain. Because
the datatype mapping is independent of the ports, you can create one
or more default mappings for a particular type that will be used for all
ports, rather than having to create a port map for every port of each
new HDL wrapper model.

Data type mapping files map types, so that ALL ports of that type on
ALL instances will now be assigned the specified mapping.

The data type mapping file is named cosim_defaults.map. The


interface looks for and reads the data mapping file in the following
places and in the following order:

1. In $VCS_HOME/include/cosim
2. In your $HOME/.synopsys_ccss directory
3. In the current directory.
An entry in a later file overrules an entry in an earlier file.

Each entry for a SystemC type has the following:

1. It begins with the keyword Verilog or VHDL.

Using the VCS MX / SystemC Co-Simulation Interface


12-35
2. It is followed by the bit width. For vectors, an asterisk (*) is a
wildcard to designate vectors of any bit width not specified
elsewhere in the file.
3. The corresponding Verilog or VHDL “type” using keywords that
specify if it is scalar, unsigned vector, or signed port, the same
keywords used in the port mapping file.
4. The SystemC or Native C++ type
Example 12-5 shows an example of a data type mapping file.

Example 12-5 Data Type Mapping File


##################################################
# Mappings between SystemC and Verilog datatypes
##################################################
Verilog * bit_vector sc_bv
Verilog 1 bit bool
Verilog * bit_vector int
Verilog * signed int
Verilog 1 bit sc_logic
Verilog 1 bit sc_bit
Verilog * bit_vector char
Verilog * bit_vector uchar
Verilog * bit_vector short
Verilog * bit_vector ushort
Verilog * bit_vector uint
Verilog * bit_vector long
Verilog * bit_vector ulong

Debugging a Mixed Simulation

To debug just the SystemC code in the mixed simulation, do the


following:

Using the VCS MX / SystemC Co-Simulation Interface


12-36
1. Run syscan with the -cflags "-g" option to build the SystemC
source code for debugging.
2. Start the C++ debugger on the simv executable file.

If you are using the Sun Forte compiler:


dbx ./simv

If you are using the Gnu compiler on Solaris or Linux:

Run both syscan and VCS with the -cpp path option

gdb ./simv

If you are using the aCC compiler on the HP platform, you can use
either the gdb or wdb debugger:

gdb ./simv
wdb ./simv

You can now set and stop at breakpoints in your SystemC code.

To also debug the Verilog/VHDL portions of your design, follow the


debug instructions in the VCS MX User's Guide under "Debugging
and Post-Processing" for mixed designs to enable debugging in the
VHDL and/or Verilog modules. With either the VCS or VCS MX
debugger running, find the simv/scsim executable process id:

% ps -e | grep simv (or scsim)


12216 pts/1 0:00 simv

Launch your SystemC debugger using the process ID to connect to


the running simulations, for example:

Using the VCS MX / SystemC Co-Simulation Interface


12-37
% gdb ./simv 12216

Using the Built-in SystemC Simulator

VCS MX contains a built-in SystemC which it uses by default. No


setup is necessary. Using this simulator does not require setting an
environment variable (in earlier releases, the interface required the
SYSTEMC environment variable).

Compatibility with OSCI SystemC 2.0.1


The built-in SystemC simulator is binary compatible to the OSCI
SystemC 2.0.1 simulator. That means that you can link into a simv
executable objects files (*.{o,a,so}) compiled with the OSCI SystemC
2.0.1 simulator.

Supported Compilers
The following compilers are supported:

• Linux: gcc 2.96 and gcc 3.2.1


• Solaris: SC 6.2, gcc 2.95.2, gcc 3.2.2
• HP: aCC 3.35
Compiling Source Files
If you need to compile source files that include systemc.h in your own
environment and not with the syscan script, then add
compiler flag -I$VCS_HOME/include/systemc.

Using the VCS MX / SystemC Co-Simulation Interface


12-38
Using a Customized SystemC Installation

Important:
This feature is not available in VCS 7.2 beta.

You can install the OSCI SystemC simulator and tell VCS MX to use
it for Verilog/VHDL/SystemC cosimulation. To do so you set the
SYSTEMC_OVVERRIDE environment variable to the directory
where you installed it, for example:

setenv SYSTEMC_OVERRIDE /net/user/systemc-2.0.1

The OSCI SystemC simulator installation must have the usual OSCI
structure of $SYSTEMC_OVERRIDE/include and
$SYSTEMC_OVERRIDE/lib-<arch>/libsystemc.a.

The installation must contain the patches required for the


cosimulation interface.

Compatibility with OSCI SystemC 2.0.1


The built-in SystemC simulator is binary compatible to the OSCI
SystemC 2.0.1 simulator. That means that you can link into a simv
executable objects files (*.{o,a,so}) compiled with the OSCI SystemC
2.0.1 simulator.

Supported Compilers
The following compilers are supported:

Linux: gcc 2.96 and gcc 3.2.1

Solaris: SC 6.2, gcc 2.95.2, gcc 3.2.2

HP: aCC 3.35

Using the VCS MX / SystemC Co-Simulation Interface


12-39
Compiling Source Files
If you need to compile the source files that include systemc.h in your
own environment and not with the syscan script, then add compiler
flag -I$VCS_HOME/include/systemc.

Using the VCS MX / SystemC Co-Simulation Interface


12-40
13
Using Synopsys Models 2
The models from Synopsys that you can instantiate in your design
include:

• SmartModels
• Hardware models
SmartModels are models from Synopsys that model devices from
various vendors. See “SmartModel Interface” for more information.

You can also instantiate an actual device in your VHDL design using
a Synopsys hardware modeler. See LM-Family Hardware Modeler
Interface.

Using Synopsys Models


13-1
SmartModel Interface

The SmartModel interface enables you to use VCS MX and simulate


VHDL designs that contain SmartModel components. The
SmartModel library contains descriptions of industry standard
components that you can use in VHDL simulations.

This section contains the following topics:

• Setting Up the Environment for SmartModels


• Using SmartModels in VHDL Source Files
• SmartModel Windows
• Error Messages
• Modifying the Timing Files

Before You Start

The SmartModel library provides models of over 9000 components


with flexible timing constraints. The models are software descriptions
of standard hardware components ranging from TTL parts to complex
components such as microprocessors.

The SmartModel interface is an option for VCS MX. It does not require
extensions to the VHDL language. You can use SmartModels
concurrently with C-language models. SmartModels also work in
simulations using the LM-family hardware modelers.

Using Synopsys Models


13-2
Setting Up the Environment for SmartModels

To use SmartModels, you must ensure that your host environment is


properly set up. The setup involves

• Setting the environment variables


• Creating the SmartModel VHDL library

Setting the Environment Variables


You must set the following UNIX environment variables:

• LMC_HOME
• SNPSLMD_LICENSE_FILE or LM_LICENSE_FILE
• LD_LIBRARY_PATH
You can check the current setting of these variables by using the
UNIX echo command. For example, to display the current setting of
the LMC_HOME variable, type

% echo $LMC_HOME

LMC_HOME
The LMC_HOME environment variable must point to the SmartModel
installation directory that contains the templates and lib
subdirectories. To set LMC_HOME, type

% setenv LMC_HOME /SmartModel_installation_directory_path

Using Synopsys Models


13-3
SNPSLMD_LICENSE_FILE or LM_LICENSE_FILE
The SNPSLMD_LICENSE_FILE or LM_LICENSE_FILE
environment variables must point to the product authorization file. To
set variables, type

% setenv SNPSLMD_LICENSE_FILE path_to_authorization_file


% setenv LM_LICENSE_FILE path_to_authorization_file

LD_LIBRARY_PATH
Before you change the LD_LIBRARY_PATH environment variable,
perform the following steps:

1. Set the VCS_HOME environment variable


2. Source the $VCS_HOME/admin/setup/environ.csh file
3. Ensure that the LD_LIBRARY_PATH is set to the $VCS_HOME/
<ARCH>/sim/lib variable
The LD_LIBRARY_PATH environment variable must point to the
directory that contains the SmartModel shared object. For example,
to set LD_LIBRARY_PATH on a SunSparc machine running the
Solaris operating system, type

% setenv LD_LIBRARY_PATH
$LMC_HOME/lib/sun4Solaris.lib:$LD_LIBRARY_PATH

Creating the SmartModel VHDL Library


After you set your environment variables, you can create and analyze
the SmartModel VHDL library. Use the create_smartmodel_lib
command to create, update, and analyze the SMARTMODEL library.
Use this library as you would use any other VHDL resource library.

Using Synopsys Models


13-4
Note:
You use the create_smartmodel_lib command only if you install
a new version of a SmartModel library or a new version of VCS
MX.

Using the create_smartmodel_lib Utility


To use create_smartmodel_lib, you must make sure that the

• LMC_HOME, VCS_HOME, and LD_LIBRARY_PATH


environment variables are set properly.
• SMARTMODEL library name mapping in the setup file points to
the same directory when you invoke create_smartmodel_lib
and when you simulate a design that instantiates SmartModel
components. See “Modifying the SmartModel Library Name
Mapping” later in this chapter for more information about the
SMARTMODEL library name mapping.
The syntax of create_smartmodel_lib is

create_smartmodel_lib [--][-nc][-create][-srcdir dir]


[-analyze][-nowarn] [-modelfile file]
{ -model modelname }

Using Synopsys Models


13-5
Command Options
--
Displays the usage and all the command line options of the utility.
-nc
Suppresses the Synopsys copyright message.
-create
Creates the VHDL source files (.vhd files) for the SMARTMODEL
library and saves the source files in the $LMC_HOME/synopsys
directory.
-srcdir dir
Lets you specify the location of the VHDL source files that you
create. The default location is $LMC_HOME/synopsys.
-analyze
Analyzes the SMARTMODEL library source files (.vhd files) by
invoking vhdlan. The analyzed files (.sim and .mra files) are saved
in the $LMC_HOME/synopsys/smartmodel directory. This
directory is specified by SMARTMODEL logical name mapping in
the setup file.
-nowarn
Suppresses the warning messages. The warning messages notify
you of any port name mappings. See “VHDL Reserved Port and
Window Names” for more information about port name mappings.
-modelfile file
A list of SMARTMODEL component names is read from file.
Names are separated by spaces. Only those component names
specified are included in the SMARTMODEL component library.
-model modelname
modelname is included in the resulting SMARTMODEL
component library. Repeat this option to specify multiple models.
Only those component names specified are included in the

Using Synopsys Models


13-6
SMARTMODEL component library.
If you specify neither the -create nor -analyze options,
create_smartmodel_lib creates and analyzes the source files
for the SMARTMODEL library.

Example 13-1 shows a sample SmartModel VHDL library source file


(.vhd). This file is created by create_smartmodel_lib and
contains the ttl00 and ttl04 models.

Example 13-1 Sample SmartModel VHDL Library File


library SYNOPSYS,IEEE;
use SYNOPSYS.TYPES.all;
use IEEE.STD_LOGIC_1164.all;
package COMPONENTS is

component ttl00
-- Available timing versions:
-- 54AC00-FAI
-- 54AC11000
-- 54ACT11000
-- 54F00-FAI
-- 54F00-SIG
-- 74AC00-FAI
-- 74AC11000
-- 74ACT11000
-- 74F00-FAI
-- 74F00-SIG
-- 74HC00-SIG
-- 74HCT00-SIG
-- CD54AC00
-- CD54ACT00
-- CD54HC00
-- CD54HCT00
-- CD74AC00
-- CD74AC00-EXT
-- CD74ACT00
-- CD74ACT00-EXT
-- CD74HC00
-- CD74HCT00

Using Synopsys Models


13-7
-- SN54ALS00A
-- SN54AS00
-- SN54F00
-- SN54LS00
-- SN74ALS00A
-- SN74AS00
-- SN74F00
-- SN74LS00
generic (
TimingVersion : STRING := “SN74AS00”;
DelayRange : STRING := “Max”);
port (
I1 : in STD_LOGIC;
I2 : in STD_LOGIC;
O1 : out STD_LOGIC);
end component;

component ttl04
-- Available timing versions:
-- 54AC11004
-- 74AC11004
-- 54ACT11004
-- 74ACT11004
-- CD74AC04
-- CD74AC04-EXT
-- CD74ACT04
-- CD74ACT04-EXT
-- SN74ALS04B
-- SN74AS04
-- 74F04-FAI
-- 74F04-SIG
-- 74HC04-SIG
-- CD74HC04
-- SN74HC04
-- 74HCT04-SIG
-- CD74HCT04
-- SN74LS04
-- CD54AC04
-- CD54ACT04
-- SN54ALS04B
-- SN54AS04

Using Synopsys Models


13-8
-- 54F04-FAI
-- 54F04-SIG
-- CD54HC04
-- SN54HC04
-- CD54HCT04
-- SN54LS04
-- SN54F04
-- SN74F04
generic (
TimingVersion : STRING := “SN74AS04”;
DelayRange : STRING := “Max”);
port (
I1 : in STD_LOGIC;
O1 : out STD_LOGIC);
end component;
end COMPONENTS;

library SYNOPSYS,IEEE;
use SYNOPSYS.TYPES.all;
use SYNOPSYS.ATTRIBUTES.all;
use IEEE.STD_LOGIC_1164.all;

entity ttl00 is
generic (
TimingVersion : STRING := “SN74AS00”;
DelayRange : STRING := “Max”);
port (
I1 : in STD_LOGIC;
I2 : in STD_LOGIC;
O1 : out STD_LOGIC);
end ttl00;

architecture SMARTMODEL of ttl00 is


attribute FOREIGN of SMARTMODEL : architecture is
“Synopsys:SMARTMODEL”;
begin
end;

library SYNOPSYS,IEEE;
use SYNOPSYS.TYPES.all;
use SYNOPSYS.ATTRIBUTES.all;
use IEEE.STD_LOGIC_1164.all;

Using Synopsys Models


13-9
entity ttl04 is
generic (
TimingVersion : STRING := “SN74AS04”;
DelayRange : STRING := “Max”);
port (
I1 : in STD_LOGIC;
O1 : out STD_LOGIC);
end ttl04;

architecture SMARTMODEL of ttl04 is


attribute FOREIGN of SMARTMODEL : architecture is
“Synopsys:SMARTMODEL”;
begin
end;

VHDL Reserved Port and Window Names


When create_smartmodel_lib creates the source files (.vhd) for
the SMARTMODEL library, it renames the VHDL reserved port or
window names by appending _PORT or _SIGNAL to the original
name.

For example, if a SmartModel component uses the VHDL reserved


name ARRAY as one of its port names, create_smartmodel_lib
maps the port name to ARRAY_PORT.

VCS MX generates SmartModel warning messages and notifies you


of the name mappings.

Modifying the SmartModel Library Name Mapping


By default, the logical library name SMARTMODEL is mapped to a
UNIX directory in your system-wide synopsys_sim.setup file as
shown in the following statement:

SMARTMODEL : $LMC_HOME/synopsys/smartmodel

Using Synopsys Models


13-10
Synopsys recommends that you use the default SMARTMODEL
library name mapping. The create_smartmodel_lib utility stores
the analyzed source files in a directory as specified by the
SMARTMODEL library name mapping.

If you change the default SMARTMODEL library name mapping, you


must invoke the create_smartmodel_lib utility to reanalyze the
source files. (See, the “Creating the SmartModel VHDL Library”
section for more information about creating and analyzing
SmartModel library source files.)

To change the default mapping, specify a different path in your local


synopsys_sim.setup file. For example, you can add the following line
to the synopsys_sim.setup file in your home directory:

SMARTMODEL : ~joe/smartmodel

To determine the current SMARTMODEL library mapping, type the


following command at the prompt:

% show_setup -lib

Using SmartModels in VHDL Source Files

To use SmartModel components in the VHDL source file of your


design, you must

• Specify the SMARTMODEL library in your VHDL design.


• Instantiate the SmartModel component.
After you use the SmartModel component in your source file, you can
analyze and simulate your design.

Using Synopsys Models


13-11
Specifying the SmartModel Library
Source files that use SmartModel components must contain library
and use clauses for the SMARTMODEL library, as follows:

library SMARTMODEL;
use SMARTMODEL.components.all;

The library logical name SMARTMODEL must be mapped to the


appropriate directory. See “Modifying the SmartModel Library Name
Mapping” for instructions about mapping the library name.

Instantiating SmartModel Components


To include a SmartModel component in your VHDL design
description, perform the following steps:

• Instantiate the component.


• Specify the model options in the generic map.
Example 13-2 shows the library and use clauses for the
SMARTMODEL library, an instance (U1) of a SmartModel component
(TTL00) from the SMARTMODEL library, and the TimingVersion
(SN74ALS00A) and the DelayRange (Typ) options in the generic map
for the TTL00 component.

Example 13-2 Instantiating a SmartModel


- - Simple illustration in VHDL
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
- - Use SmartModel library as any other VHDL resource library.
library SMARTMODEL;
use SMARTMODEL.COMPONENTS.ALL;

entity TestBench is

Using Synopsys Models


13-12
end TestBench;
architecture ArchTestBench of TestBench is
signal A, B, C: STD_LOGIC;
begin
U1 : TTL00 generic map (TimingVersion => “SN74ALS00A”,
DelayRange => “Typ”)
port map (A,B,C);
P1 : process
begin
A <= 1;
B <= 1;
wait;
end process;
end ArchTestBench;
configuration CfgTestBench of TestBench is
for ArchTestBench
- - Default Architecture
end for;
end;

SmartModel Windows

SmartModel windows enable you to access internal registers and


other model states for display, tracing, and manipulation. SmartModel
windows are modeled as internal signals in VCS MX when you
generate the SmartModel VHDL library.

After a window corresponds to a local signal, you can access the


window by using the same VCS MX commands that you use to access
signals in your design. For example, you can use the assign, dump,
and ls commands to access the windows.

Windows can be scalars, vectors, or vector arrays (such as


memories.) Some operations such as ls, monitor, or dump apply
to an entire vector or a section of a vector.

Using Synopsys Models


13-13
Using VCS MX Commands on Windows
Before using the VCS MX commands on windows, you must change
your directory from its current location to the directory (using cd) that
contains the SmartModel instance. You can use the following VCS
MX signal commands on windows:

assign (cannot use the -after option)


evaluate
fprint
ls
monitor (can use only the -event option)
dump

To find out if the SmartModel contains any windows, use the


instance command with ReportStatus as the Channel Command.
For example, to find out if the /E/U1 instance contains any windows,
type the following command at the simulator prompt:

# SMARTMODEL instance /E/U1 “ReportStatus”

You can also type the short form of the instance command, as follows:

# sm i /e/u1/ “ReportStatus”

If any windows exist, the status report includes a SmartModel Window


Status statement. Following is an example of the SmartModel
Window Status Report:

SmartModel NOTE:
<<Status Report>>
Model template: windows
InstanceName: /E/U1
TimingVersion: WINDOWS-0
DelayRange: MAX
TimingConstraints: On
Instance /E/U1(Windows-0), at time 0 ps

Using Synopsys Models


13-14
SmartModel NOTE:
SmartModel Windows Status:
WA “Read-Only (Read Only)” : 0
WB “1-bit” : X
WC “64-bit” : XXXXXXXXXXXXXXXX

The ReportStatus command also displays the windows READ and


WRITE permissions. The above example shows that you have read
permission on the WA window and that you have read and write
permission on the WB and WC windows. If you write to a read-only
window, the VCS MX SmartModel Interface issues a warning
message. For example, if you type

assign ’1’ WA

the following message appears:

VSS-SmartModel Interface WARNING:


SmartWindow /E/U1/WA is not writable.

SmartModel Window Example


Example 13-3 shows a sample SmartModel library, as created by
create_SmartModel_lib, that defines three windows (Ws, Wv,
Wmem) in a SmartModel (win). The example also shows how the Ws,
Wv, and Wmem windows are represented as signals in a VHDL file.
Ws is a scalar window, Wv is a vector window with a dimension of
one, and Wmem is an array of vectors window. You can instantiate
the win component in your source code (see Example 13-2 for an
example of component instantiation.)

Note:
win is a dummy SmartModel. It does not exist in your SmartModel
library.

Using Synopsys Models


13-15
Example 13-3 Sample SmartModel VHDL Library File with SmartModel
Windows
library SYNOPSYS,IEEE;
use SYNOPSYS.TYPES.all;
use SYNOPSYS.ATTRIBUTES.all;
use IEEE.STD_LOGIC_1164.all;

entity win is
generic (
TimingVersion : STRING := “WINDOW-0”;
DelayRange : STRING := “Max”);
port (
CLK : in STD_LOGIC;
PWA : out STD_LOGIC;
PWB : out STD_LOGIC;
PWC : out STD_LOGIC);
end win;

architecture SMARTMODEL of win is


attribute FOREIGN of SMARTMODEL : architecture is
“Synopsys:SMARTMODEL”;
signal Ws : STD_LOGIC; -- Scalar Window element
signal Wv : STD_LOGIC_VECTOR (63 downto 0); -- Vector
type Wmem_2048_8 is array (0 to 2047) of
STD_LOGIC_VECTOR(7 downto 0);
signal Wmem : Wmem_2048_8; -- Mem window (width=8,
len=2048) begin
end;

To execute a command on all the windows, you can use the wildcard
character to refer to all the signals, as follows:

*’signal
W*

To execute a command on a specific window, you can explicitly use


the window names, as follows:

Ws

Using Synopsys Models


13-16
Wv
Wmem

To execute a command on sub-elements of a window, you can specify


the window element as in the following examples:

Wv(i) i is a value from 0 to 63


Wmem(j)j is a value from 0 to 2047
Wmem(j)(k)k is a value from 0 to

To access these windows, you can use the monitor command as in


the following examples:

cd win_instance_dir
monitor -event {Ws Wv}
monitor -event {Wmem(0) Wmem(1) Wmem(2047) Wmem (2 to 3)}
ls -v *’sig
monitor -event Wmem

To find the range of a vector window, you can use the evaluate
command as in the following examples:

evaluate {Wv’left Wv’right}


evaluate {Wmem’left Wmem’right}
evaluate {Wmem(x)’left Wmem(x)’right}

Note:
The range of a vector window is from a number down to 0. As
shown in Example 13-3, Wv is a vector window that has a range
of 63 downto 0.

The range of an array of vectors window is from 0 to a number


and the width of it is from a number down to 0. As shown in
Example 13-3, Wmem is an array of vectors window that has a
range of 0 to 2047 and a width of 7 downto 0.

Using Synopsys Models


13-17
SmartModel Window Precautions
Synopsys recommends that you do not use the monitor or dump
commands on window sections that contain a large number of
vectors. In general, the larger the number of vectors that you monitor,
the slower the performance of the Simulator. Use the monitor or
dump command on window sections containing a small numbers of
vectors.

If you monitor or trace window sections greater than 64 vectors, the


VCS MX SmartModel Interface issues a warning message informing
you that the performance of the simulator is drastically affected.

The SmartModel Interface does not support windows created from


SCF files. For more information about SCF files, refer to the
SmartModel documentation.

Error Messages

SmartModel messages issued by VCS MX start with the following line:

VSS-SmartModel Interface

SmartModel messages issued by Synopsys SmartModels start with


the following line:

SmartModel

There are four types of SmartModel messages from Synopsys


SmartModels: Warning, Trace, Note, and Error.

Warning, Trace, and Note messages have the following format:

SmartModel Warning:

Using Synopsys Models


13-18
scsim,432:

SmartModel Trace:
Trace is turned on.
SmartModel Instance U1 (SCF-0), at time 200NS.

SmartModel Note:
Reading configuration file:
’scf.1’.
Instance E/UT (SCF-0), at time 0NS.

An Error message has the following format:

**Error: scsim,431:
SmartModel FATAL ERROR:
The LMC_HOME environment variable has not been set.

For information about specific messages, see SmartModel


documentation.

Modifying the Timing Files

Normally, you use the default timing file for a SmartModel in your
simulation. However, you can edit the values in the default file to use
in your simulation.

For more information about editing the timing file and using it in your
simulation, see the SmartModel documentation.

LM-Family Hardware Modeler Interface

The interface for using LM-family hardware modelers with


VCS MX involves these primary concepts:

Using Synopsys Models


13-19
• Before You Start
• Setting Up the Environment
• Creating VHDL Model Support Files
• Modifying LM-family Shell Software Files
• Analyzing and Linking the Design
• Simulating the Design
• Error messages
• LM-family modeler example

Before You Start

The LM-family hardware modeler uses actual hardware devices to


model their behavior during simulation. The modeler applies the
inputs to the physical device, evaluates the device behavior, and
returns the results to VCS MX through the interface.

Figure 13-1 shows the relationship of the LM-family modelers to VCS


MX. When you invoke the Simulator (scsim), it accesses the LM-
family Shell Software files and manages the Ethernet link
communications with the modeler.

Interface Benefits
Following are the primary benefits of the Synopsys’ LM-family
hardware modeler interface:

• Provides model-independence

Using Synopsys Models


13-20
The interface allows you to simulate different configurations
without generating a different simulator for each hardware model.

With model-independence, you can also create your own


hardware models to use with the Simulator. For example, you can
simulate a proprietary microprocessor that is still in development.

• Uses standard VHDL code for hardware model support


Because the hardware modeler uses standard VHDL code for the
interface, it is a straightforward task for you to modify a VHDL
design to use LM-family hardware models.

Documentation for Operating the Modeler


Except for the Synopsys restrictions on Shell Software files, use
Hardware Models documentation to install and operate the modeler.

Using Synopsys Models


13-21
Figure 13-1 LM-Family Modeler in the VCS MX Environment

VHDL
VHDL
VHDL
SOURCE
SOURCE
MODEL SUPPORT
VHDL
FILES
FILES
FILES
MODEL SUPPORT
FILES

VHDL
ANALYZER

DESIGN
DESIGN
DESIGN
LIBRARY
LIBRARY
LIBRARY
FILES
FILES
FILES

VHDL
SIMULATOR

VHDL
VHDL ENVIRONMENT
LM-FAMILY
SOURCE LM-FAMILY AND SUPPORT
SOURCE
SHELLFILES
SOFTWARE
FILES INTERFACE UTILITIES
FILES

ETHERNET

LM Modeler
HARDWARE
MODEL(S)

Using Synopsys Models


13-22
Logic Types Requirement
VCS MX requires you to use std_logic defined types for LM-family
models, unless you provide a map between std_logic and a user-
defined enumeration type.

LM-Family Utilities
Synopsys provides two utilities, lm and lmdaemon, for you to use with
the LM-family modeler.

lm Utility
The lm utility is a menu-based program for creating and verifying
models and for performing maintenance and diagnostic functions on
the modeler. See the Hardware Models documentation for complete
information.

lmdaemon Utility
The lmdaemon utility runs as a system background process (daemon)
and monitors activity on the LM-family hardware modeler. The
lmdaemon utility has two functions:

• It deletes any instance information that has been idle in the


hardware modeler for more than a user-specified time limit.
• It automatically reboots the modeler if the modeler crashes.
The use of lmdaemon is optional.

Using Synopsys Models


13-23
Setting up the Environment

The LM-family modeler must be installed before you set up the


environment. For information on installing the LM-family modeler, see
the Logic Modeling documentation.

Set up your environment by performing the following steps:

1. Set the LM_DIR and LM_LIB environment variables. You can set
these variables manually from the UNIX prompt, or you can add
the settings to your .cshrc file so that they are automatically set
when you invoke a new shell.
unix% setenv LM_DIR pathname/lm_dir
unix% setenv LM_LIB pathname/models:pathname/maps

Replace pathname with the LM software installation pathname.

2. Use the lm utility to verify that the hardware modeler is properly


installed in the Ethernet network environment where you are using
VCS MX. See the LM-family documentation for more information
on the lm utility.
3. Ensure that you have the appropriate license in your license file
for the LM-family hardware modeler.

Using Synopsys Models


13-24
Creating VHDL Model Support Files

For each LM-family model, you must provide

• A file containing an entity-architecture pair declaration, so that the


VHDL design can reference it later in a component instantiation
statement.
• A package for defining constants, declaring components, and
instantiating components.
• A test bench or input stimulus file for exercising the model.
These can be in one file or in separate files. The input stimulus file
also normally contains an instantiation of the model and can contain
any processes necessary to simulate the support circuitry for the
model (for example, clocks signals.)

Using the create_hwmodel_shell Utility


You can use the utility create_hwmodel_shell to generate the
entity-architecture pair declaration. This utility is a simple awk script
that reads the model’s NAM file and produces the model’s VHDL shell.

The syntax of create_hwmodel_shell is

create_hwmodel_shell model.NAM outfile.vhd

Entity Declaration
Example 13-4 shows the basic format of an entity declaration for the
LM-family modeler. Example 13-5 shows the actual entity declaration
for the MC68020 model. Note that only some of the generic types are
used in Example 13-5; the others will have their default values.

Using Synopsys Models


13-25
Example 13-4 Basic Template for Entity Declarations
library SYNOPSYS;
use SYNOPSYS.ATTRIBUTES.all;
library IEEE;
use IEEE.std_logic_1164.all;

entity MODELNAME is
generic (timing : LMSI_TIMING_MEASUREMENT := DISABLED;
log : LMSI_LOG := DISABLED;
delay_type : LMSI_DELAY_TYPE := TYPICAL;
delay : LMSI_DELAY := ENABLED;
timing_violations : LMSI_TIMING_VIOLATIONS := DISABLED;
xprop : LMSI_XPROP := DISABLED;
xprop_method : LMSI_XPROP_METHOD := HIGH);

port (clk, siga, sigb : in STD_LOGIC;


address : in STD_LOGIC_VECTOR(15 downto 0);
data : inout STD_LOGIC_VECTOR( 7 downto 0);
interrupt : out STD_LOGIC;
reset : inout STD_LOGIC);
end MODELNAME;

Example 13-5 Entity Declaration for the MC68020 Model


library SYNOPSYS;
use SYNOPSYS.ATTRIBUTES.all;
library IEEE;
use IEEE.std_logic_1164.all;

entity MC68020 is
generic (timing : LMSI_TIMING_MEASUREMENT := DISABLED;
delay : LMSI_DELAY_TYPE := TYPICAL);
port (clk, cdis_b, avec_b, br_b, bgack_b, berror_b : in STD_LOGIC;
ipl_b : in STD_LOGIC_VECTOR( 2 downto 0);
dsack_b : in STD_LOGIC_VECTOR( 1 downto 0);
adr : out STD_LOGIC_VECTOR(31 downto 0);
siz : out STD_LOGIC_VECTOR( 1 downto 0);
funcode : out STD_LOGIC_VECTOR( 2 downto 0);
adrstrobe_b, datastrobe_b, readwrite_b : out STD_LOGIC;
rmc_b, dben_b : out STD_LOGIC;
ipend_b, bg_b, ecs_b, ocs_b : out STD_LOGIC;
data : inout STD_LOGIC_VECTOR(31 downto 0);
Reset_b, Halt_b : inout STD_LOGIC);
end MC68020;

Using Synopsys Models


13-26
The VHDL library and use clauses at the top of the file allow you to
access the types and attributes you plan to use in your VHDL code,
so the Simulator can communicate with the modeler.

Entity Name Restrictions


The entity name must meet the file naming restrictions of the OS that
is running on your platform. VCS MX requires that the entity name
match the device name.

Using Generics
You can use the generic clause in an entity declaration to

• Specify the source of the timing values passed from the Modeler
to the Simulator.
• Specify the delay type (minimum, typical, or maximum) the
Simulator will use at evaluation time.
• Enable or disable the propagation of unknown (’X’) values during
simulation.
• Determine the method used to propagate unknown (’X’) values.
• Enable or disable delay calculations, violation-reporting, and test-
vector logging.
Use the LM-family Shell Software files to control other settings, such
as the hostname of the target modeler.

The following sections describe the generics you can use with the
LM-family hardware modeler. If you do not specify a value for a
generic, the Simulator uses the default value. The Simulator reports
an error if you attempt to assign values other than the ones explained
below and defined in the SYNOPSYS.ATTRIBUTES package.

Using Synopsys Models


13-27
Specifying Timing Source
You can choose two sources of timing values for your simulation
session:

• Actual pin-to-pin timing measurements


• Timing measurements from a timing (.TMG) file
The following possible values of LMSI_TIMING_MEASUREMENT in
the generic clause select the timing source:

ENABLED
Modeler measures and records the actual pin-to-pin timing values
and passes them to the Simulator.
DISABLED
Modeler passes to the Simulator the pin-to-pin timing values from
the .TMG file. DISABLED is the default value of
LMSI_TIMING_MEASUREMENT.
Example 13-5 contains the following line:

generic (timing LMSI_TIMING_MEASUREMENT := DISABLED);

The actual identifier name (for example, timing) is not important. If


two or more identifiers have type LMSI_TIMING_MEASUREMENT,
the modeler issues a warning and uses the default value.

The MC68020 microprocessor example uses the pin-to-pin delay


values defined in the MC68020.TMG file rather than the actual
measured values.

Using Synopsys Models


13-28
Specifying Delay Type
At evaluation time, the modeler returns each pin value with three
delay values: minimum, typical, and maximum. The delay values can
come from a record of actual device timing measurements or from a
.TMG file, as explained in the previous section. By adding an identifier
of type LMSI_DELAY_TYPE to the generic clause of your entity
declaration, you can indicate which delay value the Simulator uses.

Table 13-1 lists the permitted values for the delay generic as defined
in the SYNOPSYS.ATTRIBUTES package.

Table 13-1 Delay Generic Types


Type Allowable Values
LMSI_DELAY_TYPE MINIMUM

TYPICAL (default)

MAXIMUM

For example, Example 13-5 has the following lines:

generic (timing : LMSI_TIMING_MEASUREMENT := DISABLED;


delay_type : LMSI_DELAY_TYPE := TYPICAL);

You select the actual identifier name (for example, delay_type). If two
or more identifiers have type LMSI_DELAY_TYPE, the modeler
issues a warning and uses the default value. Example 13-4 and
Example 13-5 use the TYPICAL delay (which is the default).

Turning ’X’ Propagation On and Off


You can use generics to control the propagation of Unknown (’X’)
values from input pins to output pins of LM-family hardware models.

Using Synopsys Models


13-29
A generic of type LMSI_XPROP in an entity declaration enables or
disables ’X’ propagation for all instances of that entity. (To turn ’X’
propagation on and off for specific pins, use the simulator command
lmsi xpropagation, described below.) By default, ’X’ propagation is
turned off.

Note:
An on_unknown statement in a Shell Software file overrides both
command-line and generic ’X’ propagation settings.

The entity declaration in Example 13-4 contains the following line:

generic (xprop : LMSI_XPROP := DISABLED);

With this setting, all instances of MODELNAME will have ’X’


propagation turned off.

The possible values for a generic of type LMSI_XPROP are


ENABLED and DISABLED.

The actual identifier you use to name the generic (in the example,
xprop) is not important. If two or more identifiers have type
LMSI_XPROP, the modeler issues a warning and uses the default
value.

Specifying the Propagation Method


When you enable ’X’ propagation, you can specify any of the four
methods used by LM-family modelers to propagate unknown values:
PREVIOUS, HIGH, LOW, and FLOAT. The default method is
PREVIOUS. See your modeler documentation for a description of the
propagation methods.

Using Synopsys Models


13-30
A generic of type LMSI_XPROP_METHOD in an entity declaration
determines the method of ’X’ propagation for all instances of that
entity.

The entity declaration in Example 13-4 contains the following line:

generic (xprop_method : LMSI_XPROP_METHOD := HIGH);

With this setting, the modeler will use the HIGH method when
propagating unknown values for all instances of MODELNAME.

The possible values for a generic of type LMSI_XPROP_METHOD


are PREVIOUS, HIGH, LOW, and FLOAT.

The actual identifier you use to name the generic (in the example,
xprop_method) is not important. If two or more identifiers have type
LMSI_XPROP_METHOD, the modeler issues a warning and uses
the default value.

Turning Delay Calculation On and Off


You can use generics to control whether the LM-family modeler
performs delay calculations. Disabling the calculations increases
simulation speed.

By default, delay calculation is enabled. When you turn delay


calculation off for a given device, the simulator assumes a unit delay
of one simulation time tick.

A generic of type LMSI_DELAY in an entity declaration determines


whether or not delay calculations are performed for all instances of
that entity. The entity declaration in Example 13-4 contains the
following line:

generic (delay : LMSI_DELAY := ENABLED);

Using Synopsys Models


13-31
With this setting, all instances of MODELNAME will have delay
calculation turned on.

The possible values for a generic of type LMSI_DELAY are


ENABLED and DISABLED.

The actual identifier you use to name the generic (in the example,
delay) is not important. If two or more identifiers have type
LMSI_DELAY, the modeler issues a warning and uses the default
value.

Turning Timing-Violation Reports On and Off


You can use generics to control whether the LM-family modeler
reports timing violations. Disabling the reports increases simulation
speed.

Note:
A report timing_violation statement in a Shell Software file
overrides both command-line and generic violation-reporting
settings.

By default, violation-reporting is enabled. A generic of type


LMSI_TIMING_VIOLATIONS in an entity declaration determines
whether or not timing violations are reported for all instances of that
entity. The entity declaration in Example 13-4 contains the following
line:

generic (timing_violations : LMSI_TIMING_VIOLATIONS :=


DISABLED);

With this setting, all instances of MODELNAME will have violation


reporting turned off.

Using Synopsys Models


13-32
The possible values for a generic of type
LMSI_TIMING_VIOLATIONS are ENABLED and DISABLED.

The actual identifier you use to name the generic (in the example,
timing_violations) is not important. If two or more identifiers have type
LMSI_TIMING_VIOLATIONS, the modeler issues a warning and
uses the default value.

Logging Test Vectors


You can use generics to control whether the LM-family modeler logs
test vectors. By default, test-vector logging is off.

The entity declaration in Example 1-1 contains the following line:

generic (log : LMSI_LOG := DISABLED);

With this setting, all instances of MODELNAME will have test-vector


logging turned off.

The possible values for a generic of type LMSI_LOG are ENABLED


and DISABLED.

The actual identifier you use to name the generic (in the example,
log) is not important. If two or more identifiers have type LMSI_LOG,
the modeler issues a warning and uses the default value.

Architecture Declaration
The attribute FOREIGN in an architecture declaration indicates to the
Analyzer (vhdlan) that the architecture is not fully described in
VHDL. The value of FOREIGN indicates which interface (LM-family
modeler, SmartModel, or VHPI) contains the complete architecture.

Using Synopsys Models


13-33
Example 13-6 shows the basic format of the architecture declaration
for an architecture in the LM-family modeler. The architecture
declaration is empty except for the attribute specification, which
instructs the Simulator to use the LM-family modeler.

Example 13-6 Basic Template for Architecture Declarations


architecture architecture of entity_name is
attribute FOREIGN of architecture: architecture is ”Synopsys:LMSI”;
begin
end;

You must use the attribute value "Synopsys:LMSI" for the LM-family
modeler; the value is case-insensitive.

Example 13-7 shows the architecture declaration for an MC68020


model. It demonstrates the case insensitivity of the FOREIGN
attribute value ”synopsys:lmsi”.

Example 13-7 Architecture Declaration for the MC68020 Model


library SYNOPSYS;
use SYNOPSYS.ATTRIBUTES.all;

architecture LMSI of MC68020 is


attribute FOREIGN of LMSI: architecture is ”synopsys:lmsi”;
begin
end;

Model Package
You can provide a package for defining constant values and declaring
components. Example 13-8 shows a package for the MC68020
model example.

Example 13-8 Package Used with the MC68020 Model


library SYNOPSYS;
use SYNOPSYS.ATTRIBUTES.all;
library IEEE;

Using Synopsys Models


13-34
use IEEE.std_logic_1164.all;

package LMSI_MC68020 is

-- basic timing info

constant CLK_PERIOD : TIME := 250 ns; -- 4 MHz clock


constant THOLD : TIME := 50 ns; -- data/addr hold time
constant BUS_ERROR_TIMEOUT : TIME := 20 * CLK_PERIOD; -- 20 clocks
--to bus error asserted

-- encoded ’size’ (from CPU)

constant LONG : STD_LOGIC_VECTOR := ”00” ; -- 32 bit access


-- (size = long word)
constant BYTE : STD_LOGIC_VECTOR := ”01” ; -- 8 bit access (size=byte)
constant WORD : STD_LOGIC_VECTOR := ”10” ; -- 16 bit access (size=word)
constant THREE_BYTE : STD_LOGIC_VECTOR := ”11” ; -- 24 bit access
-- (size = 3 bytes)

-- dsack response/control (to CPU)

constant ACK_LONG : STD_LOGIC_VECTOR :=”00” ; -- 32 bit response (dsack


-- long)
constant ACK_WORD : STD_LOGIC_VECTOR :=”01” ; -- 16 bit response (dsack
-- short)
constant ACK_BYTE : STD_LOGIC_VECTOR := ”10” ; -- 8 bit response (dsack
-- byte)
constant ACK_OFF : STD_LOGIC_VECTOR :=”11” ; -- undriven (dsack
undriven)

-- the 68020 component


-- note that port names must match the Shell Software MC68020.NAM file

component MC68020
generic (timing : LMSI_TIMING_MEASUREMENT := DISABLED;
delay : LMSI_DELAY_TYPE := TYPICAL);
port (clk,cdis_b,avec_b,br_b,bgack_b, berror_b : in STD_LOGIC;
ipl_b : in STD_LOGIC_VECTOR(2 downto 0);
dsack_b : in STD_LOGIC_VECTOR(1 downto 0);
adr : out STD_LOGIC_VECTOR(31 downto 0);
siz : out STD_LOGIC_VECTOR(1 downto 0);
funcode : out STD_LOGIC_VECTOR(2 downto 0);
adrstrobe_b, datastrobe_b, readwrite_b:out STD_LOGIC;
rmc_b, dben_b : out STD_LOGIC;
ipend_b, bg_b, ecs_b, ocs_b : out STD_LOGIC;
data : inout STD_LOGIC_VECTOR(31 downto 0);
Reset_b, Halt_b : inout STD_LOGIC);
end component;

Using Synopsys Models


13-35
end LMSI_MC68020;

Input Stimulus and Component Instantiation


You must provide input stimulus to initialize the model. Normally you
also include an instantiation of the component.

Example 13-9 shows declarations for input signals and their initial
values, their output signals, and the instantiation of a component, U0,
that uses these signals.

Example 13-9 Component Instantiation Used with the MC68020 Model


library SYNOPSYS;
use SYNOPSYS.ATTRIBUTES.all;
use SYNOPSYS.BV_ARITHMETIC.all;
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use WORK.LMSI_MC68020.all;

entity E is
end E;

architecture A of E is

-- inputs
signal clk : STD_LOGIC := ’0’ ; -- start off clock low
signal reset : STD_LOGIC := ’L’ ;
-- start off in reset mode
signal halt : STD_LOGIC := ’H’ ;-- ... with reset on, no halt
signal dsack : STD_LOGIC_VECTOR(1
downto 0) := ACK_OFF; -- data strobe
--ack (start ’OFF’)
signal data : STD_LOGIC_VECTOR(31 downto 0) := (others => ’Z’); -- data
-- bus

-- outputs
signal as : STD_LOGIC; -- address strobe
signal ds : STD_LOGIC; -- data strobe
signal rw : STD_LOGIC; -- read/write state (read = 1)
signal addr : STD_LOGIC_VECTOR(31 downto 0); -- address bus
signal size : STD_LOGIC_VECTOR(1 downto 0); -- cycle size

-- unused inputs

Using Synopsys Models


13-36
signal cdis : STD_LOGIC := ’L’ ; -- internal cache disabled
signal avec : STD_LOGIC := ’H’ ; -- no autovectors here!
signal berr : STD_LOGIC := ’H’ ; -- ... or bus errors
signal br : STD_LOGIC := ’H’ ; -- ... or bus requests
signal bgack : STD_LOGIC := ’H’ ; -- ... or bus grants
signal ipl : STD_LOGIC_VECTOR(2 downto 0) := (others => ’H’); --level 0

-- unused outputs
signal bg : STD_LOGIC; -- bus grant (n/u)
signal ecs,ocs : STD_LOGIC; -- ext/op cycle start (n/u)
signal rmc : STD_LOGIC; -- read/mod/write cycle (n/u)
signal dben : STD_LOGIC := ’H’; -- data bus enabled (n/u)
signal funcode : STD_LOGIC_VECTOR(2 downto 0);-process state info (n/u)
signal ipend : STD_LOGIC; -- interrupt pending (n/u)

for all : WORK.LMSI_MC68020.MC68020


use entity WORK.MC68020(LMSI);
begin

U0 : WORK.LMSI_MC68020.MC68020
generic map (ENABLED, MAXIMUM)
port map ( clk => clk, cdis_b => cdis, avec_b => avec,
br_b => br, bgack_b => bgack, berror_b => berr, ipl_b => ipl,
.
.
.

Processes
You can develop VHDL processes that simulate the support circuitry
of the model device. The MC68020 example provides processes in
the mc68020.vhd file to simulate the support circuitry for the
MC68020 microprocessor.

Example 13-10 shows the process clock that simulates the clock
signal circuitry for the MC68020. The LMSI_68020 package defines
the constant CLK_PERIOD.

Example 13-10 Clock Generation Process for the MC68020 Model


clock: process -- the clock (free running)
begin
clk <= ‘0’;

Using Synopsys Models


13-37
wait for CLK_PERIOD/2; -- 50% duty cycle on clock
clk <= ‘1’;
wait for CLK_PERIOD/2;
end process;
.
.
.

The microprocessor executes a program held in an array variable


that calculates the Fibonacci series. Example 13-11 shows the
beginning VHDL code in the process access_cycles that declares the
array variable MEMORY with the assembly instructions of the
program.

Example 13-11 Memory Image for the MC68020 Model


access_cycles: process
type T_MEMORY is array (0 to 100000) of STD_LOGIC_VECTOR(7
downto 0);

variable MEMORY : T_MEMORY :=


( "00000000", "00000000", "00010000", "00000000",
"00000000", "00000000", "00000000", "00001000",
"01001110", "01010110", "00000000", "00000000",
"11011111", "11111100", "11111111", "11111111",
.
.
.

Modifying LM-Family Shell Software Files

Shell Software refers to ASCII UNIX-level support files. When


simulation begins, the modeler expects the required Shell Software
files for each device in the modeler. Synopsys provides Shell
Software files to support its logic models.

Using Synopsys Models


13-38
You can modify the Shell Software files to incorporate the
VCS MX restrictions summarized in “Shell Software File Restrictions.”
You can also generate Shell Software files to support proprietary
designs you want to simulate in the hardware modeler with VCS MX.

Table 13-2 shows the LM-family Shell Software file organization and
naming scheme.

Table 13-2 LM-Family Shell File Summary


Required/
Filename Optional Description
ENTITY_NAME.MDL Required Contains the name of the device (component entity
name) and a list of LM-family Shell Software files
included in the simulation.
ENTITY_NAME.NAM Required Maps VHDL port names to the modeler device pin
names. VCS MX requires this file.
ENTITY_NAME.DEV Required Describes the device technology, speed, pin
attributes, and so forth. Also maps device pin
names to package pin numbers.
package.PKG Required Contains device packaging information. Also maps
package pin numbers to adapter pin names.
adapter.ADP Required Maps device adapter pin names to device adapter
net numbers with optional trace delay information.
name.TMG Optional Contains timing information.
name.OPT Optional Contains options definitions.

The UNIX environment variable LM_LIB specifies a path of one or


more directories to search for the Shell Software files. The modeler
searches the directories for all references to Shell Software files in
the following order:

1. The current working directory.


2. All directories in the LM_LIB path.

Using Synopsys Models


13-39
3. All immediate subdirectories of the directories in the LM_LIB path.
The environment variable LM_LIB is set when you source the
$VCS_HOME/admin/setup/environ.* file during installation. You can
modify LM_LIB to suite your environment. See the Hardware Models
documentation for an explanation of the host-specific syntax for
defining LM_LIB.

The following sections outline only the conventions and restrictions


for the Shell Software files. See Hardware Models documentation for
more information.

Shell Software File Restrictions


Synopsys imposes the following restrictions on the use of the LM-
family Shell Software files:

• The .NAM file is required when using the LM-family interface.


At the last level of mapping device pins to names, you must map
each pin name to a legal VHDL identifier.

The modeler can contain multiple mappings of names to a device


pin. The .NAM file contains the topmost (last) level of mapping
that you can use, and the .DEV file is one step of mapping below
the .NAM file. At the last level mapping from either the .NAM or
.DEV file, you must map each pin name to a legal VHDL identifier.

• At the last level of mapping, you must map the Shell Software-
defined pin names to names of all uppercase letters.

Using Synopsys Models


13-40
All objects in the Shell Software files are case-sensitive, while in
VHDL they are case-insensitive. Because VCS MX internally
maps all object names to uppercase letters, Synopsys requires
that all top level names be valid VHDL identifiers of all uppercase
letters.

• The device name in the model (.MDL) file, the base name of the
.MDL file, and the component entity name must be identical and
in uppercase letters.
VCS MX gets the entity name from the base name of the .MDL
file, not from the device_name parameter contained in the .MDL
file.

The .MDL File


The LM-family modeler requires an .MDL file for each device it
models. Synopsys requires that the base name of this file, the
component entity name, and the device name (device_name)
contained in this file are identical. Additionally, use uppercase for all
alphabetic characters in the filename.

The .MDL file serves as the header file for the Shell Software
description of the device. It holds the name of the device and the
names of all Shell Software files necessary for the simulation. The
Simulator accesses all device-specific information such as names,
timing, and technology through the .MDL file.

For example, the MC68020 entity declaration of Example 13-5 must


have a corresponding file, MC68020.MDL, shown in Example 13-12.

Example 13-12 MC68020 Model .MDL File


{********************************************************}
{* Copyright (c) 1988-1989 by Logic Modeling Systems, Inc. *}
{* All rights reserved. *}

Using Synopsys Models


13-41
{********************************************************}
{* Logic Model main MODEL file for Motorola MC68020 *}
{* 32-Bit Microprocessor *}
{********************************************************}
device_name MC68020
{--------------------------------------------------------}
{ model_revision A,B }
{ shell_revision B }
{--------------------------------------------------------}
physical ’MC68020.DEV’
timing ’MC68020A.TMG’ { 12.5MHz }
package ’PGA.PKG’ { 114 }
adapter ’PGA160.ADP’
options ’MC68020.OPT’
names ’MC68020.NAM’
{--------------------------------------------------------}

The .NAM File


VCS MX requires the .NAM file. The base name of this file is the same
as the .MDL file.

The .NAM file maps the device pin names in the modeler (specified
in the .DEV file) to legal VHDL identifiers you have in the port
specification of your VHDL entity statement. However, the names in
the .NAM file must be in uppercase letters.

Example 13-13 shows a portion of the .NAM file for the MC68020.

Example 13-13 Portion of MC68020 Model .NAM File


pin_name_mapping
.
.
.
{ input pins (in_pin) }
CLK = CLK
CDIS_B = ’-CDIS’
AVEC_B = ’-AVEC’
BR_B = ’-BR’

Using Synopsys Models


13-42
BGACK_B = ’-BGACK’
BERROR_B = ’-BERR’
IPL_B[2:0] = ’-IPL’[2:0]
DSACK_B[1:0] = ’-DSACK’[1:0]

{ output pins (out_pin) }


ADR[31:0] = A[31:0]
{ SIZ[1:0] = SIZ[1:0] }
FUNCODE[2:0] = FC[2:0]
RMC_B = ’-RMC’
ADRSTROBE_B = ’-AS’
DATASTROBE_B = ’-DS’
READWRITE_B = ’R/-W’
DBEN_B = ’-DBEN’
IPEND_B = ’-IPEND’
BG_B = ’-BG’
ECS_B = ’-ECS’
OCS_B = ’-OCS’

{ bidirectional pins (io_pin) }


DATA[31:0] = D[31:0]
RESET_B = ’-RESET’
HALT_B = ’-HALT’

{ power pins (power_pin) }


{ VCC = VCC }

{ ground pins (ground_pin) }


{ GND = GND }
.
.
.

The Simulator ignores comments (the text enclosed in braces.)

The name on the left side of each statement is the user-definable


name in the entity declaration in the VHDL model support file. The
alphabetic characters in the left side must be uppercase letters. A
portion of the model support file for the MC68020, mc68020.vhd, is
shown below:

Using Synopsys Models


13-43
library SYNOPSYS;
use SYNOPSYS.ATTRIBUTES.all;
library IEEE;
use IEEE.std_logic_1164.all;

entity MC68020 is
generic (timing : LMSI_TIMING_MEASUREMENT := DISABLED;
delay : LMSI_DELAY_TYPE := TYPICAL);
port (clk, cdis_b, avec_b, br_b, bgack_b, berror_b: in
STD_LOGIC;
ipl_b : in STD_LOGIC_VECTOR(2 downto 0);
dsack_b : in STD_LOGIC_VECTOR(1 downto 0);
adr : out STD_LOGIC_VECTOR(31 downto 0);
.
.
.

All name references in the .NAM file must exactly match those in the
LM-family Shell Software .DEV file.

You can assign vectors within the LM-family Shell Software in the
format:

name[n:m]

The identifier on the right side of the = sign is a name in the Logic
Modeling model and is defined in the .DEV file.

The interface directly translates vectors on the left-hand side of the


= sign to a signal of type std_logic_vector. The interface translates
any left side object that does not have brackets (for example,
ADRSTROBE_B and RESET_B) to a scalar signal of type std_logic.
No other signal types are available.

Using Synopsys Models


13-44
The order of the port names is not important; however, all pin names
you define in the port specification of the VHDL support file must
appear in the Shell Software files. Pin names must be in all uppercase
letters in the Shell Software files.

The last line in the example mapping CLK to CLK is not required but
is included here for clarity. If a name in the .DEV file does not require
mapping to another name, it need not appear in the .NAM file.

The .DEV File


The LM-family modeler requires the .DEV file. The base name of this
file is the same as the .MDL file.

Consult the LM-family hardware modeler manual for a list of required


and valid file statements. Logic Modeling provides this file with each
hardware model so you do not have to modify this file. You do have
to view the .DEV file to determine the pin names and pin numbers
you must map to the pin names in your VHDL support file. Place this
mapping in the .NAM file.

The .DEV file contains statements describing the following physical


characteristics of a device:

• Fabrication technology (for example, NMOS)


• Device speed
• Pin I/O characteristics
• Mappings for pin numbers to pin names and device pin numbers
to package pin numbers
Example 13-14 shows a portion of the .DEV file for the MC68020
model.

Using Synopsys Models


13-45
Example 13-14 Portion of MC68020 Model .DEV File
technology NMOS
{--------------------------------------------------------------------}
device_speed 8 MHz - 12.5 MHZ { MC68020RC12, MC68020RC16 }
device_setup_time 35 { parameter 48, 12.5MHz }
device_hold_time 20 { parameter 47B, 12.5MHz }
.
.
.
in_pin
CLK = C2 : store, keepalive { clock - 10MHz keepalive }
’-CDIS’ = H1 { cache disable }
.
.
.
out_pin
A[31:0] = A3, B4, C5, A4, B5, A5, C6, B6, { address bus }
A6, A7, C7, B7, A8, B8, C8, C9,
.
.
.
io_pin
D[31:0] = N1, L3, M2, N2, L4, M3, N3, M4, { data bus }
L5, N4, M5, N5, L6, M6, N6, M7,
.
.
.

The .PKG File


The hardware modeler requires the .PKG file. This file maps device
package pin numbers to device adapter pin names. The format is
described in the LM-family modeler documentation. The base name
of this file must be the name of the map file, for example PGA.PKG.

Logic Modeling provides this file with each hardware model so you
should not have to modify this file.

Example 13-15 shows a portion of the .PKG file for the MC68020
model.

Using Synopsys Models


13-46
Example 13-15 Portion of MC68020 Model .PKG File
package_mapping
A1 = A1
A2 = A2
A3 = A3
A6 = A6
A7 = A7
A8 = A8
A9 = A9
A10 = A10
A11 = A11
A12 = A12
A13 = A13
A14 = A14
A15 = A15

The .ADP File


The hardware modeler requires the .ADP file. This file maps device
adapter pin names to the device adapter net numbers. (The device
adapter physically holds the chip in the hardware modeler.) You may
also include trace delay information.

Logic Modeling provides this file with each hardware model, so you
do not have to modify it.

The base name of this file must be the name of the adapter map file,
for example, PGA160.ADP.

See the LM-family hardware modeler documentation for more


information on the .ADP file.

Example 13-16 shows a portion of the .ADP file for the MC68020
model.

Using Synopsys Models


13-47
Example 13-16 Portion of MC68020 Model .ADP File
adapter_mapping
A1 = 108 : trace_delay = 1.3663 {, cut_label=1 }
A2 = 95 : trace_delay = 1.1782 {, cut_label=160 }
A3 = 110 : trace_delay = 1.3611 {, cut_label=3 }
A4 = 92 : trace_delay = 1.3640 {, cut_label=5 }
A5 = 89 : trace_delay = 1.0955 {, cut_label=8 }
.
.
.

The .TMG File


The .TMG file is optional and provides information on propagation
delays for the device. You may select any base name for the file.

The LM-family hardware modeler provides the Simulator with


minimum, typical, and maximum propagation delays. The values can
come from the actual hardware device or from one or more .TMG
files. To define the source of the timing values, see “Specifying Timing
Source.”

In a .TMG file, you can assign the minimum, typical, and maximum
delays for pairs of pins: one input and one output. You can also assign
a default delay for any pair of pins not having an explicit delay.

You can generate a .TMG file from a simulation session to use in


future sessions by following this procedure:

1. Set the LMSI_TIMING_MEASUREMENT to ENABLED in the


generics section of the device VHDL support file. This setting
directs the modeler to measure the response timing of the actual
device and write the values to a .TIM file. (For more information
on LMSI_TIMING_MEASUREMENT, see “Specifying Timing
Source.”)
2. Use the LM-family utility lm to convert the .TIM file to a .TMG file.

Using Synopsys Models


13-48
Example 13-17 shows a portion of the .TMG file for the MC68020
model.

Example 13-17 Portion of MC68020 Model .TMG File


default_delay min 3, max 30
{----------------------------------------------------}
delay
from high(CLK)
to valid(A[31:0]) = 0, 40 { 6, 8 }
to float(A[31:0]) = 0, 80 { 7 }
to valid(FC[2:0]) = 0, 40 { 6, 8 }
to float(FC[2:0]) = 0, 80 { 7 }
to valid(SIZ[1:0]) = 0, 40 { 6, 8 }
to float(SIZ[1:0]) = 0, 80 { 7 }
to valid(‘-RMC’) = 0, 40 { 6, 8 }
to float(‘-RMC’) = 0, 80 { 7 }
to low(‘-ECS’) = 0, 30 { 6A }
to low(‘-OCS’) = 0, 30 { 6A }
to float(D[31:0]) = 0, 80 { 7 }
to valid(D[31:0]) = 0, 40 { 23, 53 }
to float(‘-AS’) = max 80 { 16 }
to float(‘-DS’) = max 80 { 16 }
to float(‘R/-W’) = max 80 { 16 }
to high(‘R/-W’) = 0, 40 { 18 }
to low(‘R/-W’) = 0, 40 { 20 }
to float(‘-DBEN’) = max 80 { 16 }
to low(‘-DBEN’) = 0, 40 { 40 }
to high(‘-DBEN’) = 0, 40 { 43 }
from low(CLK)
to low(‘-AS’) = 3, 40 { 9 }
.
.
.

Using Synopsys Models


13-49
The .OPT File
The options file provides control over operational modeler features,
such as reporting certain warning conditions and using a specific
modeler. The Simulator has no restrictions for this file, including the
base name. See the LM-family modeler documentation for more
information on the .OPT file.

Example 13-18 shows a template for the .OPT file.

Example 13-18 Template for MC68020 Model .OPT File


{*********************************************************************}
{*Copyright (c) 1988-9 by Logic Modeling,Inc. All rights reserved.}
{*********************************************************************}
{* Logic Model OPTIONS file for Motorola MC68020 * }
{* 32-Bit Microprocessor *
{*********************************************************************}
{* Data from M68000 Family Reference 1988 *}
{---------------------------------------------------------------------}
{ model_revision A,B }
{ shell_revision B }
{---------------------------------------------------------------------}
{modeler_name your_modeler}
{ultra_fast}
{report missing_delays on}
{report io_store_changes on}
{---------------------------------------------------------------------}

Analyzing and Linking the Design

After creating the VHDL model support files, analyze and link the files
with the rest of the VHDL design with the vhdlan utility.

Compiling the Design

After analyzing the VHDL files, compile the VHDL design with the
scs utility.

Using Synopsys Models


13-50
Simulating the Design

To simulate the design, invoke the Simulator (scsim).

When you simulate your design with the LM-family modeler, you can
use all the VCS MX commands for the VHDL portion of the design.

$LMSI Variable
The predefined simulator variable $LMSI equals the number of LM-
family modeler device instances in your design. For example, to
determine the number of LM-family modeler device instances in the
current design, at the Simulator prompt type

# echo $LMSI

Simulator and LM-Family Modeler Interaction

A simulation session with LM-family models has several steps:

• Initialization
• Instantiation
• Multiple evaluations
• Release of the hardware modeler
These steps are transparent to the user and are only provided here
for you to understand how the VHDL Simulator and LM-family
modeler operate together.

Using Synopsys Models


13-51
Initialization
The Simulator does not initialize an LM-family model until it needs to
instantiate the device in the simulation. This avoids time-consuming
interaction with the modeler.

The host system, Simulator, and modeler perform the following steps
at initialization:

• The host system (for example, Sun) environment provides the


hostname and username to initialize an LM-family model. If the
host system environment does not provide hostname and
username, the default value for both of these is vhdl.
• VCS MX provides the modeler with the base simulation time unit.
The TIMEBASE setup variable in the synopsys_sim.setup file
normally defines this value; the default value is NS
(nanoseconds.) However, you can set the base simulation time
unit on VCS MX compiler (scs) invocation command line with the
-time option.
• The modeler converts all user-specified LM-family Shell Software
delays to the equivalent number of simulation ticks. The modeler
internally resolves all timing information to units of 1 picosecond.
• The Simulator performs the mapping between std_logic and the
modeler logic values at initialization time. There are no weak-X,
undefined, or don’t-care (‘W’, ‘U’, and ‘-’, respectively) equivalent
to the IEEE 1164 values in the LM-family modeler. The Simulator
maps these three logic values to ‘X’ in the STD_LOGIC value set.

Using Synopsys Models


13-52
Instantiation
During the Simulator (scsim) instantiation phase, the Simulator first
defines then instantiates the device. Your design can contain multiple
instantiations of a single physical hardware device. Instantiation
requires that the host system environment provide the following
information:

• Name of the modeler assigned to the modeling session if two or


more modelers are on the network. The name is in the Shell
Software files.
• Name of the device found in the .MDL Shell file that you use as
the entity name in your VHDL design.
The LM-family modeler must physically contain the hardware model,
or the instantiation fails.

Evaluation
When the Simulator (scsim) determines that it has changed an input
to an instance of a device in the modeler, it begins the evaluation
process with the modeler.

For each model evaluation, VCS MX

1. Transmits each pin number and its associated new value to the
modeler.
2. Calls the modeler to get the value of each pin whose output has
subsequently changed.

Using Synopsys Models


13-53
The modeler returns the information for each pin including pin type,
value, and the minimum, typical, and maximum delay values. You
can assign the delay value you want VCS MX to use in the generic
entity declaration. For more information, see the “Specifying Timing
Source and Delay Type” section.

Release of Resources
At the end of simulation, VCS MX releases all host and modeler
resources and ends the modeling sessions. However, in the case of
an abnormal end to the simulator (for example, the host machine
crashes while VCS MX is running), the LM-family modeler does not
clear out its instance data. In this case, use the LM-family utility lm
to clear any invalid or old information. See the LM-family modeler
documentation for a description of this utility.

Error Messages

The Simulator receives error messages from the LM-family modeler


and formats them according to Synopsys’ standard error reporting
syntax:

SEVERITY_LEVEL: scsim[,error_number]:
From the Logic Modeling Logic Model Interface: LM_error_message

SEVERITY_LEVEL
Errors originating in the LM-family modeler or in associated files
generate error messages with two levels of severity: error and
warning. The two are described below:
**Error
The modeling session cannot continue, but the Simulator is still
running.

Warning

Using Synopsys Models


13-54
The modeling session can continue, but an error could occur later
in the simulation session.

[error_number]
Internal error number.
LM_error_message
This is the message generated by the modeler. These messages
use four different formats that identify the source of the error:
filename, line: message
The error is from the LM-family Software Shell.
message_only
The error is from the operation of the modeler.
internal simulator error: message
The error is from internal communications.
internal error: message
The error is from internal hardware or software.
The following example is an error message from VCS MX and the
modeler:

**Error: scsim,131:
From the Logic Modeling Logic Model Interface: unable to
find file

The next example is a warning from VCS MX and the modeler:

Warning: scsim,130:
From the Logic Modeling Logic Model Interface: Unable to
open directory for reading: /usr/synopsys/sparcOS5/sim/lm1000/models

Using Synopsys Models


13-55
LM-Family Modeler Example

This example uses Synopsys’s LM-1000 modeler and MC68020


microprocessor Logic Model. In this simulation, the Motorola
MC68020 microprocessor runs a compiled C program that generates
the first numbers of the Fibonacci series.

To run the simulation, you need Synopsys’s Logic Model for the
MC68020. If you do not have this model, you may still find it worthwhile
to read through the example to understand the procedures used with
the modeler.

You need two kinds of files to support the simulation by using the
modeler:

• VHDL model support files.


A VHDL model support file for this example (which you usually
provide) is in $VCS_HOME/doc/sim/examples/lmsi_if.

• LM-family Shell Software files.


Synopsys provides the LM-family Shell Software files with the LM-
family Logic Model.

Figure 13-2 shows the MC68020 chip and its related processes.
These processes, implemented in software on the Simulator,
represent the supporting circuitry of the MC68020.

Using Synopsys Models


13-56
Figure 13-2 Schematic Diagram of the MC68020 Model

32
/
Process: 3
access_cycles /
2
/

A{31,0}
DSACK

32
/ D{31,0}
FC{2,0}
SIZ{1,0}
MC6802

MC68020
Process:
reset_cpu
CLK AS

BERR

Process:
clock
Process:
bus_error

Using Synopsys Models


13-57
VHDL Model Support Files
This section gives a step-by-step description of the VHDL code
required to run a compiled C program on the MC68020 processor
model. This code includes

• Entity-architecture declaration
• Component declaration and instantiation statement
• Values for constants
• Input signal values (stimulus)
• All processes to run the program
Although these items can be in multiple files, Synopsys provides them
in a single file, mc68020.vhd, in the directory $VCS_HOME/doc/sim/
examples/lmsi_if.

LMSI_MC68020 Package
The example first defines the package LMSI_MC68020 that contains
values for constants and the component declaration for the part. The
port names (clk, cdis_b, and so forth) in the package match the names
in the MC68020.NAM Shell Software file.

library SYNOPSYS;
use SYNOPSYS.ATTRIBUTES.all;
library IEEE;
use IEEE.std_logic_1164.all;

package LMSI_MC68020 is

-- basic timing info

constant CLK_PERIOD : TIME := 250 ns; -- 4 MHz clock


constant THOLD : TIME := 50 ns; -- data/addr hold time
constant BUS_ERROR_TIMEOUT : TIME := 20 * CLK_PERIOD; -- 20 clocks to
bus error asserted

Using Synopsys Models


13-58
-- encoded ’size’ (from CPU)

constant LONG : STD_LOGIC_VECTOR := ”00” ; -- 32 bit access (size=long word)


constant BYTE : STD_LOGIC_VECTOR := ”01” ; -- 8 bit access (size=byte)
constant WORD : STD_LOGIC_VECTOR := ”10” ; -- 16 bit access (size=word)
constant THREE_BYTE : STD_LOGIC_VECTOR := ”11” ; -- 24 bit access (size = 3 byte)
-- dsack response/control (to CPU)

constant ACK_LONG : STD_LOGIC_VECTOR := ”00” ; -- 32 bit response (dsack long)


constant ACK_WORD : STD_LOGIC_VECTOR := ”01” ; -- 16 bit response (dsack short)
constant ACK_BYTE : STD_LOGIC_VECTOR := ”10” ; -- 8 bit response (dsack byte)
constant ACK_OFF : STD_LOGIC_VECTOR := ”11” ; -- undriven (dsack undriven)

-- the 68020 component


-- note that port names must match the Shell Software MC68020.NAM file

component MC68020
generic (timing : LMSI_TIMING_MEASUREMENT := DISABLED;
delay : LMSI_DELAY_TYPE := TYPICAL);
port (clk, cdis_b, avec_b, br_b, bgack_b, berror_b : in STD_LOGIC;
ipl_b : in STD_LOGIC_VECTOR(2 downto 0);
dsack_b : in STD_LOGIC_VECTOR(1 downto 0);
adr : out STD_LOGIC_VECTOR(31 downto 0);
siz : out STD_LOGIC_VECTOR(1 downto 0);
funcode : out STD_LOGIC_VECTOR(2 downto 0);
adrstrobe_b, datastrobe_b, readwrite_b : out STD_LOGIC;
rmc_b, dben_b : out STD_LOGIC;
ipend_b, bg_b, ecs_b, ocs_b : out STD_LOGIC;
data : inout STD_LOGIC_VECTOR(31 downto 0);
Reset_b, Halt_b : inout STD_LOGIC);
end component;

end LMSI_MC68020;

Entity and Architecture Declarations


Next are the entity and architecture declarations. The architecture
declaration uses the attribute FOREIGN with the value
SYNOPSYS:LMSI to interface the Simulator with the LM-family
modeler.

library SYNOPSYS;
use SYNOPSYS.ATTRIBUTES.all;
library IEEE;

Using Synopsys Models


13-59
use IEEE.std_logic_1164.all;

entity MC68020 is
generic (timing : LMSI_TIMING_MEASUREMENT := DISABLED;
delay : LMSI_DELAY_TYPE := TYPICAL);
port (clk, cdis_b, avec_b, br_b, bgack_b, berror_b : in STD_LOGIC;
ipl_b : in STD_LOGIC_VECTOR(2 downto 0);
dsack_b : in STD_LOGIC_VECTOR(1 downto 0);
adr : out STD_LOGIC_VECTOR(31 downto 0);
siz : out STD_LOGIC_VECTOR(1 downto 0);
funcode : out STD_LOGIC_VECTOR(2 downto 0);
adrstrobe_b, datastrobe_b, readwrite_b : out STD_LOGIC;
rmc_b, dben_b : out STD_LOGIC;
ipend_b, bg_b, ecs_b, ocs_b : out STD_LOGIC;
data : inout STD_LOGIC_VECTOR(31 downto 0);
Reset_b, Halt_b : inout STD_LOGIC);
end MC68020;

library SYNOPSYS;
use SYNOPSYS.ATTRIBUTES.all;
architecture LMSI of MC68020 is
attribute FOREIGN of LMSI : architecture is “SYNOPSYS:LMSI”;
begin
end;

Component Instantiation and Input Stimulus


The last code is the testbench. It instantiates the component U0 and
declares its input signals with initial values and output signals.
Processes provide the input stimulus that mimic the support circuitry
of the microprocessor.

The top-level entity is empty. The first portion of the architecture


defines the initial values of all the in and inout ports.

library SYNOPSYS;
use SYNOPSYS.ATTRIBUTES.all;
use SYNOPSYS.BV_ARITHMETIC.all;
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use WORK.LMSI_MC68020.all;

entity E is
end E;

Using Synopsys Models


13-60
architecture A of E is

-- inputs
signal clk : STD_LOGIC := ’0’ ; -- start off clock low
signal reset : STD_LOGIC := ’L’ ; -- start off in reset mode
signal halt : STD_LOGIC := ’H’ ; -- ... with reset on, no halt
signal dsack : STD_LOGIC_VECTOR(1 downto 0) := ACK_OFF; -- data strobe ack
(start ’OFF’)
signal data : STD_LOGIC_VECTOR(31 downto 0):=(others => ’Z’);--data bus

-- outputs
signal as : STD_LOGIC; -- address strobe
signal ds : STD_LOGIC; -- data strobe
signal rw : STD_LOGIC; -- read/write state (read = 1)
signal addr : STD_LOGIC_VECTOR(31 downto 0); -- address bus
signal size : STD_LOGIC_VECTOR(1 downto 0); -- cycle size

-- unused inputs
signal cdis : STD_LOGIC := ’L’ ; -- internal cache disabled
signal avec : STD_LOGIC := ’H’ ; -- no autovectors here!
signal berr : STD_LOGIC := ’H’ ; -- ... or bus errors
signal br : STD_LOGIC := ’H’ ; -- ... or bus requests
signal bgack : STD_LOGIC := ’H’ ; -- ... or bus grants
signal ipl : STD_LOGIC_VECTOR(2 downto 0) := (others => ’H’); --level 0

-- unused outputs
signal bg : STD_LOGIC; -- bus grant (n/u)
signal ecs,ocs : STD_LOGIC; -- ext/op cycle start (n/u)
signal rmc : STD_LOGIC; -- read/mod/write cycle (n/u)
signal dben : STD_LOGIC := ’H’; -- data bus enabled (n/u)
signal funcode :STD_LOGIC_VECTOR(2 downto 0);--process state info (n/u)
signal ipend : STD_LOGIC; -- interrupt pending (n/u)

for all : WORK.LMSI_MC68020.MC68020


use entity WORK.MC68020(LMSI);
begin

U0 : WORK.LMSI_MC68020.MC68020
generic map (ENABLED, MAXIMUM)
port map ( clk => clk, cdis_b => cdis, avec_b => avec,
br_b => br, bgack_b => bgack, berror_b => berr, ipl_b => ipl,
dsack_b => dsack, adr => addr, siz => size,
funcode => funcode, rmc_b => rmc, adrstrobe_b => as,
datastrobe_b => ds, readwrite_b => rw, dben_b => dben,
ipend_b => ipend, bg_b => bg, ecs_b => ecs,
ocs_b => ocs, data => data,
reset_b => reset, halt_b => halt);

Using Synopsys Models


13-61
The input stimulus consists of processes that mimic the support
circuitry around the MC68020 chip. The support circuitry is

• A clock signal generator


• Reset circuitry
• A bus error monitor
• Memory bus support
An array variable stores the memory image of the C program the
microprocessor executes.

Process clock
The process clock runs continuously and generates a 4 MHz square
wave, illustrated in Figure 13-3.

clock: process -- the clock (free running)


begin
clk <= ’0’;
wait for CLK_PERIOD/2; -- 50 % duty cycle on clock
clk <= ’1’;
wait for CLK_PERIOD/2;
end process;

Figure 13-3 Waveform for Process clock

CLK_PERIOD / 2 250 ns

Using Synopsys Models


13-62
Process reset_cpu
The process reset_cpu provides the reset sequence to initialize the
internal circuitry of the MC68020. Figure 13-4 shows the waveform
for process reset_cpu.

reset_cpu: process -- reset processor (runs once only)


begin
assert FALSE
report ”Start of initial CPU reset”
severity NOTE;
reset <= ’L’;
halt <= ’H’;
wait for 521 * CLK_PERIOD;
reset <= ’H’;
assert FALSE
report ”End of initial CPU reset”
severity NOTE;
wait;
end process;

Figure 13-4 Waveform for Process reset_cpu

CLK ...

RESET
...
521 Clocks = Reset Interval

Using Synopsys Models


13-63
Process bus_error
The process bus_error monitors the signal AS for two conditions. If
AS is low (asserted) for too long (defined by
BUS_ERROR_TIMEOUT), the process prints the message BUS
ERROR!!! and stops the simulation. If AS is high (not asserted) for
too long (again defined by BUS_ERROR_TIMEOUT), the process
assumes the simulation is over. In this example, this condition only
occurs after the MC68020 executes a STOP instruction.

bus_error: process
begin
if RESET = ’H’ then
wait until AS’STABLE(BUS_ERROR_TIMEOUT);
if AS = ’0’ then
assert FALSE
report ”BUS ERROR!!!”
severity ERROR;
else
assert FALSE
report ”END OF RUN”
severity ERROR;
end if;
else
wait until RESET = ’H’;
end if;
end process;

Process access_cycles
The last process, access_cycles, handles CPU read bus cycles and
write bus cycles. This process includes

• The memory array that contains an assembled MC68020


program.
• A utility function to convert an object of type std_logic_vector (the
value on the address bus) to integer.

Using Synopsys Models


13-64
• Two procedures, read_from_data_bus and write_to_data_bus,
that read and write the MC68020 data bus.
The first part of access_cycles declares the memory array MEMORY
and initializes the array with the assembly code that runs on the Logic
Modeling MC68020 hardware board. The program generates the first
numbers in the Fibonacci series. The C code for the program is

int LOOP_COUNT = 20;


long *BREAKPOINT = (long *) 0x7FF0;
FIB_VALUE_1 = 1;
FIB_VALUE_2 = 1;
while (LOOP_COUNT = LOOP_COUNT - 2)
{ FIB_VALUE_1 += FIB_VALUE_2;
NEXT = FIB_VALUE_1;
FIB_VALUE_2 += FIB_VALUE_1;
NEXT = FIB_VALUE_2;
}
if (*BREAKPOINT);

The corresponding MC68020 assembly code is

link a6,#0
add #-LF12,sp
movem #LS12,sp@
movl #0x14,LOOP_COUNT
movl #0x7ff0,BREAKPOINT
movl #0x1,FIB_VALUE_1
movl #0x1,FIB_VALUE_2
L14: subql #0x2,LOOP_COUNT
tstl LOOP_COUNT
jeq L15
movl FIB_VALUE_2,d0
addl d0,FIB_VALUE_1
movl FIB_VALUE_1,NEXT
movl FIB_VALUE_1,d0
addl d0,FIB_VALUE_2
movl FIB_VALUE_2,NEXT
jra L14
L15: movl BREAKPOINT,a0

Using Synopsys Models


13-65
tstl a0@
jeq L16
L16: moveq #0,d0
unlk a6
stop #0

Code for the process access_cycles starts below.

access_cycles: process
type T_MEMORY is array (0 to 100000) of STD_LOGIC_VECTOR(7 downto 0);
variable MEMORY : T_MEMORY := (
”00000000”, ”00000000”, ”00010000”, ”00000000”,
”00000000”, ”00000000”, ”00000000”, ”00001000”,
”01001110”, ”01010110”, ”00000000”, ”00000000”,
”11011111”, ”11111100”, ”11111111”, ”11111111”,
”11111111”, ”11101100”, ”01001000”, ”11010111”,
”00000000”, ”00000000”, ”00101101”, ”01111100”,
”00000000”, ”00000000”, ”00000000”, ”00001110”,
”11111111”, ”11110100”, ”00101101”, ”01111100”,
”00000000”, ”00000000”, ”01111111”, ”11110000”,
”11111111”, ”11101100”, ”00101101”, ”01111100”,
”00000000”, ”00000000”, ”00000000”, ”00000001”,
”11111111”, ”11111100”, ”00101101”, ”01111100”,
”00000000”, ”00000000”, ”00000000”, ”00000001”,
”11111111”, ”11111000”, ”01010101”, ”10101110”,
”11111111”, ”11110100”, ”01001010”, ”10101110”,
”11111111”, ”11110100”, ”01100111”, ”00011110”,
”00100000”, ”00101110”, ”11111111”, ”11111000”,
”11010001”, ”10101110”, ”11111111”, ”11111100”,
”00101101”, ”01101110”, ”11111111”, ”11111100”,
”11111111”, ”11110000”, ”00100000”, ”00101110”,
”11111111”, ”11111100”, ”11010001”, ”10101110”,
”11111111”, ”11111000”, ”00101101”, ”01101110”,
”11111111”, ”11111000”, ”11111111”, ”11110000”,
”01100000”, ”11011000”, ”00100000”, ”01101110”,
”11111111”, ”11101100”, ”01001010”, ”10010000”,
”01001110”, ”01110001”, ”01110000”, ”00000000”,
”01001110”, ”01011110”, ”01001110”, ”01110010”,
”00000000”, ”00000000”, ”00000000”, ”00000000”,
”00000000”, ”00000000”, ”00000000”, ”00000100”,
”00000101”, ”00000000”, ”00000000”, ”00000000”,
”00000000”, ”00000000”, ”00000000”, ”00000000”,
”00000000”, ”00000000”, ”00000000”, ”00001010”,
”01011111”, ”01101101”, ”01100001”, ”01101001”,
”01101110”, ”00000000”, others => ”00000000”
);

Using Synopsys Models


13-66
variable offset : integer range MEMORY’RANGE;

function CONV_INT(a_bus : in UNSIGNED(31 downto 0)) return INTEGER is


begin
return ((CONV_INTEGER(a_bus(31 downto 1))*2)+CONV_INTEGER(a_bus(0)));
end CONV_INT;

The next segment of access_cycles defines the procedure


read_from_data_bus in the access_cycles process. The procedure

• Reads the data from the data pins of the MC68020 (placed there
by write_to_data_bus during a CPU write cycle.)
• Breaks the data into one, two, or four 8-bit bytes that depends on
the value of the signal size.
• Stores the data in the memory array MEMORY starting at address
offset.
• Drives the signal dsack with the appropriate value that depend on
the signal size.
• Waits until the address strobe is de-asserted (AS high), then prints
an informational assert statement and returns.
Two error conditions are possible if the value of size is not BYTE,
WORD, or LONG. If either errors occur, read_from_data_bus prints
an error message and terminates the simulation.

procedure read_from_data_bus is
begin

case size is

when LONG =>


MEMORY(offset) := data(31 downto 24);
MEMORY(offset+1) := data(23 downto 16);
MEMORY(offset+2) := data(15 downto 8);
MEMORY(offset+3) := data( 7 downto 0);
dsack <= ACK_LONG;

Using Synopsys Models


13-67
when WORD =>
MEMORY(offset) := data(15 downto 8);
MEMORY(offset+1) := data( 7 downto 0);
dsack <= ACK_WORD;

when BYTE =>


MEMORY(offset) := data(7 downto 0);
dsack <= ACK_BYTE;

when THREE_BYTE =>


assert FALSE
report ”Length of read is 24 bits -- out of luck”
severity ERROR;

when others =>


assert FALSE
report ”Length of read is unknown”
severity ERROR;
end case;
wait until AS = ’1’;
assert FALSE
report ”end of CPU write cycle”
severity NOTE;
end read_from_data_bus;
The next code segment of access_cycles defines the procedure
write_to_data_bus. This is the converse of
read_from_data_bus. The procedure

• Reads the data from the array MEMORY.


• Assembles it to the appropriate length according to size.
• Drives the data pins of the MC68020.
• Drives the signal dsack with the value of the signal size.
• Waits until the address and data strobes are de-asserted (both
AS and DS high, then de-asserts the signal dsack.
• Drives the data bus to high impedance.

Using Synopsys Models


13-68
• Prints an informational assert statement and returns.
The same when in the first case statement handles both WORD and
LONG CPU read cycles because of dynamic bus sizing in the
MC68020 processor. Error conditions are possible if

• The value of size is not BYTE, WORD, or LONG.


• The encoded processor state of signal funcode does not indicate
either an opcode or a data fetch.
In either case, the process prints an error message and terminates
the simulation.

procedure write_to_data_bus is
begin
case size is

-- drive upper and lower halves of data bus


-- with the same 16-bit word
when WORD | LONG =>
data <= MEMORY(offset) & MEMORY(offset+1) &
MEMORY(offset) & MEMORY(offset+1);
wait for THOLD;
dsack <= ACK_WORD;

-- drive all four bytes of the data bus


-- with the same 8-bit byte
when BYTE =>
data <= MEMORY(offset) & MEMORY(offset) &
MEMORY(offset) & MEMORY(offset);
wait for THOLD;
dsack <= ACK_BYTE;

when others =>


assert FALSE
report ”Length of value not 8, 16, or 32”
severity ERROR;
end case;

Using Synopsys Models


13-69
wait until AS = ’1’ and DS = ’1’;
dsack <= ACK_OFF;
data <= ”ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ” after 5 ns;
case funcode is

when ”110” =>


assert FALSE
report ”end CPU supervisor opcode fetch”
severity NOTE;
when ”101” =>
assert FALSE
report ”end CPU supervisor data fetch”
severity NOTE;
when others =>
assert FALSE
report ”end CPU read cycle (unknown cycle type)”
severity NOTE;
end case;
end write_to_data_bus;

Finally, below is the main body of the process access_cycles. It waits


for an access cycle to begin (both AS and DS asserted), and calls
write_to_data_bus if signal rw is asserted, or read_from_data_bus if
rw is de-asserted. This code is the last code segment for process
access_cycles and the end of the definition for architecture A.

begin
wait until as = ’0’ and ds = ’0’;
offset := CONV_INT(UNSIGNED(addr));

if (rw = ’1’) then

assert FALSE
report ”Start CPU read cycle”
severity NOTE;
write_to_data_bus;
else
assert FALSE
report ”Start CPU write cycle”
severity NOTE;

Using Synopsys Models


13-70
read_from_data_bus;
end if;

end process;
end;

Using Synopsys Models


13-71
LM-Family Shell Software Files
Synopsys supplies the LM-family Shell Software files with the Logic
Modeling MC68020 Logic Model. The files for the example are in
$VCS_HOME/doc/sim/examples/lmsi_if. The functions of the
Software Shell files are

MC68020.MDL
Contains the device name and a list of the LM-family Shell
Software files included in the model simulation. The device name,
the base name of the .MDL file, and the component entity name
are identical and in uppercase letters.
MC68020.NAM
Maps VHDL port names to the modeler device pin names. This
file is required by VCS MX.
MC68020.DEV
Describes the model device for technology, device speed, device
pin attributes, and so forth. Maps device pin numbers to package
pin numbers.
PGA.PKG
Contains device packaging information. Maps package pin
numbers to adapter pin names.
PGA160.ADP
Maps device adapter pin names to device adapter net numbers
(with optional trace delay information.)
MC68020.TMG
Contains timing information.
MC68020.OPT
The simulation does not use this file.
When simulating other LM-family Logic Models, you may have to
modify the Shell Software files to conform to Synopsys’ restrictions.

Using Synopsys Models


13-72
For a discussion of these restrictions, see the “Modifying LM-Family
Shell Software Files” section.

Verifying the Modeler Connection and Shell Software


Install the Shell Software files following the instructions in the Logic
Modeling documentation. The steps below use Synopsys’s lm utility.
For more information on this utility, see the Logic Modeling
documentation.

Note:
If you have not done so already, copy the files for the examples
from the installation examples directory ($VCS_HOME/doc/sim/
examples) to your local examples directory.

1. Move to your home directory, then move to the lmsi_if subdirectory


of your local examples directory. Type
% cd
% cd examples/lmsi_if

2. Clean the example directory in case another user has run the
example. Type
% make clean

3. Create a WORK directory where the Analyzer will place your


analyzed design files. Type
% mkdir WORK

4. Check that all the required LM-family Shell Software files are in
your current directory. Type
% ls -a

The following files and directories should appear in your listing:

Using Synopsys Models


13-73
MC68020A.TMG Makefile
synopsys_sim.setup PGA.PKG
MC68020.DEV PGA160.ADP
MC68020.MDL WORK/
MC68020.NAM mc68020.inc
MC68020.OPT mc68020.vhd

5. Make sure that the LM-family modeler is connected and running


by typing
% lm show_logic_models

The system responds

”lmsi” Logic Models

Logic Model Location Device Simulator Adapter Dev. Rev.


Status Instances Type

DIAGNOSTIC_ADAPTER A0 PUBLIC 0 / 0 DIAG LMSI A


MC68020 A1 - B1 PUBLIC 1 / 0 PGA160 LMSI B

Available Slots: B0

This response confirms that the modeler is able to communicate


with the host system, and that the correct model is loaded into the
LM-1000. Your system response may vary because of other
models you have in the modeler. If this step fails, see the Logic
Modeling documentation for more information.

6. Verify that no semantic or syntactic errors are in the Shell Software


files listed in the MC68020.MDL file by typing
% lm check -f MC68020.MDL

The system responds

Model ”MC68020.MDL” checked with no errors and no warnings

Using Synopsys Models


13-74
If any errors exist, you must correct them before running the
Analyzer.

Analyzing the VHDL Support Files


Use the Analyzer invocation command vhdlan to analyze the VHDL
support files.

1. Analyze the VHDL model support file by typing


% vhdlan mc68020.vhd

The VHDL Analyzer version number and copyright notice are


displayed, the source file is analyzed, and you are returned to the
prompt.

2. Check that the Analyzer has produced .sim and .mra files required
for the simulation by listing the files in your WORK directory. Type
% ls WORK

The following files appear:

E.mra
E.sim
E_ _A.sim
LMSI_MC68020.sim
MC68020.mra
MC68020.sim
MC68020_ _LMSI.sim

Compiling the MC68020 Logic Model


Use VCS MX compiler invocation command scs to sompile the
design.

1. Compile the VHDL model support file by typing

Using Synopsys Models


13-75
% scs -time NS E

The Compiler version number and copyright notice are displayed,


the design is compiled, and you are returned to the prompt.

2. Check that the VCS MX compiler has produced scsim

Simulating the MC68020 Logic Model


You can use the make command to setup this exercise automatically.
You then type run at the Simulator prompt to simulate the
demonstration. However, to get a good understanding of the exercise,
manually execute the steps in this section.

For the first part of the simulation (the reset cycle), the Simulator
monitors all CPU signals except the clock. The reset cycle takes
130,250 ns (521 clock cycles.) The initial output (at 0 ns) is the
initialization of the model. The output after 130,250 ns, is the
deassertion of the reset line on the MC68020. After the reset, this
example lists the first few MC68020 cycles.

1. Start up the Simulator by typing


% scsim

The system prints the copyright notice and a message similar to


the following:

Warning: scsim,130:
From the Logic Modeling Logic Model interface: device_name
MC68020: store pins will be played at a maximum device_speed of 7.35 MHz
(Message Number: 379)
Warning: scsim,130:
From the Logic Modeling Logic Model interface: device_name
MC68020: Device being modeled with a pattern clock of 14.71 MHz to
guarantee 35 ns setup time and 20 ns hold time; actual setup time 35 ns
and hold time 20 ns (Message Number: 377)
#

Using Synopsys Models


13-76
The warning comes directly from the LM-1000 modeler and is a
consequence of using the LM-family Shell Software. Continue
with the simulation.

2. Turn on monitors for all input and output signals of the MC68020
microprocessor by typing
# monitor -c -active /E/*’signal

3. List the monitors you have created by typing


# monitor -list *

The system displays all the monitors you have created:

M22 CE ACTIVE /E/IPEND


M21 CE ACTIVE /E/FUNCODE
M20 CE ACTIVE /E/DBEN
M19 CE ACTIVE /E/RMC
M18 CE ACTIVE /E/OCS
M17 CE ACTIVE /E/ECS
M16 CE ACTIVE /E/BG
M15 CE ACTIVE /E/IPL
M14 CE ACTIVE /E/BGACK
M13 CE ACTIVE /E/BR
M12 CE ACTIVE /E/BERR
M11 CE ACTIVE /E/AVEC
M10 CE ACTIVE /E/CDIS
M9 CE ACTIVE /E/SIZE
M8 CE ACTIVE /E/ADDR
M7 CE ACTIVE /E/RW
M6 CE ACTIVE /E/DS
M5 CE ACTIVE /E/AS
M4 CE ACTIVE /E/DATA
M3 CE ACTIVE /E/DSACK
M2 CE ACTIVE /E/HALT
M1 CE ACTIVE /E/RESET
M CE ACTIVE /E/CLK
#

Using Synopsys Models


13-77
4. Delete the clock monitor by typing
# monitor -delete m

5. Next, reset the MC68020 processor by holding the reset line low
for 521 clock cycles or 130,250 ns. You will simulate an additional
750 ns to allow the microprocessor to drive the address and data
strobes (AS and DS). Also, during this 750 ns, the address bus
and associated control signals (SIZn, RMC, FCn, R/W, and An)
are preparing for the first read cycle.
To start the simulation, type

# set base binary


# run 131000

The Simulator lists the value of all signals at time 0 ns because


of the initialization process within both the Simulator and the LM-
family modeler.

The system responds

0 NS
Assertion NOTE at 0 NS in design unit A from process /E/RESET_CPU:
”Start of initial CPU reset”
M22: ACTIVE /E/IPEND (value = ’1’)
M8: ACTIVE /E/ADDR (value = ”ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ”)
M18: ACTIVE /E/OCS (value = ’1’)
M9: ACTIVE /E/SIZE (value = ”ZZ”)
M21: ACTIVE /E/FUNCODE (value = ”ZZZ”)
M16: ACTIVE /E/BG (value = ’1’)
M19: ACTIVE /E/RMC (value = ’Z’)
M17: ACTIVE /E/ECS (value = ’1’)
M20: ACTIVE /E/DBEN (value = ’Z’)
M6: ACTIVE /E/DS (value = ’Z’)
M7: ACTIVE /E/RW (value = ’Z’)
M5: ACTIVE /E/AS (value = ’Z’)
M4: ACTIVE /E/DATA (value = ”ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ”)
M1: ACTIVE /E/RESET (value = ’L’)
M2: ACTIVE /E/HALT (value = ’H’)
130250 NS
Assertion NOTE at 130250 NS in design unit A from process /E/RESET_CPU:

Using Synopsys Models


13-78
”End of initial CPU reset”
M1: ACTIVE /E/RESET (value = ’H’)
130665 NS
M8: ACTIVE /E/ADDR (value = ”00000000000000000000000000000000”)
M9: ACTIVE /E/SIZE (value = ”00”)
M21: ACTIVE /E/FUNCODE (value = ”110”)
M19: ACTIVE /E/RMC (value = ’1’)
M7: ACTIVE /E/RW (value = ’1’)
130790 NS
M6: ACTIVE /E/DS (value = ’1’)
M5: ACTIVE /E/AS (value = ’1’)
131000 NS
#
In the next step you examine the first read cycles. Running the
simulation for an additional 4,000 ns produces considerably more
output. Items to look for are

- The asynchronicity of the MC68020 bus accesses (the times


are not even.)
- The nonsimultaneous change of the address bus value while
AS is not asserted.
- The changing states of the signal, particularly AS, DS, and
DSACKn.
- The various assertion notes.
6. Type % run 4000
The system responds

132390 NS
M17: ACTIVE /E/ECS (value = ’0’)
M18: ACTIVE /E/OCS (value = ’0’)
132415 NS
M20: ACTIVE /E/DBEN (value = ’1’)
132506 NS
M6: ACTIVE /E/DS (value = ’0’)
132507 NS
M17: ACTIVE /E/ECS (value = ’1’)
M5: ACTIVE /E/AS (value = ’0’)
Assertion NOTE at 132507 NS in design unit A from process /E/ACCESS_CYCLES
“Start CPU read cycle”

Using Synopsys Models


13-79
M4: ACTIVE /E/DATA (value = “00000000000000000000000000000000”)
132508 NS
.
.
Assertion NOTE at 134757 NS in design unit A from process /E/ACCESS_CYCLES
“end CPU supervisor opcode fetch”
M3: ACTIVE /E/DSACK (value = “11”)
134762 NS
M4: ACTIVE /E/DATA (value = “ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ”)
134889 NS
M17: ACTIVE /E/ECS (value = ’0’)
134890 NS
M9: ACTIVE /E/SIZE (value = “10”)
134891 NS
M8: ACTIVE /E/ADDR (value = “00000000000000000000000000000110”)
135000 NS
#
In the next step you delete the current monitors and create new
ones to show

- Reads and writes to memory.


- Stack pushes and pops (high addresses) of data saved on the
return and local variable stacks.
- Reads of the program memory (low addresses) as the CPU
fetches instructions.
Command file mc68020.inc has the commands to display these
values.

7. Delete the current monitors and include this file by typing


# monitor -delete *

8. Run the simulation for 3000 ns more by typing # run 3000


The system responds

135006 NS
Assertion NOTE at 135006 NS in design unit A from process /E/ACCESS_CYCLES
”Start CPU read cycle”
135507 NS

Using Synopsys Models


13-80
Assertion NOTE at 135507 NS in design unit A from process /E/ACCESS_CYCLES
”end CPU supervisor opcode fetch”
136757 NS
Assertion NOTE at 136757 NS in design unit A from process /E/ACCESS_CYCLES
”Start CPU read cycle”
137258 NS
Assertion NOTE at 137258 NS in design unit A from process /E/ACCESS_CYCLES
“end CPU supervisor opcode fetch”
137506 NS
Assertion NOTE at 137506 NS in design unit A from process /E/ACCESS_CYCLES
”Start CPU read cycle”
138000 NS

The final run starts producing output around 138,000 ns and


continues until LOOP_COUNT < 0.

9. Type in
# run

The system responds

138007 NS
Assertion NOTE at 138007 NS in design unit A from process /E/ACCESS_CYCLES
”end CPU supervisor opcode fetch”
138756 NS
Assertion NOTE at 138756 NS in design unit A from process /E/ACCESS_CYCLES
”Start CPU read cycle”
139257 NS
Assertion NOTE at 139257 NS in design unit A from process /E/ACCESS_CYCLES
”end CPU supervisor opcode fetch”
139506 NS
Assertion NOTE at 139506 NS in design unit A from process /E/ACCESS_CYCLES
”Start CPU read cycle”
140007 NS
Assertion NOTE at 140007 NS in design unit A from process /E/ACCESS_CYCLES
”end CPU supervisor opcode fetch”
141000 NS

Finally, around 419,000 ns, the simulation is over. The last few
lines printed are

413257 NS
Assertion NOTE at 413257 NS in design unit A from process /E/ACCESS_CYCLES
”end CPU supervisor data fetch”

Using Synopsys Models


13-81
413506 NS
Assertion NOTE at 413506 NS in design unit A from process /E/ACCESS_CYCLES
”Start CPU read cycle”
414007 NS
Assertion NOTE at 414007 NS in design unit A from process /E/ACCESS_CYCLES
”end CPU supervisor data fetch”
419007 NS
Assertion ERROR at 419007 NS in design unit A from process /E/BUS_ERROR:
”END OF RUN”
#

10. Quit the simulation by typing


# quit

You return to the operating system.

Using Synopsys Models


13-82
A
Backannotating with SDF Files A
You can backannotate timing information from files in Standard Delay
File (SDF) format into your design before or during simulation. SDF
format is commonly used to communicate timing information among
different simulators, synthesis tools, and layout tools.

You can use SDF files obtained from your ASIC vendor, generate
them using Synopsys Design Compiler or third-party tools, or write
them yourself. See the OVI Standard Delay File (SDF) Format
Specification published by Open Verilog International for instructions
on writing an SDF file.

For information about using SDF version 3.0, see “SDF Version 3.0
in Appendix A”.

Backannotating with SDF Files


A-1
To backannotate your design with SDF timing data, you need to
understand the following topics:

• Specifying the SDF files


• Examining SDF header information
• Matching SDF timing parameters to generic parameters
• Understanding device constructs
• Annotating single bits
• Backannotation restrictions
• Ignored SDF constructs
• Backannotating structural library cells

Specifying the SDF Files

There are two ways to indicate the SDF files for backannotation:

• With the scsim command


• With the simulator include command. This applies only to RTL
or non-VITAL libraries.

Backannotating with SDF Files


A-2
Invoking with scsim

When you invoke VCS MX with scsim, you can specify one or more
SDF files to annotate the entire VHDL design or any portion of the
hierarchy.

Use the following syntax:

scsim -sdf [min:|typ:|max:][region:] sdf_file]] -sdf_af


.
.
[other_scsim_options] design

SDF Options
You indicate whether to use the minimum, typical, or maximum SDF
values for backannotation. Use one of the following options:

-sdf min
Backannotates the design with minimum timing values from
filename.sdf.
-sdf typ
Backannotates the design using typical timing values from
filename.sdf.
-sdf max
Backannotates the design with maximum timing values from
filename.sdf.
If you do not specify a vlaue, VCS MX uses the typical timing values.

-sdf region

Backannotating with SDF Files


A-3
Backannotates the portion of the design below region, using
timing values from sdf_file.sdf.
-sdf_af
Creates an assign file that contains generics and their values from
filename.sdf. The assign file is called filename.inc. This file is
useful only for debugging the SDF file.
Examples
The following example uses timing data from two different SDF files
to annotate two different portions of a design:

% scsim -sdf /E/UUT/DESIGN1:myfile1.sdf \


-sdf max:/E/UUT/DESIGN2:myfile2.sdf

The above command

• Backannotates the VHDL design cfg, starting from /E/UUT/


DESIGN1, with typical timing values (the default) from the SDF
file myfile1.sdf.
• Backannotates the VHDL design cfg starting from /E/UUT/
DESIGN2 with the maximum timing values from the SDF file
myfile2.sdf.
The following example shows how to use two SDF files to
backannotate the same portion of a VHDL design:

% scsim -sdf min:/E/UUT/DESIGN:myfile1.sdf -sdf myfile2.sdf

The above command backannotates the VHDL design cfg starting


from /E/UUT/DESIGN using the minimum timing values from both
myfile1.sdf and myfile2.sdf.

Backannotating with SDF Files


A-4
Invoking with the Simulator include Command

After you start VCS MX, you can specify the SDF file for RTL or non-
VITAL libraries with the simulator include command, as follows:

include [sdf_value_option] [other_sdf_options]\


-sdf sdf_filename

SDF Options
sdf_value_option indicates whether to use the minimum, typical,
or maximum SDF values for backannotation. Use one of the following
options:

-sdf_min
Backannotates the design with minimum timing values from
filename.sdf.
-sdf_typ
Backannotates the design using typical timing values from
filename.sdf.
-sdf_max
Backannotates the design with maximum timing values from
filename.sdf.
If you do not specify sdf_value_option, VCS MX uses the typical
timing values. If you use the -sdf_top, -sdf_min, -sdf_max, or -sdf_typ
options, you must place them before the -sdf filename to apply them
to filename.

other_sdf_options is one of the following:

-sdf_top declarative_region

Backannotating with SDF Files


A-5
Backannotates the portion of the design below
declarative_region, using timing values from filename.sdf.
-sdf_af
Creates an assign file that contains generics and their values from
filename.sdf. The assign file is called filename.inc. This file is
useful only for debugging the SDF file.
You must specify precisely where you want to annotate (sdf_top),
how you want to annotate (min, typ, or max), and the filename. If you
want to use more than one SDF file, you can repeat the include
command, once for each additional SDF file.

For example, the commands

# include -sdf_top /e/b1 -sdf_min -sdf timing1.sdf


# include -sdf_top /e/b2 -sdf_typ -sdf timing2.sdf

backannotate the design with the minimum timing values from the
timing1.sdf file with the typical values from timing2.sdf.

The timing information in the SDF files can cover the whole VHDL
design or any portion of the hierarchy. If more than one SDF file
annotates the same instance, the last SDF file read overwrites all
previous ones.

To use the wildcard (*) in SDF files, set the SDFWILDCARD setup
variable to true. The default is false. To turn on wildcard capability,
put the following entry in your synopsys_sim.setup file:

SDFWILDCARD = true

Backannotating with SDF Files


A-6
Note:
Set this flag to TRUE only to use an SDF file that contains wildcard
constructs. Setting this flag to TRUE can slow down elaboration
and increase the amount of memory VCS MX uses.

Examining SDF Header Information

The header file contains information about conditions under which


the SDF file was created. For example, the name of the program that
generated the file, date of generation, ambient temperature, and so
on.

If you want to examine the header information from the SDF file, use
the following procedure:

1. Include the package header file, sdf_header.vhd, in your


testbench VHDL file. To do this, add the following line at the
beginning of your testbench file, before the first entity:
use synopsys.sdf_header.all;

The header file is located in the directory $VCS_HOME/


packages/synopsys/src. This file is automatically updated
when you read in the SDF file.

2. Invoke VCS MX (scsim) on your design.


3. Use the simulator ls command at the top level of your design.
# ls -v sdf_header

VCS MX displays the SDF header information.

Backannotating with SDF Files


A-7
Matching SDF Timing Parameters to VHDL Generics

During backannotation, VCS MX reads the values for SDF timing


parameters from the SDF file, then assigns the values to the
appropriate VHDL generic parameters in your design. This applies
only for non-VITAL libraries.

Understanding Naming Conventions

The simulator matches the VHDL generic parameter names with SDF
timing parameter names according to the convention shown in Table
A-1. The table describes the default naming convention for all the
timing parameters.

Backannotating with SDF Files


A-8
Table A-1 Matching SDF Parameters with VHDL Generics
SDF Timing Default Generic SDF Timing Default Generic
Name Name
IOPATH_01 tpd%t_%d_R NETDELAY_Z1 twd%r_R
IOPATH_10 tpd%t_%d_F PORT_Z1 twd%r_R
IOPATH_0Z tpd%t_%d_LZ INTERCONNECT_1Z twd%r_F
IOPATH_Z1 tpd%t_%d_R NETDELAY_1Z twd%r_F
IOPATH_1Z tpd%t_%d_HZ PORT_1Z twd%r_F
IOPATH_Z0 tpd%t_%d_F INTERCONNECT_Z0 twd%r_F
DEVICE_01 tpd%t_%d_R NETDELAY_Z0 twd%r_F
DEVICE_10 tpd%t_%d_F PORT_Z0 twd%r_F
DEVICE_0Z tpd%t_%d_LZ SETUP tsu%t_%r
DEVICE_Z1 tpd%t_%d_R HOLD th%t_%r
DEVICE_1Z tpd%t_%d_HZ SETUPHOLD tsu%t_%r, th%t_%r
DEVICE_Z0 tpd%t_%d_F RECOVERY tsu%t_%r
INTERCONNECT_01 twd%r_R SKEW_RR tsk%t_R_%r_R
NETDELAY_01 twd%r_R SKEW_RF tsk%t_R_%r_F
PORT_01 twd%r_R SKEW_FR tsk%t_F_%r_R
INTERCONNECT_10 twd%r_F SKEW_FF tsk%t_F_%r_F
NETDELAY_10 twd%r_F PERIOD tc%r
PORT_10 twd%r_F WIDTH_L tw%r_L
INTERCONNECT_0Z twd%r_R WIDTH_H tw%r_H
NETDELAY_0Z twd%r_R NOCHANGE tnc%t_%r_R
PORT_0Z twd%r_R NOCHANGE tnc%t_%r_F
INTERCONNECT_Z1 twd%r_R BUS_EXPANSION %b_%i

The elements comprising the VHDL generic parameter name depend


on the type of timing information. The elements are

• Delay type; for example, tpd for IOPATH, tsu for SETUP, th for
HOLD.
• Affected port names
- %t represents the triggering port.
- %d represents the destination port.

Backannotating with SDF Files


A-9
- %r represents the reference port.
- %b represents the bus name.
- %i represents the index of the bus.
• %T represents either the null string or the string ”out”. This
element is used in the generic names associated with interconnect
delays.
The interconnect delay between an output (or bidirectional) port
of an instance and an output (or bidirectional) port of a design
requires special handling by the backannotation mechanism. For
such delays, %T=”out”; for all other interconnect delays, %T is
the null string.

Note:
For interconnect delays with %T=”out”, the cell model must
include an output wire buffer at the instance port, to serve as a
delay site.

Changing the Naming Convention

You can change the naming convention of one or more of the SDF
generics, or you can add new ones in a text file called
sdf_naming_file.s. You identify the path to the sdf_naming_file.s file
with the following entry in the synopsys_sim.setup file:

SDFNAMINGFILE = path/sdf_naming.s

path is the full pathname to the naming file.

Backannotating with SDF Files


A-10
You can create another naming convention for any or all SDF timing
parameters listed in Table A-1. For example, your naming file may
contain the following lines:

IOPATH_01 = %t_mytpd%r_01
INTERCONNECT_Z1 = my_interconnect_Z1

Understanding the DEVICE Construct

The DEVICE construct specifies the intrinsic delay of a cell or gate.


When VCS MX reads a DEVICE construct, it backannotates the pin-
to-pin delay generics throughout the cell. How the simulator handles
the DEVICE construct depends on whether or not the construct
includes an output port name.

• If DEVICE includes an output port name (for example, (DEVICE


Out1 (1:2:3)), VCS MX assigns the timing value only to those pin-
to-pin delay generics in the cell with that output port name as their
destination. For example, during backannotation of the device in
Figure A-1, if the DEVICE construct is
DEVICE Out1 (1:2:3) (1:2:3)

VCS MX assigns the timing value only to the following generics:

tpdIn1_Out1_R, tpdIn1_Out1_F, tpdIn2_Out1_R, and


tpdIn2_Out1_F

It ignores the generics such as tpdIn1_Out2_R, tpdIn1_Out2_F,


tpdIn2_Out2_R, and tpdIn2_Out2_F.

Backannotating with SDF Files


A-11
• If DEVICE does not include an output port name, VCS MX assigns
the value to all the pin-to-pin delay (tpd) generics in the cell. For
example, if the DEVICE construct is
DEVICE (1:2:3)

VCS MX assigns the timing value to all the following generics:

tpdIn1_Out1_R, tpdIn2_Out1_R, tpdIn1_Out2_R, tpdIn2_Out2_R,


tpdIn1_Out1_F, tpdIn2_Out1_F, tpdIn1_Out2_F, and
tpdIn2_Out2_F.

Figure A-1 Cell with Four Possible pin-to-pin Timing Arcs

Backannotating with SDF Files


A-12
Handling Backannotation to I/O Ports

SDF Reader might incorrectly handle the DEVICE construct for an


output I/O port if the DEVICE construct does not include an output
port name. Consider the following diagram. Port B is an I/O port of
the instance U1 of type IO_CELL. If the DEVICE construct is

DEVICE (1:2:3)

VCS MX assigns the timing value to the generics tpdIn1_B_R,


tpdIn2_B_R, tpdIn1_C_R, tpdIn2_C_R, tpdIn1_B_F, tpdIn2_B_F,
tpdIn1_C_F, and tpdIn2_C_F.

Also, it incorrectly assigns timing values to the following generics


because port B is an I/O port:

tpdB_In1_R, tpdB_In1_F, tpdB_In2_R, and tpdB_In2_F

Figure A-2 Specifying Delays for an I/O Port in a Device

Backannotating with SDF Files


A-13
To handle I/O ports, use the INTERCONNECT construct instead of
the DEVICE construct.

Using the INTERCONNECT Construct

The INTERCONNECT construct represents the actual or estimated


delay in the wire between devices.

The following SDF specifies the loading for Figure A-2:

(INSTANCE CELLTYPE)
(DELAY
(ABSOLUTE
(INTERCONNECT U1/B A (2:3:4))))

In the above statements, the interconnect must be reflected at the


input of the next stage (which is actually the load or tester in this
case). Since this is not available for simulation purposes, this
interconnect is added to the output of the previous stage.

But the intent of the SDF entry was to backannotate to all generics
that use B as an output port. In this case, the following SDF entry
yields correct backannotation:

(DEVICE B (1:2:3))

Multiple Backannotations to Same Delay Site

VCS MX backannotates source to load delays onto the delay site


associated with the load port. Therefore, there are multiple delay
entries, from different source ports to the same load port. In such
cases, you can specify the delay value that you want to backannotate.

Backannotating with SDF Files


A-14
The SDFPOLICY variable allows you to select the backannotation
delay value. You can set this variable to MIN, MAX, or MINOMAX.
The default value is MAX for backwards compatibility. If you specify
a value other than MIN, MAX, or MINOMAX, VCS MX issues a
warning and uses MAX as the default value.

For example, consider the generics tpdA_Y_R and tpdA_Y_F and


the following SDF file:

(IOPATH A Y (1:2:3) (3:4:5))


(IOPATH A Y (7:8:9) (1:2:3)
(IOPATH A Y (3:4:5) (7:8:9))

Assume you run a typical simulation run. If the synopsys_sim.setup


file includes the following entry:

SDFPOLICY = MIN

the backannotation retains the minimum values on the corresponding


generics (seen by the ls -v command):

tpdA_Y_R 2 ns
tpdA_Y_F 2 ns

If the synopsys setup file had no SDFPOLICY entry or the entry was
as follows:

SDFPOLICY = MAX

the backannotation retains the maximum values on the


corresponding generics (seen by the ls -v command):

tpdA_Y_R 8 ns
tpdA_Y_F 8 ns

Backannotating with SDF Files


A-15
If the synopsys setup file includes the following entry:

SDFPOLICY = MINOMAX

the minimum of all possible values are selected during a minimum


simulation run, and the maximum of all possible values are selected
for typical and maximum simulation runs. Therefore, during a
minimum simulation run (specified on the simulator command line via
the -sdf_min flag), the backannotation retains the following values on
the corresponding generics:

tpdA_Y_R 1 ns
tpdA_Y_F 1 ns

during a typical simulation run, the following values are retained:

tpdA_Y_R 8 ns
tpdA_Y_F 8 ns

Whereas in a maximum simulation run, the following values are


retained:

tpdA_Y_R 9 ns
tpdA_Y_F 9 ns

If the synopsys setup file had an illegal value specified such as the
following:

SDFPOLICY = illegal

VCS MX issues the following warning message:

Warning: scsim,180:
Bad value specified for “SDFPOLICY”, using default: MAX.

Backannotating with SDF Files


A-16
and the backannotation retains the following maximum values on the
corresponding generics (seen by the ls -v command) during a typical
simulation run:

tpdA_Y_R 8 ns
tpdA_Y_F 8 ns

Annotating Single Bits

You can backannotate a single bit in any SDF construct where an


SDF BIT_SPEC (bit specification) is valid. For example:

(IOPATH i[1] b[2] (1:2:3) (4:5:6))

However, you cannot annotate a range of bits. For example, VCS MX


ignores the following construct:

(IOPATH I[1:2] B[2:3] (1:2:3:) (4:5:6))

The generic naming convention for a single bit is %b_%i, where

• %b is the name of the bus.


• %i is the element index in the bus.

For example, the SDF construct

(IOPATH I[1] B[2] (1:2:3) (4:5:6))

Backannotating with SDF Files


A-17
causes VCS MX to expect the following default generic parameters
in the VHDL file:

• tpdI_1_B_2_R
• tpdI_1_B_2_F
If you want to change the default naming convention for single-bit
backannotation, place the BUS_EXPANSION variable in your SDF
naming file. Set the variable equal to your new naming convention.
For example,

BUS_EXPANSION = %i_%b.

causes VCS MX to look for the generics tpd1_I_2_B_R and


tpd1_I_2_B_F in the previous example.

Back-Annotation Restrictions

Keep in mind these important points when backannotating with SDF


files:

• If there is one triplet in an IOPATH construct, VCS MX


backannotates both the rise time and fall time for the path. The
following example annotates both the rise and fall time of the path:
IOPATH CLK Q (1.109:1.445:2.335)

• If you want to only annotate the rise or fall time, you must use a
null transition (empty set of parentheses) for the delay you do not
want to annotate. The following example annotates only the rise
time:
IOPATH CLK Q (1.204:1.535:2.478) ()

Backannotating with SDF Files


A-18
• If you use conditional statements in the SDF file, you must make
sure that the conditional expression exactly matches the condition
in the VHDL model, except for white spaces such as tabs or
blanks.
For example, the following SDF statement:

COND ( B == 1’b0 ) (IOPATH A Q ...

does not match the condition in the VHDL model

attribute SDT_CONDITION of tpdA_Q_R: constant is


“ B == 1’b0 , B == 1’b1”;

To make these two statements match, the extra parenthesis are


removed from the SDF statement as follows:

COND B == 1’b0 (IOPATH A Q ...

Ignored SDF Constructs

VCS MX supports only those SDF constructs that are meaningful


during VHDL simulation. It ignores the following SDF timing
constructs:

PATHPULSE
Pulse rejection limit and the X limit.
GLOBALPATHPULSE
Pulse rejection limit and the X limit measured in percentage of cell
path delay.

Backannotating with SDF Files


A-19
PATHCONSTRAINT
Time constraint for circuit paths in timing analysis applications.
SUM
Total of the individual delays associated with start-end port pair
and its limit.
DIFF
Maximum difference in delay between two paths.
SKEWCONSTRAINT
Maximum skew delay associated with ports.
Edge Specifier
Positive edge and negative edge, except for the constructs
WIDTH and NOCHANGE.

Back-Annotating Structural Library Cells

You can change the value of behavioral cell generic parameters after
elaboration, because the value of the generic is read each time the
cell is active. Structural cells, however, use the value of the cell level
generic in the generic map of lower level structural instances.

VCS MX does not automatically propagate changes to generic values


to the places where that generic is used. Therefore, when creating a
structural library cell, you must identify the lower-level generic that
must also be updated. You do this by assigning the
PROPAGATE_VALUE attribute in the architecture declaration of the
structural cell.

attribute PROPAGATE_VALUE of generic: constant is ”generic_name_list”;

Backannotating with SDF Files


A-20
generic_name_list is a string of one or more lower-level generic
parameters that should also be updated. Use commas to separate
multiple generic parameter names.

Figure A-3 shows an example of modeling timing for a structural


library cell. The example uses a functional block with buffers on its
input and output ports. By placing delays on the buffers, you can
model such timing constructs as pin-to-pin timing.

Since VCS MX does not automatically propagate the generic values


down the hierarchy, you must indicate where the generic values are
used. Example A-1 shows a VHDL description of this cell.

Figure A-3 Modeling the Timing Characteristics of a Structural Library Cell

Example A-1 VHDL Description of Structural Library Cell

library Synopsys;
use synopsys.attributes.all;
-- declares: ”attribute PROPAGATE_VALUE : string;”
library IEEE;
use IEEE.std_logic_1164.all

Backannotating with SDF Files


A-21
use IEEE.std_logic_components.all;

entity E is
generic(tpdA_Z_R, tpdA_Z_F: time);
port (A: in std_logic; Z: out std_logic);

end;

architecture A of E is
attribute PROPAGATE_VALUE of tpdA_Z_R: constant is ”U1/tpHL”;
attribute PROPAGATE_VALUE of tpdA_Z_F: constant is ”U1/tpHL”;
attribute PROPAGATE_VALUE of tpdA_Z_F:
constant is ”U2/tpHL, U3/tpHL”;
...

signal S: std_logic;
begin
U1: BUFGATE -- Buffer to hold the timing
generic map(tpLH => tpdA_Z_R, tpHL => tpdA_Z_F)
port map(A, S);
Z <= S;-- Functional block
.
.
.
end A;

You can map several SDF timing values to either the same cell-level
generics or the same lower-level generics. VCS MX applies the
largest timing value to the generic.

SDF Back-Annotation for Gate-Level Timing Simulation

VHDL VITAL gate level simulation performance is very slow


compared to Verilog gate level simulation. Synopsys recommends
using the VCS MX flow with VHDL testbench environment and Verilog
netlist.

Backannotating with SDF Files


A-22
The original design can be synthesized and a gate level netlist can
be generated using the synthesis tool. Keeping the rest of the
environment same, the VHDL RTL portion can either be simulated
with the Verilog netlist or can be substituted by Verilog netlist and
simulated using VCS MX and VCS MX Verilog.

Figure 13-5 Gate Level Simulation Using Verilog Netlist

VHDL IP
VHDL
RTL
VHDL Verilog IP Design
VERA Flow
Test-
bench
Synthesis

Verilog Gates

By default, VCS MX Verilog compiles the SDF file because compiled


SDF back-annotation is much faster. However, you can include the
+oldsdf compile-time option so that VCS MX Verilog can back-
annotate from the ASCII text SDF file, instead of its compiled version.

Backannotating with SDF Files


A-23
You can not back-annotate delay values through SDF back-
annotation on the entire mixed language design simultaneously but
you can always back-annotate delay values from an SDF file to the
Verilog netlist. SDF file must have the same design name as the
module name of the netlist which is instantiated in VHDL.

For simple Verilog netlist timing simulation using compiled SDF back-
annotation, you must follow these steps:

1. Specify the $sdf_annotate system task in the Verilog netlist (top


level module) with the netlist module name and SDF file. For
example,
$sdf_annotate (“SDF_File”, Module_Name);

Specifying Module name is optional. By default, since the task is


in the netlist module, the SDF back-annotation will be performed
on the same netlist module.
If you specify a module_instance argument in the $sdf_annotate
system task, you cannot enter an absolute hierarchical name for
the module instance. You can only enter a relative hierarchical
module name. An absolute hierarchical name begins with the
name of a top-level module in the Verilog design that you
instantiate in the VHDL design. Entering this hierarchical name is
not absolute because the root of absolute hierarchical names in
VCS MX flow is up in the VHDL part of the design. A relative
hierarchical name begins with a module instance name of a
module instance that is instantiated in the module definition that
contains the $sdf_annotate system task.
For example, if TOP_GATE (netlist, Verilog) is instantiated in
TB_TOP_GATE (VHDL) as VLOG_GATES (instance name,
VHDL), the correct specification of $sdf_annotate task in Verilog
netlist (TOP_GATE) is

Backannotating with SDF Files


A-24
$sdf_annotate(“SDF_FILE”, TOP_GATE);

and not
$sdf_annotate(“SDF_FILE”, VLOG_GATES);

Note :
a. You can not specify $sdf_annotate in a separate Verilog
module.
b. Although specifying module instance name instead of module
name is supported, because of complications in specifying the
correct hierarchical path for the netlist instance, it is
recommended not to use this method but instead use the
method explained above.

2. Follow the steps mentioned in VCS MX flow.

- Instantiate the Verilog netlist module in VHDL design using


component declaration and instantiation.
- Analyze Verilog netlist along with library modules.
% vlogan netlist.v \
-v /design/syn/lib_file \
-y /design/syn/lib_dir1 +libext+.v \
+notimingchecks

You must specify all the required source files (with the netlist),
library files, and directories needed for Verilog portion. All the
rules mentioned earlier regarding library files and directories
apply.
- Analyze VHDL design units including one which instantiates
Verilog netlist.

Backannotating with SDF Files


A-25
- Elaborate VHDL design units and compile Verilog netlist using
correct options for scs. For example,
% scs lib.cfg_tb_gate -verilogcomp “+rad+1”

- Simulate the entire design using scsim with correct usage of


run-time options.
% scsim -verilogrun “+notimingchecks”

Backannotating with SDF Files


A-26
B
Using VITAL Models and Netlists B
You use VHDL Analyzer and VCS MX to validate and optimize a
VHDL initiative toward ASIC libraries (VITAL) model and to simulate
a VITAL-based netlist. Typically, the optimization of the VITAL model
is done by library developers, and simulation of the VITAL-based
netlist is done by designers.

The library developer uses a single ASIC cell from the system, verifies
its correctness, and optimizes that single cell. The designer simulates
large numbers of cells, organized in a netlist, by applying test vectors
and timing information.

This chapter describes how the library developer can validate and
optimize a VITAL model and how the designer can simulate a VITAL
netlist.

Using VITAL Models and Netlists


B-1
Validating and Optimizing a VITAL Model

The library developer performs the following tasks:

• Validates the model for VITAL conformance


• Verifies the model for functionality
• Optimizes the model for performance and capacity
• Re-verifies the model for functionality

Validating the Model for VITAL Conformance

Library developers can validate the conformance of the VHDL design


units to VITAL 95 IEEE specifications, according to level 0 or level 1
as specified in the model, by using vhdlan.

vhdlan checks the VITAL design units for conformance when you set
the VITAL attribute on the entity (VITAL_Level0) and architecture
(VITAL_Level1) to TRUE. vhdlan does not check the design unit for
VITAL conformance if the attribute is set to FALSE.

Verifying the Model for Functionality

Library developers then verify the model’s functions by using scsim.


The functional verification includes checking the following:

• Timing values for the cell, including hazard detection


• Correct operation of the timing constraints and violation detection
• Other behavioral aspects of the cell according to specifications

Using VITAL Models and Netlists


B-2
Optimizing the Model for Performance and Capacity

Library developers compile the VHDL design units to optimize the


model for simulation by using vhdlan. vhdlan checks the design unit
for VITAL conformance before performing any optimization.

To optimize the design units, perform the following steps:

1. Set the VITAL attribute on the entity (VITAL_Level0) and on the


architecture (VITAL_Level1) to TRUE.
When you optimize architectures that have the VITAL_Level1
attribute set to TRUE, visibility into the cell is lost and the cell is
marked as PRIVATE. Ports and generics remain visible.

2. Use either the OPTIMIZE variable in the setup file or -optimize


option to the vhdlan command.
The command line option overrides the setting in the
synopsys_sim.setup file.

a. Set the OPTIMIZE variable in the setup file


Table B-1 lists the legal values of the variable, the design unit
type, and the results of each setting.

Using VITAL Models and Netlists


B-3
Table B-1 Optimize Variable Values
Design Unit
Variable Values Type Result
OPTIMIZE TRUE Non-VITAL Analyzer does not perform any optimization.
OPTIMIZE TRUE VITAL Analyzer performs the optimization on design
units that are VITAL conformant.
OPTIMIZE FALSE Non-VITAL Analyzer does not perform any optimization.
OPTIMIZE FALSE VITAL Analyzer does not perform optimization on
design unit regardless of its VITAL
conformance status (default).

b. Use the -optimize option to the vhdlan command.

3. Use either the -event option to vhdlan or make sure that the
DEFAULT_ANALYZE_MODE variable is set to -event.
For example, to optimize the design unit, use the command line option
by typing:

vhdlan -optimize -event

Using VITAL Models and Netlists


B-4
Re-Verifying the Model for Functionality

After validating and then optimizing the cell, library developers re-
verify the results against expected results. The optimizations
performed by VCS MX typically result in correct code.

Understanding Error and Warning Messages

If the VITAL conformance checks for a design unit fail, the analyzer
reports an error message and stops the optimization of the design
unit. Simulation files (.sim and .o files) are not created, and simulation
is not possible for this design unit until the model is changed to
conform to VITAL specifications.

If the analyzer reports a warning message, the optimization stops


only if the message is related to the VITAL architecture, otherwise
the optimization continues. Simulation files are generated, and you
can simulate the design units.

Table B-2 lists the status of optimization and simulation file generation
based on the type of messages reported by the analyzer.

Table B-2 Analyzer Status Messages


VITAL Attribute Message Types Optimization Simulation Files
Level 0 (entity) error stops not created
Level 1 (architecture) error stops not created
Level 0 (entity) warning continues created
Level 1 (architecture) warning stops created

For a complete list of conformance checking error messages, see the


“Understanding VITAL Timing Delays and Error Messages” chapter
in this manual.

Using VITAL Models and Netlists


B-5
Distributing a VITAL Model

VITAL library developers (usually, ASIC vendors) can distribute


models (ASIC library) to designers in any of the following formats:

• A VHDL source file


After conformance checking and verification, you can distribute
the cell library in source format. The library is unprotected, but it
is portable.

• An encrypted VHDL source file


You can distribute the encrypted file similar to the VHDL source
file. Because the encryption algorithms are generally not public
and the code is protected, models are not portable to other
simulators.

• Simulation files (the .sim and .o files)


The cell is analyzed and optimized by the ASIC vendor. The library
is protected and is not portable to other simulators or simulator
versions.

For the VHDL file and the encrypted VHDL source file formats, the
designer can perform the final compilation to optimize the library
object codes by using the -optimize and -event options. ASIC vendors
can provide designers with a script specifying the correct compilation
procedure.

Using VITAL Models and Netlists


B-6
Simulating a VITAL Netlist

A VITAL-based netlist consists of instances of VITAL cells. There are


no VITAL specific or other restrictions on the location of such cells in
the netlist, nor are there restrictions regarding the quantity or ratio of
such cells in relation to other VHDL descriptions.

To simulate a VITAL netlist, simply invoke scsim.

Applying Stimulus

You apply the input stimulus for the VITAL netlist using the same
method and format that you use to apply them for any other netlist,
such as using WIF, text input/output, or a testbench.

Overriding Generic Parameter Values

The setup file contains the following three flags that you can use to
control the simulation of a VITAL netlist:

• Force_TimingChecksOn_TO
This global flag affects all occurrences of the TimingChecksOn
generic in a VITAL cell.

• Force_XOn_TO
This global flag affects all occurrences of the XOn generic in a
VITAL cell.

Using VITAL Models and Netlists


B-7
• Force_MsgOn_TO
This global flag affects all occurrences of the MsgOn generic in a
VITAL cell.

The flags override the value of the generic parameter regardless of


the source of the value.

In VITAL, you control the timing constraints and hazards by using the
same flag.

Table B-3 lists timing and constraint hazard flags.

Table B-3 Timing Constraint and Hazard Flags


Flag Name Legal Values Result
Force_TimingChecksOn_TO TRUE Timing checks are performed.

FALSE Timing checks are disabled for that


cell.
AsIs (default) User-specified value of the generic is
not modified. This is the default.
Force_XOn_TO TRUE X’s are generated with violations.
FALSE X generation is disabled for that cell.
AsIs (default) User-specified value of the generic is
not modified. This is the default.
Force_MsgOn_TO TRUE Messages are reported on violations.
FALSE Timing messages are disabled for that
cell.
AsIs (default) User-specified value of the generic is
not modified.

These flags override the value of VITAL generic parameters. The


flags have no effect if the model does not use the generic parameter.
The generics XOn and MsgOn are parameters to VITAL timing and
path delay subprograms.

Using VITAL Models and Netlists


B-8
Understanding VCS MX Error Messages

VCS MX reports two types of errors: system errors and model/netlist


errors.

System Errors
VCS MX reports a system error if any of the following conditions occur:

• If there are any negative timing values after all timing values are
imported and negative constraint calculations (NCC) are
performed.
All the adjusted timing values must be positive or zero (>=0) after
all timing values are imported and NCC is performed. If an
adjusted value is negative, NCC issues a warning message and
uses zero instead.

Use the man vss-297 and man vss-298 command to get more
information about NCC error messages.

• If you try to “look-into” the parts of the model that are invisible
(using the SCL commands, such as ls or cd.)
This is because the visibility is limited in VITAL cells that have
been optimized, and the cells are marked as PRIVATE.

Model and Netlist Errors


A VITAL model in a VITAL netlist generates several kinds of errors.
The most important are hazard and constraint violations. Both are
associated with a violation of the timing model. The format of such
errors is defined by the VITAL standard (in VHDL packages.)

Using VITAL Models and Netlists


B-9
Viewing VITAL Subprograms

You cannot view or access VITAL subprograms. The VITAL


packages are built-in. Any reference to a VITAL subprogram
(functions or procedures) or any other item in the VITAL packages is
converted by the analyzer to a built-in representation.

Timing Back-annotation

A VITAL netlist can import timing information from a VHDL


configuration or an SDF file.

• A VHDL configuration
VHDL allows the use of a configuration block to override the
values of generics specified in the entity declaration. This is done
during analysis of the design.

• SDF file
VITAL netlist can import an SDF 2.1 version file. The VITAL
standard defines the mapping for SDF 2.1 and the subset
supported.

You can back-annotate different versions of SDF files.

- SDF 2.1 files: For VITAL entities with VITAL_Level0 attributes


set to TRUE.
- SDF 1.0/ 2.1 files: For other cell type and for back-annotation.
Newly back-annotated values are visible at all times to let you
know that back-annotation was successful.

Using VITAL Models and Netlists


B-10
Note:
You cannot assign values to the generics of optimized VITAL cells
using the assign command.

VCS MX Naming Styles

VCS MX automatically determines what naming style is used


according to the cell:

• For conformance checked VITAL cells (that is, VITAL entities with
the VITAL_Level0 attribute set to TRUE), VCS MX uses VITAL
naming styles.
• For non-VITAL conformance checked cells, VCS MX uses the
Synopsys naming style (or the style described in SDF naming file.)
Note:
VCS MX ignores the SDFNAMINGSTYLE variable in the setup
file when determining the naming style.

Negative Constraints Calculation (NCC)

Adjusting the cell timing values and converting the negative values
follows the elaboration and back-annotation phases. VCS MX follows
these steps to prepare the design units for simulation:

1. Elaborate design
Elaboration is a VHDL step, the design is created and is ready for
the simulation run.

Using VITAL Models and Netlists


B-11
2. Back-annotate timing delay values
Timing values are imported, and the value of generic parameters
are updated. VITAL models that support NCC accept
backannotation information as in any other cell.

3. Convert the negative constraint values


The value of generic parameters is modified to conform to the
NCC algorithm, and negative constraint values are converted to
zero or positive.

VCS MX automatically performs NCC only when the


VITAL_Level0 attribute is set to TRUE for the VITAL entity and
the internal clock delay generic (ticd) or internal signal delay
generic (tisd) is set.

VCS MX does not run NCC on design units that have a non-VITAL
design type, but you can simulate them.

Note:
VCS MX performs NCC after SDF annotation. If you don’t back-
annotate the time delays using SDF, NCC is done after
elaboration.

4. Run the simulation.

Using VITAL Models and Netlists


B-12
Understanding VITAL Timing Delays and Error
Messages

This section describes how VCS MX annotates Standard Delay


Format (SDF) data during simulation and how it calculates negative
timing constraints during elaboration. This section also lists the error
messages that VHDL Analyzer generates while checking design units
for VITAL conformance.

This chapter contains the following sections:

• SDF Back-Annotation
• Negative Constraint Calculation (NCC)
• Conformance Checks
• Error Messages

SDF Back-Annotation

The SDF annotator in VCS MX supports the following for VITAL


models:

• Mixed versions of SDF files


• Multiple SDF files

Using VITAL Models and Netlists


B-13
Mixed Versions of SDF Files

The SDF annotator in VCS MX can annotate mixed versions of SDF


files (version 1.0 and 2.1) into a design that contains VITAL cells.
VCS MX can annotate this mixed version of SDF for the same
simulation run.

Naming Styles for Delay Generics


VITAL models can only use SDF version 2.1. When you use SDF
version 2.1, SDF annotator uses the VITAL naming styles and creates
generic names based on the VHDL model (the VITAL_Level0
attribute must be set to TRUE in the VHDL entity); otherwise it uses
the VCS MX naming styles as shown in Table B-4.

Table B-4 Naming Styles for Delay Generics by SDF Version Number
SDF Version VITAL/non-VITAL Naming Style
1.0 VITAL VCS MX reports an error
1.0 non-VITAL VCS MX naming style
2.1 VITAL VITAL naming style
2.1 non-VITAL VCS MX naming style

VCS MX ignores the SDFNAMINGSTYLE variable settings in the


synopsys_sim.setup file. Because of the dependency on VHDL
models, to use the SDF wildcard (*) for VITAL models, first you must
use a nonconditional specification for initializing the
SDFNAMINGSTYLE to VITAL.

Using VITAL Models and Netlists


B-14
DEVICE Delay
Note:
VCS MX supported VITAL version 3.0 timing generic rules
beginning with version 3.4b of VCS MX and continues to support it.

The VITAL-SDF name mapping rule for the DEVICE delay is as


follows:

tdevice_<InstanceName>[_<OutputPort>]

<InstanceName> is the label for a VITAL primitive concurrent


procedure call, and _<OutputPort> is optional.

SDF annotator maps each DEVICE delay into one timing generic.

Example 1:

The SDF entry

(CELL (CELLTYPE ”AN2”)


(INSTANCE Top.I1.P2)
(DELAY (ABSOLUTE (DEVICE Y (3)(5))))
)

maps to the generic

tdevice_P2_Y

Example 2:

The SDF entry

(CELL (CELLTYPE ”AN2”)


(INSTANCE Top.I1.P2)
(DELAY (ABSOLUTE (DEVICE (3)(5))))

Using VITAL Models and Netlists


B-15
)

maps to the generic

tdevice_P2

Multiple SDF Files

When you specify multiple SDF files and their switches on the
command line, SDF annotator uses the following sequence to apply
the switches:

1. Reads and applies the command line switches.


2. Reads the synopsys_sim.setup file.
3. Uses the default values.
For example, if you specify the scsim command for SDF as

scsim -sdf min:/top/blockB/I1:f1.sdf -sdf f2.sdf

and if the synopsys_sim.setup file includes

SDF_TOP = /top/block1

and the default values are

SDF_TOP = NULL
SDFINDEX = SDF_TYP

SDF annotator uses the region /top/blockB/I1 and the MIN switches
only for the f1.sdf file, and it uses the settings from the
synopsys_sim.setup file and the defaults for the f2.sdf file.

Using VITAL Models and Netlists


B-16
Therefore, SDF annotator uses /top/blockB/I1 as the top-level design
name and MIN delay for the f1.sdf file. For f2.sdf, it uses /top/block1
as the top-level design name and TYP delay.

SDF Restrictions

When using SDF with VITAL, you must be aware of the following two
restrictions:

• SDF port names are not checked.


• VCS MX cannot back-annotate SDF file at run time.

SDF Port Names Not Checked


VCS MX does not check SDF port names against VHDL port names,
because VITAL does not require the use of PORT names as the suffix
of VITAL generic names. Timing generic names are generated based
on delay type and port specification from the SDF file.

Back-Annotation at Elaboration Time


You must back-annotate the SDF file during elaboration and not while
you are running simulation. Therefore, you cannot use the include
command to invoke the SDF parser for a design that has a VITAL
component.

Using VITAL Models and Netlists


B-17
Negative Constraint Calculation (NCC)

VITAL defines the special generics ticd, tisd, tbpd, SignalDelay Block,
and equations to adjust the negative setup and hold time and related
IOPATH delays.

For VITAL models, NCC adjusts the timing generics for the ticd or
tisd generic. The ticd delay is calculated based on SETUP and
RECOVERY time. Therefore, NCC resets the original ticd delay in
VITAL cells.

Conformance Checks

For VITAL conformance, the analyzer checks the design units that
have the VITAL_Level0 or VITAL_Level1 attribute set to TRUE (if the
attributes are set to FALSE, the analyzer reports a warning). The only
result of the conformance checking from the analyzer is the error
messages.

The analyzer performs the following checks:

• Type checking
• Syntactic and Semantic checks

Type Checks

The analyzer checks and verifies the type for generics, restricted
variables, timing constraints, delays, and ports.

Using VITAL Models and Netlists


B-18
VITAL_Level0 timing generics are checked for type and name. The
decoded name can only belong to a finite predefined set { tpd, tsetup,
thold, trecovery, ...}.

Table B-5 shows the VITAL delay type names for the generics and
the corresponding class for VITAL_Level0 design units.

Table B-5 Delay Type Name and Corresponding Design Unit Class
Generic Type Name Class
Time VITAL simple delay type
VitalDelayType VITAL simple delay type
VitalDelayArrayType VITAL simple delay type
VitalDelayType01 VITAL transition delay type
VitalDelayType01Z VITAL transition delay type
VitalDelayType01ZX VITAL transition delay type
VitalDelayArrayType01 VITAL transition delay type
VitalDelayArrayType01Z VITAL transition delay type
VitalDelayArrayType01ZX VITAL transition delay type

The analyzer checks for the existence of the ports the generic refers
to. For vector subtypes, it checks the index dimensionally.

Table B-6 contains the list of the predefined timing generics. When
the analyzer finds any port names while checking the generic names,
it verifies the type of the generic name.

Using VITAL Models and Netlists


B-19
Table B-6 Predefined Timing Generics
Prefix Name Ports VITAL type
tpd <InPort><OutPort> VITAL delay type
tsetup <TestPort><RefPort> simple delay type
thold <TestPort><RefPort> simple delay type
trecovery <TestPort><RefPort> simple delay type
tremoval <TestPort><RefPort> simple delay type
tperiod <InPort> simple delay type
tpw <InPort> simple delay type
tskew <Port1><Port2> simple delay type
tncsetup <TestPort><RefPort> simple delay type
tnchold <TestPort><RefPort> simple delay type
tipd <InPort> VITAL delay type
tdevice <InstanceName>[OutPort] VITAL delay type
ticd <ClockPort> simple delay type
tisd <InPort><ClockPort> simple delay type
tbpd <InPort><OutPort><ClockPort> VITAL delay type

VITAL_level0 control generics are only checked for type as shown in


Table B-7.

Table B-7 Type Checks for Control Generics


Name Type
InstancePath String
TimingChecksOn Boolean
Xon Boolean
MsgOn Boolean

Syntactic and Semantic Checks

Before conformance checking, VHDL grammar checks are


performed. VITAL is a subset of VHDL, so any further checks are
actually semantic checks.

Using VITAL Models and Netlists


B-20
Error Messages

The error messages are grouped into different classes according to


the type of error or the hierarchy of error as shown in Table B-8.

Table B-8 Error Message Classes


Error Class Error Prefix
Syntax VITAL error
Type VITAL error
Context VITAL error
Parameter VITAL error
Illegal Value VITAL error
Entity Error
Package
Usage
Architecture Level 0
Architecture Level 1
1. Constraints
2. Delay

Error messages have the following features:

• Display the description and location information separately


• Display an error prefix with entity and architecture, type of error,
severity level, file name, line number and the offending line from
the source
• Display only user-helpful information
• Denote the name of the preceding reference as %s. For example,
port%s means that the name of the port should appear at the
output.

Using VITAL Models and Netlists


B-21
• Are one-liners for grep/awk retrieval from the log file
• Are numbered as follows: E-VTL001, W-VTL002, ...
Table B-9 and Table B-10 list all the VITAL error messages. Every
message is prefixed with an error class specific message and
sufficient context for you to find the problem object. For example, if
a port is the offending object, the name of the port and entity are
provided. For type violation, the offending type is shown. When there
is no indication of what was found, it means that the negation of the
statement was found. For example, the error message “The actual
part of ... MUST be static” indicates that the type found is not static.

Using VITAL Models and Netlists


B-22
Table B-9 VITAL Error Messages for Level 0 Conformance Issues
# Error VITAL Error Message
Class Reference
Manual
section
number
1 type 4.1 The attribute %s { VITAL_Level0, VITAL_Level1 }
MUST be declared in package VITAL_Timing and it is
declared in %s.
2 type 4.1 The type of the attribute %s { VITAL_Level0,
VITAL_Level1 } MUST be Boolean and it is %s.
3 warning 4.1 The value of the attribute %s { VITAL_Level0,
VITAL_Level1 } MUST be True and it is %s.
4 scope 4.2 %s declared in VITAL package %s cannot have an
overloaded outside the package.
5 scope 4.2.1 Use of foreign architecture body %s for entity %s is
prohibited.
6 Not 4.2.1 The syntactic rule %s, removed in IEEE Std 1076-1993
implemen is illegal in VITAL.
ted
7 syntax 4.3 The only declaration allowed inside an entity’s %s
declarative part is VITAL_Level0 attribute declaration.
8 syntax 4.3 No statements allowed inside a VITAL entity’s %s
statement part.
9 semantic 4.3.1 Entity %s port %s name CAN NOT contain underscore
character(s).
10 semantic 4.3.1 Entity %s port %s CAN NOT be of mode LINKAGE.
11 semantic 4.3.1 Entity %s: The type of the scalar port %s MUST be a
subtype of Std_Logic. Type is %s.
12 semantic 4.3.1 Entity %s: The type of vector port %s MUST be
Std_Logic_Vector. Type is %s.
13 syntax 4.3.1 Entity %s port %s CAN NOT be a guarded signal.
14 semantic 4.3.1 Entity %s: a range constraint is not allowed on port %s.
15 semantic 4.3.1 Entity %s port %s CAN NOT specify a user defined
resolution function.
16 warning 4.3.2.1.1 Entity %s: No port associated with the timing generic
%s. Generic %s unused by VITAL and no check will be
performed on it.
17 type 4.3.2.1.2 Entity %s: The type of the scalar generic timing
parameter %s does not match the type of associated
with a vector port %s.

Using VITAL Models and Netlists


B-23
# Error VITAL Error Message
Class Reference
Manual
section
number
18 type 4.3.2.1.2 Entity %s: the dimension(s) of the vector timing generic
%s does not match that of the associated port %s.
19 type 4.3.all The type of the timing generic %s MUST be one of { %s,
...} and it is %s.
20 semantic 4.3.2.1.3.14 Biased propagation delay timing generic %s needs a
propagation delay timing generic associated with the
same port, condition and edge.
21 semantic 4.3.2.1.3.14 The type %s of biased propagation delay timing generic
%s does not match the type %s of the propagation
delay timing generic %s associated with the same port,
condition and edge.
22 semantic 4.3.3 The type %s of the control generic %s is illegal. Type
MUST be %s.
23 semantic 4.4.1 Entity %s: Timing generic %s value used before
simulation.
24 semantic 4.4 Architecture %s { VITAL_Level0, VITAL_Level1 } %s
must be associated with a VITAL_Level0 entity.

Using VITAL Models and Netlists


B-24
Table B-10 VITAL Error Messages for Level 1 Conformance Issues
# Error VITAL Error Message
Class Reference
Manual
section
number
1 semantic 6.2 VITAL_GLOBSIG, VERR_USER, MARK
Signal ’%s’ MUST be an entity port or an internal signal.
2 semantic 6.2 VITAL_GLOBSIG, VERR_USER, MARK
Signal-valued attribute ’%s’ is not allowed in a VITAL
Level 1 architecture.
3 semantic 6.2 It is illegal for a signal %s in architecture %s to have
multiple drivers. The drivers are { %s, ... }
4 semantic 6.2 Internal signal %s of type %s in architecture %s is
illegal. Type can be only of type { Std_ULogic,
StdLogic_Vector }. Type is %s.
5 semantic 6.2 Operators used in a VITAL_Level1 architecture MUST
be defined in Std_Logic_1164 . Operator %s is defined
in %s.
6 semantic 6.2 Subprogram invoked in a VITAL_Level1 architecture
MUST be defined in Std_Logic_1164 or VITAL
package. Subprogram %s is defined in %s.
7 semantic 6.2 Formal subelement association %s in a subprogram
call %s is not allowed.
8 semantic 6.2 Type conversion %s in a subprogram call %s is not
allowed.
9 semantic 6.4 Multiple wire delay blocks in architecture %s are not
allowed. Offending blocks are labeled { %s, ... }. At
most one block with a label “WireDelay” is allowed.
10 syntax 6.4 Architecture %s body is allowed at most one negative
constraint block to compute the internal signal delays
declared in entity %s.
11 syntax 6.4 Architecture %s needs at least one process statement
or a concurrent procedure call.
12 semantic 6.4.1 Illegal block label %s. It MUST be “WireDelay."
13 context 6.4.1 Procedure VitalWireDelay MUST be declared in
package VITAL_Timing and it is declared in %s.
14 semantic 6.4.1 A call to a VitalWireDelay procedure outside a wire
delay block is not allowed.

Using VITAL Models and Netlists


B-25
# Error VITAL Error Message
Class Reference
Manual
section
number
15 semantic 6.4.1 At most one wire delay per port of mode IN or INOUT
and associated with a wire delay concurrent procedure
is allowed inside a wire delay block. Offending signals
are {%s, ...}.
16 semantic - A VITAL predefined name %s CAN NOT be
overloaded outside the VITAL package %s.
17 semantic 6.4.1 Internal wire delayed signal %s representing the wire
delay of port %s MUST be the same type as the port.
18 semantic 6.4.1 The value of port %s can be read only as an actual part
to a wire delay concurrent procedure call.
19 semantic 6.4.1 No range attribute specified for generate statement of
a wire delay port %s.
20 semantic 6.4.1 Only a concurrent procedure call allowed inside an
array port %s generate statement.
21 usage 6.4.1 The index for the generate statement %s for the array
port %s MUST be the name of the generate parameter
%s.
22 semantic 6.4.1 The actual part associated with the input parameter
InSig for a wire delay concurrent procedure call MUST
be a name of a port of mode IN or INOUT. Offending
port %s is of mode %s.
23 semantic 6.4.1 The actual part associated with the output parameter
OutSig for a wire delay concurrent procedure call
MUST be a name of an internal signal. The actual part
is %s of type %s.
24 semantic 6.4.1 TWire delay value parameter does not take negative
values. Value is %s.
25 semantic 6.4.1 The actual part associated with wire delay parameter
TWire MUST be locally static or a name of an
interconnect delay parameter. Actual part is %s.
26 semantic 6.4.2 VITAL negative constraint block MUST have a label
named “SignalDelay.” Label is %s.
27 semantic 6.4.2 Negative constraint %s has no procedure call
associated with it and therefore is unused by VITAL.
28 semantic 6.4.2 Negative constraint %s has more than one procedure
call { %s, ... } associated with it. Only one procedure
call per generic timing parameter is allowed.

Using VITAL Models and Netlists


B-26
# Error VITAL Error Message
Class Reference
Manual
section
number
29 context 6.4.2 Procedure VitalSignalDelay MUST be declared in
package VITAL_Timing and it is declared in %s.
30 semantic 6.4.2 A call to VitalSignalDelay is not allowed outside a
negative constraint block.
31 semantic 6.4.2 The actual part associated with the delay value
parameter Dly in VitalSignalDelay MUST be a timing
generic representing internal signal or internal clock
delay. The actual part is %s.
32 semantic 6.4.2 The actual part associated with the input signal
parameter S in VitalSignalDelay MUST be a static
name denoting an input port or the corresponding wire
delay signal (if it exists).
33 semantic 6.4.2 The actual part associated with the output signal
parameter DelayedS MUST be an internal signal.
34 syntax 6.4.3 A VITAL process statement %s MUST have sensitivity
list.
35 context 6.4.3 Signal %s CAN NOT appear in the sensitivity list of
process %s.
36 semantic 6.4.3.1.1 Vital unrestricted variable %s MUST be of type
{ Std_ulogic, Std_logic_vector, Boolean } only. Type is
%s.
37 semantic 6.4.3.1.1.1 The actual part %s of a restricted formal parameter %s
MUST be a simple name.
38 semantic 6.4.3.1.1.1 The initial value of the restricted variable %s
associated with the restricted formal parameter
GlitchData in procedure VitalPathDelay MUST be a
VITAL constant or VITAL function with a locally static
parameters, but it is %s.
39 semantic 6.4.3.1.1.1 The initial value of the restricted variable %s
associated with the restricted formal parameter
TimingData in procedure %s { VitalSetupHoldCheck,
VitalRecoveryRemovalCheck } MUST be a VITAL
constant or VITAL function with a locally static
parameters, but it is %s.

Using VITAL Models and Netlists


B-27
# Error VITAL Error Message
Class Reference
Manual
section
number
40 semantic 6.4.3.1.1.1 The initial value of the restricted variable %s
associated with the restricted formal parameter
PeriodPulseData in procedure VitalPeriodPulseCheck
MUST be a VITAL constant or VITAL function with a
locally static parameters, but it is %s.
41 semantic 6.4.3.1.1.1 The initial value of the restricted variable %s
associated with the restricted formal parameter
PreviousDataIn in procedure VitalStateTable can be
only a VITAL constant or a VITAL function with a locally
static parameters, but it is %s.
42 syntax 6.4.3.2 A VITAL process statement cannot be empty.
43 syntax 6.4.3.2.1 The condition in timing check IF statement MUST be
the simple name TimingCheckOn defined in entity %s
as a control generic.
44 semantic 6.4.3.2.1 A VITAL timing check statement can be only a call to
one of { VITAL_Timing, VITALSetupHoldCheck,
VITALRecoveryRemovalCheck,
VITALPeriodPulseCheck }.
45 semantic 6.4.3.2.1 The procedure %s { VITAL_Timing,
VITALSetupHoldCheck,
VITALRecoveryRemovalCheck,
VITALPeriodPulseCheck } MUST be declared in
package VITAL_Timing, but it is declared in %s.
46 semantic 6.4.3.2.1 A call to %s ( One of { VITAL_Timing(),
VITALSetupHoldCheck(),
VITALRecoveryRemovalCheck(),
VITALPeriodPulseCheck() } ) occurred outside a
timing check section.
47 semantic 6.4.3.2.1 The actual part %s associated with the formal
parameter %s (representing a signal name %s) MUST
be locally static.
48 semantic 6.4.3.2.1 The actual %s associated with the formal parameter
HeaderMsg MUST be a globally static expression.
49 semantic 6.4.3.2.1 The actual %s of the timing check procedure %s
associated with a formal parameter %s of type Time
MUST be a locally static expression or simple name
denoting the control generic of the same name.

Using VITAL Models and Netlists


B-28
# Error VITAL Error Message
Class Reference
Manual
section
number
50 semantic 6.4.3.2.1 The actual %s associated with a formal parameter %s
{ XOn, MsgOn } MUST be a globally static expression.
51 semantic 6.4.3.2.1 A function %s call or an operator %s invocation in the
actual part to a formal parameter %s MUST be a
function/operator defined in one of packages
{ Standard, Std_logic_1164, VITAL_Timing }.
52 semantic 6.4.3.2.1 The actual %s associated with the formal parameter
%s { TestSignalName } MUST be locally static
expression.
53 context 6.4.3.2.1 variable %s associated with a timing check violation
parameter %s could not be used in another timing
check statement. It appears in timing check %s.
54 context 6.4.3.2.2 procedure VitalStateTable() MUST be declared in the
package VITAL_Primitives, but it is declared in %s.
55 semantic 6.4.3.2.2 Only a call to the predefined procedure
VitalStateTable() is allowed inside a VITAL
functionality section.
56 semantic 6.4.3.2.2 The actual %s associated with the StateTable
parameter to procedure VitalStateTable MUST be
globally static expression.
57 semantic 6.4.3.2.2 The index constraint on the variable %s associated
with the PreviousDataIn parameter MUST match the
constraint on the actual associated with the DataIn
parameter.
58 semantic 6.4.3.2.2 The target of a VITAL variable assignment MUST be
unrestricted variable denoted by a locally static name,
but it is %s.
59 type 6.4.3.2.2 The target of an assignment statement of a standard
logic type inside a functionality section requires a
primary on the right side to be one of the following:
1. A globally static expression
2. A name of a port or an internal signal
3. A function call to a standard logic function, a VITAL
primitive or VITALTruthTable()
4. An aggregate or a qualified expression with an
aggregate operand
5. A parenthesized expression

Using VITAL Models and Netlists


B-29
# Error VITAL Error Message
Class Reference
Manual
section
number
60 semantic 6.4.3.2.2 A call to function VITALTruthTable CAN NOT occur
outside VITAL functionality section.
61 semantic 6.4.3.2.3 The procedure %s { VITALPathDelay,
VITALPathDelay01, VITALPathDelay01Z } MUST be
defined in package VITAL_Timing, but it is defined in
%s.
62 semantic 6.4.3.2.3 A call to procedure %s { VITALPathDelay,
VITALPathDelay01, VITALPathDelay01Z } CAN NOT
occur outside a path delay section.
63 semantic 6.4.3.2.3 The actual part associated with the formal parameter
OutSignal of a path delay procedure %s
{ VITALPathDelay, VITALPathDelay01,
VITALPathDelay01Z } MUST be a locally static signal
name, but it is %s.
64 semantic 6.4.3.2.3 The actual part associated with the formal parameter
Paths of a path delay procedure %s { VITALPathDelay,
VITALPathDelay01, VITALPathDelay01Z } MUST be
an aggregate, but it is %s.
65 semantic 6.4.3.2.3 The sub-element PathDelay of the actual part
associated with the formal parameter Paths to a path
delay procedure %s { VITALPathDelay,
VITALPathDelay01, VITALPathDelay01Z } MUST be
globally static, but it is %s.
66 semantic 6.4.3.2.3 The subelement InputChangeTime of the actual
associated with the formal parameter Paths %s
{ VITALPathDelay, VITALPathDelay01,
VITALPathDelay01Z } MUST be a LastEvent attribute
or a locally static expression, but it is %s.
67 semantic 6.4.3.2.3 The actual associated with the formal parameter
GlitchMode to a path delay procedure %s MUST be a
literal, but it is %s.
68 semantic 6.4.3.2.3 The actual part associated with the formal parameter
GlitchData MUST be a locally static name, but it is %s.
69 semantic 6.4.3.2.3 The actual part associated with the formal parameter
%s { Xon, MsgOn } MUST be a locally static expression
or a simple name denoting control generic of the same
name, but it is %s.

Using VITAL Models and Netlists


B-30
# Error VITAL Error Message
Class Reference
Manual
section
number
70 semantic 6.4.3.2.3 The actual part associated with the formal parameter
%s { OutSignalName, DefaultDelay, OutputMap }
MUST be a locally static expression.
71 No Check 6.4.3.2.3 Port of type %s { OUT, INOUT, BUFFER } has to be
driven by a VITAL primitive procedure call or a path
delay procedure, but the driver is %s.
72 semantic 6.4.4 The actual associated with the formal parameter %s
of class VARIABLE or SIGNAL on VITAL primitive %s
MUST be a static name, but it is %s.
73 semantic 6.4.4 The actual part associated with the formal parameter
%s of class CONSTANT to a procedure call %s MUST
be a locally static expression, but it is %s.
74 semantic 6.4.4 The actual part associated with the formal parameter
ResultMap to a procedure call %s MUST be a locally
static expression, but it is %s.
75 semantic 6.4.4 The actual part associated with the formal parameter
%s { TruthTable, StateTable } on table primitive
procedure call %s MUST be a constant whose value
expression is an aggregate with fields that are locally
static expressions.
76 No Check 7.1.1 VITAL logic primitive %s MUST be defined in package
%s.
77 No Check 7.3.1 Symbol %s CAN NOT appear in Table %s.
78 No Check 7.3.3.1 Wrong number of inputs to an object %s of type
VitalTruthTable. The number MUST equal to the value
of the DataIn parameter VitalTruthTable.
79 No Check 7.3.3.1 Wrong dimensions for table %s of type %s
{ VitalTruthTable, VitalStateTable }.
80 Package 7.4.3.2.2 procedure VitalStateTable() MUST be declared in
VitalPrimitives, but it is declared in %s.
81 Package 7.4.3.2.3 procedure %s { VITALPathDelay, VITALPathDelay01,
VITALPathDelay01Z } MUST be defined in package
VITAL_Timing, but it is defined in %s.

Using VITAL Models and Netlists


B-31
Using VITAL Models and Netlists
B-32
C
SAIF Support C
You can do power analysis and power optimization using the Synopsys Power
Compiler by entering the power command from the simulator prompt. This
command outputs Switching Activity Interchange Format (SAIF) files for your
design.

Signals and ports are supported for monitoring as well as constructs such as
generates, enumerated types, records, array of arrays, and integers.

Using SAIF files with VCS MX

Note the following when using SAIF files with VCS/VCS MX in the new flow:

• No additional switches are necessary for VCS/VCS MX.


• A Power Compiler specific tab file (and the corresponding library) does not
need to be provided to VCS.
• No additional settings are needed for VCS/VCS MX.

SAIF Support
C-1
• Functionality is built-in to VCS and VCS MX.
If you want to switch to the old flow of dumping SAIF files with the PLI, you can
continue to give "-P $VPOWER_TAB $VPOWER_LIB" to VCS, and the flow will
not use the native support. So, just by removing the PLI-related SAIF arguments
from VCS command line, you can switch to native SAIF support in VCS.

SAIF Calls that can be Used on Verilog or Verilog-Top


Designs

This section describes SAIF calls that can be used at the Verilog or VCS-CLI
prompt.

Note that mixedHdlScope in the following discussion can be one of the following:

• Verilog scope
• VHDL scope
• Mixed HDL scope
Note also that a design_object in the following discussion can be one of the
following:

• Verilog scope or variable


• VHDL scope or variable
• Any MixedHDL scope or variable)

$set_toggle_region
Allows you to define an object or a scope region for which the
switching activity needs to be reported.
Syntax:
$set_toggle_region(design_obj [, design_object]);

SAIF Support
C-2
$toggle_start
Instructs the simulator to start monitoring switching activity.
Syntax:
$toggle_start();

$toggle_stop
Instructs the simulator to stop monitoring switching activity.
Syntax
$toggle_stop();

$toggle_reset
This command sets the toggle counter to 0 for all the nets in the
current toggle region.
Syntax:
$toggle_reset();
$toggle_report
Reports switching activity to an output file.
Syntax:
$toggle_report(<outputFile>, synthesisTimeUnit,
<mixedHdlScope>);
This task has a slight change in native SAIF implementation
compared to PLI-based implementation. Only the arguments
specified here will be considered for processing. Other arguments
have no meaning.

SAIF Support
C-3
$read_lib_saif
Allows you to read in a SDPD library forward SAIF file. It registers the
state and path dependent information on the scope. It also turns on
monitor on internal nets of the design.
Syntax:
$read_lib_saif(<inputFile>);

$read_rtl_saif
Allows the user to read in an RTL forward SAIF file. It registers
synthesis invarient elements by reading forward SAIF file. By default,
it doesn't register internal nets. If neither $read_lib_saif nor
$read_rtl_saif is specified, then also all the internal nets will be
monitored.
Syntax:
$read_rtl_saif(<inputFile>, [, testbench_path_name]);

$set_gate_level_monitoring

Allows the user to turn on/off the monitoring of nets in the design if
both $read_lib_saif and $read_rtl_saif are present in the design.
Syntax:
$set_gate_level_monitoring("on" | "off" | "rtl_on");
"rtl_on": All reg type of objects are monitored for toggles. Net
type of objects are monitored only if it is a cell highconn. This is
the
default monitoring policy.
"off": net type of objects are not monitored.
"on": reg type of objects are monitored only if it is a cell hiconn.

SAIF Support
C-4
For more details on these task calls, refer to Power Compiler User Guide.

Note: The $read_mpm_saif, $toggle_set, and $toggle_count tasks in


the PLI-based vpower.tab file are obsolete and will not be supported.

SAIF Calls that can be Used on VHDL or VHDL-Top


Designs

VHDL's use model mainly consists of user commands at the scsim prompt.

power
-enable
-disable
-reset
-report <filename> <synthesisTimeUnit>
<mixedHdlScope>
-rtl_saif <filename> [<testbench_path_name>]
-gate_level on|off|rtl_on
<region/signal/variable>
-enable
Enables monitoring of switching (toggle_start)
-disable
Disables monitoring of switching (toggle_stop)
-reset
Resets monitoring of switching (toggle_reset)
-report
Reports switching activity to an output file (toggle_report)
-rtl_saif
Reads the RTL forward SAIF file (read_rtl_saif)
-gate_level
Turns on or off the monitoring based on the following:
on: Monitors both ports and signals.

SAIF Support
C-5
off: Does not print ports or signals.
rtl_on: Monitors both ports and signals (same as on)
<region/signal>
Arguments for specifying the following:
region: MixedHDL/VHDL region and its children to consider for
monitoring.
signal: (hierarchical path to) signal name.
NOTE: VHDL variables are not dumped in SAIF SDPD (VHDL gate level) is not
supported in SAIF.

Examples

# power -enable
# power -report

Typical Flow to Dump the Backward SAIF File in a


Verilog or Verilog-Top Design

Generating a backward SAIF file using forward RTL SAIF file:

initial begin
$read_rtl_saif(<inputFile>, <mixedHdlScope>);
$set_toggle_region(<mixedHdlScope>);
// initialization of Verilog signals, and then:
$toggle_start;
// testbench
$toggle_stop;
$toggle_report(<outputFile>, timeUnit,
<mixedHdlScope>);
end

Generating a backward SAIF file without using forward RTL SAIF file:

SAIF Support
C-6
initial begin
$set_gate_level_monitoring("rtl_on");
$set_toggle_region(<mixedHdlScope>);
// initialization of Verilog signals, and then:
$toggle_start;
// testbench
$toggle_stop;
$toggle_report(<outputFile>, timeUnit,
<mixedHdlScope>);
end

Generating an SDPD backward SAIF file using a forward SAIF file:

initial begin
$read_lib_saif(<inputFile>);
$set_toggle_region(<mixedHdlScope>);
// initialization of Verilog signals, and then:
$toggle_start;
// testbench
$toggle_stop;
$toggle_report(<outputFile>, timeUnit,
<mixedHdlScope>);
end

Generating a non-SDPD backward SAIF file without using SAIF files:

initial begin
$set_gate_level_monitoring("on");
$set_toggle_region(<mixedHdlScope>);
// initialization of Verilog signals, and then:
$toggle_start;
// testbench
$toggle_stop;
$toggle_report(<outputFile>, timeUnit,
<mixedHdlScope>);
end

SAIF Support
C-7
Criteria for Choosing Signals for SAIF Dumping

Verilog:

Only scalar wire and reg, as well as vector wire and reg, are supported for
monitoring. All wire/reg declared within functions, tasks and named blocks are
not considered for dump. Bit selects and part selects as arguments to
$set_toggle_region or $toggle_report are not supported. In addition, cell hiconns
will be monitored based on the policy.

VHDL:

Signals are ports are supported for monitoring. Variables are not supported, as
it is difficult to infer latches/flops at RTL level.

Constructs like, generates, enumerated types, records, array of arrays integers


etc, are also supported over and above the basic VHDL types

The following rules are followed regarding the monitoring policy for VHDL:

Port Signals Variables


on Y Y N
off N N N
rtl_on Y Y N

MixedHDL:

The rules for MixedHDL are basically the same as that of VHDL if VHDL is on
top, and Verilog if Verilog is on top.

SAIF Support
C-8
TCL File for MTI Users to Convert Existing SAIF UI
Commands

If you are an MTI user, you can source a TCL file so that you don't have to
convert your existing SAIF UI commands to VCS MX "power" commands.

The script, named "cmdPower.tcl", is installed in the following location:

$VCS_HOME/etc/misc
To use this TCL file and have access to all MTI power commands, enter the
following command at the scsim prompt:

source cmdPower.tcl

SAIF Support
C-9
SAIF Support
C-10
D
Using VCS MX ESI Adapter A
VCS MX ESI Adapter integrates VCS-MX with the Specman Elite
Release 4.2.1 with the ESI interface. This appendix describes how
to prepare a stand-alone VHDL design or mixed VHDL/ Verilog design
for use with the ESI interface. Please refer to the Specman Elite User
Guide for further information.

Note that Specman is implemented as a VHPI foreign architecture.


So, a VHDL stub file called specman.vhd is provided as part of VCS
MX release. It has to be instantiated in the DUT, and you will need
to anlayze the file explicitly.

This appendix covers the following topics:

• Type Support
• Usage Flow

Using VCS MX ESI Adapter


D-1
Type Support

The VCS MX ESI adapter supports the following VHDL types:

• Predefined types
- bit
- boolean
- std_logic/std_ulogic
- character
• User-defined enum types
• in/out/inout/buffer ports
• Access to elements of the following composite types supported:
- Access to individual elements of any of the supported scalar
types
- Predefined types based on any of the supported scalar types
such as string, bit_vector, integer, etc.
The VCS MX ESI adapter supports the following Verilog Types
• nets
• wires
• registers
• integers
• array of registers (verilog memory)

Using VCS MX ESI Adapter


D-2
Other Verilog support:

• Verilog macros
• Verilog tasks
• Verilog functions
• Verilog events
• in/out/inout ports

Usage Flow

The Specman usage model for VCS MX depends upon whether e


code can access both VHDL and Verilog, or just one language. If e
code can access just one language, then you don't have to specify
the unused part.

Setting Up to Run Specman with VCS MX

This section describes how to set up your enviornment to run


Specman with VCS MX:

1. Set your VCS_HOME and SPECMAN_HOME environment


variables:

$ setenv VCS_HOME <vcs mx installation>


$ setenv SPECMAN_HOME <specman installation>

2. Source you env.csh file for Specman:

source ${SPECMAN_HOME}/env.csh

Using VCS MX ESI Adapter


D-3
3. Set your environment for the VCS MX Specman ESI adapter:
- In 7.0.x releases:

% setenv SPECMAN_VCSMX_VHDL_ADAPTER $VCS_HOME/


$ARCH/sim/lib/libvhdl_sn_adapter.so
- In in 7.1.x releases:

$ setenv SPECMAN_VCSMX_VHDL_ADAPTER ${VCS_HOME}/${ARCH}/


lib/libvhdl_sn_adapter.so

4. Set your environment to run e code in loaded mode (default


mode):

$ setenv SPECMAN_DLIB ${SPECMAN_HOME}/`${SPECMAN_HOME}/


bin/sn_arch.sh`/libspecman.so

or set your environment to run run e code in compiled mode:

% $SPECMAN_HOME/bin/sn_compile.sh -shlib xor_verify


% setenv SPECMAN_DLIB `pwd`/libsn_<xor_verify>.so

Note that VCS MX Specman ESI adapter is implemented as a vhpi


foreign architecture. So, a VHDL stub file called 'specman.vhd' is
provided as part of VCS MX release. It has to be instantiated in DUT
and user needs to anlayze the file explicitly. The file is located under
your VCS MX installation ($VCS_HOME/packages/synopsys/src/
specman.vhd)

Using VCS MX ESI Adapter


D-4
VHDL Only Flow

There are two methods of running VHDL only. You can load the ecode
before compiling the design. or you can load the e code at run time.
as shown below.

1. Instantiate SPECMAN_REFERENCE in the top VHDL design, for


example:
component specman
end component;
for all: specman use entity
work.SPECMAN_REFERENCE(arch);

2. Analyze the VHDL stub file provided by VCS MX.


$ vhdlan $VCS_HOME/packages/synopsys/src/specman.vhd
$ vhdlan <vhdl source files>

3. Compile the e code.


4. Compile the HDL design.
$ sn_compile.sh -shlib <top e module>

5. Elaborate the design.


$ scs <config>

6. Simulate the HDL design.


$ scsim
To load the e code at run time, do not compile the e code before
compiling the HDL design (step 4 above). Instead, load the e code
after invoking scsim (step 6 above) by executing the following
commands:

Using VCS MX ESI Adapter


D-5
sn load <top e module>
sn test

VHDL-Top Flows

The VHDL-top flow you use depend on whether e code accesses


only the VHDL part of an MX Design, or both VHDL and Verilog.

MX Flow When e Code Accesses Only VHDL


The following flow applies when e code accesses only the VHDL part
of an MX design:

1. Analyze your Verilog code:


$ vlogan <verilog files>

2. Analyze the VHDL stub file:


$ vhdlan $VCS_HOME/packages/synopsys/src/specman.vhd

3. Analyze the design:


$ vhdlan <vhdl files of design>

4. Elaborate the design


$ scs [-mhdl] C [-verilogcomp " ..... "]

5. Compile e code and create a shared library object, called


libsn_<top e module name>.so. This is necessary to run
a VHDL simulation with e code.
$SPECMAN_HOME/bin/sn_compile.sh -shlib <top e module
name>

Loaded mode:

Using VCS MX ESI Adapter


D-6
scsim
# sn
Specman> load <top e module name>
Specman_top> test
# run
# quit

Compiled mode:

setenv SPECMAN_DLIB libsn_<top e module name>.so


setenv LD_LIBRARY_PATH .:$LD_LIBRARY_PATH

6. Run the simulation


scsim

# sn
Specman_top> test
# run
# quit

MX Flow When e Code Accesses Both VHDL and Verilog


The following flow applies when e code accesses both the VHDL and
Verilog parts of an MX design. The flow depends on whether you are
running loaded or unloaded mode.

For loaded mode:

1. Generate a Verilog stub file.


$ specman -c "load <top>; write stub -verilog"

2. Analyze the generated Verilog stub and supplied VHDL stub file.
$ vlogan specman.v
$ vlogan <verilog files>
$ vhdlan ${VCS_HOME}/packages/synopsys/src/specman.vhd
$ vhdlan

Using VCS MX ESI Adapter


D-7
3. Compile and elaborate your design:
$ scs -mhdl C -vltop specman -vltop specman_wave \
-verilogcomp "-P $SPECMAN_HOME/src/pli.tab \
$SPECMAN_HOME/$SPECMAN_ARCH/specman_main__.o \
$SPECMAN_HOME/$SPCEMAN_ARCH/libvcs_sn_boot.a \
$SPECMAN_HOME/$SPCEMAN_ARCH/libspecman.a"

4. Set the SPECMAN_ARCH environement variable.


$ setenv SPECMAN_ARCH `${SPECMAN_HOME}/bin/sn_arch.sh`

5. Compile the design


$ scs -mhdl C -vltop specman -vltop specman_wave
-verilogcomp "${SPECMAN_HOME}/src/pli.tab
${SPECMAN_HOME}/${SPECMAN_ARCH}/specman_main__.o
${SPECMAN_HOME}/${SPCEMAN_ARCH}/libvcs_sn_boot.a
${SPECMAN_HOME}/${SPCEMAN_ARCH}/libspecman.a"
$ sn_compile.sh -shlib <top e>

6. Set the SPECMAN_VCSMX_VHDL_ADAPTER environment


variable:
$ setenv SPECMAN_VCSMX_VHDL_ADAPTER ${VCS_HOME}/${ARCH}/
/lib/libvhdl_sn_adapter.so

7. Run the simulation:


$ scsim

Compiled Mode:

1. Generate a Verilog stub file.


$ specman -c "load xor_verify.e; write stub -verilog"

2. Analyze the generated Verilog stub and supplied VHDL stub file.
$ vlogan specman.v
$ vlogan <verilog files>

Using VCS MX ESI Adapter


D-8
$ vhdlan ${VCS_HOME}/packages/synopsys/src/specman.vhd
$ vhdlan

3. Compile and elaborate your design:


$ scs -mhdl C -vltop specman -vltop specman_wave \
-verilogcomp "-P $SPECMAN_HOME/src/pli.tab \
$SPECMAN_HOME/$SPECMAN_ARCH/specman_main__.o \
$SPECMAN_HOME/$SPCEMAN_ARCH/libvcs_sn_boot.a \
$SPECMAN_HOME/$SPCEMAN_ARCH/libspecman.a"
sn_compile.sh -t sn_work xor_verify.e

4. Compile the design


$ scs -mhdl C -vltop specman -vltop specman_wave \
-verilogcomp "-P $SPECMAN_HOME/src/pli.tab \
pwd`/sn_work/xor_verify__.o \
pwd`/sn_work/xor_verify_main_.o \
$SPECMAN_HOME/$SPCEMAN_ARCH/libvcs_sn_boot.a \
$SPECMAN_HOME/$SPCEMAN_ARCH/libspecman.a"

5. Run the simulation:


$ scsim

Using VCS MX ESI Adapter


D-9
Verilog-Top Flows

The Verilg-top flow you use depend on whether e code accesses only
the Verilog part of an MX Design, or both VHDL and Verilog.

MX Flow When e Code Accesses Only Verilog


You can run in either loaded or compiled mode.

Loaded Mode:

1. Generate a Verilog stub file:


$ specman -c "load xor_verify.e; write stub -verilog"

2. Compile the design:


$ sn_compile.sh -sim vcs -simflags "[-mhdl] specman.v
<verilog files> [-vhdlelab ' ... ' ]"

3. Run the simulation:


$ vcs_specman -s
Cli> $sn
Specman> load xor_verify
Specman_xor_verify> test
Cli> .
Cli> quit

Compiled Mode:

1. Compile the design:


$ sn_compile.sh -sim vcs -simflags "[-mhdl] specman.v
<verilog files> [-vhdlelab ' ... ' ]" xor_verify.e

2. Run the simulation:

Using VCS MX ESI Adapter


D-10
$ vcs_xor_verify -s
Cli> $sn
Specman_xor_verify> test
Cli> .
Cli> quit

MX Flow When e Code Accesses Both Verilog and VHDL


You can run in either loaded or compiled mode.

Loaded Mode:

1. Analyze the supplied VHDL stub file:


$ vhdlan $VCS_HOME/packages/synopsys/src/specman.vhd

2. Analyze the VHDL design portion.


$ vhdlan <vhdl sources>

3. Set the SPECMAN_VCSMX_VHDL_ADAPTER environment


variable:
$ setenv SPECMAN_VCSMX_VHDL_ADAPTER $VCS_HOME/$ARCH/sim/
lib/libvhdl_sn_adapter.so

4. Generate the Verilog stub file:


$ specman -c "load xor_verify.e; write stub -verilog"

5. Compile the design:


$ sn_compile.sh -sim vcs -simflags "[-mhdl] specman.v
<verilog files> [-vhdlelab ' ... ' ]"

6. Run the simulation:


$ vcs_specman -s
Cli> $sn

Using VCS MX ESI Adapter


D-11
Specman> load xor_verify
Specman_xor_verify> test
Cli> .
Cli> quit

Compiled Mode:

1. Compile the design:


$ sn_compile.sh -sim vcs -simflags "[-mhdl] specman.v
<verilog files> [-vhdlelab ' ... ' ]" xor_verify.e

2. Run the simulation:


$ vcs_xor_verify -s
Cli> $sn
Specman_xor_verify> test
Cli> .
Cli> quit

Displaying Specman Elite Objects in VCS MX VirSim


Waveform Viewer

This section explains the steps required to display Specman Elite


objects in the VCS MX VirSim waveform viewer.

Specman Elite supports the display of Specman Elite objects in the


VCS MX VirSim waveform viewer when the simulation mode (design)
is pure Verilog or MixedHDL (Verilog and VHDL). Specman Elite does
not support the display of Specman Elite objects in pure VHDL
simulation mode (design). However, you can convert a pure VHDL
design into a Mixed HDL design by adding a dummy Verilog module
into the VHDL testbench. this process will then enable you to display
Specman Elite objects in the waveform viewer.

Using VCS MX ESI Adapter


D-12
Using Specman Elite with Waveform Viewers

To display Specman Elite objects in a waveform viewer, Specman


Elite creates a configuration file named wave_top-module-name.ext.
This configuration file contains the definitions of all wave commands
issued in the Specman Elite environment ,and is updated each time
you enter a new wave command. The filename extension is
determined by the waveform viewer and assigned automatically (.cfg
for VirSim).

A Specman Elite configuration category, wave, has options you can


specify to set up the waveform display. You use the configure wave
command, or the set_config(wave, option, value) routine to set the
options.

One of the wave configuration options is working_mode. Specman


Elite has three working modes for waveform viewers:

• Off_line — used for batch operation, in this mode, Specman Elite


only creates a top waveform configuration file, not command-
specific configuration files.
• Manual — enables you to load the top waveform configuration
file manually into the waveform viewer after you enter wave
commands. If you enter a wave command after you load the top
configuration file, you must manually load the command-specific
configuration file.
• Interactive — enables you to add Specman Elite objects to the
waveform viewer during the test run, using wave commands. The
objects you add are traced and displayed in the viewer from that
point on.

Using VCS MX ESI Adapter


D-13
Note that the VCS MX VirSim waveform viewer can be used only in
off_line working mode. This is the post-processing mode for VirSim.

For a complete description of all wave configuration options, see the


"Configure Wave" section in the Specman Elite Command Reference
Guide of the Specman Elite distribution.

Using Specman Elite with the VirSim Waveform Viewer

To display Specman Elite objects in the VirSim viewer, you must


perform several tasks in sequence. These tasks are described in the
following sections:

• Setting up the VirSim Waveform Viewer


• Invoking Specman Elite with the VirSim Viewer
• Adding a Specman Elite Object to the VirSim Viewer

Setting up the VirSim Waveform Viewer


The following tasks enable you to set up the waveform viewer for
Specman Elite:

• Setting waveform configuration options


• Creating the HDL stubs file
• Loading the specman_wave file
Note that setting configuration options is an optional task, but you
must link Specman Elite with the VCS MX simulator, and you must
create an HDL stubs file in order to enable waveform integration.

Using VCS MX ESI Adapter


D-14
Setting Waveform Configuration Options for VirSim
There are several types of waveform configuration options:

• Options that affect the number of objects you can display in the
waveform viewer
• Options that affect the amount of information displayed for certain
types of objects
• Options that affect the way you can work with the viewer
The options that affect the number of Specman Elite objects you can
display in the viewer also affect the contents of the stubs file. The
stubs file contains a specman_wave module that defines a default
number of registers of various typesóoutput message, error
message, string, integer, boolean, and, for Verilog simulators only,
event types. If you use up all the registers of a particular type, you
cannot add more objects of that type to the waveform display without
rewriting the stubs file.

To avoid having to rewrite and recompile the new stubs file and then
re-invoke the simulation run, it makes sense to consider what
additional resources your verification environment normally requires
and set those configuration options in the e code using the
set_config(wave) routine.

The following example shows how to set wave configuration options


from e code by extending the sys.wave_setup() method:

extend sys {
wave_setup() is also {
set_config(wave, stub_errors, 3);
};
};

Using VCS MX ESI Adapter


D-15
For a complete list of all wave configuration options that affect the
stubs file, see the "Using a Waveform Viewer" chapter in the Specman
Elite Usage and Concepts Guide in Specman Elite distribution.

Invoking Specman Elite with the VirSim Viewer


After setting the waveform options and creating the stubs file, as
described above, you are ready to compile the HDL design and invoke
Specman Elite with the VCS MX simulator.

The compile procedure is demonstrated in the examples in the


following sections.

You can view Specman Elite objects in the VirSim viewer after a batch
run has completed.

Invoking the VirSim Viewer after a Batch Run


To invoke Specman Elite in batch mode and collect waveform data
for viewing later, you should invoke specsim, rather than specview,
as shown in the following example:

specsim -p "@batch.ecom;load test1;test -seed=7593;" \


./vcs_cpu_top -i batch.cmd -s -f vfiles.lst >& test1.log

This example assumes that you compiled all the e code into a shared
library. This example also shows two command files: batch.cmd is a
simulator command file, and batch.ecom is a Specman Elite
command file.

The following example shows a sample Specman Elite batch.ecom


command file appropriate for batch mode:

Using VCS MX ESI Adapter


D-16
1 config run -exit_on=all;
2 set check ERROR;
3 set wave -mode=off_line virsim
4 wave exp -fields sys.cpu.next_instr
5 wave exp -events -threads sys.cpu
6 wave out

A description of file is as follows:

• Lines 1-2 — These commands require Specman Elite to terminate


the simulation run if a DUT error or a Specman Elite error occurs.

• Line 3 — This command specifies VirSim as the viewer and the


mode as batch. Specman Elite creates a single, top-level
configuration file that you can manually load into the viewer at any
point after the simulation run. The name of the file has the format
wave_top-module.cfg. For example, if the name of the top-level
e module is cpu_top, the name of the configuration file is
wave_cpu_top.cfg.

• Lines 4-6 — These commands specify the Specman Elite objects


that you want to display in the waveform viewer.

Generating the verilog.dump file


Since the signal data is saved in a verilog.dump file, you must execute
the dumpvars system call prior to, or, at the beginning of simulation.
In VCS MX, add $dumpvars to some initial block in the Verilog code.

Viewing the Waveforms in VirSim from a Batch Run


To view the waveforms from a batch run, you must load the waveform
configuration file into the VirSim viewer. The viewing procedure is
demonstrated in the examples in the following sections.

Using VCS MX ESI Adapter


D-17
Adding a Specman Elite Object to the VirSim Viewer
The VirSim viewer can display only one signal group at a time. To
see signals from multiple groups, you can manually merge groups
and then load the merged group into the viewer, or you can use
several synchronized viewers at once.

Also, group names cannot be specified in Specman Elite.

To add Specman Elite objects to the waveform display, use one of


the following commands, depending on the type of object you want
to display:

ï wave [exp]
ï wave event
ï wave out

You can execute these commands from a command file or at the


Specman> prompt. You can execute additional wave commands at
any point during a simulation run. To review the wave commands you
have executed, use the show wave command.

In off_line mode, Specman Elite creates a single configuration file


that you can use at a later point to load the waveform data into viewer.

For more information on using wave command, see the "Waveform


Related Commands" chapter in the Specman Elite Command
Reference Guide of the Specman Elite distribution.

Using VCS MX ESI Adapter


D-18
Using Specman Elite with VirSim Waveform Viewer
Examples

The following two examples explain in detail the procedure to use


Specman Elite to display Specman Elite objects in the VirSim
waveform viewer for two Mixed HDL scenarios: one with a Verilog-
top testbench, and another with a VHDL-top testbench.

The same procedure of the Mixed HDL with Verilog -op testbench
applies for a pure Verilog design, but with minor modification in the
HDL compile step (remove the -mhdl VCS compile option).

Mixed HDL Design with Verilog-Top Testbench Example


The example used in this section is based on the xor example
distributed as part of the Specman Elite distribution. The original xor
example is modified to create a scenario that shows VCS MX
simulation in Mixed HDL mode with a Verilog-top testbench. The e
code in this example accesses only the Verilog code of the design.

The example has the following files:

• xor_verify.e — e code that tests the xor model


• verilog_code.e — Verilog code inserted from Specman to call
$dumpvars
• vl_xor.v — Verilog code that models xor behavior
• vh_xor.vhd — VHDL code that models xor behavior
• xor_tb.v — Verilog code that represents the Verilog top testbench
• synopsys_sim.setup — VCS MX setup file

Using VCS MX ESI Adapter


D-19
• wave.ecom — Specman command file
• cmd.in — VCS MX command file

xor_verify.e File
<'
struct verify_struct {
!ops: list of operation;
!oper: operation;
event xor_clk is fall('xor_tb.clk') @sim;
verify() @xor_clk is {
for i from 0 to 10 do {
gen oper;
ops.insert(0,oper);
inject(oper);
oper.result_from_dut = 'xor_tb.vl_out';
print 'xor_tb.vl_out';
print (oper.a ^ oper.b);
print sys.time;
check that oper.result_from_dut == (oper.a ^ oper.b);
wait cycle;
};
stop_run();
};
inject(oper: operation) @xor_clk is {
'xor_tb.inp' = pack(NULL,oper);
wait cycle;
};
};

struct operation {
%a: uint (bits: 1);
%b: uint (bits: 1);

!result_from_dut: int;
};

extend sys {
verify_struct;

Using VCS MX ESI Adapter


D-20
run() is also {
start verify_struct.verify();
};
};
'>

verilog_code.e
<'
verilog code {
"";
" initial begin";
" $dumpvars;";
" end";
"";
};
'>

vl_xor.v
module vl_xor (in1, in2, out1);
input in1;
input in2;
output out1;
assign out1 = in1 ^ in2;
endmodule

vh_xor.vhd
library IEEE; use IEEE.std_logic_1164.all;

entity vh_xor is
port (in1, in2: in std_logic; out1: out std_logic);
end;

architecture A of vh_xor is
begin

Using VCS MX ESI Adapter


D-21
out1 <= in1 xor in2;
end A;

xor_tb.v
`timescale 1 ns / 1 ns
module xor_tb;
reg [1:0] inp; // The two-bit inputs to the XOR
reg vl_out; // The XOR output
reg vh_out; // The XOR output
reg clk;
wire vl_out1_sig;
wire vh_out1_sig;

initial clk = 1'b1;


always #50 clk = ~clk; // The clock

// Verilog instance
vl_xor u_vl_xor (inp[0], inp[1], vl_out1_sig);

// VHDL instance
vh_xor u_vh_xor (inp[0], inp[1], vh_out1_sig);

always @(posedge clk) begin


vl_out = #1 vl_out1_sig;
vh_out = #1 vh_out1_sig;
end
endmodule

wave.ecom
load xor_verify.e
test
wave exp sys.verify_struct.ops
wave exp sys.verify_struct.oper
wave exp sys.verify_struct
wave event *.xor_clk

Using VCS MX ESI Adapter


D-22
cmd.in
call {$sn(" set wave virsim;")}
call {$sn(" config wave -event_data=all_data;")}
call {$sn(" load verilog_code.e;")}
call {$sn(" @wave;")}
. //dot for the run command in VCS
quit

The procedure to compile and run the example is as follows:

1. Set up the VCS MX and Specman Elite tools and licenses.

2. Analyze the VHDL component. Example:

vhdlan -nc vh_xor.vhd

3. Analyze the Verilog component. Example:

vlogan -q -timescale=1ns/1ns vl_xor.v

4. Generate the specman.v stubs file. Example:

specman -command "load verilog_code.e ;load xor_verify.e;


write stubs -verilog"

5. Compile the rest of the design and generate the simulation


executable. Example:

$SPECMAN_HOME/bin/sn_compile.sh -sim vcs -sim_flags


"xor_tb.v specman.v -mhdl"

6. Run the simulation in batch mode.

specsim ./vcs_specman -s -i cmd.in

Note: In this step, Specman Elite generates VirSim configuration


file sn_wave_xor_verify.cfg.

Using VCS MX ESI Adapter


D-23
After the simulation is completed, do the following to see the traced
Specman Elite objects in VirSim waveform viewer:

1. Invoke the VCS MX graphical user interface (VirSim) in post-


processing mode.

vcs -RPP &

The hierarchy browser window will appear

2. From the hierarchy browser window, open the waveform viewer.

3. In the waveform viewer, select File > Open.

4. In the Open File dialog box, set the Type to VCD.

5. In the Open File dialog box, select the verilog.dump file.

6. Click OK in the Open File dialog box.

7. In the waveform viewer, select File > Load Configuration.

8. In the Load Configuration dialog box, turn on Incremental Load.

9. Select the top-level wave configuration file


sn_wave_xor_verify.cfg and click OK.

The waveform viewer will disappear if Incremental Load was not


selected. In this case, re-open the waveform viewer.

10. Select the group to be viewed (top left icon). Only one group at a
time will be displayed.

The waveforms for the Specman Elite objects will appear in the
waveform viewer.

Using VCS MX ESI Adapter


D-24
Mixed HDL Design with VHDL-Top Testbench

The example used in this section is based on the xor example that is
distributed as part of the Specman Elite distribution. The original xor
example is modified to create a scenario that shows VCS MX
simulation in Mixed HDL mode with a VHDL top testbench. The e
code in this example accesses both the Verilog and the VHDL code
of the design.

The example has the following files:

• xor_verify.e — e code that tests the xor model


• verilog_code.e — Verilog code inserted from Specman to call
$dumpvars
• xor.v — Verilog code that models xor behavior
• xor_tb.vhd — VHDL code that represents the VHDL-top testbench
• synopsys_sim.setup — VCS MX setup file
• wave.ecom -- Specman command file
• cmd.in -- VCS MX command file

xor_verify.e
<'
----------------------------------------------------------
-- XOR operation definition
----------------------------------------------------------
struct operation {
-- Physical fields
%a: uint (bits: 1); -- First input
%b: uint (bits: 1); -- Second input
xor_result: int; -- Output reference
keep xor_result == (a ^ b);

Using VCS MX ESI Adapter


D-25
};
----------------------------------------------------------
-- Topmost xor unit instantiation
----------------------------------------------------------
extend sys {
xor_top: xor_top_unit is instance;
keep xor_top.hdl_path() == "~/xor_tb"; // Topmost unit path
// Using canonical name ensures simulator/language independency
keep xor_top.agent() == "VHDL"; // Topmost unit agent to be VHDL
// Agent definition can be done only by constraints
};
--------------------------------------------------------------
-- xor_top unit definition (VHDL)
--------------------------------------------------------------
unit xor_top_unit {
p_clock: in simple_port of bit is instance;
keep bind(p_clock,external);
keep p_clock.hdl_path() == "clock";
p_xor_in1: inout simple_port of bit is instance;
keep bind(p_xor_in1,external);
keep p_xor_in1.hdl_path() == "xor_in1";
p_xor_in2: inout simple_port of bit is instance;
keep bind(p_xor_in2,external);
keep p_xor_in2.hdl_path() == "xor_in2";
p_xor_out: inout simple_port of bit is instance;
keep bind(p_xor_out,external);
keep p_xor_out.hdl_path() == "xor_out";

event clock is rise(p_clock$)@sim; // A clock in the VHDL domain

xor : xor_try_unit is instance;


keep xor.hdl_path() == "u_vl_xor"; // xor_try unit path

keep xor.agent() == "Verilog"; // xor_try unit agent to be Verilog


// Agent definition can be done only by constraints

operations : list of operation;


keep operations.size() == 10; // Inputs to be injected into the DUT
keep xor.operations == operations;

drive() @me.clock is {
for each (op) in operations do {
print op;
out("

// Drive
p_xor_in1$ = op.a; // Accessing VHDL signals
p_xor_in2$ = op.b;

Using VCS MX ESI Adapter


D-26
wait cycle;

// Print state of the DUT top component


out("Time: ",sys.time, " ", agent(),
// Use the the pseudo method agent() in messages
" 'xor_in1' = ",p_xor_in1$," 'xor_in2' = ",p_xor_in2$,"\
'xor_out' = ",p_xor_out$,"

// Check the xor operation correctness


check that p_xor_in1$ == op.a;
check that p_xor_in2$ == op.b;
check that p_xor_out$ == op.xor_result;
};
stop_run();
};

run() is also {
start drive();
};
};
--------------------------------------------------------------
-- xor_try definition (Verilog)
--------------------------------------------------------------
unit xor_try_unit {
p_clk: in simple_port of bit is instance;
keep bind(p_clk,external);
keep p_clk.hdl_path() == "clk";
p_xor_in1: inout simple_port of bit is instance;
keep bind(p_xor_in1,external);
keep p_xor_in1.hdl_path() == "xor_in1";
p_xor_in2: inout simple_port of bit is instance;
keep bind(p_xor_in2,external);
keep p_xor_in2.hdl_path() == "xor_in2";
p_xor_out: inout simple_port of bit is instance;
keep bind(p_xor_out,external);
keep p_xor_out.hdl_path() == "xor_out";

event clk is rise(p_clk$)@sim; // A clock in the Verilog domain

operations : list of operation;

monitor() @me.clk is {

for each (op) in operations do {


wait cycle;

// Print state of the DUT low-level component


out("Time: ",sys.time, " ", agent(),

Using VCS MX ESI Adapter


D-27
// Use the the pseudo method agent() in messages
" 'xor_in1' = ",p_xor_in1$," 'xor_in2' = ",p_xor_in2$,"\
'xor_out' = ",p_xor_out$,"

// Check the xor operation correctness


check that p_xor_in1$ == op.a;
check that p_xor_in2$ == op.b;
check that p_xor_out$ == op.xor_result;

};
};
run() is also {
start monitor();
};
};
'>

verilog_code.e
<'
verilog code {
"";
" initial begin";
" $dumpvars;";
" end";
"";
};
'>

xor.v
module xor_module (clk,xor_in1,xor_in2,xor_out);
input clk;
input xor_in1,xor_in2;
output xor_out;
reg xor_out;

always @(posedge clk) begin


xor_out = (xor_in1 ^ xor_in2);
end
endmodule

Using VCS MX ESI Adapter


D-28
xor_tb.vhd
library IEEE; use IEEE.std_logic_1164.all;

entity xor_tb is
end xor_tb;

architecture rtl_code of xor_tb is


signal clock : std_logic := '0';
signal xor_in1 : std_logic;
signal xor_in2 : std_logic;
signal xor_out : std_logic;

-- Verilog module
component xor_component
port(clk : in std_logic; xor_in1, xor_in2 : in std_logic;\
xor_out : out std_logic);
end component;

for all: xor_component use entity work.XOR_MODULE(VERILOG);

-- Specman foreign entity


component specman
end component;
for all: specman use entity work.SPECMAN_REFERENCE(arch);

begin
sn : specman;
u_vl_xor : xor_component port map (clock,xor_in1,xor_in2,xor_out);
clock <= not clock after 20 ns;

end rtl_code;

wave.ecom
load xor_verify.e
test
wave exp sys.xor_top.xor.operations
wave event *.clock
wave event *.clk

Using VCS MX ESI Adapter


D-29
cmd.in
sn set wave virsim
sn config wave -event_data=all_data
sn load verilog_code.e
sn load xor_verify
sn test
sn @wave
run
quit

The procedure to compile and run the example is as follows:

1. Setup the VCS MX and Specman Elite tools and licenses.

2. Generate 'specman.v' Verilog stubs file.

specman -command "load verilog_code.e ;load xor_verify.e;\


write stubs -verilog"

3. Analyze Verilog components (including Verilog stubs file).

vlogan -q -timescale=1ns/1ns xor.v specman.v

4. Analyze VHDL components (including VHDL stubs file).

vhdlan -nc $VCS_HOME/packages/synopsys/src/specman.vhd\


xor_tb.vhd

5. Elaborate and compile the design and generate the simulation


executable. In this step, specman and specman_wave modules
are added to the design environment to enable the display of
Specman Elite objects through the Verilog stubs file.

scs -nc xor_tb -vltop specman -vltop specman_wave \


-verilogcomp "-P $SPECMAN_HOME/src/pli.tab \
$SPECMAN_HOME/$SPECMAN_ARCH/specman__main_.o \
$SPECMAN_HOME/$SPECMAN_ARCH/libvcs_sn_boot.a \
$SPECMAN_HOME/$SPECMAN_ARCH/libspecman.a "

Using VCS MX ESI Adapter


D-30
Note the following:
- -verilogcomp Indicates mixedHDL simulation
- -vltop adds specman and specman_wave as Verilog top
modules

This step generates the simulation executable, scsim.

6. Run the simulation in batch mode.

./scsim -nc -i cmd.in

In this step, Specman Elite generates the VirSim configuration file


sn_wave_xor_verify.cfg.

After the simulation is completed, perform the following steps to see


the traced Specman Elite objects in VirSim waveform viewer:

1. Invoke the VCS MX graphical user interface (VirSim) in post-


processing mode.

scirocco -pp &

The hierarchy browser window will appear.

2. From the Hierarchy Browser window, open the waveform viewer.

3. In the waveform viewer, select File > Open.


4. In the Open File dialog box, set the Type to VCD.
5. In the Open File dialog box, select the verilog.dump file.
6. Click OK in the Open File dialog.
7. In the Waveform Viewer, select File > Load Configuration.
8. In the Load Configuration dialog box, turn on Incremental Load.

Using VCS MX ESI Adapter


D-31
9. Select the top-level wave configuration file
sn_wave_xor_verify.cfg and click OK.
The waveform viewer will disappear if Incremental Load was not
selected. In this case re-open the waveform viewer.
10. Select the group to be viewed (top left icon). Only one group at a
time will be displayed.
The waveforms for the Specman Elite objects will appear in the
waveform viewer.
Note: The examples were verified using VCS MX version 7.1 and
Specman Elite version 4.3.

Using VCS MX ESI Adapter


D-32
E
Using Extended SystemVerilog Datatypes on
MX Boundary A
SystemVerilog supports a rich set of complex datatypes, and also
allows the instantiation of ports with these new complex datatypes.
This enables modules to exchange data between the complex types.
VCS MX enables the exchange of the complex datatypes across the
MX boundary.

The following datatypes are upported across the MX boundary layer:

• All SystemVerilog Basic 2- and 4-state Integer Types


• Enumerated Types
• Structures/Records
• Unpacked Arrays (partial support)

Using Extended SystemVerilog Datatypes on MX Boundary


E-1
Integer Types

This section describes the supported SystemVerilog integer


datatypes and the corresponding mapping required on the VHDL
side.

The following SystemVerilog integer types are supported

• shortint : 2-state, 16 bit, signed integer


• int: 2-state, 32 bit, signed integer
• longint: 2-state, 64 bit, signed integer
• byte: 2-state, 8 bit, signed integer
• bit: 2-state, user-defined vector size
• logic: 4-state, user-defined vector size
• reg: 4-state, user-defined vector size

The following VHDL integer types are supported.

• integer: 2-state, 32 bit, signed integer


• bit and bit_vector: 2-state, user-defined vector size
• std_logic/std_ulogic/std_logic_vector/std_ulogic_vector : 9 -
state, user-defined vector size

Using Extended SystemVerilog Datatypes on MX Boundary


E2
The following table provides a list of matching datatypes across the
MX boundary. The X axis lists all the VHDL datatypes, and the Y axis
lists the SystemVerilog datatypes:
.

VHDL Types
Integer Integer Bit Sstd_logic Sstd_ulogic
Sutype1 vector2 vector2 vector2
Shortint Yes Yes Yes Yes Yes
Int Yes Yes Yes Yes Yes
SystemVerilog Types

Longint Yes Yes Yes Yes Yes


Byte Yes Yes Yes Yes Yes
Bit_vector Yes Yes Yes Yes Yes
Logic No No Yes Yes Yes
Logic_vector Yes Yes Yes Yes Yes
Integer Yes Yes Yes Yes Yes

1 Anonymous integer subtype not yet supported. Eg) inputPort : in range 0 to 3 of integer;
is not yet supported

2A
size match is required. For eg., if the port in SystemVerilog is a shortint, then in the
VHDL entity that instantiates the SystemVer-ilog module, the bit-vector signal that
connects to the shortint port should be of size 16, since shortint is 16 bit wide.

Note that VCS MX supports 2-state, 4-state and 9-state ports to


communicate with each other. A size match is required if the VHDL
port is a vector type.

Using Extended SystemVerilog Datatypes on MX Boundary


E-3
Enummerated Types

SystemVerilog supports enumerated types across the ports. Three


characteristics can be attributed to SystemVerilog enumerated types
as given below.

• Base type of the enumerated type:


A SystemVerilog enumerated type can have a base type
indicating that all the members are repre-sented using the base
type.
For example:
typedef enum byte { red = 10, blue = 20, green =
30 } Colors;
In the above example, the enum's base type is byte. So all the
enumerated members' (red, blue, green) value will be represented
in terms of byte (8 bit integer type). However, VHDL does not have
any such base type.
• User encoded values:
A SystemVerilog enumerated type can have user-defined values
supplied to the enumerated mem-bers. In the example below, the
member red is assigned a value 10.
For example:
typedef enum byte { red = 10, blue = 20, green
= 30 } Colors;
Note that VHDL does not have any such user-defined encoding
values for enumerated types.
• Number of members in the enumeration.

Using Extended SystemVerilog Datatypes on MX Boundary


E4
This indicates what values a variable of the enumeration type can
possibly take. In the example below, the enumerated type has 3
members. So a variable of type Colors can take only 3 values
correspond-ing to red, blue and green.
For example:
typedef enum byte { red = 10, blue = 20, green =
30 } Colors;
Note that VCS MX supports enumerated types across the port
boundary as long as they satisfy the following conditions:
- Enumerated types with user encoded values will not be
supported
- Exact name match of the elements in the VHDL and
SystemVerilog enumerated types is re-quired. However the
enumerated type name itself need not match. In the example
above the type name Colors need not match in SystemVerilog
and VHDL but the members name red, blue and green should
match. However, it is not case-sensitive match.
- The order of the enumerated members should be same on both
SystemVerilog and VHDL.
- The number of enumerated members should be the same on
both SystemVerilog and VHDL.

Using Extended SystemVerilog Datatypes on MX Boundary


E-5
Structures/ Records

Structures / Records provide a useful mechanism for grouping related


data together. SystemVerilog supports two kinds of structs:

• Packed — A struct whose members are all of packed types


(prefixed with the packed key-word). It cannot contain fields of
type unpacked arrays, real, time etc
For example:
typedef struct packed { logic [0:31] destAddress;
int data;
bit [0:3] parity;
} PayLoad;

• Unpacked — A struct whose members need not be of packed


type.
For example:
) typedef struct { logic [0:31] destAddress;
int data;
bit [0:3] parity;
time timestamp;
}PayLoad;

Note that the VHDL equivalent of a SystemVerilog struct is a record.


VHDL does not have packed records.

The following rules apply for the exchange of SystemVerilog struct /


VHDL records across the MX boundary.

Using Extended SystemVerilog Datatypes on MX Boundary


E6
• Only SystemVerilog packed structs are supported
• Number of fields in the SystemVerilog struct and the VHDL record
should be the same
• Each field of the struct should match the corresponding field of
the VHDL record in size.
• The type of the field should be compatible (as indicated in the
previous sections).

Arrays

SystemVerilog introduces the concept of unpacked arrays in addition


to the Verilog packed arrays.

For example:

bit [3:0][7:0] joe [1:10][1:9];

The previous example defines an array of bits. The array contains 90


entries where each entry consists of 4 bytes. The dimensions
[1:10][1:9] are called unpacked dimensions while [3:0][7:0] are called
packed dimensions.

For supporting exchange of such arrays across VCS MX boundary,


the following rules apply.

• If there is a packed dimension in SystemVerilog, the VHDL side


should have a bit_vector or std_logic_vector. The length of the
bit_vector or std_logic_vector in VHDL should match the
combined packed dimensions in the SystemVerilog side.

Using Extended SystemVerilog Datatypes on MX Boundary


E-7
• The unpacked dimensions correspond to the dimensions
declared in the VHDL.
• The base type of the arrays should match.
• The number of dimensions should match.
• The size of each dimension should be the same on both sides.
• In this version of VCS MX, unpacked arrays with Verilog top is
not yet supported. Only 2 levels with VHDL top is supported for
multi-dimensional array ports across the VCS MX boundary.

Using Extended SystemVerilog Datatypes on MX Boundary


E8
Index

Symbols -ova_report 7-43, 10-8


-ova_simend_max_fail 7-45, 10-9
-a filename 5-67, 7-50, 7-67
-ova_verbose 7-43, 10-8
-E program runtime option 7-43
-PP 5-52, 5-58
-grw 7-54
-q 7-50
-I 5-58
-R 5-51
-i filename 7-45
-RI 5-58
-k 7-46
-s 7-46
-l filename 5-67, 7-50, 7-67
-V 7-50
-line 5-52
-vcd filename 7-54
-mhdl 5-50
-vhdlelab 5-51
-Mupdate 5-51
-vhdlrun 7-42
-ova_cov 7-45, 10-6
$restart 5-63, 7-63
-ova_cov_db 7-45
$value$plusargs 5-66, 7-66
-ova_cov_hier 10-6
+cliecho 7-46
-ova_cov_name 7-45
+maxdelays 7-55
-ova_debug 10-6
+mindelays 7-55
-ova_debug_vpd 10-6
+no_notifier 7-48
-ova_dir 10-7
+no_pulse_msg 7-51
-ova_enable_diag 10-7
+no_tchk_msg 7-48
-ova_file 10-7
+notimingcheck 5-67, 7-49, 7-67
-ova_filter 7-44, 10-8
+override_model_delays 7-58
-ova_filter_past 10-8
+plus-options 7-50
-ova_inline 10-7
+sdfverbose 7-51
-ova_max_fail 7-44, 10-9
+typdelays 7-56
-ova_max_success 7-45, 10-9
+v2k 3-15
-ova_name 7-44
+vcs+dumpoff+t+ht 7-54
-ova_quiet 7-43, 10-8
+vcs+dumpon+t+ht 7-54

IN-1
+vcs+dumpvarsoff 5-67, 7-54, 7-67 attributes
+vcs+finish 5-64, 7-49, 7-64 FOREIGN
+vcs+flush+all 7-57 LM-family modeler 13-33
+vcs+flush+dump 7-57
+vcs+flush+fopen 7-57
+vcs+flush+log 7-57
B
+vcs+grwavesoff 7-54 backannotation
behavioral cells A-20
+vcs+ignorestop 5-67, 7-48, 7-67
naming conventions A-8
+vcs+learn+pli 7-48 restrictions A-18
+vcs+lic+vcsi 7-57 SDF files 7-8, A-1
+vcs+lic+wait 7-57 single bits A-17
+vcs+mipd+noalias 7-58 structural cells A-20
+vcs+nostdout 7-51 base time for simulation 5-27, 7-13
+vcs+novhdldump 7-42 base time unit
+vcs+stop 5-64, 7-49, 7-64 LM-family modeler 13-52
+vcsi+lic+vcs 7-57 synopsys_sim.setup 13-52
+vera_load 7-46 bit data type 3-22
+vera_mload 7-46 bit_vector data type 3-22
+vhdllib 5-51, 5-52 boolean data type 3-22
+vpdfile 5-52

C
Numerics changemode
2-state code 5-11 command to switch command languages
4-state code 5-11 7-83
CLI
special rules for mixed HDL simulation 7-80
A +cliecho 7-46
-a filename 5-67, 7-50, 7-67 -cm 7-46
acc_handle_simulated_net() PLI routine 7-58 -cm_dir 7-47
analysis -cm_glitch 7-47
using make utility 4-11 -cm_log 7-47
Analyzer -cm_name 7-47
invoking for compiled simulation -cm_tglfile 7-48
optimizing compiled code 4-17 -cm_zip 7-48
passing options to the compiler 4-18, 5-21 cnt.txp 10-4
selecting a compiler 5-21 compiling to use interactively in mixed HDL
architectures simulation 5-58
editing to instantiate Verilog 3-21 Control-c Simulator command 7-13
assertion files 10-3 create_smartmodel_lib command 13-5, 13-25
assertions 10-3 CS_CCFLAGS_ARCH setup variable 4-19,
5-21

IN-2
CS_CCPATH_ARCH setup variable 5-21 F
customer support -xxi
facilities, test 10-3
cycle command 5-11
example 5-14 file, report 10-12
cycle elaboration reports 5-33 files
SDF backannotation 7-8, A-1
files, temporal assertion 10-3
D FOREIGN attribute
LM-family modeler interface 13-33
Data Type Mapping File
VCS/SystemC cosimulation interface 12-35
data types
you can use when instantiating Verilog in
G
VHDL 3-22 gcc C compiler 4-19, 5-21
debug mode 5-18 generic clause with LM-family modeler 13-27
-debug option 5-11 generic parameters
default naming convention A-8 matching to SDF parameters A-8
propagation A-20
design entity
instantiating 3-12 generics
LMSI_DELAY_TYPE 13-29
design libraries
LMSI_TIMING_MEASUREMENT 13-28
version compatibility 4-5
mapping to Verilog parameters 3-23
DEVICE SDF construct A-11
-grw 7-54
DKI Communication 12-17
DKI communication 12-6
documentation -xviii H
online -xix
help -xix
hotline, customer -xxi
E HTML report 7-7, 7-16
-E program 7-43
editing VHDL to instantiate Verilog 3-21 I
elaborator
-I 5-58
Z state 5-17
-i filename 7-45
entity-architecture pair
LM-family modeler 13-25 IEEE default name mapping 1-7
error messages Ignoring Calls and License Checking 7-53
LM-family modeler 13-54 Instatiating Verilog in VHDL 3-21–3-27
SmartModel interface 13-18 parameterized ports 3-25
example interrupting a simulation 7-13
temporal assertion file 10-4 intrinsic timing delay backannotation A-11
expressions 10-3

IN-3
J directory search order 13-39
files 13-38
jumpered ports 3-27 .MDL model file 13-41
.NAM name file 13-42
.OPT option file 13-50
K .PKG package file 13-46
-k 7-46 specifying vectors in files 13-44
Synopsys restrictions 13-40
.TMG timing file 13-48
L Simulato