ns_vcs_mx

Discovery™ AMS: NanoSim®-VCS®-MXVersion X-2005.09, September 2005

Copyright Notice and Proprietary InformationCopyright © 2005 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 DocumentationThe 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 StatementAll 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.

DisclaimerSYNOPSYS, 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 (®)Synopsys, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, Cadabra, Calaveras Algorithm, CATS, CSim, Design Compiler, DesignPower, DesignWare, EPIC, Formality, HSPICE, Hypermodel, iN-Phase, in-Sync, Leda, MAST, Meta, Meta-Software, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical Compiler, PowerMill, PrimeTime, RailMill, RapidScript, Saber, SiVL, SNUG, SolvNet, Superlog, System Compiler, Testify, TetraMAX, TimeMill, TMA, VCS, Vera, and Virtual Stepper are registered trademarks of Synopsys, Inc.

Trademarks (™)abraCAD, abraMAP, Active Parasitics, AFGen, Apollo, Apollo II, Apollo-DPII, Apollo-GA, ApolloGAII, Astro, Astro-Rail, Astro-Xtalk, Aurora, AvanTestchip, AvanWaves, BCView, Behavioral Compiler, BOA, BRT, Cedar, ChipPlanner, Circuit Analysis, Columbia, Columbia-CE, Comet 3D, Cosmos, CosmosEnterprise, CosmosLE, CosmosScope, CosmosSE, Cyclelink, Davinci, DC Expert, DC Expert Plus, DC Professional, DC Ultra, DC Ultra Plus, Design Advisor, Design Analyzer, Design Vision, DesignerHDL, DesignTime, DFM-Workbench, Direct RTL, Direct Silicon Access, Discovery, DW8051, DWPCI, Dynamic-Macromodeling, Dynamic Model Switcher, ECL Compiler, ECO Compiler, EDAnavigator, Encore, Encore PQ, Evaccess, ExpressModel, Floorplan Manager, Formal Model Checker, FoundryModel, FPGA Compiler II, FPGA Express, Frame Compiler, Galaxy, Gatran, HDL Advisor, HDL Compiler, Hercules, Hercules-Explorer, Hercules-II, Hierarchical Optimization Technology, High Performance Option, HotPlace, HSPICE-Link, iN-Tandem, Integrator, Interactive Waveform Viewer, i-Virtual Stepper, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, JVXtreme, Liberty, Libra-Passport, Library Compiler, Libra-Visa, Magellan, Mars, Mars-Rail, Mars-Xtalk, Medici, Metacapture, Metacircuit, Metamanager, Metamixsim, Milkyway, ModelSource, Module Compiler, MS-3200, MS-3400, Nova Product Family, Nova-ExploreRTL, Nova-Trans, Nova-VeriLint, Nova-VHDLlint, Optimum Silicon, Orion_ec, Parasitic View, Passport, Planet, Planet-PL, Planet-RTL, Polaris, Polaris-CBS, Polaris-MT, Power Compiler, PowerCODE, PowerGate, ProFPGA, ProGen, Prospector, Protocol Compiler, PSMGen, Raphael, Raphael-NES, RoadRunner, RTL Analyzer, Saturn, ScanBand, Schematic Compiler, Scirocco, Scirocco-i, Shadow Debugger, Silicon Blueprint, Silicon Early Access, SinglePass-SoC, Smart Extraction, SmartLicense, SmartModel Library, Softwire, Source-Level Design, Star, Star-DC, Star-MS, Star-MTB, Star-Power, Star-Rail, Star-RC, Star-RCXT, Star-Sim, Star-SimXT, Star-Time, Star-XP, SWIFT, Taurus, TimeSlice, TimeTracker, Timing Annotator, TopoPlace, TopoRoute, Trace-On-Demand, True-Hspice, TSUPREM-4, TymeWare, VCS Express, VCSi, Venus, Verification Portal, VFormal, VHDL Compiler, VHDL System Simulator, VirSim, and VMC are trademarks of Synopsys, Inc.

Service Marks (SM)MAP-in, SVP Café, and TAP-in are service marks of Synopsys, Inc.

SystemC is a trademark of the Open SystemC Initiative and is used under license.ARM and AMBA are registered trademarks of ARM Limited.All other product or company names may be trademarks of their respective owners.

Printed in the U.S.A.

Discovery™ AMS: NanoSim®-VCS®-MX, X-2005.09

ii

Contents

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

What’s New in this Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

1. Using NanoSim-VCS-MX

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Installation Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Setting up Your Own Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

NanoSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

VCS-MX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

License. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Mixed-simulation Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Supported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Flow Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Known Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2. Preparing Your Mixed-signal Simulation

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Choosing Your Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

iii

Choosing Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Requirements, Modifications, and Limitations of the Input Files . . . . . . . 13VHDL Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Verilog Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14SPICE Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Using a VHDL Setup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Using a Verilog Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Using the Mixed-signal Simulation Setup File . . . . . . . . . . . . . . . . . . . . . . . . . 19

The choose Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

The partition Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Module-based Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Instance-based Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Known Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

The set bus_format Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

The set rmap Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3. Running Your Mixed-Signal Simulation

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

VHDL-top Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Verilog-top Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Back-annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Using the SDF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Using the HSPF or HSPEF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4. Customizing the NanoSim/VCS-MX Interface

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Autowrapper Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Using the Autowrapper Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Converting Signal Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Digital to Analog Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Using the NanoSim set_vec_opt Configuration Command . . . . . . . . . . . 48

Analog to Digital Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Using the NanoSim set_node_thresh Configuration Command. . . . 50

iv

Signal Strength Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Converting from Digital to Analog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Converting from Analog to Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Creating a Resistance Map File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Unidirectional Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Bidirectional Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5. Mixed Simulation Output and Display

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Print (or Post-processing) Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

VHDL Syntax (VHDL-top flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Verilog Syntax (Verilog-top flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Transistor-level Description (VHDL-top and Verilog-top flows). . . . . . . . . 58

Viewing Waveform Files Separately with Viewers . . . . . . . . . . . . . . . . . . . . . . 58

Using turboWave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Using Alternative Waveform Viewers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Viewing a Single Waveform File with the Unified Output Display (UOD) . . . . . 60

Using the set_print_uod Configuration Command for NS-VCS-MX. . . . . 61

UOD File Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Reducing File Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

A. NanoSim-supported Commands

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

set_cosim_tres Configuration Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

set_print_uod Configuration Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

NanoSim Command-line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

B. Troubleshooting

Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Time Precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

What Time Precision Value is Used in my Mixed-signal Simulation?. . . . 72

Limitations at the Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Performance Improvement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Glossary

v

vi

About This Manual

The NanoSim-VCS-MX User Guide describes how to use the NanoSim-VCS-MX interface, which is a bridge (flow) between the VCS-MX and NanoSim tools.

Audience

This user guide is meant for designers who use the NanoSim-VCS-MX interface.

Knowledge of the C-programming language, UNIX, NanoSim, VCS, VHDL, and the turboWave waveform viewer is assumed.

Related Publications

For additional information about NanoSim-VCS-MX, see

• Documentation on the Web, which provides HTML and PDF documents and is available through SolvNet athttp://solvnet.synopsys.com

• Synopsys Online Documentation (SOLD), which is included with the software for CD users or is available to download through the Synopsys Electronic Software Transfer (EST) system

• The Synopsys MediaDocs Shop, from which you can order printed copies of Synopsys documents, at http://mediadocs.synopsys.com

vii

http://solvnet.synopsys.com

http://mediadocs.synopsys.com

About This ManualConventions

You might also want to refer to the documentation for the following related Synopsys products:

• NanoSim

• VCS

• VHDL

Conventions

The following conventions are used in Synopsys documentation.

Convention Description

Courier Indicates command syntax.

Courier italic Indicates a user-defined value in Synopsys syntax, such as object_name.

Regular italic A user-defined value that is not Synopsys syntax, such as a user-defined value in a Verilog statement.

Courier bold Indicates user input—text you type verbatim—in Synopsys syntax and examples.

Regular bold User input that is not Synopsys syntax, such as a user name or password you enter in a GUI.

[ ] Denotes optional parameters, such as

pin1 [pin2 ... pinN]

... Indicates that a parameter can be repeated as many times as necessary

| 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 terms that are read as a single term by the system, such as set_annotated_delay

viii

About This ManualCustomer Support

Customer Support

Customer support is available through SolvNet online customer support and through contacting the Synopsys Technical Support Center.

Accessing SolvNet

SolvNet includes an electronic knowledge base of technical articles and answers to frequently asked questions about Synopsys tools. SolvNet also gives you access to a wide range of Synopsys online services including software downloads, documentation on the Web, and “Enter a Call to the Support Center.”

To access SolvNet,

1. Go to the SolvNet Web page at http://solvnet.synopsys.com.

2. If prompted, enter your user name and password. (If you do not have a Synopsys user name and password, follow the instructions to register with SolvNet.)

If you need help using SolvNet, click SolvNet Help in the Support Resources section.

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 Indicates a path to a menu command, such as opening the Edit menu and choosing Copy.

Convention Description

ix


About This ManualWhat’s New in this Release

Contacting the Synopsys Technical Support Center

If you have problems, questions, or suggestions, you can contact the Synopsys Technical Support Center in the following ways:

• Open a call to your local support center from the Web by going to http://solvnet.synopsys.com (Synopsys user name and password required), then clicking “Enter a Call to the Support Center.”

• Send an e-mail message to your local support center.

- E-mail [email protected] from within North America.

- Find other local support center e-mail addresses at http://www.synopsys.com/support/support_ctr.

• Telephone your local support center.

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

- Call (650) 584-4200 from Canada.

- Find other local support center telephone numbers at http://www.synopsys.com/support/support_ctr.

What’s New in this Release

For this release, the following items are new:

• The NS-VCS flow has been removed. It is now part of the E-NS-VCS flow.

x


http://www.synopsys.com/support/support_ctr

http://www.synopsys.com/support/support_ctr

1Using NanoSim-VCS-MX1

This chapter provides you with the basic information you need to start simulating with NanoSim-VCS-MX—including installation and setup.

Overview

NanoSim-VCS-MX (NS-VCS-MX) is a feature that provides you with a mixed-signal, mixed-HDL language verification solution. NS-VCS-MX enables you to simulate a design described in SPICE (or other transistor-level description language that NanoSim supports), Verilog-HDL (“Verilog”), and VHDL.

NanoSim-VCS-MX provides you with two flows:

• VHDL-top design flow

• Verilog-top design flow

Note:

The SPICE-top flow is not supported at this time.

The transistor-level design blocks are always located under Verilog in the design hierarchy, and is interfaced by the Verilog module—referred to as the Verilog wrapper (module).

1

Using NanoSim-VCS-MXInstallation Requirements

You must be familiar with the SPICE, VCS, and VHDL languages, as well as NanoSim and VCS-MX usage. See the respective manuals for more information.

This chapter contains the following sections:

• Installation Requirements

• Setting up Your Own Environment

• Mixed-simulation Basics

• Supported Features

• Flow Description

• Known Limitations

Installation Requirements

In order to use NS-VCS-MX, you must install both NanoSim and VCS-MX.

Important:

The tool versions must be compatible!

Check the respective release notes to verify compatible tool versions. Generally, only one version of NanoSim and one version of VCS-MX are certified for each NS-VCS-MX release. (Non-recommended versions are not supported—accuracy/performance of your results are not guaranteed!) Refer to the Installation Requirements section of each manual for installation specifications.

Note that 64-bit platforms (Solaris, HP, AMD) are not yet supported.

If you are running on Linux, check the gcc and ld versions that are recommended. For Linux RH3.0: use gcc version 3.3.2 and ld version 2.14.90.0.4

Important:

To use NS-VCS-MX, an individual product license is required for both NanoSim and VCS-MX.

2

Using NanoSim-VCS-MXSetting up Your Own Environment

Setting up Your Own Environment

Running a mixed-mode simulation requires setting up paths and environment variables for both simulators (NanoSim and VCS-MX).

NanoSim

A NanoSim installation comprises CSHRC files for every platform. Source the CSHRC file for the platform on which you are running your simulation.

Note that you have to re-source the NanoSim CSHRC file when you change platforms:

source Nanosim_installation_directory/CSHRC_platform

VCS-MX

For VCS-MX, you must set the VCS_HOME environment variable and specify the path to the bin directory available in the VCS-MX installation directory:

setenv VCS_HOME VCS-MX_installation_directory

set path = ($VCS_HOME/bin $path)

License

Both LM_LICENSE_FILE and SNPSLMD_LICENSE_FILE can be used to specify the license file location.

setenv LM_LICENSE_FILE Location_of_License_Fileor

setenv SNPSLMD_LICENSE_FILE Location_of_License_File

See the following example to set up your environment to run on the Solaris 32-bit platform:

setenv VCS_HOME /usr/synopsys/VCSset path = ($VCS_HOME/bin $path)source /usr/synopsys/Nanosim/CSHRC_sparcOS5setenv LM_LICENSE_FILE 26585@synopsys:$LM_LICENSE_FILE

3

Using NanoSim-VCS-MXMixed-simulation Basics

Mixed-simulation Basics

In a mixed-simulation, two simulator engines run and interact with each other. Information is exchanged between the two simulators through converters.

In an NS-VCS-MX simulation, VCS-MX is the digital simulator and NanoSim is the analog simulator.

The circuit must be partitioned into digital (VCS-MX) blocks and analog (NanoSim) blocks. Partitioning the circuit is your responsibility.

You must choose the part of your circuit to be simulated with VCS-MX, and choose the blocks to be simulated with NanoSim. The converters at the interface are automatically inserted by the NS-VCS-MX tool.

There are two types of converters:

• Digital-to-Analog (D2A)

Converts a signal coming from the VCS-MX world into an analog signal

• Analog-to-Digital (A2D)

Converts a signal coming from the NanoSim world into a digital signal

Figure 1 visually displays the mixed-simulation basics.

Figure 1 Mixed-simulation basics

4

Using NanoSim-VCS-MXSupported Features

Supported Features

NS-VCS-MX supports the following features:

• VHDL-top design flow (see Figure 2)

Figure 2 VHDL-top design

• Verilog-HDL top design flow (see Figure 3)

Figure 3 Verilog-HDL top design

• Donuts (donut configuration) in HDL blocks, which is a VCS-MX feature (see Figure 4)

5

Using NanoSim-VCS-MXFlow Description

Figure 4 Donuts in HDL blocks

• Verilog-A and ADFMI descriptions instantiated in a SPICE description

Verilog-A or ADFMI descriptions cannot be instantiated in Verilog or VHDL.

• Real-type port support in VHDL (to communicate with the transistor-level block)

• Integration of the Value Change Dump Plus (VPD) format and NanoSim output (.out) format into one unified output (_uod.out) file: the Unified Output Display (UOD).

VPD format is the VCS-MX output format.

Flow Description

If you intend to run Enhanced NanoSim-VCS (E-NS-VCS), that is, if there is no VHDL description in your design, refer to the Enhanced NanoSim-VCS User Guide.

Important:

The NS-VCS-MX flow is different from the E-NS-VCS flow!

There are two possible flows for an NS-VCS-MX simulation:

• VHDL-top

• Verilog-top

6

Using NanoSim-VCS-MXFlow Description

In the present version, a SPICE (transistor-level) description for the top cell is not possible. The top cell must be described in either the VHDL or Verilog language.

Both Verilog-top and VHDL-top flows are similar (see Figure 1), but the executables differ. The Verilog-top flow is driven by VCS; therefore, vcs is the compilation and elaboration tool and simv is the simulation executable. The VHDL-top flow is driven by VHDL; therefore, scs is the compilation and elaboration tool and scsim is the simulation executable.

The SPICE description (NanoSim netlist) must always be enveloped by a Verilog module, also called a Verilog wrapper. See Chapter 2, “Preparing Your Mixed-signal Simulation,” for more information on the Verilog wrapper.

For a visual representation of the NS-VCS-MX flow, see Figure 5.

7

Using NanoSim-VCS-MXKnown Limitations

Figure 5 NanoSim-VCS-MX flow

Known Limitations

Limitations exist in NS-VCS-MX, due to the existing limitations in the VCS-MX flow. Please refer to the VCS-MX User Guide for more details.

The known NS-VCS-MX limitations are:

• Transistor-level blocks must be leaf cells

(SPICE-top is not permitted.)

• Donuts in a SPICE description are not permitted

8


A SPICE description that instantiates a Verilog module or a VHDL component is not possible.

• A single VCD file generated for both a VHDL and Verilog design is not supported, even though you can generate two separate VCD files—one for VHDL and one for Verilog. Only VPD files generated for the entire (VHDL and Verilog) design are supported—the UOD feature only works with VPD files.

• Cross-module references (XMR) over the Verilog and transistor-level boundary are not supported.

• NanoSim GUI is not supported.

• The NanoSim set_sim_hierid configuration command is ignored.

Known Problems

The following problems currently exist:

• names.map file generates incompletely

• HAR feature requires two submissions of scsim :

- run #1 is for HAR setup

- run #2 is for HAR simulation

9


10

2Preparing Your Mixed-signal Simulation2

This chapter provides you with information for preparing your files (input data) in order to run a mixed-signal simulation.

Overview

Before you begin using the NS-VCS-MX flow, there are several required tasks you must complete before starting the simulation. You must prepare the input files so both the VCS-MX simulation and the NanoSim simulation can run stand-alone. Additional tasks are also required for a successful run of the mixed-signal simulation.

Figure 6 shows the recommended flow for preparing your mixed-signal simulation.

11

Preparing Your Mixed-signal SimulationChoosing Your Flow

Figure 6 Flow for preparing a mixed-signal simulation


• Choosing Your Flow

• Choosing Input Files

• Using a VHDL Setup File

• Using a Verilog Wrapper

• Using the Mixed-signal Simulation Setup File

Choosing Your Flow

Before you begin simulating your design, you must determine what flow you want to use:

• VHDL-top

• Verilog-top

12

Preparing Your Mixed-signal SimulationChoosing Input Files

Once you have chosen either the VHDL-top or Verilog-top flow, you must decide how to partition your circuit. You must list the blocks you want to simulate using

• NanoSim

• Verilog description

• VHDL description

Choosing Input Files

Once the partitioning of your design is determined, you must ensure you have all the required files.

The required files for the mixed-signal simulation for NanoSim are

• transistor-level descriptions (or SPICE netlists)

• device model libraries (can be included inside the SPICE netlist)

• configuration file (not required, but often used)

The required files for the mixed-signal simulation for VCS-MX are

• VHDL setup file

• Verilog description file

• VHDL description file

• VHDL command file (for batch run only)

For the mixed-signal simulation, you need to create

• a Verilog wrapper

• a mixed-signal simulation setup file

Later in this chapter, you will learn how to create these files.

Requirements, Modifications, and Limitations of the Input Files

An NS-VCS-MX simulation demands several requirements, modifications, and limitations of the input files, described as follows:

13


VHDL DescriptionFor a VHDL description, see the following guideline:

• Inout ports with a real data type are not supported.

The mode or direction of the ports in the VHDL code with a real data type must be changed from inout to input or to output.

Verilog DescriptionFor a Verilog description, see the following guidelines:

• In case of a Verilog-top flow, there must be a top-level module.

• The 'timescale compiler directive must be specified with the correct values. You should specify the time precision value using 10ps or less, since the NanoSim default is 10ps.

• Cross-module reference (XMR) is only available in Verilog or mixed-HDL. XMR must be removed or commented-out if it references any modules or instances replaced by transistor-level blocks.

• A wreal net-type definition is not allowed in a Verilog module, other than the Verilog wrappers.

See Example 1 for a sample Verilog netlist.

Example 1 Verilog netlist‘timescale 1ns/10psmodule top ();wire in1, in2, in3, out1;stim s1 (.oa (in1), .ob(in2), .oc(in3));test t1 (.a(in1), .b(in2), .c(in3), .d(out1));initial begin$monitor ("%d out1=%b", $time, out1);$dumpvars;$dumpfile ("test.vcd");#1000$finish;endendmodule/* The module declaration of stim and test are not shown in this example */

14


Limitation for Verilog Modeling. The mixed-nets should not be connected to the following:

• Bi-directional pass switches (tran, rtran, tranif0, rtranif0, tranif1, and rtranif1)

• Jumper ports (see Example 2)

Example 2 Jumper port samplemodule jumper (a, a);inout a;. . .endmodule

SPICE NetlistFor a SPICE netlist, see the following guidelines:

• Instantiations of subcircuits are not allowed in the SPICE-top netlist (SPICE-top simulation is not supported). Only subcircuit descriptions (starting with .SUBCKT), voltage sources and SPICE commands (.GLOBAL, .TEMP, .OPTIONS,…) are allowed.

• All the power supply nodes (and ground) must be specified in a .global statement. Voltage sources for power supplies are required.

• The subcircuit name and port names in the subcircuit must be identical to the module name and port names in the corresponding Verilog wrapper module.

Be aware of case-sensitivity issues. For example, HSPICE format is case-insensitive and is treated—by default—as lower-case in NanoSim. Verilog is case-sensitive.

• Voltage source connected to nodes that are not defined with a .global statement must be defined inside the subcircuit. Any node connected to a voltage source cannot be an interface node.

• The current source definitions must be defined in subcircuits. Any node that is connected to current sources cannot be an interface node.

• The strength calculation may be incorrect if the ports are connected to BJTs, diodes, or coupling capacitors inside the subcircuits (which are partitioned for Verilog wrapper modules). You will see a WARNING message when BJTs or coupling capacitors are connected to mixed-nets: WARNING:

15

Preparing Your Mixed-signal SimulationUsing a VHDL Setup File

NanoSim:0x2070fe17: the element "top.l1.c1" is not supported in mixed net driving strength calculation. Ignored.

Only series resistance (MOS transistors and/or resistors) connected to the local power supply or ground from a mixed-net, is used to determine the Verilog strength.

• Unused ports must be removed from the subcircuits that are partitioned for Verilog wrapper modules.

NanoSim removes those ports by default. The corresponding ports in the Verilog wrapper modules must also be removed. You will see a WARNING and ERROR message when NanoSim removes the port: WARNING: mixed node “net10” not found.ERROR: Unable to find nanosim id for net ‘net10’ interface signal mismatch

See Example 3 for a sample SPICE netlist.

Example 3 SPICE netlist* The first line is always a comment in Spice syntax.lib 'models' TT.inc 'cells.spi'.options scale=1e-6.temp 27.global vdd gndvvdd vdd 0 dc 3.3vgnd gnd 0 dc 0.subckt test a b c dx1 a b n1 vdd cell1x2 c n1 d ref cell2vref ref gnd 2.0.ends*no instance definition allowed.*cell1 and cell2 subcircuit description are not shown here.end

Using a VHDL 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 setup files

16

Preparing Your Mixed-signal SimulationUsing a Verilog Wrapper

can be located in the VCS-MX installation directory, in your home directory, or in your run directory.

These setup files map VHDL design library names to specific host directories, set search paths, and assign values to simulation control variables.

For more information on the VCS-MX setup file, please refer to the VCS-MX User Guide.

Example 4 is a synopsys_sim.setup file. The WORK directory is the design library; it contains the intermediate files generated by the vlogan and vhdlan utilities. You must create the WORK directory in your run directory. The time resolution in Example 4 is set to 10ps.

Example 4 VHDL setup fileWORK > defaultdefault: ./WORKTIMEBASE=nsTime_resolution=10ps

It is recommended to use 10ps for the time resolution value, because this is the default time resolution for NanoSim.

Using a Verilog Wrapper

A VHDL description cannot directly instantiate a SPICE description—it is impossible. When a SPICE description is instantiated in a VHDL description, you must create a Verilog module (the Verilog wrapper) with the same name and identical port names and port order as the SPICE subcircuit.

If a Verilog description already exists for the SPICE block, you can use the existing Verilog module as the Verilog wrapper. If not, you can either manually create it or use the autowrapper utility—see section “Using the Autowrapper Utility” in Chapter 4, “Customizing the NanoSim/VCS-MX Interface,” for the autowrapper usage.

If you use real ports in the VHDL description, ensure that you use a wreal declaration for the same ports in the Verilog wrapper module. When using a wreal declaration, only input and output ports are allowed—inout ports are not supported.

See Example 5 for a wreal declaration file sample.

17

Preparing Your Mixed-signal SimulationUsing a Verilog Wrapper

Example 5 wreal declaration file//Verilog wrapper for using real portsmodule test (a, b);input a;wreal a;output b;wreal b;/* in addition to module name, port name, and directions,wreal declaration is also required */end module

Note:

Input signal resolution depends on the sampling rate to generate pseudo-analog signals in a VHDL testbench. You do not have to consider this when using NanoSim-VCS-MX.

Using real ports can result in a simulation performance penalty; specifically, real values passed through NanoSim to VHDL. NanoSim communicates with VHDL by way of VCS, based on the resolution value that is specified in the mixed-signal simulation setup file. Be aware that smaller resolution values may cause slower simulation.

Case-sensitivity issues may arise—NanoSim assumes HSPICE netlists are case-insensitive (translated to lowercase).

In SPICE format, input and output ports are not differentiated—all ports are designated as inout. When you create a Verilog wrapper, ensure that you correctly specify input and output ports.

The Verilog wrapper module definition and instantiation name (corresponding component declaration in VHDL) must match the subcircuit name in the transistor-level netlist. Port names in the Verilog wrapper module must also match the subcircuit node names in the transistor-level netlist.

Example 6 is a SPICE subcircuit, including its instance in the VHDL description and the requested corresponding Verilog wrapper.

Example 6 SPICE subcircuit*.subckt chargepump_com + com_inv<3> com_inv<2> com_inv<1> com_inv<0>+ com_rsh<3> com_rsh<2> com_rsh<1> com_rsh <0>+ clk* we skip the subckt description.ends

18

Preparing Your Mixed-signal SimulationUsing the Mixed-signal Simulation Setup File

Example 7 is an instance of Example 6 (SPICE subcircuit) in the VHDL description.

Example 7 Instance of Example 6 (SPICE subcircuit)I3 : chargepump_com

port map (com_inv=> com_inv(3 downto 0),com_rsh=> com_rsh(3 downto 0),clk => clk);

Example 8 is a Verilog wrapper you must create in order to run the NS-VCS-MX simulation.

Example 8 Verilog wrapper'timescale 1ns/10psmodule chargepump_com(com_inv, com_rsh, clk);input [3:0] com_inv, com_rsh;input clk;reg [3:0] reg_com_inv, reg_com_rsh;always @ (posedge clk)begin reg_com_inv = com_inv; reg_com_rsh = com_rsh;endendmodule

Using the Mixed-signal Simulation Setup File

The mixed-signal simulation setup file informs the simulator about how

• the circuit is partitioned (partition command)

• to run NanoSim (choose command)

This file can also contain other optional commands specific to the interface between the VCS-MX and NanoSim simulators (set rmap and set bus_format commands).

The default name for the mixed-signal simulation setup file is vcsAD.init. All commands in the file must be completed with a semi-colon character (;).You can create a comment line by inserting the double forward slash character (//) at the beginning of the line.

See Example 9 for an example of a comment line in a vcsAD.init file.

19


Example 9 vcsAD.init filepartition -cell chargepump_com;choose nanosim -n chargepump.spi -C cfg -o lcd;//set bus_format <%d>;

Within the vcsAD.init file, you may find the following commands that are described (in detail) in this chapter:

• The choose Command (required)

• The partition Command (required)

• The set bus_format Command (optional)

• The set rmap Command (optional)

The choose Command

The choose command defines command-line options for NanoSim. During run time, the NanoSim command options are passed to NanoSim to properly simulate the transistor-level blocks.

See the following syntax, example, and description:

choose nanosim command-line options;

choose nanosim -n net.spi models.sp -C config;

This example tells NS-VCS-MX that you are using SPICE netlists named net.spi, and models.sp, and a configuration file named cfg for the NanoSim simulation.

The syntax after the choose keyword is the regular NanoSim command-line syntax. However, mixed-signal simulation does not support all NanoSim command-line options.

See Appendix B, “Troubleshooting,” for the supported options and descriptions for NS-VCS-MX. See the NanoSim User Guide for information about writing configuration files. See the Circuit Simulation and Analysis Tools Reference Guide for more information about technology and netlist files.

The partition Command

The partition command defines the parts of the design that will be simulated at the transistor level (with NanoSim). This command specifies the

20


name of the block, and determines if this is a module or an instance. The partitioning supports both cell-based and instance-based partitioning.

Module-based PartitioningYou can perform module-based partitioning by specifying the module name to be simulated with NanoSim after the -cell option in the partition command.


partition -cell module_name;

partition -cell vco bandgap;

In this example, the two cells vco and bandgap are specified to be simulated at the transistor level. That means:

• vco and bandgap are existing Verilog modules (either actual Verilog modules or the modules were created in a Verilog wrapper)

• vco and bandgap are existing SPICE subcircuits

• The module name (vco and bandgap) must be the same (with the same case-sensitivity) in the Verilog description (wrapper or existing module) and in the SPICE description

The partition command takes the Verilog module identified as module_name; however, VCS ignores this module for simulation. The specified module is simulated using the subcircuit described in the transistor-level netlist that you supplied. The subcircuit name must be identical to the Verilog module name.

You can specify as many partition commands as you wish, provided all of the corresponding subcircuits described in the SPICE netlist are supplied and identified in the choosecommand. In case of cell-based partitioning, all instances of the specified module are simulated with NanoSim.

Instance-based PartitioningYou can perform instance-based partitioning by specifying the full hierarchical name of the instance to be simulated with NanoSim after the partition command.


partition hierarchical_instance_name;

21


partition top.u1.u2;

In this example, the top Verilog top-level module contains a module instantiated as u1. This module contains another module instantiated as u2 that is chosen to be simulated at the transistor level.

Example 10 is a VHDL-top flow, so the hierarchical instance name must begin with the forward slash character ( / ) and the text must be uppercase.

Example 10partition /TOP/U1/U2;

In both examples,

• U2 must be an instance of an existing Verilog module (either actual Verilog module or the module has been created in a Verilog wrapper)

• U2 must be an instance of a SPICE subcircuit

The partition command takes the Verilog module instance identified as hierarchical_instance_name; however, VCS ignores this module for simulation. The specified instance is simulated using the subcircuit described in the SPICE netlist you supplied. The subcircuit name in the transistor-level description must be the same name as the Verilog module name.

You can specify as many partition commands as you wish, provided all of the corresponding subcircuits described in the SPICE netlists are supplied and identified using the choose command.

Known LimitationIn the VHDL-top flow, you should use the ‘/’ hierarchical delimiter for VHDL instances and the ‘.’ hierarchical delimiter for the Verilog instances.

For example:

partition TOP/U1.I1

The set bus_format Command

The set bus_format command defines the bus format used in the SPICE netlist. The bus notation format for Verilog is [msb:lsb]. In SPICE format, a bus does not generally exist—the bus is split into single bits and the notation for the single bits can greatly differ from Verilog notation.


22


set bus_format open_char %d close_char ;

set bus_format <%d>;

This example instructs VCS that angle brackets (< >) are used as delimiters in the transistor-level netlist. For example, you can use it when you encounter the following SPICE subcircuit, shown in Example 11.

Example 11.subckt addr4 a<3> a<2> a<1> a<0>+b<3> b<2> b<1> b<0> cin+s<3> s<2> s<1> s<0> coutx1 a<3> b<3> cout s<3> n1 addrx2 a<2> b<2> n1 s<2> n2 addrx3 a<1> b<1> n2 s<1> n3 addrx4 a<0> b<0> n3 s<0> cin addr.ends

The set bus_format command specifies the bus format in the SPICE netlist. The bus index is indicated by the number shown at the %d position in the SPICE netlist. The bus index must be sequential from MSB to LSB or from LSB to MSB (for example, a<3> a<2> a<1> a<0>) in the .subckt port list. If the bit indexes are mixed (for example, a<3>, a<0>, a<2>, a<1>) the bus is ignored.

Note:

NanoSim only supports the following bus format characters: { } < > [ ] _

A summary of the mixed-signal simulation setup file commands is shown in Table 1.

Table 1 Mixed-signal simulation command summary

Command Use Definition

choose nanosim command-line options; required Defines command-line options for NanoSim

partition -cell module_name;

partition hierarchical_inst_name;

required Defines module to be simulated as a transistor-block

23


The set rmap Command

The set rmap command defines the resistance map file to be used. The resistance map file is a file used to map the analog (transistor-level) impedance to a digital strength, and vice-versa. The resistance map file is described more fully in Chapter 3, “Running Your Mixed-Signal Simulation.”


set rmap resistance_map_name or resistance_map_path_name;

set rmap resis_comp.map;

In this example, the resistance map file is the resis_comp.map file located in the current directory.

In Example 12, the resistance map file is the resis.map file located in the /home/john/work directory.

Example 12set rmap /home/john/work/resis.map;

Use the set rmap command to specify the resistance map file, or the path where the resistance map file is located. If you do not use this command, the rmapAD.init default resistance map file in the /<NanoSim_install_directory>/<platform>/ns/interface/vcsace directory is used.

Note:

Instead of using the set rmap command, you can also place resistance mapping information directly in the mixed-signal simulation setup file.

set bus_format open_char %d close_char;

optional Defines bus format used in the SPICE netlist

set rmap resistance_map_name;

set rmap resistance_map_path_name;

optional Defines the resistance map file to be used

Table 1 Mixed-signal simulation command summary

Command Use Definition

24

3Running Your Mixed-Signal Simulation3

This chapter provides you with information for successfully running your mixed-signal simulation.

Overview

The VCS-MX commands are (basically) the main commands that run a NanoSim-VCS-MX simulation. The nanosim command is included in a file read-in by the VCS-MX compilation/elaboration tool. If you want to run a mixed-signal simulation, you must know how to run a VCS-MX simulation, and you also must know how to run NanoSim.

The simulation flow is different if you choose a Verilog-top simulation or a VHDL-top simulation. Both flows are described in this chapter. For more information on the VSC-MX analyzer and compiler, it is recommend that you read the VCS-MX User Guide.


• VHDL-top Simulation

• Verilog-top Simulation

• Back-annotation

25

Running Your Mixed-Signal SimulationVHDL-top Simulation

VHDL-top Simulation

This section presents the simulation flow when your top cell is described in the VHDL language containing instances described in the Verilog language, and/or instances you want to simulate with NanoSim. See Figure 7 for a visual representation of the VHDL-top flow.

Figure 7 VHDL-top simulation flow

26


The steps that are highlighted in Figure 7 are listed as follows:

1. Prepare your VHDL setup file.

See Chapter 2, “Preparing Your Mixed-signal Simulation,” for detailed information.

2. Prepare netlists.


You can instantiate one or more modules 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. Refer to the VCS-MX User Guide for details on instantiating a Verilog module in VHDL code.

If you want to simulate a VHDL component at the transistor level (with NanoSim), you must create a Verilog wrapper and follow the same rule as for instantiating a Verilog module in a VHDL design.

3. Analyze.

The purpose of analysis is to analyze the input file (the Verilog code and the VHDL code) and create intermediate files that are used during elaboration. The intermediate files are created in the design library (specified in the synopsys_sim.setup file). The directory for the design library must be created before you run the analyzer.

In the VHDL-top design, two analyses must be performed:

a. Verilog Code Analysis: vlogan

For Verilog code analysis, use the vlogan utility. If you have many Verilog files, you should create a file containing your original Verilog files and the Verilog wrapper you have created for NanoSim modules.

See the following syntax and example:

vlogan [options] Verilog_files

vlogan example1.v example2.vor

vlogan -f allFiles.vcwhere allFiles.vc comprises the list of all your Verilog files.

27


Note:

If a real data type is used in the VHDL code, you must use the -ams option in vlogan as follows:

vlogan -ams test1.v

b. VHDL Code Analysis: vhdlan

To analyze your VHDL code including the Verilog components, use the vhdlan utility.

Note:

There is no NanoSim component in VHDL code. The NanoSim components must be read-in through Verilog wrappers; therefore, they are Verilog components inside the VHDL code.


vhdlan [options] VHDL_files

vhdlan testbench.vhd example3.vhd

The vlogan and vhdlan options are described in the VCS-MX User Guide. The NS-VCS-MX simulation does not require any special option for vhdlan. The -ams option is required for vlogan when real data types are used in VHDL.

4. Compile and elaborate.

This step elaborates your design, generates code, compiles C code, and statistically links all objects to generate the executable binary file, called scsim, for running the simulation.

The command to run compilation and elaboration is scs. Use scs with the -verilogcomp, -mhdl and “+ad” options. The -mhdloption is a VCS-MX-specific command. The -verilogcomp and “+ad” options are required for the NS-VCS-MX simulation.


scs [options] design_root -mhdl -verilogcomp "+ad [options]"

scs WORK.CFG_testbench -mhdl -verilogcomp "+ad -PP"

28


The scs utility reads-in the intermediate files previously generated by vlogan and vhdlan, as well as the vcsAD.init mixed-signal simulation setup file. You can change the name of the mixed-signal simulation setup file. In that case, you must specify its name after the +ad option. If no name is specified after the +ad option, scs looks for a vcsAD.init file in the working directory.

See the following example in which the mixed-signal simulation setup file is called MySetup:

scs WORK.CFG_testbench -mhdl -verilogcomp "+ad=MySetup"

5. Simulate.

To run the simulation with a VHDL-top design, execute scsim. You can use the -verilogrun option to specify run time options.

See the following syntax and examples:

scsim [options] [-verilogrun "options"]

scsimor

scsim -verilogrun "+notimingchecks"

By default, scsim runs in interactive mode. You must use the -include option and simulation control file with scsim to enable the batch mode, as in the following example:

scsim -include command.txt

Interactive simulation is described as follows:

When you invoke scsim without a simulation control file, the simulation stops with a # (number sign) simulator prompt (as highlighted in line 3 of Example 13). You can enter simulation control commands at this prompt using VCS-MX VHDL Common Language (SCL) commands. (See the VCS-MX User Guide, VCS-MX Reference Guide and the NanoSim-VCS-MX tutorial for more information.)

You can execute NanoSim interactive commands at the VCS-MX VHDL prompt with the ace prefix. Ensure you have passed NanoSim DC initialization before entering any NanoSim interactive commands. When scsim is invoked without a simulation control file, the simulation stops before NanoSim DC initialization begins (as highlighted in line 2 of Example 13). You can then enter transient analysis.

29

Running Your Mixed-Signal SimulationVerilog-top Simulation

Example 13Levelizing stages …Levelizing stages took 0.000 s# run 1nsDC initialization ...Initializing level 1Finishing initialization (level 0 -- 1)0 dynamic stages assigned in DC InitializationNumber of residual dc events scheduled : 0Number of ic nodes scheduled : 16DC initialization took 0.000 sSimulation begins in pwl mode ...***** Notes: Nanosim VCS cosimulation can not report percentage of simulation time.Simulation time progresses to 0.000 ns

# ace get_node_info TESTBENCH.I3.com_rsh[2]Ver X-2005.09> get_node_info TESTBENCH.I3.com_rsh[2]

Node status of TESTBENCH.I3.com_rsh[2](58): 0 (0.000 V)Total Capacitance: 22.5198fF t1: 2460.010 ns s1: 1 t2: 2470.010 ns s2: 0 t: 2470.560 ns v: 0.000 V nt: 2475.560 ns nv: 0.000 V

#

Limitation:

If you hit Ctrl-C while scsim is running, currently the simulation will not stop and the interactive mode will not begin.

6. Display results.

See Chapter 5, “Mixed Simulation Output and Display,” for detailed information.

Verilog-top Simulation

This section presents the simulation flow when your top cell is described in the Verilog language containing instances described in the VHDL language, and/or instances you want to simulate with NanoSim. See Figure 8 for a visual representation of the Verilog-top flow.

30


Figure 8 Verilog-top simulation flow

The steps that are highlighted in Figure 8 are listed as follows:

1. Prepare your VHDL setup file.


2. Prepare netlists.

31



You can instantiate one or more modules of a VHDL block into a Verilog design the same way you instantiate a Verilog module—by using a module instantiation statement. Refer to the VCS-MX User Guide for details on instantiating a VHDL component in Verilog code.

3. Analyze.

The purpose of analysis is to analyze the input file (the Verilog code and the VHDL code) and create intermediate files that are used during elaboration. The intermediate files are created in the design library (specified in the synopsys_sim.setup file). The directory for the design library must be created before you run the analyzer.

In the Verilog-top design, two analyses must be performed:

a. Verilog Code Analysis: vlogan

For Verilog code analysis, use the vlogan utility. If you have many Verilog files, you should create a file containing your original Verilog files and the Verilog wrapper you have created for NanoSim modules.


vlogan [options] Verilog_files

vlogan top.v example2.vor

vlogan -f allFiles.vcwhere allFiles.vc comprises the list of all your Verilog files.

Note:

If a real data type is used in the VHDL code, you must use the -ams option in vlogan as follows:

vlogan -ams test1.v

b. VHDL code analysis: vhdlan

To analyze your VHDL code including the Verilog components, use the vhdlan utility.

32


Note:

The NanoSim components must be read-in through the Verilog wrappers; therefore, they are Verilog components inside the VHDL code.


vhdlan [options] VHDL_files

vhdlan example3.vhd

The vlogan and vhdlan options are described in the VCS-MX User Guide. The NS-VCS-MX simulation does not require any special option for vhdlan. The -ams option is required for vlogan when real data types are used in VHDL.

4. Compile and elaborate.

This step elaborates your design, generates code, compiles C code, and statistically links all objects to generate the executable binary file, called simv, for running the simulation.

The command to run compilation and elaboration is vcs. Use vcs with the -mhdl and “+ad” options. The -mhdloption is a VCS-MX-specific command. The “+ad” option is required for the NS-VCS-MX simulation.


vcs [options] -mhdl +ad Verilog_files [-vhdlelab “options”]

vcs -mhdl +ad example3.v example4.v

The vcs utility reads-in the intermediate files previously generated by vlogan and vhdlan, as well as the vcsAD.init mixed-signal simulation setup file. You can change the name of the mixed-signal simulation setup file. In that case, you must specify its name after the +ad option. If no name is specified after the +ad option, vcs looks for a vcsAD.init file in the working directory.

See the following example in which the mixed-signal simulation setup file is called MySetup:

vcs top.v -mhdl +ad=MySetup

5. Simulate.

33


To run the simulation with a Verilog-top design, execute simv.

See the following syntax and examples:

simv [options] [-vhdlrun "options"]

simv

Note:

The vhdlan, vhdlelab and vcs options must not conflict. (Refer to the VCS-MX User Guide for more details about command options.)

Interactive simulation is described as follows:

By default, simv runs the batch mode. To enable the interactive mode during runtime, you must generate simv with the +cli option during compile time.

See the following example:

vcs design.v +cli+1 -mhdl

To enter the interactive mode or stop simulation during run time, use one (or all) of the following three methods:

- Execute simv with the -s runtime option to stop the simulation at time 0.

The simulation stops before DC initialization in NanoSim. If you want to use the NanoSim interactive commands, you must advance several time steps to make sure DC initialization has completed.

- Use the $stop systems task in the Verilog netlist to stop the simulation at any time (see line 3 in Example 14).

- Type Ctrl-c to stop the simulation immediately.

When the simulation stops, you see the VCS Command Line Interface (cli) prompt shown in line 4 of Example 14. At the prompt, you can use any VCS interactive command. You can begin transient analysis after passing DC initialization.

Limitation:

Ctrl-c does not always stop the simulation—this is a known bug.

To invoke a NanoSim interactive command at the CLI prompt, you must use the ace keyword.

34


Example 14Levelizing stages ...Levelizing stages took 0.000 s$stop at time 0cli_0 > once #10cli_1 > . 0 a= 0 b= 1 cin= 0 s= x cout= z DC initialization ...Initializing level 3Finishing initialization (level 0 -- 3)0 dynamic stages assigned in DC Initialization

Number of residual dc events scheduled : 0Number of ic nodes scheduled : 18DC initialization took 0.010 s

Simulation begins in pwl mode ...

NOTICE:Nanosim VCS cosimulation can not report percentage of simulation time. 0 a= 0 b= 1 cin= 0 s= f cout= z Simulation time progresses to 0.000 ns Time break at time 10 breakpoint #1 tbreak ##10cli_2 > ace get_node_info top.cin

Ver X-2005.09 >get_node_info top.cin

Node status of top.cin(62): 0 (0.106 V)Total Capacitance: 19.6118fF t1: -0.100 ns s1: 0 t2: 0.000 ns s2: 0 t: 0.009 ns v: 0.100 V nt: 0.015 ns nv: 0.134 V

cli_3 >

6. Display results.

See Chapter 5, “Mixed Simulation Output and Display,” for detailed information.

35

Running Your Mixed-Signal SimulationBack-annotation

Back-annotation

NS-VCS-MX only supports block-level back-annotation (BA) simulation. Block-level back-annotation means back-annotation to the specific SPICE subcircuit, specific Verilog module, or VHDL component. Back-annotation to the mixed nets is not supported.

For back-annotation simulation, two kinds of formats are supported:

• Standard Delay Format (SDF) files to back-annotate Verilog modules and VHDL components

• Hierarchical Standard Parasitic Format (HSPF) or Hierarchical Standard Parasitic Exchange Format (HSPEF) to back-annotate SPICE subcircuits

Using the SDF File

For SDF back-annotation, there are two ways of specifying the SDF file:

• Use the $sdf_annotate system task in a Verilog module

• Use the -sdf option in the scsim command to specify SDF files

See an example of the -sdf command (VHDL-top flow):

scsim -sdf counter.sdf

See an example of the $sdf_annotate task in a Verilog module:

$sdf_annotate("SDF_FILE", TOP_GATE);

Note:

The usage of SDF back-annotation is the same for a VCS-MX simulation. See the VCS-MX User Guide for more information.

Using the HSPF or HSPEF File

For HSPF back-annotation, use the NanoSim commands to specify the SPF files by entering either:

• the NanoSim -nhspf command line

• the cspf_file_with_cell_scope netlist control option

36


For HSPEF back-annotation, use the NanoSim commands to specify the SPEF files by entering either:

• the NanoSim -nhspef command line

• the spef_file_with_cell_scope netlist control option

If you have a detailed standard parasitic format (DSPF) file for a SPICE subcircuit, you can modify it to HSPF format by editing the DSPF file and enclosing parasitic information with the .subckt subckt_name and .ends statements, as shown in Example 15:

Example 15.SUBCKT chargepump *DSPF file content:*|NET net1 3.4f*|I …….ENDS

Note:

The usage of HSPF and HSPEF back-annotation is the same for a NanoSim simulation. For more information about HSPF and HSPEF back-annotation in NanoSim, see the NanoSim User Guide.

See Example 16 for a vcsAD.init file sample for a back-annotated SPICE subcircuit:

Example 16partition -cell chargepump;choose nanosim -n chrgpmp.sp -C cfg -nhspf chrgump.spf -o RES/ns;

37


38

4Customizing the NanoSim/VCS-MX Interface4

This chapter provides you with additional information about the analog and digital interface, including customizing commands. In addition, this chapter describes the autowrapper utility, which generates Verilog wrappers, as well as how signal conversion works with mixed-nets.

Overview

In a mixed-signal simulation, two types of signals must be able to directly communicate: digital (VCS-MX) and analog (NanoSim).

The first section of the chapter describes the autowrapper utility. The autowrapper generates an empty Verilog module from a SPICE description.

The second section of the chapter describes mixed-nets. Mixed nets are the nets at the interface between the digital blocks and the analog blocks.

These nets are called mixed because they simultaneously process analog and digital information. The signals on the mixed-nets, therefore, must be converted from analog-to-digital or from digital-to-analog.

39

Customizing the NanoSim/VCS-MX InterfaceAutowrapper Utility


• Autowrapper Utility

• Converting Signal Values

• Signal Strength Conversion

Autowrapper Utility

As described in the previous chapters, a NanoSim subcircuit cannot be instantiated in a VHDL or a Verilog description. A Verilog wrapper corresponding to the subcircuit must be initially created. The wrapper can be manually created or automatically created using the autowrapper utility.

After the wrapper has been created, you have to change the port direction in the wrapper.v file. Port direction does not pertain to a SPICE subcircuit, as all ports are considered inout. The autowrapper utility specifies all ports with inout direction. You must change the port direction in the wrapper.v file to assign the actual direction to each port (such as input, output, or inout).

The autowrapper utility creates wrapper.v and wrapper.log files (by default). The wrapper.v file contains all Verilog wrapper modules corresponding to all subcircuits that are defined in the SPICE file. For instance, if there are four subcircuits specified in the SPICE file, this utility creates four Verilog wrapper modules in the wrapper.v file.


autowrapper -n[fmt] netlist_file(s)_name[-bus_fm bus_format][-cell subckt_name(s)][-xcell subckt_name(s)] [-file netlist_file_name][-o output_file_name]


autowrapper -nspice test.spi

For instance, a SPICE file contains the following subcircuit, as shown in Example 17.

Example 17 SPICE subcircuit file sample*spice sub circuit definition example.subckt inv a znm1 zn a vdd vdd p 1 0.35m2 zn a gnd gnd n 2 0.35.ends

40


The autowrapper utility creates a Verilog wrapper, as shown in Example 18.

Example 18 Verilog wrapper module file sample//generated verilog wrapper examplemodule inv (a, zn);inout a;inout zn;

endmodule

All ports are defined as inout in module inv. You must change port directions; for example, a as input and zn as output.

For a description of the autowrapper utility options, see Table 2.

Table 2 autowrapper Utility Description

Utility option Description

-n[fmt] netlist_file(s)_name

Specifies the file name (in any NanoSim- supported format) to be read-in. (Required option)

-bus_fm bus_format Enables the recognition of bus signals (with a specified bus format) for the input netlist file. The default bus format is [%d], but it can be set to any valid node name symbols.

EXAMPLE:

bus signals bus format A[0] [%d]B_1 _%dC<2> <%d>D_3_ _%d_ E{4} {%d}F5 %dG6_ %d_

The _%d bus format directs the autowrapper utility to recognize bus signals defined as A_1, A_2 ..., A_n.

41


-cell subckt_name(s) Specifies the subcircuits, in the netlist file, that must be converted into Verilog wrapper modules. (All other subcircuits are ignored.) The module name uses the same case-sensitivity as subckt_name.

If the defined subcircuit does not exactly match in the file, the following WARNING message is displayed:There is no subckt .... in nanosim_netlist_name.

-xcell subckt_name(s)

Specifies the subcircuits that must NOT be converted into Verilog wrapper modules. (All other subcircuits are converted into Verilog wrapper modules.) This option excludes specified subcircuits, and is case-insensitive.

If the defined subcircuit does not exactly match in the file, the following WARNING message is displayed:There is no subckt .... in nanosim_netlist_name.

-file netlist_file_name

Defines a list of subcircuits that must be converted into Verilog wrapper modules. These subcircuits are defined in the netlist_file. The netlist_file must have one subcircuit name per line. You can define the excluded subcircuit(s) commenting out the subcircuit names with a semicolon (;), as in the following example:File:name.txt ;inv ;xor ;f_add xfer adder

Table 2 autowrapper Utility Description (Continued)


42


Using the Autowrapper Utility

See the following guidelines about using the Autowrapper utility:

• If an inout port is connected to the register type net, VCS generates an error message and stops compilation. In Verilog, a register type net should be connected to an input port—not an inout port. The autowrapper utility only generates inout ports, since direction does not exist in SPICE netlists. Therefore, before compiling, you must edit the wrapper.v file and specify the correct port direction.

• The autowrapper utility generates one Verilog wrapper module per subcircuit; therefore, it can generate unnecessary Verilog wrappers. Some of these modules might be using the same module name as other Verilog modules in the original Verilog code. If this occurs, VCS generates an error message and stops compilation. Therefore, before compiling, you must check the module names in the Verilog wrapper file. If the name is used elsewhere in the Verilog description, and this module is not an expected Verilog wrapper, you must remove the module from the Verilog wrapper file. You want to generate a wrapper module for the SPICE subcircuit adder4. Example 19 displays the SPICE netlist as shown:

Example 19 Wrapper module for adder4.subckt adder4 a[3] a[2] a[1] a[0] b[3] b[2] b[1] b[0]+ clk cin cout xinv1 clk clkn inv….ends.subckt inv a znm1 zn a vdd vdd p 1 0.35m2 zn a gnd gnd n 2 0.35.ends

-o output_file_name Enables the output to be written in the specified Verilog wrapper file and sets the .log file prefix.

If the same file exists in your output directory, it is overridden without a WARNING message.

Table 2 autowrapper Utility Description (Continued)


43


You run the following:

Autowrapper -nspi netlist -o net.v

The net.v file displays as shown in Example 20:

Example 20 net.v file samplemodule adder4 (a, b, clk, cin, cout);inout [3:0] a;inout [3:0] b;inout clk;inout cin;inout cout;endmodule

module inv (a, zn);inout a;inout zn;endmodule

The inv module is unnecessary here and can create confusion if another inv module exists in your original Verilog code. You must remove the inv module description from the net.v file.

• Verilog is case-sensitive. SPICE is not case-sensitive. You should check/ensure that the wrapper module name uses the same case- sensitivity as the instance in the Verilog netlist.

• No timescale information in the wrapper file is generated by the autowrapper utility. Therefore, the wrapper file must be placed at the end of the Verilog file’s compilation input:

vcs +ad a.v c.v d.v wrapper.v

• If the signal in the SPICE netlist is bus- or array-type, it must be expanded.

44


The autowrapper utility automatically generates bus- or array-type signals in the Verilog wrapper file (original SPICE subcircuit), as shown in Example 21. Refer to Table 2 for details.

Example 21 Bus- or array-type signals in a Verilog wrapper (original SPICE subcircuit)

.subckt mem DATA[3], DATA[2], DATA[1], DATA[0],+ WL[0], WL[1], WL[2], WL[3],+ WL[4], WL[5], WL[6], WL[7],+ R_WB, RAM_ENB.ends

The autowrapper utility automatically forms bus- or array-type signals in the Verilog wrapper file, as shown in Example 22. Refer to Table 2 for details.

Example 22 Bus- or array-type signals in a Verilog wrapper (generated Verilog wrapper module)

module mem (DATA, WL, R_WB, RAM_ENB);inout [3:0] DATA;inout [0:7] WL;inout R_WB;inout RAM_ENB;

endmodule

• If special characters and Verilog-specific words are used for the signal or subcircuit name, the name is assigned a backslash ( \ ) leading character.

In addition, a space is inserted at the end of the name in the Verilog wrapper file, as shown in Example 23.

Example 23 Backslash leading character and space in Verilog wrappermodule \inverter.test ( \if , \1 , \2 );

inout \if ;inout \1 ;inout \2 ;

endmodule

45


module vsources (\0 , \B#1 , B, \CE# , CLK, DECOUT, \Q^ , XDPD, \b#2 );

inout \0 ;inout \B#1 ;inout [5:5] B;inout \CE# ;inout CLK;inout [7:7] DECOUT;inout \Q^ ;inout [7:7] XDPD;inout \b#2 ;

endmodule

• If subcircuit ports in a bus are randomly ordered in the transistor netlist, the autowrapper utility cannot function properly.

See Example 24 for a sample (unsupported) file.

Example 24 Subcircuit ports in bus format.subckt p7ibptacddecwr clk wlw0[0] wlw0[10] wlw0[11] wlw0[12]+wlw0[13] wlw0[14] wlw0[15] wlw0[1] wlw0[2]+wlw0[3] wlw0[4] wlw0[5] wlw0[6] wlw0[7]+wlw0[8] wlw0[9] wlw1[0] wlw1[10] wlw1[11]+wlw1[12] wlw1[13] wlw1[14] wlw1[15] wlw1[1]+wlw1[2] wlw1[3] wlw1[4] wlw1[5] wlw1[6]+wlw1[7] wlw1[8] wlw1[9] writeadd[0] writeadd[1]+writeadd[2] writeadd[3] writeen[0] writeen[1].ends

• Nested subcircuits in the SPICE netlist are supported. A module is generated for the nested subcircuit; the module name is made of the nested subcircuit name preceded by the parent subcircuit name, itself preceded by a backslash character (\).

A nested subcircuit sample is shown in Example 25.

Example 25 Nested subcircuit (original SPICE subcircuit).subckt s in out.subckt inv13 in out.ends inv13.ends s

An automatically generated Verilog wrapper module sample is shown in Example 26.

46

Customizing the NanoSim/VCS-MX InterfaceConverting Signal Values

Example 26 Nested subcircuit (Verilog wrapper module)module s (in, out)

inout out;inout in;

endmodule

module \s.inv13 (in, out);inout out;inout in;

endmodule

Converting Signal Values

A mixed net (or interface net) is a net that is either

• output of a Verilog/VHDL netlist and input of a NanoSim netlist

• output of a NanoSim netlist and input of a Verilog/VHDL netlist

The mixed net carries a signal that must be converted from digital to analog (in the first case), and from analog to digital (in the second case).

As shown in Figure 9, net2 requires an A2D (analog-to-digital) translation, and net1 requires a D2A (digital-to-analog) translation.

Figure 9 A2D/D2A net translation

Digital to Analog Conversion

A digital signal can have four values: 0, 1, X or Z. These values must be converted into voltages for the NanoSim simulation. The default conversion rules can be changed using the NanoSim set_vec_opt command.

47


Digital-to-analog signal value conversion rules are explained in Table 3.

Using the NanoSim set_vec_opt Configuration Command

The NanoSim set_vec_opt command can be used to change the

• analog value corresponding to a digital 0 with the low= option

• analog value corresponding to a digital 1 with the high= option

• analog value corresponding to a digital X with the x_state= or x2v= options

Only the low, high, x_state, x2v, and no options for set_vec_opt are supported for converting the interface net values. The other options for the set_vec_opt command are not supported—refer to the NanoSim Command Reference for more information.


set_vec_opt low=0 high=1.8 no=top.clk$1

The set_vec_opt command redefines local supply voltage values to 1.8V for the top.clk interface node. Note the $1 suffix for the net name.

Table 3 Signal value conversion rules (digital-to-analog)

Digital value Analog value

0 0V (gnd)

Unless, the NanoSim set_vec_opt low= configuration command is set.

1 Local supply voltage value

Unless, the NanoSim set_vec_opt high= configuration command is set.

Z 0V when at time 0

After time 0, keeps the value set at the previous time step. Floating attribute is internally set.

X 0V

Unless, the NanoSim set_vec_opt configuration command is set.

48


A resistor is being automatically inserted between the top.clk and top.clk$1 nodes. This resistor is used to convert the digital signal strength into analog impedance. The resistance map file determines the resistor value (see the Signal Strength Conversion section). The top.clk$1 node is tied to 1.8V, if the logic value is 1. The top.clk$1 node is tied to 0V, if the logic value is 0.

Analog to Digital Conversion

A NanoSim simulation generates voltages that must be converted into a comprehensive value for VCS-MX. No analog value can be converted into a digital X.

By default, one-half of the local voltage supply is used as a threshold for digital event generation. If you want to change the threshold values for digital event generation on particular nodes, such as interface nodes, use the NanoSim set_node_thresh configuration command.

Analog-to-digital signal conversion rules are described in Table 4.

Table 4 Signal value conversion rules (analog-to-digital)

Analog value Digital value

Less than (<) or equal to (=) 50% of the local voltage supply value, unless the NanoSim set_node_thresh command is set

Less than (<) or equal to (=) ‘0.5*(high_thresh + low_thresh)’, if the set_node_thresh evt=0 NanoSim configuration command is used

Less than (<) or equal to (=) low_thresh, if the NanoSim set_node_thresh evt=1 NanoSim configuration command is used

0

49


Using the NanoSim set_node_thresh Configuration CommandThe set_node_thresh NanoSim configuration command can be used to change the threshold voltage; that is, the voltage value that makes logic 0 convert to logic 1, or logic 1 convert to logic 0.

Example 27 sets 0.35V as the low-thresh and 0.65V as the high-thresh. If the voltage on the top.dout interface node increases to 0.65V, the digital event is generated and the logic value changes from 0 to 1. If the voltage on the top.dout interface node decreases to 0.35V, the digital event is generated and the logic value changes from 1 to 0.

Example 27 set_node_thresh command exampleset_node_thresh 0.35 0.65 evt=1 top.dout

See Figure 10 for a visual representation.

Greater than (>) or equal to (=) 50% of the local voltage supply value, unless the NanoSim set_node_thresh command is set

Greater than (>) or equal to (=) ‘0.5*(high_thresh + low_thresh)’, if the set_node_thresh evt=0 NanoSim configuration command is used

Greater than (>) or equal to (=) high_thresh, if the set_node_thresh evt=1 NanoSim configuration command is used

1

Any value with a floating attribute Z

Table 4 Signal value conversion rules (analog-to-digital)

Analog value Digital value

50

Customizing the NanoSim/VCS-MX InterfaceSignal Strength Conversion

Figure 10 top.dout comparison (NanoSim vs. VCS)

Signal Strength Conversion

On the digital side, nets have a logic strength level. On the analog side, the reference term strength can be replaced by drive resistance. At the interface between NanoSim and VCS-MX, the logic strength on mixed-nets is converted into resistance, and the mixed-nets resistance is converted into logic strength.

The resistance mapping information maps ranges of transistor-level drive resistances to Verilog logic strength levels. You can map drive resistances to Verilog logic strength levels unidirectionally or bidirectionally.

Converting from Digital to Analog

Verilog strength is converted to the average resistance value. This value is calculated using the corresponding resistance range listed in a resistance map file. For example, the strength “6” is converted to 500.65 (ohm) by the default resistance map file.

51


Converting from Analog to Digital

Transistor-level resistance value is converted to the corresponding Verilog strength using a resistance map file. For example, the resistance value 100 (ohm) is converted to the strength “6” by the default resistance map file.

Creating a Resistance Map File

The default resistance map file rmapAD.init is available in the following directory

/<Nanosim_installed_directory>/<platform>/ns/interface/vcsace

Unless you specify your own resistance map file with the set rmap command in the mixed-signal simulation setup file (vcsAD.init, by default), the default resistance map file is used.

You can create your own resistance map file using unidirectional mapping, or bidirectional mapping.

Unidirectional MappingWhen you map unidirectionally, you specify that a signal—within a certain range of drive resistances—propagates from the transistor-level to the Verilog part of the design when a specific logic strength level is reached. In addition, when you unidirectionally map you specify that a signal—with a specific logic strength level—propagates to the transistor-level part of the design when a specific range of drive resistances is reached.

The drive resistance range from transistor-level to a Verilog strength level does not have to match the drive resistance range from a Verilog strength level to transistor-level.

The following shows resistance mapping information with unidirectional mapping

See the following syntax (-from -to) for unidirectional mapping:

resistance_map -from analog resistance_value_range -to verilog strength;

See the following syntax (-to -from) for unidirectional mapping:

resistance_map -to analog resistance_value_range -from verilog strength;

52


See Example 28 for a unidirectional resistance map file.

Example 28 Unidirectional resistance map fileresistance_map -from analog 90000.2-1e32 -to verilog 0;resistance_map -from analog 70000.2-90000.1 -to verilog 1;resistance_map -from analog 50000.2-70000.1 -to verilog 2;resistance_map -from analog 5000.2-50000.1 -to verilog 3;resistance_map -from analog 4000.2-5000.1 -to verilog 4;resistance_map -from analog 3000.2-4000.1 -to verilog 5;resistance_map -from analog 1.2-3000.1 -to verilog 6;resistance_map -from analog 0-1.1 -to verilog 7;

resistance_map -to analog 2002.2-1e32 -from verilog 0;resistance_map -to analog 1500.2-2002.1 -from verilog 1;resistance_map -to analog 1000.2-1500.1 -from verilog 2;resistance_map -to analog 500.2-1000.1 -from verilog 3;resistance_map -to analog 400.2-500.1 -from verilog 4;resistance_map -to analog 300.2-400.1 -from verilog 5;resistance_map -to analog 1.2-300.1 -from verilog 6;resistance_map -to analog 0-1.1 -from verilog 7;

Note:

Both directional definitions, -from analog -to verilog and -to analog -from verilog, are required.

Bidirectional Mapping

You can map drive resistance ranges to Verilog logic strength levels bidirectionally, so that the drive resistance range from transistor-level to Verilog (for logic strength level) matches the driver resistance range from Verilog to transistor-level (for logic strength level). The following is an example of the contents of such a resistance mapping file.

See the following syntax for bidirectional mapping:

resistance_map resistance_value_range strength;

See Example 29 for a sample bidirectional resistance map file.

53


Example 29 Bidirectional resistance map fileresistance_map 90000.2-1e32 0;resistance_map 70000.2-90000.1 1;resistance_map 50000.2-70000.1 2;resistance_map 5000.2-50000.1 3;resistance_map 4000.2-5000.1 4;resistance_map 1000.2-4000.1 5;resistance_map 1.2-1000.1;resistance_map 0-1.1 7;

54

5Mixed Simulation Output and Display5

This chapter describes saving signals or traces for display using waveform viewers and the unified output display (UOD) feature.

Overview

The output results of a mixed-signal simulation can be saved into two separate files: one file for VCS-MX results (VCD or VCD+ format) and one file for NanoSim results (.out or .fsdb format). As an alternative, your output results can be saved in a single (unified) output file (the UOD).


• Print (or Post-processing) Commands

• Viewing Waveform Files Separately with Viewers

• Viewing a Single Waveform File with the Unified Output Display (UOD)

55

Mixed Simulation Output and DisplayPrint (or Post-processing) Commands

Print (or Post-processing) Commands

You can save signal waveforms (or traces) for printing with

• VHDL syntax for a VHDL-top flow

• Verilog syntax for a Verilog-top flow

• NanoSim syntax (if the net you want to use is in the transistor-level description)

The Verilog and VHDL commands that save signal traces for printing do not save any of the analog signals. Only NanoSim commands can save analog signal waveforms.

The only formats that support VCS-MX traces, together with NanoSim waveforms in a single file, is

• VPD for the digital traces

• .out for the analog signal waveforms

VHDL Syntax (VHDL-top flow)

You can create a single VPD (VCD+) file for the digital part of the design (VHDL plus Verilog) using the VCS-MX dump command. To enable post-processing in the Verilog portion of the design, use the -PP switch for Verilog compilation (through -verilogcomp).

Example 30 is a compilation command that enables Verilog post-processing in the VHDL-top flow:

Example 30

scs WORG.CFG_TESTBENCH -mhdl -verilogcomp "+ad -PP"

By default, the dump command saves the signals in VCD+ format (.vpd); it is possible to generate VCD output format using the dump -vcd command.

See the following examples of VHDL dump commands:

Example 31 traces all signals in /TESTBENCH that are saved in the res.vdp file.

56

Mixed Simulation Output and DisplayPrint (or Post-processing) Commands

Example 31dump -deep /TESTBENCH -o res.vpd

Example 32 traces all signals from the TESTBENCH top-level (down) to the first level of hierarchy, which are dumped in the default VPD file name.

Example 32dump -deep -depth "1" /TESTBENCH

Example 33 traces all signals and ports of the I1 component in TESTBENCH that are saved in the dump.vpd file in the RES directory (RES must have been created before).

Example 33dump -deep /TESTBENCH/I1 -o RES/dump.vpd

See the VCS-MX Reference Guide for more information on the dump command.

Verilog Syntax (Verilog-top flow)

VCD+ files (or VPD files) are generated when VCS executes the $vcdpluson system task. When enabled, the VCD+ file contains simulation results from both the Verilog and VHDL sections of the design. Remember to compile vcs with the -PP option to enable the $vcdpluson task.

See the syntax and examples for the $vcdpluson Verilog task $vcdpluson[(level_number,module_instance|net or reg)];

In Example 34 all Verilog and VHDL signals are saved.

Example 34$vcdpluson;

In Example 35 all Verilog and VHDL signals for hierarchy levels 1 and 2 are saved (no traces for lower levels of hierarchy).

57

Mixed Simulation Output and DisplayViewing Waveform Files Separately with Viewers

Example 35$vcdpluson(2,top);

Transistor-level Description (VHDL-top and Verilog-top flows)

You can save the transistor-level description signal waveforms using the print_node_v and print_node_l NanoSim configuration commands . In a NS-VCS-MX mixed-simulation, the transistor-level description can never be at the top-level of the design; therefore, the specified names in the print_node_v or print_node_l commands must follow the design hierarchy. You can use the level option in the print_node_v or print_node_l command. The Verilog or VHDL hierarchy levels must take the level value into consideration.

See the following examples of the NanoSim print commands:

In Example 36, the transistor-level description is contained in the I1 component; all net voltages in the I1 component are saved.

Example 36print_node_v TESTBENCH.I1.*

In Example 37, all nets of the transistor-level descriptions are saved in both voltage and logic values.

Example 37print_node_v *print_node_l *

In Example 38, all voltage values at the first level of hierarchy are saved. If there are no SPICE nets at the first level of hierarchy in the design, voltage is not saved.

Example 38print_node_v level=1 *

Viewing Waveform Files Separately with Viewers

In NS-VCS-MX, the value change dump (VCD) file or the value change dump plus (VCD+) file is generated for the Verilog simulation portion. The NanoSim .out or .fsdb file is generated for the transistor-level portion. turboWave or

58

Mixed Simulation Output and DisplayViewing Waveform Files Separately with Viewers

CosmosScope is usually chosen for viewing NanoSim results, while VirSim is usually chosen for viewing VCS-MX results.

For a visual overview of how the turboWave and VirSim viewers enable you to view simulation results separately, see Figure 11.

Figure 11 Separate waveform viewing

Using turboWave

turboWave reads both the VCD file format and the NanoSim .out output file format. turboWave also reads .fsdb binary file format, but cannot read VCD+ binary file format. To generate the .fsdb binary format, use the set_print_format for=fsdb configuration command, or the -out fsdb command-line option for NanoSim.

The interactive display (marching waveform) is only available with the .out or .fsdb file. The UOD file cannot be used for the interactive display.

Using Alternative Waveform Viewers

The CosmosScope waveform viewer reads the .fsdb binary file format.

59

Mixed Simulation Output and DisplayViewing a Single Waveform File with the Unified Output Display (UOD)

When you use alternative waveform viewers, you must verify that the viewers can read the appropriate file formats.

Note:

See the respective manuals for details regarding the dumping of output files.

Viewing a Single Waveform File with the Unified Output Display (UOD)

The Unified Output Display (UOD) integrates the Value Change Dump+ (VPD) file in NS-VCS-MX with the NanoSim transistor-level circuit simulation .out file. The respective integration produces the _uod.out unified output file.

The UOD enables you to easily view all simulation results in one waveform viewer (such as turboWave). This new unified output file contains the complete hierarchy of all the signals from the SPICE netlist, Verilog netlist, and VHDL netlist.

For a visual overview of how the UOD enables you to view simulation results in a single waveform file, see Figure 12.

Figure 12 Single waveform view using the UOD

60


Using the set_print_uod Configuration Command for NS-VCS-MX

The NanoSim set_print_uodconfiguration command enables the UOD feature.

To write waveform data to the _uod.out file, you must use the VHDL dump command or the VCS $vcdpluson system task with either the NanoSim print_node_logicor the print_node_v configuration command. The UOD file is created only if analog signals are saved in the nanosim.out file. If neither print_node_v nor print_node_l commands are used, the _uod.out file is not created. You cannot use SPICE commands.

The following NanoSim configuration commands are not supported by UOD:

• set_print_filter

• set_print_tres (ignored)

When the set_print_uod command is in the NanoSim configuration file, the set_print_tres command is ignored. The UOD file print resolution is determined by the VCS-MX time resolution value.

UOD File Naming

The UOD file name is defined by the combination of the name specified by the NanoSim -o command-line option, and the _uod.out suffix. The default is nanosim_uod.out.

Reducing File Size

For large _uod.out files, you must set the set_print_uod command and the split_print_file command in the NanoSim configuration file to split the original .out file into several files.

If you set the NanoSim set_print_compress command, NanoSim generates an .out file in compressed format. The UOD generates the same compressed format.

Known Limitations

The following limitations currently apply:

61


• The UOD only supports NanoSim .out file format as output

• The UOD file cannot be used for the interactive display (marching waveform)

The UOD only supports the following original file formats:

• NanoSim (.out)

• VCD+ (.vpd)

Caution!

Do not use the set_print_uod command with the set_cosim_tres use=ns command.

62

ANanoSim-supported CommandsA

This appendix describes the NanoSim configuration commands and command-line options that are specific to NS-VCS-MX.

Overview

To support a mixed-signal simulation, two configuration commands have been implemented in NanoSim: set_cosim_tres and set_print_uod. A description of the configuration commands and NanoSim command-line options follows.

This chapter contains the following topics:

• set_cosim_tres Configuration Command

• set_print_uod Configuration Command

• NanoSim Command-line Options

set_cosim_tres Configuration Command

To synchronize the NanoSim and VCS-MX simulators, it is preferable for both simulators to use a single time resolution value. By default, if the NanoSim time resolution value is less than the VCS-MX time resolution value, NanoSim uses

63

NanoSim-supported Commandsset_cosim_tres Configuration Command

its own value and VCS-MX uses its own value. If the VCS-MX time resolution value is less than the NanoSim time resolution value, the VCS-MX value overrides the NanoSim value.

Although not recommended, if you prefer to use a NanoSim time precision value that is greater than a VCS-MX time precision value, you must use the NanoSim set_cosim_tres use=ns configuration command in combination with the set_sim_tres <value> command. Note that there is a slight risk of your simulation terminating, due to asynchronism. If this occurs, discontinue using the set_cosim_tres command.

The set_sim_tres command sets the NanoSim time resolution value and the set_cosim_tres use=ns command forces NanoSim to keep its own time resolution value (even if the VCS-MX time resolution value is smaller).

See the following syntax:

set_cosim_tres [use=ns]

When the use=ns option is set, VCS uses its own time resolution value (see Example 39), and NanoSim uses its own time resolution value specified by the set_sim_tres configuration command.

Example 39 Using the set_sim_tres value as the NanoSim time resolution value

set_cosim_tres use=ns

If the time resolution differs between VCS and NanoSim, NanoSim generates a warning message. Example 40 and Example 41 show the difference in time resolutions. In both examples, the VHDL time resolution is not set, the VHDL time base is nanoseconds, and the VHDL time resolution is 1 ns.

Example 40 VCS description‘timescale 1ns/1ps

The NanoSim configuration file displays:

set_cosim_tres use=ns

Since the default value for set_sim_tres is 10ps, the following message appears:

WARNING: VCS time resolution doesn't match NanoSim time resolution. VCS time resolution is <1ps>, NanoSim time resolution is <10ps>. Simulation time resolution: <10ps>

64

NanoSim-supported Commandsset_print_uod Configuration Command

Example 41 Second VCS description‘timescale 1ns/10ps

The NanoSim configuration file displays:

set_cosim_tres use=nsset_sim_tres 1ps

The following message appears:

WARNING: VCS time resolution doesn't match NanoSim time resolution. VCS time resolution is <10ps>, NanoSim time resolution is <1ps>. Simulation time resolution: <1ps>

In Example 41, the set_cosim_tres use=ns command is not useful because the default time resolution would have been 1ps—the smallest of the VCS-MX and NanoSim time resolution values.

set_print_uod Configuration Command

The set_print_uod configuration command directs NS-VCS-MX to generate the _uod.out file.


set_print_uod [out=uod|all]

set_print_uod

The _uod.out file is generated, if:

• VHDL-top design flow dump command or Verilog-top design flow $vcdpluson system task is specified in the Verilog description

• set_print_uod is specified in the NanoSim configuration file

• print_node_v command or print_node_logic command is specified in the NanoSim configuration command file

The default value for the out= option is uod. When the set_print_uod configuration command is used, a single output file (if no option or out=uod option is used) with the _uod.out suffix is generated. The format of this file is the NanoSim .out ASCII format.

If you specify a format different from .out for the NanoSim simulation (using the set_print_format configuration command or -out command-line

65

NanoSim-supported CommandsNanoSim Command-line Options

option), a warning is issued and the output format is forced to .out. See the following sample warning message: WARNING: Illegal output file type defined 'fsdb' in UOD mode. The output file type has been changed to .out print format.

For a description of the set_print_uod configuration command arguments, see Table 5.

NanoSim Command-line Options

The NanoSim command-line must be specified in the mixed-signal simulation setup file (vcsAD.init). The general syntax is

nanosim -n[format] netlist [options]

For a summary of the NanoSim command-line options supported for NS-VCS-MX simulation, see Table 6.

Table 5 set_print_uod command arguments

Command Argument Description

out=uod Generates the UOD file only

out=all Generates all formats: UOD, vpd and out

Table 6 NanoSim-supported command-line options

NanoSim command-line option syntax

Description

-A This option starts the double-precision version of NanoSim. You often need to use this option to simulate analog circuits.

-c configuration_ file(s) This option specifies the names of the configuration files for a NanoSim run.

-C configuration_ file(s) This option does the same as the -c option, except that all the commands in the configuration files specified with this option are logged in the .log file.

66


-d timing_mode By default, NanoSim uses piecewise linear (PWL) mode. This option changes the timing mode in which NanoSim runs.

Choose one of the following modes:

• t (or rc) = full-delay (rc) mode• u (or ud) = unit-delay mode

-fm ADFMI_file(s) This option specifies files that contain ADFMI-based C models. You can use the full name of the model files, with the .c or .o extension, but it is not required. This option does not force a recompilation of the .c file, if the .o file is newer. See the NanoSim Modeling Guide for ADFMI and Verilog-A for details on how to use the ADFMI-based C models.

-FM ADFMI_file(s) This option is the same as the -fm option, except it forces the recompilation of the .c files.

-fm_user_lib Specifies the complete path to the global model library. Note: you are required to set the LD_LIBRARY_PATH environment variable with the path where the pre-compiled shared libraries are located.

-har [hilo_file] This option starts Hierarchical Array Reduction (HAR). It takes one optional argument: the name of a hilo file.

-include_path This option specifies the search path for include statements.

-L library_path This option specifies the search order when a subcircuit cell (for example, inv) is encountered: (1) Reads the input file, including any .INC or .LIB files, for a subcircuit with the specified cell name; (2) Searches the directories, specified by the -L option, for cell_name.xxx, while .xxx can be any NanoSim-supported SPICE file extension such as .spi or .spec.

Table 6 NanoSim-supported command-line options (Continued) (Continued)


Description

67


-n[format] netlist(s) This option specifies the netlist format and the netlist file(s) containing the input netlist and stimulus descriptions for NanoSim. The format argument can be any one of the following:spice (for SPICE), spectre (for Spectre), edif (for EDIF), vlog (for Verilog), vec (for vector files) or hspf (for hierarchical SPF). By default, the format is spice.

-o output_file_prefix This option directs the simulation output files to be saved with the specified prefix. EXAMPLE: -o myfile

-out out|fsdb|wdb|cou|custom_format_name

This option specifies the format of the NanoSim output file. The default is out.

-p technology_file This option specifies the name of the technology file for NanoSim. The technology file describes the key features of the process technology that NanoSim uses to predict the transistor behavior in the circuit. EXAMPLE:nanosim -n netlist -p tech.tt.25.5

-Q This option specifies quiet mode, which suppresses the printing of warning messages to stderr or the .log files.

-q This option suppresses the printing of all warning messages to the stderr (to the screen).

-r [always | never | compare | warning]

This option controls the process by which NanoSim automatically generates technology files for HSPICE netlists. It is not required for automatic technology file generation to work. Only one keyword can be specified.

-W max_messages This option specifies the maximum number of warning messages to be reported.



Description

68


Note:

The -t option is not supported for NS-VCS-MX simulation. If you specify time with the -t option, it is ignored. For a complete list of the NanoSim command-line options, please see the NanoSim User Guide.

-w With this option specified, NanoSim waits for you to respond to each warning message.

-y This option turns on the warning message printing for unused netlist ports.

-z prefix This option starts the automatic technology-file-generation feature for HSPICE netlists. It also names or designates the technology files to be used for a particular simulation run.



Description

69


70

BTroubleshootingB

This appendix contains some helpful hints for debugging and successfully running your mixed-signal simulation.

Debugging

Before starting a mixed-signal simulation, it is highly recommended that you first run a pure VCS-MX simulation. Try— if possible—to replace the transistor-level section with VHDL or Verilog models, and ensure you can run the VCS-MX simulation and get expected results. You can then replace the Verilog or VHDL blocks you want to simulate with NanoSim using a transistor-level description.

If possible, you should run the transistor-level description blocks as a stand-alone with NanoSim. Create stimuli that emulates the digital input behavior, run NanoSim on the block(s), and ensure you get the expected results outside the design environment. Try—as much as possible—to reduce the number of subcircuits connected to Verilog or VHDL. The fewer A2D and D2A conversions, the better the performance will be.

71

TroubleshootingTime Precision

Time Precision

Time precision may be a concern in a mixed-signal simulation because three types of descriptions are used: VHDL, Verilog, and SPICE (NanoSim):

• In VHDL code, time precision is specified with the time_resolution value in the synopsys_sim.setup file. See the following example:

TIMEBASE = nsTIME_RESOLUTION = 10ps

or, it can be specified in the scs command line. See the following example:

scs config -time_res 10ps -verilogcomp "+ad"

If TIME_RESOLUTION is not specified, the time precision is set to 1x'TIMEBASE'. For instance, if TIMEBASE=ns and TIME_RESOLUTION is not set, the time precision is set to 1ns by default. Note that the default for TIMEBASE is ns.

• In Verilog, the time precision is specified in the first line of the Verilog description. It is the last argument of the 'timescale command. See the following example:

`timescale 1ns/10ps

Note that the vcs command also has a -timescale=timeunit/time_precision option.

• In NanoSim, the time precision is set with the NanoSim set_sim_tres configuration command (the default value is 10ps), or is set with the sim option in the set_sim_eou command. See the following examples:

set_sim_tres 1psor

set_sim_eou sim=4; sim=4 forces ‘set_sim_tres 1ps’

What Time Precision Value is Used in my Mixed-signal Simulation?

The time precision value used in your simulation is either the VCS-MX value or the NanoSim value—or both. The VCS-MX time resolution is always the smallest of the VHDL and Verilog time resolution values. You should use the

72

TroubleshootingTime Precision

same time precision for the VHDL and Verilog descriptions. See the following guidelines:

• If you do not specify in the NanoSim configuration file: set_cosim_tres use=ns; (note that ns stands for NanoSim, not nanosecond!), or if you specify set_cosim_tres use=vcs; (default), NanoSim and VCS-MX time precision values are determined under the following conditions:

a. The NanoSim value is equal to or greater than the VCS-MX value

The VCS-MX time resolution value is used in both the NanoSim and VCS-MX simulators.

b. The NanoSim value is less than the VCS-MX value

Both simulators use their own time resolution values.

If the values differ, a warning message appears. If the VCS time resolution is smaller, the following warning appears:

***** WARNING: VCS time resolution doesn't match NanoSim time resolution. NanoSim time resolution override by VCS time resolution automatically. VCS time resolution is <1ps>, NanoSim time resolution is <10ps>. Simulation time resolution :<1ps>

If the NanoSim time resolution is smaller, the following warning appears:

***** Warning: VCS time resolution (10.000000 ps) is larger than NanoSim time resolution (1.000000 ps)

***** Warning: NS time resolution 1.000000 ps is used

Simulation time resolution :<1ps>

• If you specify set_cosim_tres use=ns in the NanoSim configuration file, this command forces both NanoSim and VCS to keep their own time resolutions. If the time resolutions differ, warnings appear as shown in the section set_cosim_tres Configuration Commandof Appendix A, “NanoSim-supported Commands.”

73

TroubleshootingLimitations at the Interface

Limitations at the Interface

The present version of the NS-VCS-MX mixed-signal simulator has limitations at the interface between VCS-MX and NanoSim. These limitations are as follows:

• In the VHDL description, any port with a real data type cannot be inout. The port_mode (port direction) must be input or output.

• In the Verilog wrapper description, any port defined as wreal cannot beinout. The port must be input or output.

• Power nets (ground or supplies) are not expected at the interface.

Performance Improvement

Occasionally, a mixed-signal simulation is not as rapid as expected. Some recommendations for performance improvement in your mixed-signal simulation follow:

• Avoid mixed (interface) nets with a real data type in VHDL.

• Do not use ground or supply nets at the interface.

• Minimize the number of interface nets.

• Minimize the number of SPICE subcircuits connected to VCS. It is preferable to have a single subcircuit rather than several subcircuits. The purpose is to minimize the unneeded A2A conversions.

In Figure 13, three SPICE subcircuits are instantiated in the Verilog description. A total of six conversions is required including two analog-to-analog (A2A) conversions.

74

TroubleshootingPerformance Improvement

Figure 13 Three SPICE subcircuits

In Figure 14, the three subcircuits have been assembled into a single subcircuit. Only four conversions are required—all A2A conversions have been removed.

Figure 14 Three subcircuits

75

TroubleshootingPerformance Improvement

76

GlossaryGL

A2DAn analog-to-digital converter.

BABack-annotation (BA) is a process of stitching the parasitic RCs back to your design netlist through connectivity information (net name, instance name, pin name) inside the parasitic file.

bidirectional switchA device that conducts in both directions. In such cases, signals on either side of the device can be the driver signal. A bidirectional switch is typically used to enable isolation between buses or signals.

D2AA digital-to-analog converter.

donut configurationIn NS-VCS-MX, a donut configuration only applies to the VCS-MX description. You can instantiate a Verilog design in a VHDL design in a Verilog design (Verilog-VHDL-Verilog). This is commonly referred to as a mixed-HDL donut.

DSPFA detailed standard parasitic format (DSPF) output netlist format is generated by an extraction tool, and describes interconnect information. Actual net parasitic resistance and capacitance component information is contained in this format.

GUIA graphical user interface (GUI) for NanoSim.

HARHierarchical array reduction (HAR) in NanoSim that speeds-up the simulation for memory designs (DRAM and SRAM).

77

mixed-signalA circuit containing analog- and digital-style components.

NanoSimThe Synopsys fast-SPICE transistor-level simulator.

PLIA programming language interface (PLI) of Verilog HDL is a mechanism for interfacing Verilog programs with programs written in the C language. PLI also provides a mechanism for accessing internal databases of the simulator from the C program.

real data typeThe Verilog or VHDL data type defined in IEEE Std 1264-1996 and Std 1364-2001.

resistance map fileAn ASCII file that equates MOSFET "on" resistance to Verilog drive strength; the resistance map file contains the signal conversion data between a SPICE analog value to a Verilog digital value, and a Verilog digital value to a SPICE analog value.

scsA VHDL compiler command.

scsimA VHDL simulator command.

SDFA standard delay format (SDF) file stores the timing data generated by EDA tools for use in any stage of a design process. The data in the SDF file is represented in a tool-independent way and includes the following information: delay, timing check, timing constraint, incremental and absolute delay.

simvA Verilog simulator command.

SPEFA standard parasitic extraction format (SPEF) file is an IEEE standard format. This file provides a standard median to pass parasitic information between EDA tools during any stage in the design process. This format contains actual net parasitic resistance and capacitance components.

SPICE netlistIn the present context, the term SPICE netlist is used in place of transistor-level netlist

78

VCSA Synopsys Verilog hardware description language (HDL) simulator.

VCS-MXA Synopsys simulator for Verilog, VHDL, and mixed-HDL design descriptions.

VHDLVHSIC HDL

VPDAn output format for VCS-MX. VPD uses the VCD+ (value change dump) format.

Verilog dummy moduleA module that is the Verilog place holder for a transistor block. A dummy module is an empty module containing only the module declaration and port declarations.

Verilog wrapperA Verilog netlist comprising an empty module. Only the module name and port description are in the wrapper.

vhdlanA VHDL analyzer command.

vloganA Verilog analyzer command.

wreal data typeA real net data type used in a Verilog wrapper module to interface a real data type VHDL port and a SPICE port in NS-VCS-MX.

XMRA feature that is extensively used in Verilog testbenches, and is referred to as a cross-module reference or Verilog hierarchical referencing. This feature enables simple probing into, or monitoring of, buried signals without requiring the signals to be routed to the top of the design for observation. No declaration of global signals in a package is required for this feature, nor is any modification of the original monitored code.

79

80

Index

Symbols$vcdpluson system task 61

Aanalog conversion 52analog to digital conversion 49array-type signal, Verilog wrapper 45array-type signals, Verilog wrapper 45autowrapper utility 40

Bback-annotation 36bidirectional mapping 53bus-type signal, Verilog wrapper 45bus-type signals, Verilog wrapper 45

Ccommands

partition 20set bus_format 22set rmap 24

configuration commandset_cosim_tres 64

configuration commands 63configuration files, specifying 66converting signal values 47Cosmos Scope waveform viewer 59

Ddigital conversion 51

digital to analog conversion 47double-precision mode 66dump command 61

EEDIF netlist format 68

Ffiles

<italics>See output filesflow description 6

Hhelp commands

set_cosim_tres 64hierarchical SPF netlist format 68HSPF back-annotation 36

Iinput files 13

configuration 66netlist 68technology 68

input netlist 68installation requirements 2instance-based partitioning 21

Mmixed-signal simulation setup file 19module-based partitioning 21

81

Index

Nnanosim command, choosing 20NanoSim command-line options 66NanoSim commands, supporting 61NanoSim configuration commands 63NanoSim reduction commands

set_print_compress 61split_print_file 61

NanoSim-VCS-MX, cosimulating 1netlist file

specifying format 68

Ooutput files

prefix specification 68

Ppartition command 20partitioning commands

set bus_format 22set rmap 20, 24

printing commands 56

Rresistance map file 52resistance map file, creating 52

SSDF file 36set bus_format command 22set rmap command 24set_cosim_tres command 64set_node_thresh 50set_print_compress command, compressing 61set_print_tres command 61set_print_uod command 61set_vec_opt 48

high= argument 48low= argument 48no= argument 48x_state= argument 48

setting up environment 3signal strength conversion 51signal value conversion rules 48

simulator, selecting 20SPICE netlist 15

array-type signal 44bus-type signal 44

SPICE netlist format 68SPICE netlist guidelines 15split_print_file command, splitting files 61supported features 5

Ttechnology files

automatic generation 68specifying 68

transistor-level description 58turboWave 59

Uunidirectional mapping 52unified output file 60UOD file naming 61

VVerilog input 14Verilog netlist format 68Verilog syntax 57Verilog wrapper 17Verilog wrapper file, bus/array-type signals 45Verilog-top flow 30VHDL design library 17VHDL input 14VHDL syntax 56VHDL-top flow 26viewing waveforms separately 58viewing with UOD 60

Wwaveform viewer

Cosmos Scope 59

XXMR, cross module reference 9

82

Date post:	22-Dec-2015
Category:	Documents
Upload:	salman-salu
View:	21 times
Download:	6 times

ns_vcs_mx

Documents