Vcs /vcsi™ User Guide: Version F-2011.12-Sp1 May 2012
Vcs /vcsi™ User Guide: Version F-2011.12-Sp1 May 2012
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Registered Trademarks ()
Synopsys, AEON, AMPS, Astro, Behavior Extracting Synthesis Technology, Cadabra, CATS, Certify, CHIPit, CoMET, Confirma, CODE V, Design Compiler, DesignWare, EMBED-IT!, Formality, Galaxy Custom Designer, Global Synthesis, HAPS, HapsTrak, HDL Analyst, HSIM, HSPICE, Identify, Leda, LightTools, MAST, METeor, ModelTools, NanoSim, NOVeA, OpenVera, ORA, PathMill, Physical Compiler, PrimeTime, SCOPE, Simply Better Results, SiVL, SNUG, SolvNet, Sonic Focus, STAR Memory System, Syndicated, Synplicity, the Synplicity logo, Synplify, Synplify Pro, Synthesis Constraints Optimization Environment, TetraMAX, UMRBus, VCS, Vera, and YIELDirector are registered trademarks of Synopsys, Inc.
Trademarks ()
AFGen, Apollo, ARC, ASAP, Astro-Rail, Astro-Xtalk, Aurora, AvanWaves, BEST, Columbia, Columbia-CE, Cosmos, CosmosLE, CosmosScope, CRITIC, CustomExplorer, CustomSim, DC Expert, DC Professional, DC Ultra, Design Analyzer, Design Vision, DesignerHDL, DesignPower, DFTMAX, Direct Silicon Access, Discovery, Eclypse, Encore, EPIC, Galaxy, HANEX, HDL Compiler, Hercules, Hierarchical Optimization Technology, High-performance ASIC Prototyping System, HSIMplus, i-Virtual Stepper, IICE, in-Sync, iN-Tandem, Intelli, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, Liberty, Libra-Passport, Library Compiler, Macro-PLUS, Magellan, Mars, Mars-Rail, Mars-Xtalk, Milkyway, ModelSource, Module Compiler, MultiPoint, ORAengineering, Physical Analyst, Planet, Planet-PL, Polaris, Power Compiler, Raphael, RippledMixer, Saturn, Scirocco, Scirocco-i, SiWare, Star-RCXT, Star-SimXT, StarRC, System Compiler, System Designer, Taurus, TotalRecall, TSUPREM-4, VCSi, VHDL Compiler, VMC, and Worksheet Buffer are trademarks of Synopsys, Inc.
ii
Contents
1. Getting Started Simulator Support with Technologies . . . . . . . . . . . . . . . . . . . . . Setting Up the Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifying Your System Configuration . . . . . . . . . . . . . . . . . . . Obtaining a License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Up Your Environment. . . . . . . . . . . . . . . . . . . . . . . . . Setting Up Your C Compiler. . . . . . . . . . . . . . . . . . . . . . . . . . Using the Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default Time Unit and Time Precision . . . . . . . . . . . . . . . . . . . . . 2. VCS Flow Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using vcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commonly Used Options . . . . . . . . . . . . . . . . . . . . . . . . . Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interactive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 2-2 2-3 2-8 2-8 1-2 1-4 1-4 1-5 1-6 1-8 1-8 1-9 1-9
iii
Batch Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commonly Used Runtime Options. . . . . . . . . . . . . . . . . . . . . 3. Modeling Your Design Avoiding Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using and Setting a Value at the Same Time . . . . . . . . . . . . Setting a Value Twice at the Same Time . . . . . . . . . . . . . . . . Flip-Flop Race Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . Continuous Assignment Evaluation . . . . . . . . . . . . . . . . . . . . Counting Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time Zero Race Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . Race Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Dynamic Race Detection Tool. . . . . . . . . . . . . . . . . . . . . Introduction to the Dynamic Race Detection Tool . . . . . . Enabling Race Detection . . . . . . . . . . . . . . . . . . . . . . . . . The Race Detection Report . . . . . . . . . . . . . . . . . . . . . . . Post Processing the Report . . . . . . . . . . . . . . . . . . . . . . . Debugging Simulation Mismatches . . . . . . . . . . . . . . . . . The Static Race Detection Tool . . . . . . . . . . . . . . . . . . . . . . . Optimizing Testbenches for Debugging. . . . . . . . . . . . . . . . . . . . Conditional Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling Debugging Features At Runtime. . . . . . . . . . . . . . . Combining the Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . Avoiding the Debugging Problems From Port Coercion . . . . . . . Creating Models That Simulate Faster . . . . . . . . . . . . . . . . . . . . Unaccelerated Data Types, Primitives, and Statements . . . .
2-9 2-9
3-2 3-2 3-3 3-4 3-5 3-6 3-7 3-7 3-8 3-8 3-11 3-12 3-15 3-17 3-19 3-21 3-22 3-23 3-26 3-27 3-28 3-29
iv
Inferring Faster Simulating Sequential Devices . . . . . . . . . . . Modeling Faster always Blocks . . . . . . . . . . . . . . . . . . . . . . . Using the +v2k Compile-Time Option . . . . . . . . . . . . . . . . . . Case Statement Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Precedence in Text Macro Definitions . . . . . . . . . . . . . . . . . . . . . Memory Size Limits in the Simulator . . . . . . . . . . . . . . . . . . . . . . Using Sparse Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . Obtaining Scope Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scope Format Specifications . . . . . . . . . . . . . . . . . . . . . . . . . Returning Information About the Scope. . . . . . . . . . . . . . . . . Avoiding Circular Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . Designing With $lsi_dumpports for Simulation and Test . . . . . . . Dealing With Unassigned Nets . . . . . . . . . . . . . . . . . . . . . . . Code Values at Time 0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross Module Forces and No Instance Instantiation . . . . . . . Signal Value/Strength Codes . . . . . . . . . . . . . . . . . . . . . . . . . 4. Compiling the Design Compiling or Elaborating the Design in Debug Mode . . . . . . . . . Compiling or Elaborating the Design in Optimized Mode . . . . . . Key Compilation Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Initializing Verilog Memories and Registers . . . . . . . . . . . . . . Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overriding Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-31 3-35 3-36 3-37 3-38 3-38 3-39 3-40 3-40 3-43 3-46 3-48 3-48 3-49 3-50 3-52
Checking for X and Z Values In Conditional Expressions . . . Enabling the Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . Filtering Out False Negatives . . . . . . . . . . . . . . . . . . . . . . VCS V2K Configurations and Libmaps . . . . . . . . . . . . . . . . . Library Mapping Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchical Configurations . . . . . . . . . . . . . . . . . . . . . . . The -top Compile-time Option . . . . . . . . . . . . . . . . . . . . . Limitations of Configurations . . . . . . . . . . . . . . . . . . . . . . Using +evalorder Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Simulating the Design Using DVE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using UCLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ucli2Proc Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options for Debugging Using DVE and UCLI . . . . . . . . . . . . . . . Key Runtime Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Passing Values from the Runtime Command Line . . . . . . . . Profiling the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPU Time Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Memory Usage Views . . . . . . . . . . . . . . . . . . . . . . . . . . . Save and Restart The Simulation . . . . . . . . . . . . . . . . . . . . . Save and Restart Example. . . . . . . . . . . . . . . . . . . . . . . . Save and Restart File I/O . . . . . . . . . . . . . . . . . . . . . . . . . Save and Restart With Runtime Options . . . . . . . . . . . . . Specifying a Long Time Before Stopping The Simulation . . . How VCS Prevents Time 0 Race Conditions . . . . . . . . . . . . .
4-7 4-8 4-8 4-11 4-11 4-13 4-16 4-17 4-18 4-18
5-2 5-3 5-5 5-6 5-8 5-8 5-9 5-10 5-19 5-22 5-23 5-24 5-25 5-26 5-28
vi
6. VCS Multicore Technology Application Level Parallelism VCS Multicore Technology Options . . . . . . . . . . . . . . . . . . . . . . . Use Model for Assertion Simulation. . . . . . . . . . . . . . . . . . . . Use Model for Toggle and Functional Coverage . . . . . . . . . . Use Model for VPD Dumping. . . . . . . . . . . . . . . . . . . . . . . . . Running VCS Multicore Simulation . . . . . . . . . . . . . . . . . . . . . . . Assertion Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Toggle Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VPD File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parallel SAIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customary SAIF System Function Entries. . . . . . . . . . . . . . . Enabling Parallel SAIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. VPD, VCD, and EVCD Utilities Advantages of VPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dumping a VPD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using System Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enable and Disable Dumping. . . . . . . . . . . . . . . . . . . . . . Override the VPD Filename . . . . . . . . . . . . . . . . . . . . . . . Dump Multi-dimensional Arrays and Memories . . . . . . . . Using $vcdplusmemorydump . . . . . . . . . . . . . . . . . . . . . . Capture Delta Cycle Information . . . . . . . . . . . . . . . . . . . Dumping an EVCD File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2 7-3 7-3 7-4 7-7 7-8 7-17 7-18 7-19 6-2 6-4 6-4 6-4 6-5 6-5 6-6 6-7 6-9 6-10 6-10 6-11 6-11
vii
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Post-processing Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The vcdpost Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scalarizing the Vector Signals . . . . . . . . . . . . . . . . . . . . . Uniquifying the Identifier Codes . . . . . . . . . . . . . . . . . . . . The vcdpost Utility Syntax . . . . . . . . . . . . . . . . . . . . . . . . The vcdiff Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The vcdiff Utility Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . The vcat Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The vcat Utility Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating Source Files From VCD Files . . . . . . . . . . . . Writing the Configuration File . . . . . . . . . . . . . . . . . . . . . . The vcsplit Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The vcsplit Utility Syntax . . . . . . . . . . . . . . . . . . . . . . . . . The vcd2vpd Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options for specifying EVCD options . . . . . . . . . . . . . . . . The vpd2vcd Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Command File Syntax. . . . . . . . . . . . . . . . . . . . . . . . The vpdmerge Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Performance Tuning Compile-time Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Incremental Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compile Once and Run Many Times . . . . . . . . . . . . . . . . . . . Parallel Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Runtime Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Radiant Technology . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-21 7-23 7-23 7-24 7-25 7-26 7-26 7-27 7-35 7-35 7-39 7-40 7-45 7-45 7-48 7-50 7-50 7-56 7-60
viii
Compiling With Radiant Technology. . . . . . . . . . . . . . . . . Applying Radiant Technology to Parts of the Design . . . . Improving Performance When Using PLIs. . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. Gate-level Simulation SDF Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Unified SDF Feature . . . . . . . . . . . . . . . . . . . . . . . . . . Using $sdf_annotate System Task. . . . . . . . . . . . . . . . . . . . .
Using -xlrm Option for SDF Retain, Gate Pulse Propagation, and Gate Pulse Detection Warning . . . . . . . . . . . . . . . . . . . . . . . . . 9-5 Using Optimistic Mode in SDF . . . . . . . . . . . . . . . . . . . . . 9-5 Using Gate Pulse Propagation . . . . . . . . . . . . . . . . . . . . . 9-6 Generating Warnings During Gate Pulses . . . . . . . . . . . . 9-7 Precompiling an SDF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating the Precompiled Version of the SDF file . . . . . . SDF Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Delay Objects and Constructs . . . . . . . . . . . . . . . . . . . . . SDF Configuration File Commands . . . . . . . . . . . . . . . . . approx_command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . mtm_command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . scale_command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SDF Example with Configuration File. . . . . . . . . . . . . . . . Delays and Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport and Inertial Delays. . . . . . . . . . . . . . . . . . . . . . . . . Different Inertial Delay Implementations . . . . . . . . . . . . . 9-8 9-8 9-9 9-10 9-11 9-11 9-12 9-13 9-14 9-16 9-17 9-19
ix
Enabling Transport Delays . . . . . . . . . . . . . . . . . . . . . . . . Pulse Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pulse Control with Transport Delays . . . . . . . . . . . . . . . . . . . Pulse Control with Inertial Delays. . . . . . . . . . . . . . . . . . . Specifying Pulse on Event or Detect Behavior . . . . . . . . . Specifying the Delay Mode . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Configuration File to Disable Timing . . . . . . . . . . . . . . Using the timopt Timing Optimizer . . . . . . . . . . . . . . . . . . . . . . . Editing the timopt.cfg File . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing Potential Sequential Device Entries . . . . . . . . . . . Editing Clock Signal Entries . . . . . . . . . . . . . . . . . . . . . . . Using Scan Simulation Optimizer . . . . . . . . . . . . . . . . . . . . . . . ScanOpt Config File Format . . . . . . . . . . . . . . . . . . . . . . . . . ScanOpt Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Negative Timing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Need for Negative Value Timing Checks . . . . . . . . . . . . The $setuphold Timing Check Extended Syntax . . . . . . . Negative Timing Checks for Asynchronous Controls . . . . The $recrem Timing Check Syntax . . . . . . . . . . . . . . . . . Enabling Negative Timing Checks . . . . . . . . . . . . . . . . . . . . . Other Timing Checks Using the Delayed Signals . . . . . . . . . Checking Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Toggling the Notifier Register. . . . . . . . . . . . . . . . . . . . . . . . . SDF Back-annotation to Negative Timing Checks . . . . . . . . . How VCS Calculates Delays . . . . . . . . . . . . . . . . . . . . . . . . . Using Multiple Non-overlapping Violation Windows. . . . . . . .
9-21 9-22 9-24 9-26 9-31 9-35 9-37 9-37 9-40 9-40 9-41 9-42 9-43 9-44 9-45 9-46 9-51 9-54 9-55 9-57 9-58 9-62 9-63 9-64 9-65 9-67
10. Coverage Code Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options For Coverage Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . 11. Using OpenVera Native Testbench Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Template Generator . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiple Program Support . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration File Model . . . . . . . . . . . . . . . . . . . . . . . . . Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Model for Multiple Programs . . . . . . . . . . . . . . . . . NTB Options and the Configuration File. . . . . . . . . . . . . . Separate Compilation of Testbench Files . . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class Dependency Source File Reordering. . . . . . . . . . . . . . Circular Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . Dependency-based Ordering in Encrypted Files . . . . . . . Using Encrypted Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Reference Verification Methodology . . . . . . . . . . . . . . Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3 11-3 11-5 11-5 11-6 11-18 11-18 11-19 11-19 11-20 11-21 11-23 11-24 11-24 11-25 11-26 11-27 11-28 11-29 11-29 11-30 10-1 10-2 10-3
xi
Performance Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling the NTB Profiler. . . . . . . . . . . . . . . . . . . . . . . . . Performance Profiler Example . . . . . . . . . . . . . . . . . . . . . 12. Using SystemVerilog Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using VMM with SV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Debugging SystemVerilog Designs . . . . . . . . . . . . . . . . . . . . . . . Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Newly implemented SystemVerilog Constructs . . . . . . . . . . . . . .
Support for Aggregate Methods in Constraints Using the with Construct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5 Debugging During Initialization SystemVerilog Static Functions and Tasks in Module Definitions . . . . . . . . . . . . . . . . . . . . . . . 12-6 Explicit External Constraint Blocks . . . . . . . . . . . . . . . . . . . . 12-10 Generate Constructs in Program Blocks . . . . . . . . . . . . . . . . 12-13 Error Condition for Using a Genvar Outside of its Generate Block 12-15 Randomizing Unpacked Structs. . . . . . . . . . . . . . . . . . . . . . . 12-16 Using the Scope Randomize Method std::randomize() . . 12-17 Using the Class Randomize Method randomize() . 12-21 Disabling and Re-enabling Randomization . . . . . . . . . . . 12-24 Using In-line Random Variable Control . . . . . . . . . . . . . . 12-28 Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-32 Making wait fork Statements Compliant with the SV LRM . . . Making disable fork Statements Compliant with the SV LRM Recently Implemented SystemVerilog Constructs. . . . . . . . . . . . 12-32 12-35 12-36
xii
The std::randomize() Function . . . . . . . . . . . . . . . . . . . . . . . . SystemVerilog Bounded Queues . . . . . . . . . . . . . . . . . . . . . . wait() Statement with a Static Class Member Variable. . . . . . Parameters and Localparams in Classes . . . . . . . . . . . . . . . SystemVerilog Math Functions . . . . . . . . . . . . . . . . . . . . . . . Streaming Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packing (Used on RHS) . . . . . . . . . . . . . . . . . . . . . . . . . . Unpacking (Used on LHS) . . . . . . . . . . . . . . . . . . . . . . . . Packing and Unpacking . . . . . . . . . . . . . . . . . . . . . . . . . . Propagation and force Statement. . . . . . . . . . . . . . . . . . . Error Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structures with Streaming Operators . . . . . . . . . . . . . . . . Extensions to SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12-37 12-40 12-41 12-42 12-42 12-43 12-43 12-44 12-44 12-44 12-45 12-45 12-45
Unique/Priority Case/IF Final Semantic Enhancements . . . . 12-46 Using Unique/Priority Case/If with Always Block or Continuous Assign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-47 Using Unique/Priority Inside a Function . . . . . . . . . . . . . . 12-50 System Tasks to Control Warning Messages . . . . . . . . . . 12-53 Single-Sized Packed Dimension Extension . . . . . . . . . . . . . . Covariant Virtual Function Return Types . . . . . . . . . . . . . . . . Self Instance of a Virtual Interface . . . . . . . . . . . . . . . . . . . . . UVM Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13. Aspect Oriented Extensions Aspect-Oriented Extensions in SV. . . . . . . . . . . . . . . . . . . . . Processing of AOE as a Precompilation Expansion . . . . . . . Weaving advice into the target method . . . . . . . . . . . . . . 13-3 13-5 13-10 12-54 12-57 12-58 12-60
xiii
Pre-compilation Expansion details. . . . . . . . . . . . . . . . . . . . . Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14. Using Constraints Inconsistent Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constraint Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Randomize Serial Number. . . . . . . . . . . . . . . . . . . . . . . . . . . Solver Trace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constraint Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test Case Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using multiple +ntb_solver_debug arguments . . . . . . . . . . . Summary for +ntb_solver_debug. . . . . . . . . . . . . . . . . . . . . . +ntb_solver_debug=serial . . . . . . . . . . . . . . . . . . . . . . . . +ntb_solver_debug=trace. . . . . . . . . . . . . . . . . . . . . . . . . +ntb_solver_debug=profile. . . . . . . . . . . . . . . . . . . . . . . . +ntb_solver_debug=extract . . . . . . . . . . . . . . . . . . . . . . . Constraint Debug Using DVE . . . . . . . . . . . . . . . . . . . . . . . . . . . Constraint Guard Error Suppression . . . . . . . . . . . . . . . . . . . . . . Error Message Suppression Limitations . . . . . . . . . . . . . . . . Flattening Nested Guard Expressions . . . . . . . . . . . . . . . Pushing Guard Expressions into Foreach Loops . . . . . . . Array and XMR Support in std::randomize() . . . . . . . . . . . . . . . . Error Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XMR Support in Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . XMR Function Calls in Constraints . . . . . . . . . . . . . . . . . . . .
13-15 13-16
14-2 14-3 14-4 14-6 14-7 14-12 14-13 14-15 14-15 14-15 14-15 14-16 14-16 14-16 14-16 14-18 14-18 14-19 14-20 14-22 14-22 14-24
xiv
State Variable Index in Constraints . . . . . . . . . . . . . . . . . . . . . . . Runtime Check for State Versus Random Variables . . . . . . . Array Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Soft Constraints in SystemVerilog . . . . . . . . . . . . . . . . . . . Using Soft Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling Soft Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . Soft Constraint Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . Within a Single Class . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Soft Constraints Defined in Classes Instantiated as rand Members in Another Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-30 Soft Constraints Inheritance Between Classes . . . . . . . . . . . Soft Constraints in AOP Extensions to a Class . . . . . . . . . . . Soft Constraints in View Constraints Blocks . . . . . . . . . . . . . Discarding Lower-Priority Soft Constraints . . . . . . . . . . . . . . Using DPI Function Calls in Constraints . . . . . . . . . . . . . . . . . . . Invoking Non-pure DPI Functions from Constraints. . . . . . . . Using Foreach Loops Over Packed Dimensions in Constraints . Memories with Packed Dimensions . . . . . . . . . . . . . . . . . . . . Single Packed Dimension . . . . . . . . . . . . . . . . . . . . . . . . Multiple Packed Dimensions . . . . . . . . . . . . . . . . . . . . . . MDAs with Packed Dimensions . . . . . . . . . . . . . . . . . . . . . . . Single Packed Dimension . . . . . . . . . . . . . . . . . . . . . . . . Multiple Packed Dimensions . . . . . . . . . . . . . . . . . . . . . . 15. Extensions for SystemVerilog Coverage Support for Reference Arguments in get_coverage() . . . . . . . . . 15-1 14-32 14-32 14-34 14-35 14-37 14-38 14-42 14-42 14-42 14-42 14-43 14-43 14-43
xv
15-2 15-2
Functional Coverage Methodology Using the SystemVerilog C/C++ Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3 SystemVerilog Functional Coverage Flow . . . . . . . . . . . . . . . Covergroup Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SystemVerilog (Covergroup for C/C++): covg.sv . . . . . . . C Testbench: test.c. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Approach #1: Passing Arguments by Reference . . . . . . . Approach #2: Passing Arguments by Value . . . . . . . . . . . Compile Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C/C++ Functional Coverage API Specification . . . . . . . . . . . 16. OpenVera-SystemVerilog Testbench Interoperability Scope of Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing OpenVera types into SystemVerilog . . . . . . . . . . . . . . Data Type Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mailboxes and Semaphores . . . . . . . . . . . . . . . . . . . . . . . . . Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enumerated Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integers and Bit-Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structs and Unions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Connecting to the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2 16-3 16-6 16-7 16-9 16-9 16-10 16-12 16-13 16-15 16-15 15-4 15-6 15-7 15-7 15-8 15-8 15-8 15-9 15-9
xvi
Mapping Modports to Virtual Ports. . . . . . . . . . . . . . . . . . . . . Virtual Modports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Importing Clocking Block Members into a Modport . . . . . Semantic Issues with Samples, Drives, and Expects . . . . . . Notes to Remember . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Blocking Functions in OpenVera . . . . . . . . . . . . . . . . . . . Constraints and Randomization . . . . . . . . . . . . . . . . . . . Functional Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17. Using SystemVerilog Assertions Using SVAs in the HDL Design . . . . . . . . . . . . . . . . . . . . . . . . . . Using Standard Checker Library . . . . . . . . . . . . . . . . . . . . . . Instantiating SVA Checkers in Verilog . . . . . . . . . . . . . . . Binding SVA to a Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . Inlining SVAs in the Verilog Design . . . . . . . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling SystemVerilog Assertions . . . . . . . . . . . . . . . . . . . . . Compilation and Runtime Options . . . . . . . . . . . . . . . . . . . . . Assertion Monitoring System Tasks . . . . . . . . . . . . . . . . . . . . Using Assertion Categories . . . . . . . . . . . . . . . . . . . . . . . . . . Using System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stopping and Restarting Assertions By Category . . . . . . Viewing Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16-15 16-15 16-16 16-21 16-22 16-22 16-22 16-23 16-24 16-25
17-2 17-2 17-3 17-4 17-5 17-6 17-6 17-7 17-9 17-13 17-13 17-16 17-17 17-27
xvii
Using a Report File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enhanced Reporting for SystemVerilog Assertions in Functions Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Name Conflict Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . Checker and Generate Blocks . . . . . . . . . . . . . . . . . . . . . . . . Controlling Assertion Failure Messages . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options for Controlling Default Assertion Failure Messages . Options to Control Termination of Simulation. . . . . . . . . . . . . Option to Enable Compilation of OVA Case Pragmas . . . . . . 18. Using Property Specification Language Including PSL in the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using SVA Options, SVA System Tasks, and OV Classes . . . . . Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19. Using SystemC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17-27 17-28 17-28 17-30 17-30 17-30 17-31 17-31 17-32 17-33 17-36
19-5
Verilog Design Containing Verilog Modules and SystemC Leaf Modules 19-6 Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-7
xviii
Input Files Required. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating Verilog Wrappers for SystemC Modules . . . . Supported Port Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling Time Scale and Resolution in a SystemC . . . . . . Automatic adjustment of the time resolution . . . . . . . . . . Setting time scale/resolution of Verilog kernel. . . . . . . . . Setting time scale/resolution of SystemC kernel . . . . . . . Adding a Main Routine for Verilog-On-Top Designs . . . . . . . SystemC Designs Containing Verilog Modules . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Input Files Required. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating a SystemC Wrapper for Verilog Modules . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compilation Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SystemC Only Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supported and Unsupported UCLI/DVE and CBug Features Accessing Cross Module Hierarchy . . . . . . . . . . . . . . . . . . . . . . Controlling TimeScale Resolution . . . . . . . . . . . . . . . . . . . . . . . . Setting Timescale of SystemC Kernel . . . . . . . . . . . . . . . . . . Automatic Adjustment of Time Resolution . . . . . . . . . . . . Considerations for Export DPI Tasks. . . . . . . . . . . . . . . . . . . . . . Use syscan -export_DPI [function-name]. . . . . . . . . . . . . Use syscan -export_DPI [Verilog-file]. . . . . . . . . . . . . . . .
19-8 19-9 19-12 19-13 19-15 19-16 19-16 19-17 19-18 19-19 19-19 19-20 19-21 19-23 19-25 19-28 19-28 19-29 19-30 19-31 19-32 19-32 19-33 19-34 19-34 19-35
xix
Use a Stubs File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using options -Mlib and -Mdir . . . . . . . . . . . . . . . . . . . . . . . . Specifying Runtime Options to the SystemC Simulation. . . . . . . Using a Port Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using a Data Type Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . Combining SystemC with Verilog Configurations . . . . . . . . . . . . Verilog-on-top, SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compiling a Verilog/SystemC design . . . . . . . . . . . . . . . . SystemC-on-top, Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compiling a SystemC/Verilog design . . . . . . . . . . . . . . . . Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameters in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameters in SystemC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verilog-on-Top, SystemC-down . . . . . . . . . . . . . . . . . . . . . . . SystemC-on-Top, Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameter specification as vcs elaboration arguments . . . . Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Debugging Mixed Simulations Using DVE or UCLI . . . . . . . . . . . Transaction Level Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interface Definition File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generation of the TLI Adapters . . . . . . . . . . . . . . . . . . . . . . . Transaction Debug Output. . . . . . . . . . . . . . . . . . . . . . . . . . .
19-37 19-37 19-38 19-39 19-40 19-42 19-43 19-44 19-45 19-47 19-47 19-48 19-48 19-49 19-49 19-51 19-52 19-52 19-53 19-53 19-53 19-55 19-56 19-60 19-61
xx
Instantiation and Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supported Data Types of Formal Arguments. . . . . . . . . . . . . Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Delta-cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using a Customized SystemC Installation. . . . . . . . . . . . . . . . . . Compatibility with OSCI SystemC . . . . . . . . . . . . . . . . . . . . . Compiling Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Posix threads or quickthreads . . . . . . . . . . . . . . . . . . . . . . Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing VG GNU Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static and Dynamic Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static Linking in VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic Linking in VCS. . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic Linking in VCS. . . . . . . . . . . . . . . . . . . . . . . . . . LD_LIBRARY_PATH Environment Variable . . . . . . . . . . Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Incremental Compile of SystemC Source Files . . . . . . . . . . . . . . Full Build from Scratch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Full Incremental Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Partial Build with Object Files . . . . . . . . . . . . . . . . . . . . . . . . Partial Build with Shared Libraries . . . . . . . . . . . . . . . . . . . . . Updating the Shared Library . . . . . . . . . . . . . . . . . . . . . . Using Different Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . Partial Build Invoked with vcs. . . . . . . . . . . . . . . . . . . . . . Partial Build if Just One Shared Library is Updated . . . . .
19-62 19-65 19-66 19-66 19-67 19-69 19-70 19-70 19-71 19-75 19-75 19-76 19-76 19-78 19-78 19-79 19-80 19-80 19-81 19-82 19-84 19-84 19-85 19-85 19-85
xxi
Adding or Deleting SC Source Files in Shared Library . . Changing From a Shared Library Back to Object Files . . Suppressing Automatic Dependency Checking. . . . . . . . . . . Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TLI Direct Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accessing SystemC Members from SystemVerilog. . . . . . . . 19-88 TLI Adaptor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-88 Instantiating the TLI adaptor in SV . . . . . . . . . . . . . . . . . . 19-88 Direct Variable Access . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-89 Calling SystemC Member Function . . . . . . . . . . . . . . . . . 19-89 Arguments of Type char* used in Blocking Member Functions 19-91 Supported Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-91 SC_FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-95 Non-SystemC Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-95 Sub-classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-96 Name Clashes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-97 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-99 Compile Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-99 Syntax of TLI File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-100 Debug Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-103 Accessing Struct or Class Members of a SystemC Module from SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-104 Enhancements to TLI for Providing Access to SystemC/C++ Class Members from SystemVerilog. . . . . . . . . . . . . . . . . . . 19-105 Accessing Struct or Class Members of a SystemC Module Object from SystemVerilog. . . . . . . . . . . . . . . . . . . . . . . . . . . 19-105 Accessing Generic C++ Struct or Class . . . . . . . . . . . . . . 19-109 Extensions of TLI Input File . . . . . . . . . . . . . . . . . . . . . . . 19-113
xxii
Invoking Pack or Unpack Adaptor Code Generation . . . . 19-114 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-115 Accessing Verilog Variables from SystemC . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supported Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Type Conversion Mechanism . . . . . . . . . . . . . . . . . . . . . . 19-115 19-115 19-116 19-117 19-118 19-119
Accessing SystemVerilog Functions and Tasks from SystemC19-121 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-122 Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-122 Function Declaration Hierarchy . . . . . . . . . . . . . . . . . . . . 19-123 Passing Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-125 Supported Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-126 Usage Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-126 Compile Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-128 Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-129 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-130 Accessing SystemC Members from SystemVerilog Using the tli_get_<type> or tli_set_<type> Functions. . . . . . . . . . . . 19-131 Using the tli_get_<type> and tli_set_<type> Functions . . 19-131 Prototypes of tli_get_<type> and tli_set_<type> Functions 19-132 Supported Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-133 Member Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-136 Type Conversion Mechanism . . . . . . . . . . . . . . . . . . . . . . 19-138 Compile Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-140 Generating C++ Struct Definition from SystemVerilog Class Definition 19-142
xxiii
Use Model for Generating C++ Struct from SystemVerilog Class 19-143 Data Type Conversion from SystemVerilog to C++ . . . . . 19-144 Example for Generating C++ Struct from SystemVerilog Class 19-145 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-146 Exchanging Data Between SystemVerilog and SystemC Using Byte Pack/Unpack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-147 Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-148 Supported Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-149 Unsupported Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 19-149 Mapping of SystemC/C++ and SystemVerilog/VMM Data Types 19-150 Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-155 Using the Pack Operator . . . . . . . . . . . . . . . . . . . . . . . . . 19-155 Using Unpack Operator . . . . . . . . . . . . . . . . . . . . . . . . . . 19-156 Using Pack and Unpack Functions . . . . . . . . . . . . . . . . . . . . 19-156 Using Code Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Input Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supported Data types for Automatic Code Generation . . Correcting the Generated Files . . . . . . . . . . . . . . . . . . . . Compile Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Example for Code Generator . . . . . . . . . . . . . . . . 19-159 19-160 19-160 19-162 19-163 19-164 19-165 19-166
Using Direct Program Interface Based Communication . . . . . . . 19-175 Limitations of Using DPI-based Communication Between Verilog and SystemC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-176
xxiv
Improving VCS-SystemC Compilation Speed Using Precompiled C++ Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-176 Introduction to Precompiled Header Files . . . . . . . . . . . . . . . 19-177 Using Precompiled Header Files . . . . . . . . . . . . . . . . . . . . . . 19-177 Example to Use the Precompiled Header Files . . . . . . . . . . . 19-179 Invoking the Creation of Precompiled Header Files. . . . . . . . 19-179 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-180 Limitations of syscan -prec . . . . . . . . . 19-181 Limitations of using -prec with path . . . . . . . . . . . . . . . . 19-182 Limitations of Sharing Precompiled Header Files . . . . . . 19-182 Increasing Stack and Stack Guard Size . . . . . . . . . . . . . . . . . . . Increasing the Stack Size . . . . . . . . . . . . . . . . . . . . . . . . . Increasing the Stack Guard Size . . . . . . . . . . . . . . . . . . . Guidelines to Diagnose Stack Overrun . . . . . . . . . . . . . . 19-183 19-184 19-185 19-185
Using HDL and SystemC Sync Loops. . . . . . . . . . . . . . . . . . . . . 19-186 The Coarse-Grained Sync Loop . . . . . . . . . . . . . . . . . . . . . . 19-187 The Fine-Grained Sync Loop. . . . . . . . . . . . . . . . . . . . . . . . . Run Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alignment of Delta Cycles . . . . . . . . . . . . . . . . . . . . . . . . Example Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-187 19-187 19-188 19-189
Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-189 Restrictions That No Longer Apply. . . . . . . . . . . . . . . . . . 19-190 Controlling Simulation Run From sc_main . . . . . . . . . . . . . . . . . 19-190 Effect on end_of_simulation Callbacks . . . . . . . . . . . . . . . . . 19-193 UCLI Save Restore Support for SystemC-on-top and Pure-SystemC 19-194 SystemC with UCLI Save and Restore Use Model . . . . . . . . 19-195
xxv
SystemC with UCLI Save and Restore Coding Guidelines . . 19-195 Saving and Restoring Files During Save and Restore. . . . . . 19-196 Restoring the Saved Files from the Previous Saved Session 19-197 Limitations of UCLI Save Restore Support . . . . . . . . . . . . . . 19-198 Enabling Unified Hierarchy for VCS and SystemC . . . . . . . . . . . 19-198 Using Unified Hierarchy Elaboration . . . . . . . . . . . . . . . . . . . 19-198 Value Added by Option sysc=unihier . . . . . . . . . . . . . . . 19-201 Using the sysc=show_sc_main Switch . . . . . . . . . . . . . . . . 19-202 SystemC Unified Hierarchy Flow Limitations . . . . . . . . . . . . . 19-203 Aligning VMM and SystemC Messages . . . . . . . . . . . . . . . . . . . 19-204 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-204 Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-205 Changing Message Alignment Settings . . . . . . . . . . . . . . . . . 19-206 Mapping SystemC to VMM Severities . . . . . . . . . . . . . . . . . . 19-207 Filtering Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-208 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-211 UVM Message Alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-211 Enabling UVM Message Alignment . . . . . . . . . . . . . . . . . . . . 19-211 Accessing UVM Report Object of SystemC Instance . . . . . . 19-216 Introducing TLI Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TLI Adapter Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . SystemC Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Global Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-218 19-219 19-220 19-220 19-222
xxvi
VMM TLM Interface (vmm_tlm_generic_payload) . . . . . . VMM Channel/TLM Interface (Other data type) . . . . . . . . SV Interface Other Than vmm_channel/vmm_tlm . . . . . . VMM Channel Interface Details. . . . . . . . . . . . . . . . . . . . VMM TLM Interface Details . . . . . . . . . . . . . . . . . . . . . . . E .............................................. xamples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example-5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example-6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example-7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example-8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example-9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example-10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19-229 19-232 19-232 19-233 19-236 19-240 19-241 19-245 19-248 19-250 19-252 19-256 19-259 19-261 19-263 19-266
Using VCS UVM TLI Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . 19-270 Using the UVM TLI Adapters . . . . . . . . . . . . . . . . . . . . . . . . . UVM TLM Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UVM Analysis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . Handling Multiple Subscribers . . . . . . . . . . . . . . . . . . . . . UVM TML Communication Examples . . . . . . . . . . . . . . . . . . uvm_tlm_blocking Example . . . . . . . . . . . . . . . . . . . . . . . uvm_tlm_nonblocking Example . . . . . . . . . . . . . . . . . . . . uvm_tlm_analysis Example . . . . . . . . . . . . . . . . . . . . . . . 19-270 19-270 19-272 19-274 19-274 19-274 19-276 19-278
xxvii
20. C Language Interface Using PLI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Writing a PLI Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions in a PLI Application . . . . . . . . . . . . . . . . . . . . . . . . Header Files for PLI Applications. . . . . . . . . . . . . . . . . . . . . . PLI Table File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the PLI Table File . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling ACC Capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . Globally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Configuration File . . . . . . . . . . . . . . . . . . . . . . . Selected ACC Capabilities . . . . . . . . . . . . . . . . . . . . . . . . PLI Access to Ports of Celldefine and Library Modules . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Visualization in DVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using VPI Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-2 20-3 20-4 20-5 20-6 20-6 20-19 20-20 20-20 20-21 20-24 20-28 20-29 20-31 20-32
Support for VPI Callbacks for Reasons cbForce and cbRelease 20-32 Support for the vpi_register_systf Routine. . . . . . . . . . . . . . . Integrating a VPI Application With VCS . . . . . . . . . . . . . . . . . PLI Table File for VPI Routines . . . . . . . . . . . . . . . . . . . . . . . Virtual Interface Debug Support. . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unimplemented VPI Routines . . . . . . . . . . . . . . . . . . . . . . . . Using DirectC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Direct C/C++ Function Calls . . . . . . . . . . . . . . . . . . . . 20-33 20-34 20-36 20-36 20-37 20-40 20-40 20-42 20-43
xxviii
How C/C++ Functions Work in a Verilog Environment. . . Declaring the C/C++ Function . . . . . . . . . . . . . . . . . . . . . Calling the C/C++ Function . . . . . . . . . . . . . . . . . . . . . . . Storing Vector Values in Machine Memory. . . . . . . . . . . . Converting Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Avoiding a Naming Problem. . . . . . . . . . . . . . . . . . . . . . . Using Pass by Reference. . . . . . . . . . . . . . . . . . . . . . . . . Using Direct Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the vc_hdrs.h File. . . . . . . . . . . . . . . . . . . . . . . . . . Access Routines for Multi-Dimensional Arrays . . . . . . . .
20-46 20-47 20-53 20-55 20-57 20-60 20-61 20-62 20-69 20-70
Using Abstract Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-71 Using vc_handle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-72 Using Access Routines . . . . . . . . . . . . . . . . . . . . . . . . . . 20-73 Summary of Access Routines . . . . . . . . . . . . . . . . . . . . . 20-117 Enabling C/C++ Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-122 Mixing Direct And Abstract Access . . . . . . . . . . . . . . . . . 20-124 Specifying the DirectC.h File . . . . . . . . . . . . . . . . . . . . . . 20-124 Extended BNF for External Function Declarations . . . . . . . . 20-125 21. SAIF Support Using SAIF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SAIF System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow to Dump the Backward SAIF File . . . . . . . . . . . . . . . . . . . . SAIF Support for Two-Dimensional Memories in v2k Designs . . UCLI SAIF Dumping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Criteria for Choosing Signals for SAIF Dumping . . . . . . . . . . . . . 21-2 21-2 21-5 21-5 21-6 21-6
xxix
22. Encrypting Source Files Using Compiler Directives or Pragmas . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Automatic Protection Options . . . . . . . . . . . . . . . . . . . . . . 23. Integrating VCS with Vera Setting Up Vera and VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Vera with VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24. Integrating VCS with HSIM Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25. Integrating VCS with NanoSim Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26. Integrating VCS with Specman Type Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Up The Environment . . . . . . . . . . . . . . . . . . . . . . . . . Specman e Code Accessing Verilog . . . . . . . . . . . . . . . . . . . Using specrun and specview. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26-2 26-3 26-3 26-3 26-5 25-2 25-3 24-2 24-2 23-2 23-3 23-4 22-2 22-3 22-5
xxx
Adding Specman Objects To DVE . . . . . . . . . . . . . . . . . . . . . . . . Version Checker for Specman. . . . . . . . . . . . . . . . . . . . . . . . . . . Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27. Integrating VCS with Denali Setting Up Denali Environment for VCS . . . . . . . . . . . . . . . . . . . Integrating Denali with VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Model for Verilog Memory Models . . . . . . . . . . . . . . . Execute Denali Commands at UCLI Prompt . . . . . . . . . . . . . 28. Integrating VCS with Debussy Using the Current Version of VCS with Novas 2010.07 Version . Setting Up Debussy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Model to Dump fsdb File. . . . . . . . . . . . . . . . . . . . . . . Using Verilog System Tasks . . . . . . . . . . . . . . . . . . . . . . . Using UCLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29. Integrating VCS with XA Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30. Integrating VCS with MVSIM Native Mode Introduction to MVSIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29-2 29-3
30-1
xxxi
30-2 30-3
A-1 A-3
Options for Accessing Verilog Libraries . . . . . . . . . . . . . . . . . Options for Incremental Compilation . . . . . . . . Options for Help and Documentation. . . . . . . . . . . . . . . . . . . Option for SystemVerilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options for SystemVerilog Assertions . . . . . . . . . . . . . . . . . . Options to Enable Compilation of OVA Case Pragmas . . . . . Options for Native Testbench. . . . . . . . . . . . . . . . . . . . . . . . . Options for Different Versions of Verilog . . . . . . . . . . . . . . . .
Options for Initializing Memories and Registers with Random Values B-23 Options for Using Radiant Technology. . . . . . . . . . . . . . . . . . Options for 64-bit Compilation . . . . . . . . . . . . . . . . . . . . . . . . Options for Starting Simulation Right After Compilation . . . . Options for Specifying Delays and SDF Files . . . . . . . . . . . . Options for Compiling an SDF File . . . . . . . . . . . . . . . . . . . . Options for Specify Blocks and Timing Checks . . . . . . . . . . . Options for Pulse Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . Options for Negative Timing Checks . . . . . . . . . . . . . . . . . . . B-24 B-24 B-25 B-25 B-30 B-30 B-32 B-33
xxxii
B-35
Options to Specify Source Files and Compile-time Options in a File B-35 Options for Compiling Runtime Options into the Executable . Options for PLI Applications . . . . . . . . . . . . . . . . . . . . . . . . . Options to Enable the VCS DirectC Interface . . . . . . . . . . . . Options for Flushing Certain Output Text File Buffers . . . . . . Options for Controlling Messages . . . . . . . . . . . . . . . . . . . . . Options for Cell Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . Options for Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options for Controlling the Linker . . . . . . . . . . . . . . . . . . . . . Options for Controlling the C Compiler . . . . . . . . . . . . . . . . . Options for Source Protection . . . . . . . . . . . . . . . . . . . . . . . . Options for Mixed Analog/Digital Simulation . . . . . . . . . . . . . Options for Changing Parameter Values . . . . . . . . . . . . . . . . Checking for X and Z Values in Conditional Expressions . . . Options for Detecting Race Conditions . . . . . . . . . . . . . . . . . Options to Specify the Time Scale . . . . . . . . . . . . . . . . . . . . . Options for Overriding Parameters . . . . . . . . . . . . . . . . . . . . General Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enable Verilog 2001 Features . . . . . . . . . . . . . . . . . . . . . Specifying Directories for include Seaches . . . . . . . . . . . Enable the VCS/SystemC Cosimulation Interface . . . . . . TetraMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Make Accessing an Undeclared Bit an Error Condition . . Allow Inout Port Connection Width Mismatches. . . . . . . . B-36 B-37 B-40 B-41 B-42 B-44 B-46 B-47 B-49 B-52 B-54 B-55 B-55 B-56 B-57 B-58 B-61 B-61 B-61 B-61 B-62 B-62 B-62
xxxiii
Allow Zero or Negative Multiconcat Multiplier . . . . . . . . . Specifying a VCD File. . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling Dumping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Memories and Multi-Dimensional Arrays (MDAs) . . . . . . Specifying a Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing Source File Identifiers to Upper Case . . . . . . . Defining a Text Macro. . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying the Name of the Executable File. . . . . . . . . . . Returning The Platform Directory Name . . . . . . . . . . . . . Enable Loop Detect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gate-Level Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . Appendix C. Simulation Options
B-63 B-63 B-63 B-64 B-64 B-65 B-65 B-66 B-66 B-66 B-67
Options for Simulating Native Testbenches . . . . . . . . . . . . . . Options for SystemVerilog Assertions . . . . . . . . . . . . . . . . . . Options to Control Termination of Simulation. . . . . . . . . . . . . Options for Enabling and Disabling Specify Blocks . . . . . . . . Options for Specifying When Simulation Stops . . . . . . . . . . . Options for Recording Output . . . . . . . . . . . . . . . . . . . . . . . . Options for Controlling Messages . . . . . . . . . . . . . . . . . . . . . Options for VPD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options for VCD Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options for Specifying Delays . . . . . . . . . . . . . . . . . . . . . . . . Options for Flushing Certain Output Text File Buffers . . . . . . Options for Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Options to Specify User-Defined Runtime Options in a File .
C-2 C-10 C-18 C-18 C-19 C-20 C-20 C-21 C-24 C-24 C-26 C-27 C-28
xxxiv
Options for Initializing Memories and Registers with Random Values at Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-28 General Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing the Compile-Time Options . . . . . . . . . . . . . . . . . Recording Where ACC Capabilities are Used . . . . . . . . . Suppressing the $stop System Task . . . . . . . . . . . . . . . . Enabling User-defined Plusarg Options . . . . . . . . . . . . . . Enabling Overriding the Timing of a SWIFT SmartModel. Specifying acc_handle_simulated_net PLI Routine . . . . . Appendix D. Compiler Directives and System Tasks D-1 D-2 D-2 D-3 D-5 D-6 D-6 D-7 D-8 D-8 D-8 D-8 D-9 D-10 D-10 D-11 C-30 C-30 C-31 C-31 C-31 C-31 C-32
Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compiler Directives for Cell Definition . . . . . . . . . . . . . . . . . . Compiler Directives for Setting Defaults . . . . . . . . . . . . . . . . Compiler Directives for Macros . . . . . . . . . . . . . . . . . . . . . . . Compiler Directives for Delays. . . . . . . . . . . . . . . . . . . . . . . . Compiler Directives for Backannotating SDF Delay Values. . Compiler Directives for Source Protection . . . . . . . . . . . . . . . Debugging Partially Encrypted Source Code . . . . . . . . . . Compiler Directives for Controlling Port Coercion . . . . . . . . . General Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . Compiler Directive for Including a Source File . . . . . . . . . Compiler Directive for Setting the Time Scale . . . . . . . . . Compiler Directive for Specifying a Library . . . . . . . . . . . Compiler Directive for File Names and Line Numbers . . . Unimplemented Compiler Directives . . . . . . . . . . . . . . . . . . . System Tasks and Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . .
xxxv
System Tasks for SystemVerilog Assertions Severity . . . . . . System Tasks for SystemVerilog Assertions Control . . . . . . . System Tasks for SystemVerilog Assertions . . . . . . . . . . . . . System Tasks for VCD Files . . . . . . . . . . . . . . . . . . . . . . . . . System Tasks for LSI Certification VCD and EVCD Files . . . System Tasks for VPD Files. . . . . . . . . . . . . . . . . . . . . . . . . . System Tasks for SystemVerilog Assertions . . . . . . . . . . . . . System Tasks for Executing Operating System Commands . System Tasks for Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . System Tasks for Data Type Conversions . . . . . . . . . . . . . . . System Tasks for Displaying Information . . . . . . . . . . . . . . . . System Tasks for File I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Tasks for Loading Memories . . . . . . . . . . . . . . . . . . . System Tasks for Time Scale. . . . . . . . . . . . . . . . . . . . . . . . . System Tasks for Simulation Control . . . . . . . . . . . . . . . . . . . System Tasks for Timing Checks. . . . . . . . . . . . . . . . . . . . . . Timing Checks for Clock and Control Signals . . . . . . . . . . . . System Tasks for PLA Modeling . . . . . . . . . . . . . . . . . . . . . . System Tasks for Stochastic Analysis . . . . . . . . . . . . . . . . . . System Tasks for Simulation Time. . . . . . . . . . . . . . . . . . . . . System Tasks for Probabilistic Distribution . . . . . . . . . . . . . . System Tasks for Resetting VCS . . . . . . . . . . . . . . . . . . . . . . General System Tasks and Functions . . . . . . . . . . . . . . . . . . Checks for a Plusarg . . . . . . . . . . . . . . . . . . . . . . . . . . . . SDF Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Counting the Drivers on a Net . . . . . . . . . . . . . . . . . . . . .
D-11 D-11 D-12 D-12 D-15 D-18 D-26 D-27 D-28 D-28 D-29 D-30 D-32 D-33 D-33 D-34 D-35 D-37 D-37 D-38 D-39 D-40 D-40 D-40 D-41 D-41
xxxvi
Depositing Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fast Processing Stimulus Patterns. . . . . . . . . . . . . . . . . . Saving and Restarting The Simulation State . . . . . . . . . . Checking for X and Z Values in Conditional Expressions Calculating Bus Widths . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying the Method Stack . . . . . . . . . . . . . . . . . . . . . . IEEE Standard System Tasks Not Yet Implemented . . . . . . . Appendix E. PLI Access Routines
Access Routines for Reading and Writing to Memories . . . . . . . acc_setmem_int. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_getmem_int . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_clearmem_int . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_setmem_hexstr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_getmem_hexstr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_setmem_bitstr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_getmem_bitstr. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_handle_mem_by_fullname . . . . . . . . . . . . . . . . . . . . . . . acc_readmem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_getmem_range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_getmem_size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_getmem_word_int. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_getmem_word_range . . . . . . . . . . . . . . . . . . . . . . . . . . . Access Routines for Multidimensional Arrays . . . . . . . . . . . . . . .
E-2 E-4 E-5 E-6 E-6 E-11 E-12 E-15 E-16 E-17 E-18 E-18 E-19 E-21 E-22 E-23 E-24 E-24
xxxvii
tf_mdanodeinfo and tf_imdanodeinfo. . . . . . . . . . . . . . . . . . . acc_get_mda_range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_get_mda_word_range() . . . . . . . . . . . . . . . . . . . . . . . . . acc_getmda_bitstr() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_setmda_bitstr() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access Routines for Probabilistic Distribution . . . . . . . . . . . . . . . vcs_random . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcs_random_const_seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcs_random_seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcs_dist_uniform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcs_dist_normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcs_dist_exponential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcs_dist_poisson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access Routines for Returning a Pointer to a Parameter Value . acc_fetch_paramval_str. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access Routines for Extended VCD Files . . . . . . . . . . . . . . . . . . acc_lsi_dumpports_all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_lsi_dumpports_call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_lsi_dumpports_close. . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_lsi_dumpports_flush . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_lsi_dumpports_limit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_lsi_dumpports_misc . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_lsi_dumpports_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_lsi_dumpports_on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_lsi_dumpports_setformat . . . . . . . . . . . . . . . . . . . . . . . .
E-26 E-27 E-29 E-30 E-31 E-32 E-33 E-34 E-34 E-35 E-35 E-36 E-37 E-37 E-38 E-38 E-40 E-41 E-43 E-44 E-45 E-46 E-47 E-48 E-50
xxxviii
acc_lsi_dumpports_vhdl_enable . . . . . . . . . . . . . . . . . . . . . . Access Routines for Line Callbacks . . . . . . . . . . . . . . . . . . . . . . acc_mod_lcb_add . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_mod_lcb_del . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_mod_lcb_enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_mod_lcb_fetch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_mod_lcb_fetch2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . acc_mod_sfi_fetch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access Routines for Source Protection . . . . . . . . . . . . . . . . . . . . vcsSpClose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpEncodeOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpEncodeOn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpEncoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpGetFilePtr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpInitialize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpOvaDecodeLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpOvaDisable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpOvaEnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpSetDisplayMsgFlag . . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpSetFilePtr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpSetLibLicenseCode . . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpSetPliProtectionFlag. . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpWriteChar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vcsSpWriteString . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access Routine for Signal in a Generate Block. . . . . . . . . . . . . .
E-51 E-52 E-53 E-55 E-57 E-57 E-59 E-61 E-62 E-66 E-67 E-68 E-70 E-71 E-72 E-73 E-74 E-75 E-77 E-77 E-78 E-79 E-80 E-81 E-83
xxxix
xl
1
Getting Started 1
VCS is a high-performance, high-capacity Verilog simulator that incorporates advanced, high-level abstraction verification technologies into a single open native platform. VCS is a compiled code simulator. It enables you to analyze, compile, and simulate Verilog, SystemVerilog, OpenVera and SystemC design descriptions. It also provides you with a set of simulation and debugging features to validate your design. These features provide capabilities for source-level debugging and simulation result viewing. VCS accelerates complete system verification by delivering the fastest and highest capacity Verilog simulation for RTL functional verification.
This chapter includes the following sections: Simulator Support with Technologies Setting Up the Simulator Using the Simulator Default Time Unit and Time Precision
In addition to its standard Verilog and SystemVerilog compilation and simulation capabilities, VCS includes the following integrated set of features and tools: SystemC - VCS / SystemC Co-simulation Interface enables VCS and the SystemC modeling environment to work together when simulating a system described in the Verilog and SystemC languages. For more information, refer to Using SystemC on page 1. Discovery Visualization Environment (DVE) For more information, refer to Using DVE on page 2. Unified Command-line Interface (UCLI) For more information, refer to Using UCLI on page 3.
Built-In Coverage Metrics a comprehensive built-in coverage analysis functionality that includes condition, toggle, line, finite-state-machine (FSM), path, and branch coverage. You can use coverage metrics to determine the quality of coverage of your verification test and focus on creating additional test cases. You only need to compile once to run both simulation and coverage analysis. For more information, refer to Coverage on page 1. DirectC Interface this interface allows you to directly embed user-created C/C++ functions within your Verilog design description. This results in a significant improvement in ease-of-use and performance over existing PLI-based methods. VCS atomically recognizes C/C++ function calls and integrates them for simulation, thus eliminating the need to manually create PLI files.
VCS supports Synopsys DesignWare IPs, VCS Verification Library, VMC models, Vera, HSIM, and NanoSim. For information on integrating VCS with HSIM, refer to the HSIM-VCS DKI and HSIMVCS-MX DKI Mixed-Signal Simulation Application Note. For information on integrating VCS with NanoSim, refer to the Discovery AMS: Mixed-Signal Simulation User Guide available in the NanoSim installation directory. VCS can also be integrated with third-party tools such as Specman, Debussy, Denali, and other acceleration and emulation systems.
When you encounter any issue, run the script with tracing enabled to capture the output and contact Synopsys. To enable tracing, you can either uncomment the set -x line in the syschk.sh file or enter the following command:
% sh -x syschk.sh >& syschk.log
Use syschk.sh -v to generate a more verbose output stream including the exact path for various binaries used by the script, etc. For example:
% syschk.sh -v
Note: If you copy the syschk.sh script to another location before using it, you must also copy the syschk.dat data file to the same directory. You can also refer to the "Supported Platforms and Products" section of the VCS Release Notes for a list of supported platforms, and recommended C compiler and linker versions.
Obtaining a License
You must have a license to run VCS. To obtain a license, contact your local Synopsys Sales Representative. Your Sales Representative will need the hostid for your machine. To start a new license, do the following: 1. Verify that your license file is functioning correctly:
% lmcksum -c license_file_pathname
Running this licensing utility ensures that the license file is not corrupt. You should see an "OK" for every INCREMENT statement in the license file.
Note: The snpslmd platform binaries and accompanying FlexLM utilities are shipped separately and are not included with this distribution. You can download these binaries as part of the Synopsys Common Licensing (SCL) kit from the Synopsys Web Site at:
http://www.synopsys.com/cgi-bin/ASP/sk/smartkeys.cgi
3. Set the LM_LICENSE_FILE or SNPSLMD_LICENSE_FILE environment variable to point to the license file. For example:
% setenv LM_LICENSE_FILE /u/edatools/vcs/license.dat
or
% setenv SNPSLMD_LICENSE_FILE /u/edatools/vcs/ license.dat
Note: - You can use SNPSLMD_LICENSE_FILE environment variable to set licenses explicitly for Synopsys tools. - If you set the SNPSLMD_LICENSE_FILE environment variable, then VCS ignores the LM_LICENSE_FILE environment variable.
Set the environment variable VCS_HOME to the path where VCS is installed as shown below:
% setenv VCS_HOME installation_path
$PATH environment variable Set your UNIX PATH variable to $VCS_HOME/bin as shown below:
% set path = ($VCS_HOME/bin $path) OR % setenv PATH $VCS_HOME/bin:$PATH
variable: Set the license variable LM_LICENSE_FILE or SNPSLMD_LICENSE_FILE to your license file as shown below:
% setenv LM_LICENSE_FILE Location_to_the_license_file
or
% setenv SNPSLMD_LICENSE_FILE /u/edatools/vcs/ license.dat
Note: - You can use SNPSLMD_LICENSE_FILE environment variable to set licenses explicitly for Synopsys tools. - If you set the SNPSLMD_LICENSE_FILE environment variable, then VCS ignores the LM_LICENSE_FILE environment variable. For additional information on environment variables, see Appendix A, "VCS Environment Variables".
Getting Started 1-7
Compiling the Design VCS provides you with the vcs executable to compile and elaborate the design. This executable compiles your design using the intermediate files in the design or work library, generates the object code, and statically links them to generate a binary simulation executable, simv. For more information, see Chapter 2, "VCS Flow".
Simulating the Design Simulate your design by executing the binary simulation executable, simv. For more information, see Chapter 2, "VCS Flow".
Simulation
% simv [run_options]
2
VCS Flow
Simulating a design using VCS involves two basic steps: Compilation Simulation
VCS uses the same two steps to compile any design irrespective of the HDL, HVL, and other supported technologies used. For information on supported technologies, refer to Simulator Support with Technologies on page 2.
Compilation
Compiling is the first step to simulate your design. In this phase, VCS builds the instance hierarchy and generates a binary executable simv. This binary executable is later used for simulation.
In this phase, you can choose to compile the design either in optimized mode or in debug mode. Runtime performance of VCS is based on the mode you choose and the level of flexibility required during simulation. Synopsys recommends you use full-debug or partial-debug mode until the design correctness is achieved, and then switch to optimized mode. In optimized mode, also called batch mode, VCS delivers the best compile-time and runtime performance for a design. You typically choose optimized mode to run regressions, or when you do not require extensive debug capabilities. For more information, see Compiling or Elaborating the Design in Optimized Mode . You compile the design in debug mode, also called interactive mode, when you are in the initial phase of your development cycle, or when you need more debug capabilities or tools to debug the design issues. In this mode, the performance will not be the best that VCS can deliver. However, using some of the compile-time options, you can compile your design in full-debug or partial-debug mode to get maximum performance in debug mode. For more information, see Compiling or Elaborating the Design in Debug Mode .
Using vcs
The syntax to use vcs is shown below:
% vcs [compile_options] Verilog_files
-y directory Specifies a Verilog library directory. VCS looks in the source files in this directory for definitions of the module and UDP instances that VCS found in your source code but for which it did not find the corresponding module or UDP definitions in your source code. VCS looks in this directory for a file with the same name as the module or UDP identifier in the instance (not the instance name). If it finds this file, VCS looks in the file for the module or UDP definition to resolve the instance. Note: If you have multiple modules with the same name in different libraries, VCS selects the module defined in the library that is specified with the first -y option. For example: If rev1/cell.v and rev2/cell.v and rev3/cell.v all exist and define the module cell(), and you issue the following command:
% vcs -y rev1 -y rev2 -y rev3 +libext+.v top.v
VCS selects cell.v from rev1. However, if the top.v file has a `uselib compiler directive as shown below:
//top.v `uselib directory = /proj/libraries/rev3 //rest of top module code //end top.v
...then `uselib takes priority. In this case, VCS will use rev3/ cell.v when you issue the following command:
% vcs -y rev1 -y rev2 +libext+.v top.v
Include the +libext compile-time option to specify the file name extension of the files you want VCS to look for in these directories. +incdir+directory+ Specifies the directory or directories that VCS searches for include files used in the `include compiler directive. More than one directory may be specified when separated by the plus (+) character. +libext+extension+ Specifies that VCS search only for files with the specified file name extensions in a library directory. You can specify more than one extension, separating the extensions with the plus (+) character. For example, +libext+.v+.V+ specifies searching for files with either the .v or .V extension in a library. The order in which you add file name extensions to this option does not specify an order in which VCS searches files in the library with these file name extensions. +liborder Specifies searching for module definitions for unresolved module instances through the remainder of the library where VCS finds the instance, then searching the next and then the next library on the vcs command line before searching in the first library on the command line. Options for 64-bit Compilation -full64
VCS Flow 2-5
Enables compilation and simulation in 64-bit mode. Option to Specify Files and Compile-time Options in a File -file filename Specifies a file containing a list of files and compile-time options. Options for Discovery Visual Environment and UCLI -gui When used at compile time, always starts DVE at runtime. For information on DVE, see the DVE User Guide. For information on UCLI, see the UCLI User Guide. Options for Starting Simulation Right After Compilation -R Runs the executable file immediately after VCS links it together. Options for Changing Parameter Values -pvalue+parameter_hierarchical_name=value Changes the specified parameter to the specified value. -parameters filename Changes parameters specified in the file to values specified in the file. The syntax for a line in the file is as follows:
assign value path_to_parameter
The path to the parameter is similar to a hierarchical name except that you use the forward slash character (/) instead of a period as the delimiter.
For more information on overriding parameters, see Overriding Parameters . Options for Controlling Messages
-notice
Enables verbose diagnostic messages. -q Quiet mode; suppresses messages such as those about the C compiler VCS is using, the source files VCS is parsing, the top-level modules, or the specified timescale. -V Verbose mode; compiles verbosely. The compiler driver program prints the commands it executes as it runs the C compiler, assembler, and linker. Specifying a Log File -l filename Specifies a file where VCS records compilation messages. If you also enter the -R option, VCSrecords messages from both compilation and simulation in the same file. Defining a Text Macro +define+macro=value+ Defines a text macro in your source code to a value or character string. You can test for this definition in your Verilog source code using the ifdef compiler directive. If there are blank spaces in the character string then you must enclose it in quotation marks.
For example:
vcs design.v +define+USELIB="dir=dir1 dir=dir2"
Simulation
During compilation, using the intermediate files generated, VCS creates a binary executable, simv. You can use simv to run the simulation. Based on how you compile the design, you can run your simulation the following ways: Interactive mode Batch mode
Interactive Mode
You compile your design in interactive mode, also called debug mode, in the initial phase of your design cycle. In this phase, you require abilities to debug the design issues using a GUI or through the command line. To debug using a GUI, you can use the Discovery Verification Environment (DVE), and to debug through the command-line interface, you can use the Unified Command-line Interface (UCLI).
Note: To simulate the design in the interactive mode, you must compile the design using the -debug or -debug_all compile-time options. For information on compiling the design, refer to the Compilation section.
Batch Mode
You compile your design in batch mode, also called as optimized mode, when most of your design issues are resolved. In this phase, you will be more interested to achieve better performance to run regressions, and with minimum debug abilities. Note: The runtime performance reduces if you use -debug or -debug_all. Use these options only when you require runtime debug abilities. The following command line simulates the design in batch mode:
% simv
By default, VCS generates the binary executable simv. However, you can use the compile-time option, -o with the vcs command line to generate the binary executable with the specified name.
3
Modeling Your Design 1
Verilog coding style is the most important factor that affects the simulation performance of a design. How you write your design can make the difference between a fast error-free simulation, and one that suffers from race conditions and poor performance. This chapter describes some Verilog modeling techniques that will help your code designs simulate most efficiently with VCS. This chapter includes the following topics: Avoiding Race Conditions Race Detection Optimizing Testbenches for Debugging Avoiding the Debugging Problems From Port Coercion Creating Models That Simulate Faster
Case Statement Behavior Precedence in Text Macro Definitions Memory Size Limits in the Simulator Using Sparse Memory Models Obtaining Scope Information Avoiding Circular Dependency Designing With $lsi_dumpports for Simulation and Test
module race; reg a; initial begin a = 0; #10 a = 1; end initial begin #10 if (a) $display("may not print"); end endmodule
You can also move it to the next time step with a non-zero delay.
The solution is to stagger the assignments to register r1 by finite time, so that the ordering of the assignments is guaranteed. Note that using the nonblocking assignment (<=) in both assignments to r1 would not remove the race condition in this example.
Modeling Your Design 3-3
The solution for this case is straightforward. Use the nonblocking assignment in the flip-flop to guarantee the order of assignments to the output of the instances of the flip-flop and sampling of that output. The change looks like this:
always @(posedge clk) q <= d; // ok
q <= #1 d;
// ok
Note that the following change does not resolve the race condition:
always @(posedge clk) #1 q = d; // race!
The #1 delay simply shifts the original race by one time unit, so that the intermediate node is set and sampled one time unit after the posedge of clock, rather than on the posedge of clock. Avoid this coding style.
In VCS, this displays 0, while in Verilog-XL, it displays 1, because the assignment of the value to x races with the usage of that value by the $display. Another example of this type of race condition is the following:
assign state0 = (state == 3'h0); always @(posedge clk)
The modification of state may propagate to state0 before the if statement, causing unexpected behavior. You can avoid this by using the nonblocking assignment to state in the procedural code as follows:
state <= 0; if (state0) // do something
This guarantees that state is not updated until the end of the time step, that is, after the if statement has executed.
Counting Events
A different type of race condition occurs when code depends on the number of times events are triggered in the same time step. For instance, in the following example, if A and B change at the same time, it is unpredictable whether count is incremented once or twice:
always @(A or B) count = count + 1;
Another form of this race condition is to toggle a register within the always block. If toggled once or twice, the result may be unexpected behavior. The solution to this race condition is to make the code inside the always block insensitive to the number of times it is called.
Modeling Your Design 3-6
This is a race condition because the transition of clock to 1 (posedge) may happen before or after the event trigger (always @(posedge clock)) is established. Often the race is not evident in the simulation result because reset occurs at time zero. The solution to this race condition is to guarantee that no transitions take place at time zero of any signals inside event triggers. Rewrite the clock driver in the above example as follows:
initial begin clock = 1bx; #50 clock = 1b0; forever #50 clock = ~clock; end
Race Detection
VCS provides the following race detection tools: Dynamic Race Detection Tool - Finds the race conditions during simulation.
Static Race Detection Tool - Finds the race conditions by analyzing source code during compilation.
The above two tools are described in the following sections: The Dynamic Race Detection Tool The Static Race Detection Tool
Read - Write Race Condition The Read - Write race condition occurs when both Read and Write on a signal take place at the same simulation time.
Example:
initial #5 var1 = 0; // write operation on signal var1 initial #5 var2 = var1; // read operation on signal var2
Read Procedural assignment in any one of the always or initial block, or a continuous assignment samples the value of signal var1 to drive signal var2. Write Procedural assignment in another always or initial block, or another continuous assignment assigns a new value to signal var1. In the above example, at the simulation time 5, there is both read and write operation on signal var1. When simulation time 5 is over, you do not know if signal var2 will have the value 0 or the previous value of signal var1. Write - Write Race Condition The Write - Write race condition occurs when multiple writes on a signal take place at the same simulation time. Example:
initial #5 var1 = 0; // write operation on signal var1 initial #5 var1 = 1; // write operation on signal var1
Write-Write Value of the signal var1 is non-deterministic when there are multiple concurrent procedural assignments on the same variable at the same simulation time. In the above example, at simulation time 5, different initial blocks assign 0 and 1 to signal var1. When simulation time 5 is over, you do not know if var1 signal value is 0 or 1. Finding these race conditions is important because in Verilog simulation you cannot control the order of execution of statements in different always or initial blocks, or continuous assignments that execute at the same simulation time. This means that a race condition can produce different simulation results when you simulate a design with different, but both properly functioning Verilog simulators. Even worse, a race condition can result in different simulation results with different versions of a particular simulator, or with different optimizations or performance features of the same version of a simulator. Note: $dumpvars can also expose races. Also, sometimes modifications in one part of a design can cause hidden race conditions to surface even in unmodified parts of a design, thereby causing different simulation results from the unmodified part of the design. The indications of a race condition are the following: When simulation results do not match when comparing simulators
When design modifications cause inexplicable results When simulation results do not match between different simulation runs of the same simulator, when different versions or different optimization features of that simulator are used
Therefore, even when a Verilog design appears to be simulating correctly and you see the results you want, you should look for race conditions and remove them so that you will continue to see the same simulation results from an unrevised design well into the future. Also, you should look for race conditions while a design is in development. VCS can help you find these race conditions by writing report files about the race conditions in your design. VCS writes the reports at run time, but you should enable race detection at compile-time with a compile-time option. The reports can be lengthy for large designs. You can post-process the report to generate another shorter report that is limited, for example, to only part of the design or to only between certain simulation times.
Note: The -race and -racecd compile-time options supports dynamic race detection for both pure Verilog and SystemVerilog data types.
Filename and line number where VCS finds the write operation
Filename and line number where VCS finds the read operation
1 "c": write
Identifier of the signal whose value change is in the race condition
Delimiter between information for a a write and a read operation or between two write operations
The following is the source file, with line numbers added for this race condition report:
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. module test; reg a,b,c,d; always @(a or b) c = a & b; always begin a = 1; #1 a = 0; #2; end always begin #1 a = 1;
17. 18. 19. 20. 21. 22. 23. 24. 25. 26.
As stipulated in race.out: At simulation time 0, there is a procedural assignment to reg c on line 5, and also $display system task displays the value of reg c on line 23. At simulation time 1, there is a procedural assignment to reg a on line 10 and another procedural assignment to reg a on line 16. Also, at simulation time 1, there is a procedural assignment to reg c on line 5, and the value of reg c is in an expression that is evaluated in a procedural assignment to another register on line 17.
Races of No Consequence Sometimes race conditions exist, such as write-write race to a signal at the same simulation time, but the two statements that are assigning to the signal are assigning the same value. This is a race of no consequence, and the race tool indicates this with **NC at the end of the line for the race in the race.out file.
0 "r4": write test (nc1.v: 40) && write test (nc1.v:44)**NC 20 "r4": write test (nc1.v: 40) && write test (nc1.v:44)**NC 40 "r4": write test (nc1.v: 40) && write test
(nc1.v:44)**NC 60 "r4": write test (nc1.v: 40) && write test (nc1.v:44) 80 "r4": write test (nc1.v: 40) && write test (nc1.v:44)**NC
-f filename Specifies the name of the input file. Use this option if you have changed the name of the race.out file. -o filename The default name of the output file is race.out.post. If you want a different name, specify it with this option. You can enter more than one of these options on the PostRace.pl command line. If you enter an option more than once, the script uses the last of these multiple entries. Unless you specify a different name with the -o option, the report generated by the PostRace.pl script is in the race.out.post file. The following is an example of the command line:
PostRace.pl -minmax 80 250 -f mydesign.race.out -o mydesign.race.out.post
In this example, the output file is named mydesign.race.out.post, and reports the race conditions between 80 and 250 time units. The post-process file is named mydesign.race.out. Modifying the PostRace.pl Script The first line of the PostRace.pl Perl script is as follows:
#! /usr/local/bin/perl
If Perl is installed at a different location at your site, you must modify the first line of this script. This script needs a perl5 interpreter. You can find this script at the following location: vcs_install_dir/bin/PostRace.pl
If you enter the vcdiff command without arguments, you see the usage information including the options. Method 1: If the Number of Unique Race Conditions is Small A unique race condition is a race condition that can occur several times during simulation, but only the first occurrence is reported in the race.unique.out file. If the number of lines in the race.unique.out file are smaller than the number of unique race conditions, then for each signal in the race.unique.out file:
1. Look in the output file from the vcdiff utility. If the signal values are different, you have found a critical write-write race condition. 2. If the signal values are not different, look for the signals that are assigned the value of this signal, or assigned expressions that include this signal (read operations). 3. If the values of these other signals are different at any point in the two simulations, note the simulation times of these differences on the other signals, and post-process the race.out file looking for race conditions in the first signal at around the simulation times of the value differences on the other signals. Specify simulation times before and after the time of these differences with the -minmax option. Enter:
PostRace.pl -sig first_signal -minmax time time2
If the race.out.post file contains the first signal, then it is a critical race condition, and must be corrected. Method 2: If the Number of Unique Races is Large If there are many lines in the race.unique.out file and a large number of unique race conditions, then the method of finding the critical race conditions is to do the following: 1. Look in the output file from the vcdiff utility for the simulation time of the first difference in simulation values. 2. Post-process the race.out file looking for races at the time of the first simulation value difference. Specify simulation times before and after the time of these differences with the -minmax option. Enter:
PostRace.pl -minmax time time2
- If the simulation values differ in the two simulations, then the race condition in the race.out.post file is a critical race condition. - If the simulation values are not different, check the signals that are assigned the value of this signal or assigned expressions that include this signal. If the values of these other signals are different, then the race condition in the race.out.post file is a critical race condition. Method 3: An Alternative When the Number of Unique Race Conditions is Large 1. Look in the output file from the vcdiff utility for the simulation time of the first difference in simulation values. 2. For each signal that has a difference at this simulation time: a. Traverse the signal dependency backwards in the design until you find a signal whose values are same in both simulations. b. Look for a race condition on that signal at that time. Enter: PostRace.pl -sig signal -minmax time time2 If there is a race condition at that time on that signal, then it is a critical race condition.
These situations arise when level-sensitive sensitivity lists (event controls which immediately follow the always keyword in an always block, and which do not contain the posedge or negedge keywords) and procedural assignment statements in the always blocks combine with other statements such as continuous assignment or module instantiation statements to form a potential loop. It is observed that these situations do not occur if the always blocks contain delays or other timing information, non-blocking assignment statements, or PLI calls through user-defined system tasks. You can use the +race=all compile-time option to start the static race detection tool. Note: The +race=all compile-time option supports only pure Verilog constructs. After compilation, the static race detection tool writes the file named race.out.static which reports the race conditions. The following example shows an always block that combines with other statements to form a loop:
35 36 37 38 39 40 always @( A or C ) begin D = C; B = A; end assign C = B;
The race.out.static file from the compilation of this source code follows:
Race-[CLF] Combinational loop found
"source.v", 35: The trigger C of the always block can cause the following sequence of event(s) which can again trigger the always block. "source.v", 37: B = A; which triggers B. "source.v", 40: assign C = B; which triggers C.
enable debugging features. The following sections describe a number of techniques that you can use to choose when debugging features are enabled.
Conditional Compilation
Use ifdef, else, and endif compiler directives in your testbench to specify which system tasks you want to compile for debugging features. Then, when you compile the design with the +define compile-time option on the command line (or when the define compiler directive appears in the source code), VCS will compile these tasks for debugging features. For example:
initial begin `ifdef postprocess $vcdpluson(0,design_1); $vcdplustraceon(design_1); $vcdplusdeltacycleon; $vcdplusglitchon; `endif end
The system tasks in this initial block record several types of information in a VPD file. You can use the VPD file with DVE to post-process the design. In this particular case, the information is for all the signals in the design, so the performance cost is extensive. You would only want to do this early in the development cycle of the design when finding bugs is more important than simulation speed.
The command line includes the +define+postprocess compile-time option, which tells VCS to compile the design with these system tasks compiled into the testbench. Later in the development cycle of the design, you can compile the design without the +define+postprocess compile-time option and VCS will not compile these system tasks into the testbench. Doing so enables VCS to simulate your design much faster. Advantages and Disadvantages The advantage of this technique is that simulation can run faster than if you enable debugging features at runtime. When you use conditional compilation, VCS has all the information it needs at compile-time. The disadvantage of this technique is that you have to recompile the testbench to include these system tasks in the testbench, thus increasing the overall compilation time in the development cycle of your design. Synopsys recommends that you consider this technique as a way to prevent these system tasks from inadvertently remaining compiled into the testbench, later in the development cycle, when you want faster performance.
In this technique you do not include the +define compile-time argument on the vcs command line. Instead you compile the system tasks into the testbench and then enable the execution of the system tasks with the runtime argument to the $test$plusargs system function. Therefore, in this example, the simv command line is as follows:
% simv +postprocess
During simulation VCS writes the VPD file with all the information specified by these system tasks. Later you can execute another simv command line, without the +postprocess runtime option. As a result, VCS does not write the VPD file, and therefore runs faster. There is a pitfall to this technique. This system function will match any plusarg that has the functions argument as a prefix. For example:
module top; initial begin if ( $test$plusargs("a") ) $display("\n<<< Now a >>>\n"); else if ( $test$plusargs("ab") ) $display("\n<<< Now ab >>>\n"); else if ( $test$plusargs("abc") )
No matter whether you enter the +a, +ab, or +abc plusarg, when you simulate the executable, VCS always displays the following:
<<< Now a >>>
To avoid this pitfall, enter the longest plusarg first. For example, you would revise the previous example as follows:
module top; initial begin if ( $test$plusargs("abc") ) $display("\n<<< Now abc >>>\n"); else if ( $test$plusargs("ab") ) $display("\n<<< Now ab >>>\n"); else if ( $test$plusargs("a") ) $display("\n<<< Now a >>>\n"); end endmodule
Advantages and Disadvantages The advantage to using this technique is that you do not have to recompile the testbench in order to stop VCS from writing the VPD file. This technique is something to consider using, particularly early in the development cycle of your design, when you are fixing a lot of bugs and already doing a lot of recompilation. The disadvantages to this technique are considerable. Compiling these system tasks, or any system tasks that write to a file, into the testbench requires VCS to compile the simv executable so that it is possible for it to write the VPD file when the runtime option is included on the command line. This means that the simulation runs
significantly slower than if you dont compile these system tasks into the testbench. This impact on performance remains even when you dont include the runtime option on the simv command line. Using the $test$plusargs system function forces VCS to consider the worst case scenario plusargs will be used at runtime and VCS generates the simv executable with the corresponding overhead to prepare for these plusargs. The more fixed information VCS has at compile-time, the more VCS can optimize simv for efficient simulation. Alternatively, the more user control at runtime, the more overhead VCS has to add to simv to accept runtime options, and the less efficient the simulation. For this reason Synopsys recommends that if you use this technique, you should plan to abandon it fairly early in the development cycle and switch to either the conditional compilation technique for writing simulation history files, or a combination of the two techniques.
In this instance, both the +define+comppostprocess compiletime option and the +runpostprocess runtime option are required for VCS to write the VPD file. This technique allows you to avoid recompiling just to prevent VCS from writing the file during the next simulation and also provides you with a way to recompile the testbench, later in the development cycle, to exclude these system tasks without first editing the source code for the testbench.
1. If you need values to propagate in and out of a port, declare it as an inout port. If you dont need this bidirectional behavior, declare it as an input or output port. 2. Compile the modules with these ports under the noportcoerce compiler directive.
VCS is optimized for simulating sequential devices. Under certain circumstances VCS infers that an always block is a sequential device and simulates the always block much faster. This section describes the coding guidelines you should follow to make VCS infer an always block as a sequential device. When writing an always block, if you cannot follow the inferencing rules for a sequential device there are still things that you should keep in mind so that VCS simulates the always block faster. This section also describes the guidelines for coding faster simulating always blocks that VCS infers to be combinatorial instead of sequential devices.
Avoid Unaccelerated Primitives VCS cannot accelerate tranif1, tranif0, rtranif1, rtranif0, tran, and rtran switches. They are defined in IEEE Std 1364-2001 page 86. Avoid Calls to User-defined Tasks or Functions Declared in Another Module VCS cannot accelerate user-defined tasks or functions declared in another module. For example:
module bottom (x,y); . . . always @ y top.task_indentifier(y,rb); endmodule
Avoid Strength Specifications in Continuous Assignment Statements Omit strength specifications in continuous assignment statements. For example:
assign net1 = flag1;
statements
repeat statements
Using either blocking or nonblocking procedural assignment statements in the always block does not prevent VCS from inferring a sequential device, but in VCS blocking procedural assignment statements are more efficient. Synopsys recommends zero delay nonblocking assignment statements to avoid race conditions. IEEE Std 1364-2001 describes blocking and nonblocking procedural assignment statements on pages 119-124. Place Task Enabling Statements in Their Own always Block and Use No Delays IEEE Std 1364-2001 defines tasks and task enabling statements on pages 151-156. VCS infers that an always block that contains a task enabling statement is a sequential device only when there are no delays in the task declaration. All Sequential Controls Must Be in the Sensitivity List To borrow a concept from VHDL, the sensitivity list for an always block is the event control that immediately follows the always keyword. IEEE Std 1364-2001 defines event controls on page 138 and mentions sensitivity lists on page 139. For correct inference, all sequential controls must be in the sensitivity list. The following code examples illustrate this rule: VCS does not infer the following DFF to be a sequential device:
always @ (d)
Even though clk is in an event control, it is not in the sensitivity list event control. VCS does not infer the following latch to be a sequential device:
always begin wait clk; q <= d; @ d; end
There is no sensitivity list event control. VCS infers the following latch to be a sequential device:
always @ (clk or d) if (clk) q <= d;
The sequential controls, clk and d, are in the sensitivity list event control. Avoid Level-sensitive Sensitivity Lists Whose Signals are Used Completely VCS infers a combinational device instead of a sequential device if the following conditions are both met: The sensitivity list event control is level sensitive A level sensitive event control does not contain the posedge or negedge keywords. The signals in the sensitivity list event control are used completely in the always block Used completely means that there is a possible simulation event if the signal has a true or a false (1 or 0) value.
The following code examples illustrate this rule: Example 1 VCS infers that the following always block is combinatorial, not sequential:
always @ (a or b) y = a or b
Here the sensitivity list event control is level sensitive and VCS assigns a value to y whether a or b are true or false. Example 2 VCS also infers that the following always block is combinatorial, not sequential:
always @ (sel or a or b) if (sel) y=a; else y=b;
Here the sensitivity list event control is also level sensitive and VCS assigns a value to y whether a, b, or sel are true or false. Note that the if-else conditional statement uses signal sel completely, VCS executes an assignment statement whether sel is true or false. Example 3 VCS infers that the following always block is sequential:
always @ (sel or a or b) if (sel) y=a;
In this instance, there is no simulation event when signal sel is false (0).
yes yes
yes
Std 1364-2001 Construct the power operator: r1=r2**r3; attributes: (* optimize_power=1 *) module dev (res,out,clk,data1,data2); generate statements localparam declarations Automatic tasks and functions task automatic t1();
yes
yes yes requires the -sverilog compile-time option yes requires the -sverilog compile-time option
constant functions localparam lp1 = const_func(p1); parameters with a bit range parameter bit [7:0][31:0] P = {32'd1,32'd2,32'd3,32'd4,32'd5,32'd6,32'd7,32'd8};
VCS merges the second $display system task with the comment on the previous line and does not display the text string Im OK.
In simulations, this memory model uses 4 MB of machine memory with the /*sparse*/ pragma, 81 MB without it. There is a small runtime performance cost to sparse memory models: the simulation of the memory with the /*sparse*/ pragma took 64 seconds, 56 seconds without it.
The larger the memory, and the fewer elements in the memory that your design reads or writes to, the more machine memory you will save by using this feature. It is intended for memories that contain at least a few MBs. If your design accesses 1% of its elements you could save 97% of machine memory. If your design accesses 50% of its elements, you save 25% of machine memory. Do not use this feature if your design accesses more than 50% of its elements because using the feature in these cases may lead to more memory consumption than not using it. Note: Sparse memory models cannot be manipulated by PLI applications through tf calls (the tf_nodeinfo routine issues a warning for sparse memory and returns NULL for the memory handle). Sparse memory models cannot be used as a personality matrix in PLA system tasks.
name of the module instance that contains the system task. If the system task is in a scope lower than a module instance, it tells VCS to do the following: In named begin-end or fork-join blocks, it adds the block name to the hierarchical name. In user-defined tasks or functions, it considers the hierarchical name of the task declaration or function definition as the hierarchical name of the module instance.
VCS has the following additional format specifications for displaying scope information: %i Specifies the same as %m with the following difference: when in a user-defined task or function, the hierarchical name is the hierarchical name of the instance or named block containing the task enabling statement or function call, not the hierarchical name of the task or function declaration. If the task enabling statement is in another user-defined task, the hierarchical name is the hierarchical name of the instance or named block containing the task enabling statement for this other user-defined task. If the function call is in another user-defined function, the hierarchical name is the hierarchical name of the instance or named block containing the function call for this other user-defined function. If the function call is in a user-defined task, the hierarchical name is the hierarchical name of the instance or named block containing the task enabling statement for this user-defined task.
%-i Specifies that the hierarchical name is always of a module instance, not a named block or user-defined task or function. If the system task (such as $write and $display) is in: - A named block the hierarchical name is that of the module instance that contains the named block - A user-defined task or function the hierarchical name is that of the module instance containing the task enabling statement or function call Note: The %i and %-i format specifications are not supported with the $monitor system task. The following commented code example shows what these format specifications do:
module top; reg r1; task my_task; input taskin; begin $display("%m"); $display("%i"); $display("%-i"); end endtask
function my_func; input taskin; begin $display("%m"); // displays "top.my_func" $display("%i"); // displays "top.d1.named" $display("%-i"); // displays "top.d1" end
endfunction dev1 d1 (r1); endmodule module dev1(inport); input inport; initial begin:named reg namedreg; $display("%m"); // displays "top.d1.named" $display("%i"); // displays "top.d1.named" $display("%-i"); // displays "top.d1" namedreg=1; top.my_task(namedreg); namedreg = top.my_func(namedreg); end endmodule
2. If there are no arguments, it returns a pointer to the temporary location. Pointers are not used in Verilog but they are in DirectC applications. The possible arguments are hierarchical names. If there are arguments, it compares them from left to right with the current scope. If an argument matches, the system function returns a 32-bit non-zero value. If none of the arguments match the current scope, the system function returns a 32-bit zero value. The following example contains these system functions:
module top; reg r1; initial r1=1; dev1 d1(r1); endmodule module dev1(in); input in; always @ (posedge in) begin:named if ($activeinst("top.d0","top.d1")) $display("%i"); if ($activescope("top.d0.block","top.d1.named")) $display("%-i"); end endmodule
The following is an example of a DirectC application that uses the $activeinst system function:
extern void showInst(input bit[31:0]); module discriminator; task t; reg[31:0] r; begin showInst($activeinst); if($activeinst("top.c1", begin r = $activeinst; $display("for instance end end endtask
declaration of C function named showInst $activeinst system function without arguments passed to the C function
"top.c3"))
module child; initial discriminator.t; endmodule module top; child c1(); child c2(); child c3(); child c4(); endmodule
In task t, the following occurs: 1. The $activeinst system function returns a pointer to the current scope, which is passed to the C function showInst. It is a pointer to a volatile or temporary char buffer containing the name of the instance. 2. A nested begin block executes only if the current scope is either top.c1 or top.c3. 3. VCS displays whether $activeinst points to a zero or non-zero value.
Function showInst declares the char pointer str and assigns to it the value of its parameter, which is the pointer in $activeinst in the Verilog code. Then with a printf statement, it displays the hierarchical name that str is pointing to. Notice that the function begins the information it displays with DirectC: so that you can differentiate it from what VCS displays. During simulation VCS and the C function display the following:
DirectC: [top.c1] for instance top.c1 the pointer is non-zero DirectC: [top.c2] DirectC: [top.c3] for instance top.c3 the pointer is non-zero DirectC: [top.c4]
When you do this, you might set up a circular dependency between the seed value and the statement, resulting in an infinite loop and a simulation failure. This circular dependency doesnt usually occur, but it can occur, so VCS displays a warning message when you use a seeded argument with these kinds of statements. This warning message is as follows:
Warning-[RWSI] $random() with a seed input $random in the following statement was called with a seed input This may cause an infinite loop and an eventual crash at runtime. "exp1.v", 24: assign dr1 = $random(in);
The warning message ends with the source file name and line number of the statement, followed by the statement itself. This possible circular dependency does not occur either when you use a seed argument and the return value is the assigned value in a procedural assignment statement, or when you do not use the seed argument in a continuous, procedural continuous, or force statement. For example:
assign out = $random(); initial begin assign dr1 = $random(); force dr2 = $random(); dr3 = $random(in);
These statements do not generate the warning message. You can tell VCS not to display the warning message by using the +warn=noRWSI compile-time argument and option.
child child_1(A); endmodule module child(A); input A; wire Z,A,B; and (Z,A,B); endmodule
In this case, the top-level wire A is undriven at the top level. It is an input which goes to an input in DUT_1, then to an input in CHILD_1 and finally to an input of an AND gate in CHILD_1. When $lsi_dumpports evaluates the drivers on port A of test.DUT_1, it finds no drivers on either side of port A of DUT_1, and therefore gives a code of F, tristate (input and output unconnected). The designer actually meant for a code of Z to be returned, input tristated. To achieve this code, the input A needs to be assigned a value of z. This is achieved by removing the comment from the line, // assign A = 1'bz;, in the above code. Now, when the code is executed, VCS is able to identify that the wire A going into DUT_1 is being driven to a z. With the wire driven from the outside and not the inside, $lsi_dumpports returns a code of Z.
First, there is no instance name specified for $lsi_dumpports. The syntax for $lsi_dumpports calls for an instance name. Since the user didn't instantiate module top in the test fixture, they are left specifying the MODULE name top. This will produce a warning message from VCS. Since top appears only once, that instance will be assumed. The second problem comes from the cross-module reference (XMR) that the force command uses. Since the module test doesn't instantiate top, the example uses an XMR to force the desired
signal. The signal being forced is port a in instance u1. The problem here is that this force is done on the port from within the instance u1. The user expects this port a of u1 to be an input, but when $lsi_dumpports evaluates the ports for the drivers, it finds that port a of instance u1 is being driven from inside and therefore returns a code of L. To correct these two problems, you need to instantiate top inside test, and drive the signal a from within test. This is done in the following way:
module test; wire a; initial begin force a = 1'b0; $lsi_dumpports(test.u0.u1,"dump.out2"); end top u0 (a); endmodule module top(a); input a; middle u1 (a); endmodule module middle(a); input a; wire b; buf(b,a); endmodule
By using the method in this example, the port a of instance u1 is driven from the outside, and when $lsi_dumpports checks for the drivers it reports a code of D as desired.
Testbench Level (only z drivers from the DUT) Drivers Active on Both Levels
c f
4
Compiling the Design
This chapter describes the following sections: Compiling or Elaborating the Design in Debug Mode Compiling or Elaborating the Design in Optimized Mode Key Compilation Features
If you use the UCLI commands to force a signal, to write into a registers/nets
VCS has the following compile-time options for debug mode: -debug_pp, -debug, and -debug_all The following examples show how to compile the design in full and partial debug modes. Compiling the design in partial debug mode
% vcs -debug [compile_options] TOP.v
For information on DVE or UCLI, see the DVE User Guide and UCLI User Guide respectively.
Note: This option allows you to initialize to specific value (0 or 1) or random value with specific seed at runtime. For more information on using this option at runtime, see Options for Initializing Memories and Registers with Random Values at Runtime . Note: +vcs+initreg+ options work only for the Verilog portion of the design. The +vcs+initreg option initializes regular memories and multidimensional arrays of the reg data type also. For example:
reg [7:0] mem [7:0][15:0];
The +vcs+initreg option does not initialize registers (variables) and multi-dimensional arrays of any other data type. To prevent race conditions, avoid the following when you use these options: Assigning initial values to a reg in their declaration when the value you assign is not the same as the value specified with the +vcs+initreg option. For example:
reg [7:0] r1=8b01010101;
Assigning values to regs or memory elements at simulation time 0 when the value you assign is not the same as the value specified with the +vcs+initreg option.
For example:
initial begin mem[1][1]=8b00000001;
Use Model
Compilation
% vcs +vcs+initreg+random [other_vcs_options] file1.v file2.v file3.v
Simulation
% simv +vcs+initreg+0|1|random|<seed> [simv_options]
For information on the +vcs+initreg+0|1|random|<seed> option, see +vcs+initreg+random and Options for Initializing Memories and Registers with Random Values at Runtime .
Overriding Parameters
There are two compile-time options for changing parameter values from the vcs command line: -pvalue -parameters You specify a parameter with the -pvalue option. It has the following syntax:
vcs -pvalue+hierarchical_name_of_parameter=value
For example:
vcs source.v -pvalue+test.d1.param1=33
You specify a file with the -parameters option. The file contains command lines for changing values. A line in the file has the following syntax:
assign value path_to_the_parameter
Here: assign Keyword that starts a line in the file. value New value of the parameter. path_to_the_parameter Hierarchical path to the parameter. This entry is similar to a Verilog hierarchical name except that you use forward slash characters (/), instead of periods, as the delimiters. The following is an example of the contents of this file:
assign 33 test/d1/param1 assign 27 test/d1/param2
Note: The -parameters and -pvalue options do not work with a localparam or a specparam.
A case statement:
case(conditional_exp) 1b1: sig2=1; 1b0: sig3=1; 1bx: sig4=1; 1bz: sig5=1; endcase
The following is an example of the warning message that VCS displays when it evaluates the conditional expression and finds it to have an X or Z value:
warning signal_name within scope hier_name in file_name.v: line_number to x/z at time simulation_time
VCS displays this warning every time it evaluates the conditional expression to have an X or Z value, not just when the signal or signals in the expression transition to an X or Z value.
VCS does not display a warning message when a sub-expression has the value X or Z, but the conditional expression evaluates to a 1 or 0 value. For example:
r1 = 1bz; r2 = 1b1; if ( (r1 && r2 ) || 1b1) r3 = 1;
In this example, the conditional expression always evaluates to a value of 1. Therefore, VCS does not display a warning message.
Example 1 In this example, VCS displays the warning message when reg r1 transitions from 0 to X to 1 during simulation time 1. Example 4-1 False Negative Example
module test; reg r1; initial begin r1=1'b0; #1 r1=1'bx; #0 r1=1'b1; end always @ (r1) begin if (r1) $display("\n r1 true at %0t\n",$time); else $display("\n r1 false at %0t\n",$time); end endmodule
Example 2 In this example, VCS displays the warning message when reg r1 transitions from 1 to X during simulation time 1. Example 4-2 False Negative Example
end always @ (r1) begin if (r1) $display("\n r1 true at %0t\n",$time); else $display("\n r1 false at %0t\n",$time); end endmodule
If you consider these warning messages to be false negatives, use the nofalseneg argument to the -xzcheck option to suppress the messages. For example:
% vcs -xzcheck nofalseneg example.v
If you compile and simulate example1 or example2 with the -xzcheck rcompilation option, but without the nofalseneg argument, VCS displays the following warning about signal r1 transitioning to an X or Z value:
r1 false at 0 Warning: 'r1' within scope test in source.v: 13 goes to x/ z at time 1 r1 false at 1 r1 true at 1
If you compile and simulate the examples shown earlier in this chapter, Example 1 or Example 2, with the -xzcheck rcompilation option and the nofalseneg argument, VCS does not display the warning message.
Note: Path names can be absolute or relative to the current directory that contains the library mapping file. In this example library mapping file, there are two logical libraries. VCS searches the source code assigned to lib1 first to resolve module instances (or user-defined primitive or SystemVerilog interface instances) because that logical library is listed first in the library mapping file. When you use a library mapping file, source files that are not assigned to a logical library in this file are assigned to the default logical library named work. You specify the library mapping file with the -libmap during compilation. Library mapping file is a Verilog 2001 feature, therefore, use +v2k or -sverilog along with -libmap. Resolving include Compiler Directives The source file in a logical library might include the include compiler directive. If so, you can include the -incdir option on the line in the library mapping file that declares the logical library, for example: library gatelib /net/design1/gatelib/*.v -incdir / net/ design1/spec1lib, /net/design1/spec2lib; Note: The -incdir option specified in the library mapping file overrides the +incdir option specified in the VCS command line.
Configurations
Verilog 2001 configurations are sets of rules that specify what source code is used for particular instances. Verilog 2001 introduces the concept of configurations and it also introduces the concept of cells. A cell is like a VHDL design unit. A module definition is a type of cell, as is a user-defined primitive. Similarly, a configuration is also a cell. A SystemVerilog interface and testbench program block are also types of cells. Configurations do the following: Specify a library search order for resolving cell instances (as does a library mapping file) Specifies overrides to the logical library search order for specified instances Specifies overrides to the logical library search order for all instances of specified cells
You can define a configuration in a library mapping file or in any type of Verilog source file outside the module definition . Configurations can be mapped to a logical library just like any other type of cell. Configuration Syntax A configuration contains the following statements:
config config_identifier; design [library_identifier.]cell_identifier; config_rule_statement; endconfig
Where: config Is the keyword that begins a configuration. config_identifier Is the name you enter for the configuration. design Is the keyword that starts a design statement for specifying the top of the design. [library_identifier.]cell_identifier; Specifies the top-level module (or top-level modules) in the design and the logical library for this module (modules). config_rule_statement Zero, one, or more of the following clauses: default, instance, or cell. endconfig Is the keyword that ends a configuration. The default Clause The default clause specifies the logical libraries in which to search to resolve a default cell instance. A default cell instance is an instance in the design that is not specified in a subsequent instance or cell clause in the configuration. You specify these libraries with the liblist keyword. The following is an example of a default clause:
This default clause specifies resolving default instances in the logical libraries names lib1 and lib 2. Note: - Do not enter a comma (,) between logical libraries. - The default logical library work, if not listed in the list of logical libraries, is appended to the list of logical libraries and VCS searches the source files in work last. The instance Clause The instance clause specifies something about a specific instance. What it specifies depends on the use of the liblist or use keywords: liblist Specifies the logical libraries to search to resolve the instance. use Specifies that the instance is an instance of the specified cell in the specified logical library. The following are examples of instance clauses:
instance top.dev1 liblist lib1 lib2;
This instance clause tells VCS to resolve instance top.dev1 with the cells assigned to logical libraries lib1 and lib2;
instance top.dev1.gm1 use lib2.gizmult;
This instance clause tells VCS that top.dev1.gm1 is an instance of the cell named gizmult in logical library lib2. The cell Clause A cell clause is similar to an instance clause except that it specifies something about all instances of a cell definition instead of specifying something about a particular instance. What it specifies depends on the use of the liblist or use keywords: liblist Specifies the logical libraries to search to resolve all instances of the cell. use The specified cells definition is in the specified library.
Hierarchical Configurations
A design can have more than one configuration. You can, for example, define a configuration that specifies the source code you use in particular instances in a subhierarchy, then you can define a configuration for a higher level of the design. Suppose, for example, a subhierarchy of a design was an eight-bit adder and you have RTL Verilog code describing the adder in a logical library named rtllib and you have gate-level code describing the adder in a logical library named gatelib. If, for example, you wanted the gate-level code used for the 0 (zero) bit of the adder and the RTL level code used for the other seven bits, the configuration might appear as:
config cfg1; design aLib.eight_adder;
Now, if you were going to instantiate this eight-bit adder eight times to make a 64-bit adder, you would use configuration cfg1 for the first instance of the eight-bit adder, but not in any other instance. A configuration that would perform this function is as follows:
config cfg2; design bLib.64_adder; default liblist bLib; instance top.64add0 use work.cfg1:config; endconfig
The -top compile-time option requires the +v2k or -sverilog compile-time option. If you have coded your design to have more than one top-level module, you can enter more than one -top option, or you can append arguments to the option using the plus delimiter. For example:
-top top_cfg+test+
Using the -top options tells VCS not to create extraneous top-level modules, that is, one that you dont specify.
Compiling the Design 4-17
Limitations of Configurations
In the current implementation, V2K configurations have the following limitations: You cannot specify source code for user-defined primitives in a configuration. The VPI functionality, described in section 13.6 "Displaying library binding information" in the Std 1364-2001 IEEE Verilog Hardware Description LRM, is not implemented.
VCS first evaluates all the events in the combinational queue, and evaluates the events in the behavioral queue. If the behavioral events trigger more combinational events, VCS evaluates them only after the events in the behavioral queue are evaluated. This masks the race conditions happening at the boundaries of the combinational and behavioral parts of the design.
In this example, VCS without the +evalorder option will process the continuous assign statement after the statement q = 0 or add it to the active events queue for later processing. Therefore, $display will show either 0 or X as the value of p.
module eval(); wire p; reg q; assign p = q; initial begin #1 q = 0; $display(Value of p is %b, p); end endmodule
With the +evalorder option, VCS changes the scheduling of the continuous assignment to happen after all events in the initial block are done. Therefore, $display will always display the previous value of p, which is X.
5
Simulating the Design
This chapter describes the following: Using DVE Using UCLI Key Runtime Features
As described in the section Simulation on page 8, you can simulate your design in either interactive or batch mode. To simulate your design in interactive mode, you need to use DVE or UCLI. To simulate your design in batch mode, refer to the section entitled, Batch Mode on page 9.
Using DVE
DVE provides you with a graphical user interface to debug your design. Using DVE, you can debug the design in interactive mode or in post-processing mode. You must use the same version of VCS and DVE to ensure problem-free debugging of your simulation. In the interactive mode, apart from running the simulation, DVE allows you to do the following: View waveforms Trace Drivers and loads Schematic and Path Schematic view Compare waveforms Execute UCLI/Tcl commands Set line, time, event, etc breakpoints Perform line stepping
However, in post-processing mode, a VPD/VCD/EVCD file is created during simulation, and you use DVE to: View waveforms Trace Drivers and loads Schematic and Path Schematic view Compare waveforms
Use the following command to invoke the simulation in interactive mode using DVE:
% simv -gui
Note: The interactive mode of DVE is not supported, when you are running VCS slave mode simulation. For information on generating a VPD/EVCD dump file, see VPD, VCD, and EVCD Utilities on page 1. For more information on using DVE, click this link Discovery Visual Environment User Guide if you are using the VCS Online Documentation. If you are using the PDF interface, click this link dve_ug.pdf to view the DVE User Guide PDF document.
Using UCLI
Unified Command-line Interface (UCLI) provides a common set of commands for interactive simulation. UCLI is the default commandline interface for batch mode debugging in VCS . UCLI commands are based on Tcl, therefore you can use any Tcl command with UCLI. You can also write Tcl procedures and execute them at the UCLI prompt. Using UCLI commands, you can do the following: Control the simulation Dump a VPD file
Simulating the Design 5-3
Save/Restore the simulation state Force/Release a signal Debug the design using breakpoints, scope/thread information, built-in macros
UCLI commands are built based on Tcl. Therefore, you can execute any Tcl command or procedures at the UCLI prompt. This provides you with more flexibility to debug the design in interactive mode. The following command starts the simulation from the UCLI prompt:
% simv [simv_options] -ucli
When you execute the above command, VCS takes you to the UCLI command prompt. To invoke UCLI, ensure that you specify the debug_pp, -debug, or -debug_all options during compilationelaboration. You can then use the -ucli option at runtime to enter the UCLI prompt at time 0 as shown:
% simv -ucli ucli%
At the ucli prompt, you can execute any UCLI command to debug or run the simulation. You also can specify the list of required UCLI commands in a file, and source it to the UCLI prompt or specify the file as an argument to the runtime option, -do, as shown below:
% simv -ucli ucli% source file.cmds % simv -ucli -do file.cmds
Note: UCLI is not supported when you are running VCS slave mode simulation.
Note: You can use the -ucli flag at runtime even if you have NOT used some form of -debug switches during compilation. This is called a "mini UCLI" feature, where full power of Tcl is now provided with just run and quit UCLI commands. Note the following behavioral changes when UCLI is the default command-line interface: The -s switch is no longer allowed in simv. If you are unable to migrate the flow to use UCLI instead of CLI, contact VCS Support. Command line flags, such as simv -i or -do, only accept UCLI commands. Interrupting the simulation using Ctrl+C takes you to UCLI prompt by default for debugging your designs. ucli>"Include file options (-i or -do) expects a UCLI script by default.
%> simv -ucli -i ucli_script.inc
The -R feature in VCS will continue to take you to the old CLI/ MX UI, unless you explicitly add -ucli as well to VCS command line.
ucli2Proc Command
There are a few scenarios after UCLI became the default command line interface, which may require using of the -ucli2Proc switch:
In SystemC designs, you need to add the -ucli2Proc command if you want to call 'cbug' in batch mode (ucli). VCS issues a warning message if you do not add this command. When you issue a restore command inside a -i/-do/source, you need to pass the -ucli2Proc. This situation is only applicable when there are commands following the restore commands that need to be executed in the do script. Any usage of start/restart/finish/config "endofsim" from UCLI needs the -ucli2Proc command.
For more information about UCLI, click the link Unified Commandline Interface (UCLI) if you are using the VCS Online Documentation. If you are using the PDF interface, click the link ucli_ug.pdf to view the UCLI User Guide PDF document.
-debug Gives average performance and debug visibility/control i.e more visibility/control than debug_pp and better performance than debug_all. It provides force net and reg capabilities in addition to all capabilities of the debug_pp option. Similar to the debug_pp option, with the debug option also you can set value and time breakpoints, but not line breakpoints. -debug_all Gives the most visibility/control and you can use this option typically for debugging with interactive simulation. This option provides the same capabilities as the debug option, in addition it adds simulation line stepping and allows you to track the simulation line-by-line and setting breakpoints within the source code. With this option, you can set all types of breakpoints (line, time, value, event etc). -ucli Forces runtime to go into UCLI mode, by default. -gui When used at compile time, starts DVE at runtime. +vpdfile+filename Specifies the name of the generated VPD file. You can also use this option for post-processing where it specifies the name of the VPD file. +vpdfileswitchsize+number_in_MB Specifies a size for the vpd file. When the vpd file reaches this size, VCS closes this file and opens a new one with the same size.
The plusarg_format argument specifies a user-defined runtime option for passing a value to the specified signal. It specifies the text of the option and the radix of the value that you pass to the signal. The following code example contains this system function:
module valueplusargs; reg [31:0] r1;
Simulating the Design 5-8
integer status; initial begin $monitor("r1=%0d at %0t",r1,$time); #1 r1=0; #1 status=$value$plusargs("r1=%d",r1); end endmodule
The module definitions whose instances use the most CPU time The Verilog constructs in those instances that use the most CPU time
For memory usage it reports the following: The amount of memory and the percentage of memory used by the VCS kernel, the design, the SystemVerilog testbench program block, cosimulation applications using either the DPI or PLI, and the time spent writing a VCD or VPD file. The amount of memory and the percentage of memory that each module definition uses.
You can use this information to see where in your design you might be able to modify your code for faster simulation performance. The profile data in the vcs.prof file is organized into a number of views of the simulation. The vcs.prof file starts with views on CPU time, followed by views on memory usage. Note: The current profiler and the +prof compile-time option will be replaced by the unified profiler and the -simprofile compiletime option in the next release of VCS. The unified profiler is now an LCA feature, see The Unified Simulation Profiler.
The Program View The Instance View The Program to Construct Mapping View The Top-level Construct View The Construct View Across Design
The Top-level View This view displays how much CPU time was used by: Any PLI application that executes along with VCS. VCS for writing VCD and VPD files. VCS for internal operations that cant be attributed to any part of your design. The Verilog modules in your design. A SystemVerilog testbench program block, if used. Top-level View
Example 5-1
=========================================================================== TOP-LEVEL VIEW =========================================================================== TYPE %Totaltime --------------------------------------------------------------------------DPI 0.00 PLI 0.00 VCD 0.00 KERNEL 29.06 MODULES 51.87 PROGRAMS 21.17 PROGRAM GC 1.64 ---------------------------------------------------------------------------
In this example, there is no PLI application and VCS does not write a VCD or VPD file. VCS used 51.87% of the CPU time to simulate the design, 21.94% for a testbench program, and 29.06% for internal operations, such as scheduling, that VCS cannot attribute to any part of the design. The designation KERNEL is for these internal operations. PROGRAM GC is for the garbage collector. The designation VCD is for the simulation time used by the callback mechanisms inside VCS for writing either VCD or VPD files. If there was CPU time used by a PLI application, you could use a tool such as gprof or Quantify to profile the PLI application. The Module View This view displays the module definitions whose instances use the most CPU time. It does not list module definitions whose module instances collectively use less than 0.5% of the CPU time. Example 5-2 Module View
=========================================================================== MODULE VIEW =========================================================================== Module(index) %Totaltime No of Instances Definition --------------------------------------------------------------------------FD2 (1) 62.17 10000 /u/design/design.v:142. EN (2) 8.73 1000 /u/design/design.v:131. ---------------------------------------------------------------------------
In this example, there are two module definitions whose instances collectively used a significant amount of CPU time, modules FD2 and EN. The profile data for module FD2 is as follows:
FD2 has an index number of 1. Other views that show the hierarchical names of module instances use this index number. The index number associates a module instance with a module definition because module identifiers do not necessarily resemble the hierarchal names of their instances. The instances of module FD2 used 62.17% of the CPU time. There are 10,000 instances of module FD2. The number of instances is a way to assess the CPU time used by these instances. For example, as in this case, a high CPU time with a correspondingly high number of instances tells you that each instance isnt using very much CPU time. The module header, the first line of the module definition, is in source file design.v on line 142.
The Program View The program view displays the simulation time used by the testbench program, the number of instances, and the line number where is starts in its source file. Example 5-3 Program View
============================================================================== PROGRAM VIEW ============================================================================== Program(index) %Totaltime No of Instances Definition -----------------------------------------------------------------------------test (1) 21.17 1 /u/design/test.sv:25. ------------------------------------------------------------------------------
The Module to Construct Mapping View This view displays the CPU time used by different types of Verilog constructs in each module definition in the module view. The following lists the different types of Verilog constructs:
always constructs (commonly called always blocks) initial constructs (commonly called initial blocks) module path delays in specify blocks timing check system tasks in specify blocks combinational logic including gates or built-in primitives and continuous assignment statements user-defined tasks user-defined functions module instance ports user-defined primitives (UDPs) Any Verilog code protected by encryption
Ports use simulation time particularly when there are expressions in port connection lists such as bit or part selects and concatenation operators. This view has separate sections for the Verilog constructs for each module definition in the module view. Example 5-4 Module to Construct Mapping View
___________________________________________________________________________ 1. FD2 --------------------------------------------------------------------------Construct type %Totaltime %Moduletime LineNo --------------------------------------------------------------------------Always 27.44 44.14 design.v : 150-160. Module Path 23.17 37.26 design.v : 165-166.
___________________________________________________________________________ 2. EN --------------------------------------------------------------------------Construct type %Totaltime %Moduletime LineNo --------------------------------------------------------------------------Combinational 8.73 100.00 design.v: 137. ___________________________________________________________________________
For each construct the view reports the percentage of Totaltime and Moduletime. %Totaltime The percentage of the total CPU time that was used by this construct. %Moduletime Each module in the design uses a certain amount of CPU time. This percentage is the fraction of the modules CPU time that was used by the construct. In the section for module FD2: An always block in this module definition used 27.44% of the TOTAL CPU time. Of all the CPU time consumed by all instances of the FD2 module, 44.14% is spent on this construct (44.14% of 62.17% = 27.44%). The always block is in source file design.v between lines 150 and 160. If there were another always block in module FD2 that used more than 0.5% of the CPU time, there would be another line in this section for it, beginning with the always keyword.
The module path delays in this module used 23.17% of the TOTAL CPU time. Of all the CPU time consumed by all instances of the FD2 module, 37.26% is spent on this construct. These module path delays can be found on lines 165-166 of the design.v source file. The timing check system tasks in this module used 11.56% of the TOTAL CPU time. Of all the CPU time consumed by all instances of the FD2 module, 18.60% is spent on this construct. These timing check system tasks can be found on lines 167-167 of the design.v source file.
In the section for module EN, a construct classified as Combinational used 8.73 of the total CPU time. 100% of the CPU time used by all instances of EN were used for this combinational construct. No initial blocks, user-defined functions, or user-defined tasks, ports, UDPs, or encrypted code in the design used more than 0.5% of the CPU time. If there were, there would be a separate line for each of these types of constructs. The Instance View This view display the module instances that use the most CPU time. An instance must use more than 0.5% of the CPU time to be entered in this view. Example 5-5 Instance View
In this example, there is only one instance that uses more that 0.5% of the CPU time. This instances hierarchical name is test.lfsr1000_1.lfsr100_1.lfsr10_1.lfsr_1.en_1. (Long hierarchical names wrap to the next line.) The instances index number is 2, indicating an instance of module EN, which had an index of 2 in the module view. This instance used 0.73% of the CPU time. No instance of module FD2 is listed here, so no individual instance of FD2 used more that 0.5% of the CPU time. Note: It is very common for no instances to appear in the instance view. This happens when many instances use some of the simulation time, but none use more than 0.5% of the total simulation time. The Program to Construct Mapping View The program to construct mapping view lists the testbench constructs that use the most simulation time and list the percentage of the total simulation they use, and the percentage of the programs simulation time each type of construct uses. It also lists the source file and line number of the constructs declaration. Example 5-6 Program to Construct Mapping View
Construct Construct type %Totaltime %Programtime LineNo -----------------------------------------------------------------------------name1::name2 Program Task 2.85 13.45 /u/design/vmm.sv : 12668-12901. var queue.var 2.64 0.99 12.45 4.67 /u/design/vmm.sv : 14551-14558. /u/design/vmm.sv : 13890-14215.
The Top-level Construct View This view shows you the CPU time used by different types of constructs throughout the design. Example 5-7 Top-level Construct View
============================================================================== TOP-LEVEL CONSTRUCT VIEW -----------------------------------------------------------------------------Construct %Totaltime -----------------------------------------------------------------------------Combinational 28.14 Task 16.58 Program Task 9.87 Always 6.52 Program Function 5.82 queue.size 2.64 Port 2.01 Object new 1.92 Initial 0.89 Program Thread 0.79 Function 0.76 queue.name 0.09 queue.name 0.05 ______________________________________________________________________________
The Construct View Across Design This view displays the module or program definitions that contain a type of construct that used more that 0.5% of the CPU time. There are separate sections for each type of construct and each section contains a list of the modules or programs that contain that type of construct.
Example 5-8
The Top-level View This view displays how much memory was used by: Any PLI or DPI application that executes along with VCS VCS for writing VCD and VPD files VCS for internal operations (known as the kernel) that cant be attributed to any part of your design The Verilog modules in your design A SystemVerilog testbench program block, if used Top-level View
Example 5-9
=========================================================================== // Simulation memory: 2054242 bytes =========================================================================== TOP-LEVEL VIEW =========================================================================== TYPE Memory %Totalmemory --------------------------------------------------------------------------DPI 0 0.00 PLI 0 0.00 VCD 0 0.00 KERNEL 890408 43.34 MODULES 1163834 56.66 PROGRAMS 0 0.00 ---------------------------------------------------------------------------//
Just before the top-level view, VCS writes the total amount of memory used by the simulation. In this example, it is 2054242 bytes.
In this example, there is no DPI or PLI application and VCS does not write a VCD or VPD file. VCS used 1163834 bytes of memory and 56.66% of the total memory to simulate the design. VCS used 890408 bytes of memory and 43.34% of the total memory for internal operations, such as scheduling, that cant be attributed to any part of the design. The designation KERNEL is for these internal operations. The designation VCD is for the simulation time used by the callback mechanisms inside VCS for writing either VCD or VPD files. The Module View The module view shows the amount of memory used, and the percentage of memory used, by each module definition. Example 5-10 Top-level View
=========================================================================== MODULE VIEW =========================================================================== Module(index) Memory %Totalmemory No of Instances Definition --------------------------------------------------------------------------bigmem (1) 1048704 51.05 2 exp1.v:16. bigtime (2) 115030 5.60 2 exp1.v:61. test (3) 100 0.00 1 exp1.v:1. --------------------------------------------------------------------------===========================================================================
In this example, the instances of module bigmem used 1048704 bytes of memory, 51.05% of the total memory used. The instances of module bigtime used 115030 bytes of memory, 5.6% of the total memory used.
The Program View The program view displays the amount of memory used, and the percentage of memory used, by each testbench program. Example 5-11 Program View
============================================================================== PROGRAM VIEW ============================================================================== Program(index) Memory %Totalmemory No of Instances Definition -----------------------------------------------------------------------------test (1) 4459091 18.74 1 /u/design/test.sv:25.
Execution of common simulation system tasks such as $reset just once in a regression
Restrictions of save and restart include: Requires extra Verilog code to manage the save and restart Must duplicate start-up code if handling plusargs on restart File I/O suspend and resume in PLI applications must be given special consideration
% cat test.v module simple_restart; initial begin #10 $display("one"); $save("test.chk"); $display("two"); #0 // make the following occur at restart $display("three"); #10 $display("four"); end endmodule
% vcs test.v
To restart the simulation from the state saved in the check file, enter:
% simv -r test.chk
If your simulation contains PLI routines that do file I/O, the routines must detect both the save and restart events, closing and reopening files as needed. You can detect save and restart calls using misctf callbacks with reasons reason_save and reason_restart. When running the saved checkpoint file, be sure to rename it so that further $save calls do not overwrite the binary you are running. There is no way from within the Verilog source code to determine if you are in a previously saved and restarted simulation, therefore, you cannot suppress the $save calls in a restarted binary.
The following example illustrates this in greater detail. The first run optimizes simulation speed by omitting the +dump flag. If a bug is found, the latest checkpoint file is run with the +dump flag to enable signal dumping.
// file test.v module dumpvars(); task processargs; begin if ($test$plusargs("dump")) begin $dumpvars; end end end task //normal start comes here initial begin processargs; end // checkpoint every 1000 time units always #1000 begin // save some old restarts $system("mv -f save.1 save.2"); $system("mv -f save save.1"); $save("save"); #0 processargs; end endmodule // The design itself here module top(); ..... endmodule
2. Narrow down this quotient to the nearest whole number. This whole number is the second argument. In this example, you would narrow down to 2. 3. Multiply 232 with the second argument (that is, 2), and then subtract the obtained result from the large time value (that is, subtract 2 X 232 from the large time value), as shown below:
Simulating the Design 5-27
10,000,000,000-(2*4,294,967,296)=(1,410,065,408) This difference is the first argument. You now have the first and second argument. Therefore, in this example, to specify stopping simulation at time 10,000,00,000, you would enter the following runtime option:
+vcs+stop+1410065408+2
VCS can do some of this work for you by using the following source code:
module wide_time; time wide; initial begin wide = 64d10_000_000_000; $display(Hi=%0d, Lo=%0d, wide[63:32], wide[31:0]); end endmodule
reg rst; wire w1,w2; initial rst=1; bottom bottom1 (rst,w1,w2); endmodule module bottom (rst,q1,q2); output q1,q2; input rst; reg rq1,rq2; assign q1=rq1; assign q2=rq2; always @ rst begin rq1=1b0; rq2=1b0; $display("This always block executed!"); end endmodule
With other Verilog simulators there are two possibilities at time 0: The simulator executes the initial block first, initializing reg rst, then the simulator evaluates the event control sensitivity list for the always block and executes the always block because the simulator initialized rst.
The simulator evaluates the event control sensitivity list for the always block, and so far, reg rst has not changed value during this time step, therefore, the simulator does not execute the always block. Then the simulator executes the initial block and initializes rst. When this occurs, the simulator does not re-evaluate the event control sensitivity list for the always block.
6
VCS Multicore Technology Application Level Parallelism 1
VCS Multicore Technology takes advantage of the computing power of multiple processors in one machine to improve simulation turnaround time. Use the following VCS Multicore Technology options in a simulation: Assertion simulation Toggle coverage Multicore functional coverage VPD dumping SAIF dumping
When used without VCS Multicore options, -parallel enables all VCS Multicore Technology options. When used with VCS Multicore options, -parallel enables only those option specified. This option is available at compile-time only.
fc[=NCONS]
This compile-time option enables multicore Functional Coverage, and with NCONS specifies the number of PFC consumers. NCONS can be changed at run time. For example,
vcs -parallel+fc ... vcs -parallel+fc=3 ... +sva[=NCONS]
This compile-time option enables multicore SVA, and with NCONS specifies the number of multicore SVA consumers. NCONS can be changed at run time. +saif Enables SAIF file dumping, see Parallel SAIF .
+tgl[=NCONS]
Enables multicore Toggle Coverage, and specifies the number of multicore toggle coverage consumers. To enable the use of the same executable for both serial and parallel runs, use this option at runtime. NCONS specifies the number of multicore SVA consumers. For ALP, NCONS can be changed at run time.
+vpd[=NCONS]
Enables multicore VCD+ Dumping. NCONS specifies the number of multicore SVA consumers. For ALP, NCONS can be changed at run time
[-o multicore_executable_name] Using the VCS -o option to specify the simulation executable
binary filename allows work on multiple simultaneous VCS Multicore compiles and runs. VCS Multicore-specific data is stored in a directory executable_name.pdaidir. The default path name is simv.pdaidir. Note: If [NCONS] is not specified, the default is 1 client. For ALP, NCONS can be changed at run time.
-parallel+show_features
Displays enabled VCS Multicore features. Note that you must enter the -parallel option with +show_features Examples:
-parallel+vpd is equal to -parallel+vpd=1 -parallel+tgl is equal to -parallel+tgl=1
Assertion Simulation
You can process only assertion level results or assertion level results along with other VCS Multicore options. 1. Compile using the VCS Multicore -parallel option, the assertion compilation option or options, and other VCS Multicore and VCS options.
vcs filename(s).v -parallel+[sva[=NCONS]] [-ntb_opts] [ multicore_options vcs_options
2. Run the simulation with VCS and VCS Multicore run-time options.
simv
Toggle Coverage
Generate results for only toggle coverage or toggle coverage along with other results by compiling the design with VCS Multicore options that include the +tgl option and VCS coverage metrics options. You can use the +count option to report total executed transactions. After generating coverage results, you can examine them using the Unified Report Generator. Note: To enable the use of the same executable for both serial and parallel runs, use this option at runtime. tgl[+count] Report total executed transactions. 1. Compile using the VCS Multicore -parallel option, coverage option or options, and other VCS Multicore and VCS options.
vcs filename(s).v -parallel+tgl[=NCONS] -cm tgl [multicore_options] [vcs_options]
Example In this example, toggle coverage results only are generated and the URG report is produced in the default HTML format.
% vcs -cm_tgl mda -q -cm_dir pragmaTest1.vdb -cm tgl sverilog -parallel+tgl=2 pragmaTest1.v % simv -vdb tgl
VCS Multicore Technology Application Level Parallelism 6-6
Functional Coverage
Generate results for only functional coverage or functional coverage along with other results by compiling the design with VCS Multicore options that include the +fc option and VCS coverage metrics options. After generating coverage results, you can examine them using the Unified Report Generator. 1. Compile using the VCS Multicore -parallel option, coverage option or options, and other VCS Multicore and VCS options.
vcs filename(s).v -sverilog -parallel+fc[=NCONS] [parallel_vcs_options] [vcs_options]
Example In this example, functional coverage results only are generated and the URG report is produced in the default HTML format.
% % % % % vcs iemIntf.v -sverilog -parallel+fc=2 simv -covg_cont_on_error $urg -dir simv.vdb cat urgReport/gr*
VPD File
You can enable VCS Multicore VPD+ Dumping and specify the number of VCS Multicore VPD+ consumers using the VCS Multicore vpd option. To enable the use of the same executable for both serial and parallel runs, use this option at runtime. Note: When used with multiple consumers, VPD file size blow up might be an issue. Use -parallel+vpd_buffer=<N>, where N=256, 512 etc.
1. Compile using the VCS Multicore -parallel option with the vpd[=NCONS] option, and other VCS Multicore and VCS options.
vcs filename(s).v -debug_pp -parallel+vpd[=NCONS] [multicore_options] [vcs_options]
You can post-process the results with the generated +VPD database. Example In this example, a VPD+ file with three specified consumers is generated.
% vcs -debug_pp -parallel+vpd=3 design.v % simv
Parallel SAIF
SAIF is Switching Activity Interchange Format, a file format for Power Compiler. VCS writes or dumps SAIF files for it. Parallel SAIF is a feature to improve runtime performance. Parallel SAIF uses the VCS Multicore Application Level Parallelism (ALP) capability for multicore machines. In it Parallel SAIF uses a consumer or slave process to write or dump SAIF files while the simulation is run by the producer or master process. Serial SAIF dumping, that is having VCS write SAIF files without using the advantage of a multiple processor machine, is of course still supported. You specify Parallel SAIF with the -parallel+saif compile-time or runtime option.
$set_gate_level_monitoring Forward SAIF file read mode is not supported in Parallel SAIF so do not enter the following system functions: $read_lib_saif $read_rtl_saif
Limitations
Parallel SAIF has the following limitations: Parallel SAIF is not implemented for VCS Multicore Design Level Parallelism (DLP). Parallel SAIF only works with one consumer or slave process, so for example specifying more than one slave process such as entering -parallel+saif=2 results in an error condition. SAIF file read mode is not implemented for Parallel SAIF.
Multiple $toggle_start system tasks are not supported in Parallel SAIF. Only full dump mode is supported, which is one $toggle_start and $toggle_stop system task. Entering multiple $toggle_start system tasks in Parallel SAIF is an error condition.
7
VPD, VCD, and EVCD Utilities
This chapter describes the following: Advantages of VPD Dumping a VPD File Dump Multi-dimensional Arrays and Memories Dumping an EVCD File Post-processing Utilities
VCS allows you to save your simulation history in the following formats: Value Change Dumping (VCD) VCD is the IEEE Standard for Verilog designs. You can save your simulation history in VCD format by using the $dumpvars Verilog system task.
VPD, VCD, and EVCD Utilities 7-1
VCDPlus Dumping (VPD) VPD is a Synopsys propriety dumping technology. VPD has many advantages over the standard VCD ASCII format. See Advantages of VPD for more information. To dump a VPD file, use the $vcdpluson Verilog system task. See Dumping a VPD File for more information.
Extended VCD (EVCD) EVCD dumps only the port information of your design. See Dumping an EVCD File for more information.
VCS also provides several post-processing utilities to: Convert VPD to VCD Convert VCD to VPD Merge VPD Files
Advantages of VPD
VPD offers the following significant advantages over the standard VCD ASCII format: Provides a compressed binary format that dramatically reduces the file size as compared to VCD and other proprietary file formats. The VPD compressed binary format dramatically reduces the signal load time. Allows data collection for signals or scopes to be turned on and off during a simulation run, therefore, dramatically improving simulation runtime and file size.
Can save source statement execution data. This allows instant replay of source execution in the DVE Source Window.
To optimize VCS performance and VPD file size, consider the size of the design, the RAM memory capacity of your workstation, swap space, disk storage limits, and the methodology used in the project.
Usage: level |LVL=integer_variable Specifies the number of hierarchy scope levels to descend to record signal value changes (a zero value records all scope instances to the end of the hierarchy; the default is zero). You can also specify the number of hierarchy scope levels using "LVL=integer_variable". In this example, the integer_variable specifies the level to descend to record signal value changes. scope Specifies the name of the scope in which to record signal value changes (the default is all).
signal Specifies the name of the signal in which to record signal value changes (the default is all). Note: In the syntax, * indicates that the argument can have a list of more than one value (for scopes or signals). Example 1: Record all signal value changes.
timescale 1ns/1ns module test (); ... initial $vcdpluson; ... endmodule
When you simulate the above example, VCS saves the simulation history of the whole design in vcdplus.vpd. For information on the use model to simulate the design, see Basic Usage Model on page 9. Example 2: Record signal value changes for scope test.risc1.alureg and all levels below it.
timescale 1ns/1ns module test (); ... risc1 risc(...); initial $vcdpluson(test.risc1.alureg); ...
endmodule
When you simulate the previous example, VCS saves the simulation history of the instance alureg, and all instances below alureg in vcdplus.vpd. $vcdplusoff The $vcdplusoff task stops recording the signal value changes for specified scopes or signals. The following displays the syntax for vcdplusoff:
$vcdplusoff (level|"LVL=integer",scope*,signal*);
The above example, enables dumping at 0ns, and disables dumping after 5ns. Example 2: Stop recording signal value changes for scope test.risc1.alu1.
timescale 1ns/1ns module test (); ... initial begin
VPD, VCD, and EVCD Utilities 7-6
$vcdpluson; // Enable Dumping $vcdplusoff(test.risc1.alu1); //Does not dump signal value //changes in test.risc1.alu1 ... end ... endmodule
The above example, enables dumping on the entire design. However, $vcdplusoff disables dumping the instance alu1 and instances below alu1. Note: If multiple $vcdpluson commands cause a given signal to be saved, the signal will continue to be saved until an equivalent number of $vcdplusoff commands are applied to the signal.
Note: You must use $vcdpluson after specifying $vcdplusfile, as shown above, to override the default filename. Example:
timescale 1ns/1ns module test (); ... initial begin
$vcdplusfile("my.vpd"); //Dumps signal value changes //in my.vpd $vcdpluson; // Enable Dumping ... end ... endmodule
The above example writes the signal value changes of the whole design in my.vpd.
Note: You should use the compilation options +memcbk and +v2k to use these system tasks. The second method, which uses the $vcdplusmemorydump system task, stores data only when the task is called.
Syntax for Specifying MDAs Use the following syntax to specify MDAs using the $vcdplusmemon, $vcdplusmemoff, and $vcdplusmemorydump system tasks:
system_task( Mda [, dim1Lsb [, dim1Rsb [, dim2Lsb [, dim2Rsb
[, ... dimNLsb [,
dimNRsb]]]]]] );
Usage: system_task Name of the system task (required). It can be $vcdplusmemon, $vcdplusmemoff, or $vcdplusmemorydump. Mda Name of the MDA to be recorded. It must not be a part select. If there are no other arguments, then all elements of the MDA are recorded to the VPD file. dim1Lsb Name of the variable that contains the left bound of the first dimension. This is an optional argument. If there are no other arguments, then all elements under this single index of this dimension are recorded. dim1Rsb Name of the variable that contains the right bound of the first dimension. This is an optional argument. Note: The dim1Lsb and dim1Rsb arguments specify the range of the first dimension to be recorded. If there are no other arguments, then all elements under this range of addresses within the first dimension are recorded. dim2Lsb This is an optional argument with the same functionality as dim1Lsb, but refers to the second dimension.
VPD, VCD, and EVCD Utilities 7-9
dim2Rsb This is an optional argument with the same functionality as dim1Rsb, but refers to the second dimension. dimNLsb This is an optional argument that specifies the left bound of the Nth dimension. dimNRsb This is an optional argument that specifies the right bound of the Nth dimension. Note that MDA system tasks can take 0 or more arguments, with the following caveats: No arguments: The whole design is traversed and all memories and MDAs are recorded. Note that this process may cause significant memory usage, and simulation drag. One argument: If the object is a scope instance, all memories/ MDAs contained in that scope instance and its children will be recorded. If the object is a memory/MDA, that object will be recorded.
Examples This section provides examples and graphical representations of various MDA and memory declarations using the $vcdplusmemon and $vcdplusmemoff tasks.
In this example, mem01 is a three-dimensional array. It has 3x3x3 (27) locations; each location is 8 bits in length, as shown in Figure 7-1.
module tb(); ... reg [3:0] addr1L, addr1R, addr2L, addr2R, addr3L, addr3R; reg [7:0] mem01 [1:3] [4:6] [7:9] ... endmodule
Figure 7-1
Dimension 1
1
4
[76543210]
Dimension 3
[76543210] [76543210]
[76543210]
[76543210] [76543210]
8
[76543210]
[76543210] [76543210]
9
Example 2: Removed variable 'addr1L' and replaced it with constant in the system task
module test(); ... initial begin $vcdplusmemon( mem01, 2); // Records elements mem01[2][4][7] through mem01[2][6][9] ... end ... endmodule
6 [76543210]
[76543210]
3 1
Ending bound:mem0
8
[76543210]
[76543210]
[76543210]
[76543210]
[76543210]
[76543210] 9
Example 3: Removed variable 'addr1L','addr1R' and replaced them with constants in the system task
module test(); ... initial begin $vcdplusmemon( mem01, 2, 3); // Records elements mem01[2][4][7] through mem01[3][6][9] ... end .. endmodule
Starting bound:
4 1
[76543210]
[76543210] [76543210]
3 1
Ending bound:mem0
8
[76543210]
[76543210] [76543210]
[76543210]
[76543210] [76543210]
9
Example 4: Removed variable 'addr1L','addr1R','addr2L' and replaced them with constants in the system task
module test(); ... initial begin $vcdplusmemon( mem01, 2, 2, 5 ); // Records elements mem01[2][5][7] through mem01[2][5][9] ... end
... endmodule
[76543210] [76543210]
3 1
Ending bound:
8
[76543210]
[76543210] [76543210]
[76543210]
[76543210] [76543210]
9
Example 5: Removed variable 'addr1L','addr1R','addr2L','addr2R','addr3L','addr3R' and replaced them with constants in the system task
module test(); ... initial begin $vcdplusmemon( mem01, 2, 2, 5, 5, 8, 8);
VPD, VCD, and EVCD Utilities 7-15
Figure 7-5
4 1
[76543210]
[76543210] [76543210]
Selected element:mem
3 1
[76543210]
[76543210] [76543210]
8
[76543210]
[76543210] [76543210]
9
Using $vcdplusmemorydump
The $vcdplusmemorydump task dumps a snapshot of memory locations. When the function is called, the current contents of the specified range of memory locations are recorded (dumped). You can specify to dump the complete set of multi-dimensional array elements only once. You can specify multiple element subsets of an array using multiple $vcdplusmemorydump commands, but they must occur in the same simulation time. In subsequent simulation
times, $vcdplusmemorydump commands must use the initial set of array elements or a subset of those elements. Dumping elements outside the initial specifications results in a warning message.
Note: Delta cycle collection can start only at the beginning of a time sample. The $vcdplusdeltacycleon task must precede the $vcdpluson command to ensure that delta cycle collection will start at the beginning of the time sample. $vcdplusdeltacycleoff The $vcdplusdeltacycleoff task turns off reporting of delta cycle information starting at the next sample time.
Glitch detection is automatically turned off when VCS executes $vcdplusdeltacycleoff unless you have previously used $vcdplusglitchon/off. Once you use $vcdplusglitchon/ off, DVE allows you explicit control of glitch detection. Syntax:
$vcdplusdeltacycleoff;
Example:
$lsi_dumpports(top.middle1,"dumpports.dmp");
Instead, if you would prefer to have the $lsi_dumpports system task generate an extended VCD (EVCD) file, include the +dumpports+ieee runtime option. $dumpports Creates an EVCD file as specified in IEEE Standard 1364-2001 pages 339-340. You can, for example, input a EVCD file into TetraMAX for fault simulation. EVCD files are similar to the simulation history files generated by the $lsi_dumpports system task for LSI certification, but there are differences in the internal statements in the file. Further, the EVCD format is a proposed IEEE standard format whereas the format of the LSI certification file is specified by LSI. Syntax: $dumpports(module_instance,[module_instance,]"f ilename"); Example: $dumpports(top.middle1, "dumpports.evcd"); If your source code contains a $dumpports system task and you want it to generate simulation history files for LSI certification, include the +dumpports+lsi runtime option.
Limitations
Following are the limitations for EVCD dumping using $dumpports or UCLI command dump type EVCD: Unsupported Port Types For Verilog DUT: - Ports can only be of type Verilog-2001. SystemVerilog type ports are not allowed. VCS generates a warning message, if it finds any unsupported port type. - SystemVerilog complex types (including MDAs, dynamic arrays, associative arrays, queues, and so on) are not supported, and not legal in LRM. Interface or virtual interface is not supported. For ports connected to CCN (tran/rtran) directly or hierarchically: - They are only supported with $dumpports in the Verilog source, and must be known at compile-time. They are not supported with dump type EVCD UCLI command. Unsupported DUT Types DUT cannot be SV program, interface, SystemC, Spice, or Verilog-A.
Unsupported Driver Types Since tran gates divide a net into different segments, the EVCD behavior might be different in presence of XMR drivers.
$deposit, force deposit (UCLI command) associated with EVCD port is not supported. They are not true drivers, and LRM is silent about the intended behavior. If drivers of port are in encrypted region, they are ignored. Drivers through virtual interface/nested interface and so on, are not supported. High-conn logical expressions are not supported.
SystemC Support Each SystemC module is treated like a Verilog shell, and multiple drivers cannot be detected inside SystemC. SystemC is not supported as a DUT. Note: - All forces will be considered as TB regardless of where the force is applied from (TB, DUT, or UCLI). - EVCD port associated with SDF timing may not be properly handled. LRM does not specify how the delay has to be handled for various scenarios (whether to add delay on driver side for EVCD and so on). In case of SDF, value is not same for different net segments of the same net (there is a delay) and whether they should be treated as same net or different net for EVCD purpose. Current behavior is all net segments are treated as part of the same net, all drivers are reported, and driver value change is reported as it occurs in core simulation.
Post-processing Utilities
VCS provides you with the following utilities to process VCD and VPD files. You can use these utilities to perform the following conversions: VPD file to a VCD file VCD file to a VPD file Merge a VPD file
Note: All utilities are available in $VCS_HOME/bin. This section describes these utilities in the following sections: The vcdpost Utility The vcdiff Utility The vcat Utility The vcsplit Utility The vcd2vpd Utility The vpd2vcd Utility The vpdmerge Utility
Contains value change and transition times for each bit of a vector net or register, recorded as a separate signal. This is called scalarizing the vector signals in the VCD file. Avoids sharing the same VCD identifier code with more than one net or register. This is called uniquifying the identifier codes.
In this example, mid1.out1[0]is a bit select of a signal because you need to examine the transition times and value changes of this bit. VCS however writes a VCD file that contains the following:
$var wire 8 ! out1 [7:0] $end
Therefore, all the value changes and simulation times for signal out1 are for the entire signal and not just for the 0 bit. The vcdpost utility can create an alternative VCD file that defines a separate $var section for each bit of the vector signal. The results are as follows:
$var $var $var $var wire wire wire wire 8 8 8 8 ! out1 " out1 # out1 $ out1 [7] [6] [5] [4] $end $end $end $end
8 8 8 8
% & (
What this means is that the new VCD file contains value changes and simulation times for each bit.
In this example, VCS assigns the ! identifier code to more than one net. Some back-end tools from other vendors fail when you input such a VCD file. You can use the vcdpost utility to create an alternative VCD file in which the identifier codes for all nets and registers, including those instances without value changes, are unique. For example:
$var $var $var $var wire wire wire wire 1 1 1 1 ! " # $ ramsel_0_0 ramsel_0_1 ramsel_1_0 ramsel_1_1 $end $end $end $end
Usage: +scalar Specifies creating separate $var sections for each bit in a vector signal. This option is the default option and you include it on the command line when you also include the +unique option and want to create a VCD file that both scalarizes the vector nets and uniquifies the identifier codes. +unique Specifies uniquifying the identifier codes. When you include this option without the +scalar option, vcdpost uniquifies the identifier codes without scalarizing the vector signals. input_VCD_file The name of the VCD file created by VCS. output_VCD_file The name of the alternative VCD file created by the vcdpost utility.
Note: The vcdiff utility cannot compare dump files of different type. Dump files consist of two sections: A header section that reflects the hierarchy (or some subset) of the design that was used to create the dump file. A value change section, which contains all of the value changes (and times when those value changes occurred) for all of the signals referenced in the header.
The vcdiff utility always performs two diffs. First, it compares the header sections and reports any signals/scopes that are present in one dump file but are absent in the other. The second diff compares the value change sections of the dump files, for signals that appear in both dump files. The utility determines value change differences based on the final value of the signal in a time step.
[-showmasters] [-allsigdiffs] [-wrapsize size] [-limitdiffs number] [-ignorewires] [-ignoreregs] [ingorereals] [-ignorefunctaskvars][-ignoretiming units] [ignorestrength] [-geninclude [filename]] [-spikes]
Options for Specifying Scope/Signal Hierarchy The following options control how the vcdiff utility compares the header sections of the dump files: -noabsentsig Does not report any signals that are present in one dump file but are absent in the other. -absentsigscope [scope] Reports only absent signals in the given scope. -absentfile [file] Prints the full path names of all absent scopes/signals to the given file, as opposed to stdout. -absentsigiserror If this option is present and there are any absent signals in either dump file, then vcdiff returns an error status upon completion even if it doesnt detect any value change differences. If this option is not present, absent signals do not cause an error. -allabsentsig Reports all absent signals. If this option is not present, by default, vcdiff reports only the first 10 absent signals. -ignorecase
Ignores the case of scope/signal names when looking for absent signals. In effect, it converts all signal/scope names to uppercase before comparison. -matchtypes Reports mismatches in signal data types between the two dump files. Options for Specifying Scope(s) to be Value Change Diffed By default, vcdiff compares the value changes for all signals that appear in both dump files. The following options limit value change comparisons to specific scopes. -scope [scope] Changes the top-level scope to be value change diffed from the top of the design to the indicated scope. Note, all child scopes/ signals of the indicated scope will be diffed unless modified by the -level option (below). -level N Limits the depth of scope for which value change diffing occurs. For example, if -level 1 is the only command-line option, then vcdiff diffs the value changes of only the signals in the top-level scope in the dump file. -include [file] Reports value change diffs only for those signals/scopes given in the specified file. The file contains a set of full path specifications of signals and/or scopes, one per line. -ignore [file]
Removes any signals/scopes contained in the given file from value change diffing. The file contains a set of full path specifications of signals and/or scopes, one per line. Note: The vcdiff utility applies the -scope/-level options first. It then applies the -include option to the remaining scopes/signals, and finally applies the -ignore option. Options for Specifying When to Perform Value Change Diffing The following options limit when vcdiff detects value change differences: -min time Specifies the starting time (in simulation units) when value change diffing is to begin (by default, time 0). -max time Specifies the stopping time (in simulation units) when value change diffing will end. By default, this occurs at the latest time found in either dump file. -strobe first_time delta_time Only checks for differences when the strobe is true. The strobe is true at first_time (in simulation units) and then every delta_time increment thereafter. -prestrobe Used in conjunction with -strobe, tells vcdiff to look for differences just before the strobe is true.
-when expression Reports differences only when the given when expression is true. Initially this expression can consist only of scalar signals, combined with and, or, xor, xnor, and not operators and employ parentheses to group these expressions. You must fully specify the complete path (from root) for all signals used in expressions. Note, operators may be either Verilog style (&, |, ^, ~^, ~) or VHDL (and, or, xor, xnor, not). -synch signal Checks for differences only when the given signal changes value. In effect, the given signal is a "clock" for value change diffing, where diffs are only checked for on transitions (any) of this signal. -synch0 signal As -sync (above) except that it checks for diffs when the given signal transitions to 0. -synch1 As -sync (above) except that it checks for diffs only when the given signal transitions to 1. Note: The -max, -min and -when options must all be true in order for vcdiff to report a value change difference. Options for Filtering Differences The following options filter out value change differences that are detected under certain circumstances. For the most part, these options are additive.
-ignoretiming time Ignores the value change when the same signal in one of the VCD files has a different value from the same signal in the other VCD file for less than the specified time. This is to filter out signals that have only slightly different transition times in the two VCD files. The vcdiff utility reports a change when there is a transition to a different value in one of the VCD files and then a transition back to a matching value in that same file. -ignoreregs Does not report value change differences on signals that are of type register. -ignorewires Does not report value change differences on signals that are of type wire. -ignorereals Does not report value change differences on signals that are of type real. -ignorefunctaskvars Does not report value change differences on signals that are function or task variables. -ignorestrength (EVCD only) EVCD files contain a richer set of signal strength and directional information than VCD or even VPD files. This option ignores the strength portion of a signal value when checking for differences.
-compare01xz (EVCD only) Converts all signal state information to equivalent 4-state values (0, 1, x, z) before difference comparison is made (EVCD files only). Also ignores the strength information. -xzmatch Equates x and z values. -xumatch (9-state VPD file only) Equates x and u (uninitialized) values. -xdmatch (9-state VPD file only) Equates x and d (dontcare) values. -zdmatch (9-state VPD file only) Equates z and d (dontcare) values. -zwmatch (9-state VPD file only) Equates z and w (weak 1) values. In conjunction with -xzmatch (above), this option causes x and z value to be equated at all times EXCEPT time 0. Options for Specifying Output Format The following options change how value change differences are reported. -allsigdiffs By default, vcdiff only shows the first difference for a given signal. This option reports all diffs for a signal until the maximum number of diffs is reported (see -limitdiffs).
-wrapsize columns Wraps the output of vectors longer than the given size to the next line. By default, this value is 64. -showmasters (VCD, EVCD files only) Shows collapsed net masters. VCS can split a collapsed net into several sub-nets when this has a performance benefit. This option reports the master signals when the master signals (first signal defined on a net) are different in the two dump files. -limitdiffs number_of_diffs By default, vcdiff stops after the first 50 diffs are reported. This option overrides that default. Setting this value to 0 causes vcdiff to report all diffs. -geninclude filename Produces a separate file of the given name in addition to the standard vcdiff output. This file contains a list of signals that have at least one value change difference. The format of the file is one signal per line. Each signal name is a full path name. You can use this file as input to the vcat tool with vcats -include option. -spikes A spike is defined as a signal that changes multiple times in a single time step. This option annotates with #s the value change differences detected when the signal spikes (glitches). It keeps and reports a total count of such diffs.
Here: -deltaTime Specifies writing simulation times as the interval since the last value change rather than the absolute simulation time of the signal transition. Without -deltaTime a vcat output looks like this:
--- TEST_top.TEST.U4._G002 --0 x 33 0 20000 1 30000 x 30030 z 50030 x 50033 1 60000 0 70000 x 70030 z
-raw Displays raw value changed data, organized by simulation time, rather than signal name. -min time Specifies a start simulation time from which vcat begins to display data. -max time Specifies an end simulation time up to which vcat displays data. -scope instance_name Specifies a module instance. The vcat utility displays data for all signals in the instance and all signals hierarchically under this instance. -level level_number Specifies the number of hierarchical levels for which vcat displays data. The starting point is either the top-level module or the module instance you specify with the -scope option.
-include filename Specifies a file that contains a list of module instances and signals. The vcat utility only displays data for these signals or the signals in these module instances. -ignore filename Specifies a file that contains a list of module instances and signals. However, the vcat utility does NOT display data for these signals or the signals in these module instances. -spikes Indicates all zero-time transitions with the >> symbol in the leftmost column. In addition, prints a summary of the total number of spikes seen at the end of the vcat output. The following is an example of the new output:
--- DF_test.logic.I_348.N_1 --0 x 100 0 120 1 >>120 0 4000 1 12000 0 20000 1 Spikes detected: 5
-noalpha By default vcat displays signals within a module instance in alphabetical order. This option disables this ordering. -wrapsize size Specifies value displays for wide vector signals, how many bits to display on a line before wrapping to the next line.
VPD, VCD, and EVCD Utilities 7-37
-showmasters Specifies showing collapsed net masters. -showdefs Specifies displaying signals but not their value changes or the simulation time of these value changes. -showcodes Specifies displaying the signals VCD file identifier code. -stdin Enables you to use standard input, such as piping the VCD file into vcat, instead of specifying the filename. -vgen Generates from a VCD file two types of source files for a module instance: one that models how the design applies stimulus to the instance, and the other that models how the instance applies stimulus to the rest of the design. See Generating Source Files From VCD Files on page 39. The following is an example of the output from the vcat utility:
vcat exp1.vcd exp1.vcd: scopes:6 signals:12 value-changes:13 --- top.mid1.in1 --0 1 --- top.mid1.in2 --0 xxxxxxxx 10000 00000000
In this output, for example, you see that signal top.mid1.midr1 at time 0 had a value of X and at simulation time 2000 (as specified by the $timescale section of the VCD file, which VCS derives from the time precision argument of the timescale compiler directive) this signal transitioned to 1.
Note: The vcat utility can only generate these source files for instances of module definitions that do not have inout ports.
Testbench generation enables you to focus on a module instance, applying the same stimulus as the design does, but at faster simulation because the testbench is far more concise than the entire design. You can substitute module definitions at different levels of abstraction and use vcdiff to compare the results. Module generation enables you to use much faster simulating canned modules for a part of the design to enable the faster simulation of other parts of the design that need investigation. The name of the generated source file from testbench generation begins with testbench followed by the module and instance names in the hierarchical name of the module instance, separated by underscores. For example testbench_top_ad1.v. Similarly, the name of the generated source file from module generation begins with moduleGeneration followed by the module and instance names in the hierarchical name of the module instance, separated by underscores. For example moduleGeneration_top_ad1.v. You enable vcat to generate these files by doing the following: 1. Writing a configuration file. 2. Running vcat with the -vgen command-line option.
2. Specification of testbench generation with the keyword testbench or specification of module generation with the keyword moduleGeneration. 3. The module header and the port declarations from the module definition of the module instance. You can use Verilog comments in the configuration file. The following is an example of a configuration file: Example 7-1 Configuration File
top.ad1 testbench //moduleGeneration module adder (out,in1,in2); input in1,in2; output [1:0] out;
You can use a different name and location for the configuration file. In order to do this, you must enter it as an argument to the -vgen option. For example:
vcat filename.vcd -vgen /u/design1/vgen2.cfg
Example 7-2
Source Code
#0 r1=0; #10 r2=0; #10 r1=1; #10 r2=1; #10 r1=0; #10 r2=0; #10 r1=1; #10 r2=1; #10 r1=0; #10 r2=0; #10 r1=1; #10 r2=1; #10 r1=0; #10 r2=0; #100 $finish; end passer pa1 (int1,int2,r1,r2); adder ad1 (result,int1,int2); endmodule module passer (out1,out2,in1,in2); input in1,in2; output out1,out2; assign out1=in1; assign out2=in2; endmodule module adder (out,in1,in2); input in1,in2; output [1:0] out; reg r1,r2; reg [1:0] sum; always @ (in1 or in2) begin r1=in1; r2=in2; sum=r1+r2; end
Notice that the stimulus from the testbench module named test propagates through an instance of a module named passer before it propagates to an instance of a module named adder. The vcat utility can generate a testbench module to stimulate the instance of adder in the same exact way but in a more concise and therefore faster simulating module. If we use the sample vgen.cfg configuration file in Example 7-1 and enter the following command line:
vcat filename.vcd -vgen
This source file uses significantly less code to apply the same stimulus with the instance of module passer omitted. If we revise the vgen.cfg file to have vcat perform module generation, the generated source file, moduleGeneration__top_ad1.v, is as follows:
module adder (out,in1,in2) ; input in2 ; input in1 ; output [1:0] out ; reg [1:0] out ; initial begin #0 out = 2bxx; #10 out = 2b00; #10 out = 2b01; #10 out = 2b10; #10 out = 2b01; #10 out = 2b00; #10 out = 2b01; #10 out = 2b10; #10 out = 2b01; #10 out = 2b00; #10 out = 2b01; #10 out = 2b10; #10 out = 2b01; #10 out = 2b00; end endmodule
Notice that the input ports are stubbed and the values from the VCD file are assigned directly to the output port.
Here: -o output_file Specifies the name of the new VCD/EVCD/VPD file to be generated. If output_file is not specified, vcsplit creates the file with the default name vcsplit.vcd. -scope selected_scope_or_signal Specifies a signal or scope whose value changes are to be included in the output file. If a scope name is given, then all signals and sub-scopes in that scope are included. -include include_file Specifies the name of an include file that contains a list of signals/ scopes whose value changes are to be included in the output file.
The include file must contain one scope or signal per line. Each presented scope/signal must be found in the input VCD, EVCD, or VPD file. If the file contains a scope, and separately, also contains a signal in that scope, vcsplit includes all the signals in that scope, and issues a warning. Note: If you use both -include and -scope options, vcsplit uses all the signals and scopes indicated. input_file Specifies the VCD, EVCD, or VPD file to be used as input. Note: If the input file is either VCD or EVCD, and it is not specified, vcsplit takes its input from stdin. The vcsplit utility has this stdin option for VCD and EVCD files so that you can pipe the output of gunzip to this tool. If you try to pipe a VPD file through stdin, vcsplit exits with an error message. -min min_time Specifies the time to begin the scan. -max max_time Specifies the time to stop the scan. -ignore ignore_file Specifies the name of the file that contains a list of signals/scopes whose value changes are to be ignored in the output file.
If you specify neither include_file nor selected_scope_or_signal, then vcsplit includes all the value changes in the output file except the signals/scopes in the ignore_file. If you specify an include_file and/or a selected_scope_or_signal, vcsplit includes all value changes of those signals/scopes that are present in the include_file and the selected_scope_or_signal but absent in ignore_file in the output file. If the ignore_file contains a scope, vcsplit ignores all the signals and the scopes in this scope. -level n Reports only n levels hierarchy from top or scope. If you specify neither include_file nor selected_scope_or_signal, vcsplit computes n from the top level of the design. Otherwise, it computes n from the highest scope included. -v Displays the current version message. -h Displays a help message explaining usage of the vcsplit utility. Note: In general, any command-line error (such as illegal arguments) that VCS detects causes vcsplit to issue an error message and exit with an error status. Specifically:
- If there are any errors in the -scope argument or in the include file (such as a listing a signal or scope name that does not exist in the input file), VCS issues an error message, and vcsplit exits with an error status. - If VCS detects an error while parsing the input file, it reports an error, and vcsplit exits with an error status. - If you do not provide either a -scope, -include or -ignore option, VCS issues an error message, and vcsplit exits with an error status. Limitations MDAs are not supported. Bit/part selection for a variable is not supported. If this usage is detected, the vector will be regarded as all bits are specified.
Usage: -b<min_buffer_size> Minimum buffer size in KB used to store Value Change Data before writing it to disk.
-f<max_output_filesize> Maximum output file size in KB. Wrap around occurs if the specified file size is reached. -h Translate hierarchy information only. -m Give translation metrics during translation. -q Suppress printing of copyright and other informational messages. +deltacycle Add delta cycle information to each signal value change. +glitchon Add glitch event detection data. +nocompress Turn data compression off. +nocurrentvalue Do not include object's current value at the beginning of each VCB. +bitrangenospace Support non-standard VCD files that do not have white space between a variable identifier and its bit range.
Here: -h Translate hierarchy information only. -q Suppress the copyright and other informational messages. -s Allow sign extension for vectors. Reduces the file size of the generated vcd_file. -x Expand vector variables to full length when displaying $dumpoff value blocks. -xlrm Convert uppercase VHDL objects to lowercase. +zerodelayglitchfilter Zero delay glitch filtering for multiple value changes within the same time unit. +morevhdl Translates the VHDL types of both directly mappable and those that are not directly mappable to verilog types.
VPD, VCD, and EVCD Utilities 7-51
Note: This switch may create a non-standard VCD file. +start+time Translate the value changes starting after the specified start time. +end+time Translate the value changes ending before the specified end time. Note: Specify both start time and end time to translate the value changes occuring between start and end time. +dumpports+instance Generate an EVCD file for the specified module instance. If the path to the specified instance contains escaped identifiers, then the full path must be enclosed in single quotes. -f cmd_filename Specify a command file containing commands to limit the design converted to VCD or EVCD. See the The Command File Syntax section for more information. +splitpacked Use this option to change the way packed structs and arrays are reported in the output VCD file. It does the following: - Treats a packed structure the same as an unpacked structure and dumps the value changes of each field. Consider the following example:
typedef logic [1:0] t_vec; typedef struct packed { t_vec f_vec_b; } t_ps_b; module test(); t_ps_b var_ps_b; endmodule
- Treats a packed MDA as an unpacked MDA except for the inner most dimensions. Consider the following example:
typedef logic [1:0] t_vec; module test(); t_vec [3:2] var_vec; endmodule
- Expands all packed arrays defined in a packed struct. Consider the following example:
typedef logic [1:0] t_vec; typedef struct packed { t_vec f_vec; t_vec [3:2][1:0] f_vec_array; } t_ps; module test(); t_ps var_ps; endmodule
- Expands all dimensions of a packed array defined in a packed struct. Consider the following example:
typedef logic [1:0] t_vec; typedef struct packed { t_vec f_vec; t_vec [3:2][1:0] f_vec_array; } t_ps; module test(); t_ps [1:0] var_paps; endmodule
$scope module test $end $scope fork var_paps[1] $end $var reg 2 ' f_vec [1:0] $end $var reg 2 ( f_vec_array[3][1] $var reg 2 ) f_vec_array[3][0] $var reg 2 * f_vec_array[2][1] $var reg 2 + f_vec_array[2][0] $upscope $end $scope fork var_paps[0] $end $var reg 2 , f_vec [1:0] $end $var reg 2 f_vec_array[3][1] $var reg 2 . f_vec_array[3][0] $var reg 2 / f_vec_array[2][1] $var reg 2 0 f_vec_array[2][0] $upscope $end $upscope $end
- Expands and prints the value of each member of a packed union. Consider the following example:
module testit; typedef logic [1:0] t_vec; typedef union packed { t_vec f_vec; struct packed { logic f_a; logic f_b; } f_ps; } t_pu_v; typedef union packed { struct packed { logic f_a; logic f_b; } f_ps; t_vec f_vec; } t_pu_s;
Note the following before writing a command file: All commands must start as the first word in the line, and the arguments for these commands should be written in the same line. For example:
dumpvars 1 adder4
All comments written after a command, must be preceded by a space. For example:
dumpvars 1 adder4 //can write your comment here
A command file can contain the following commands: dumpports instance [instance1 instance2 ....] Specify an instance for which an EVCD file has to be generated. You can generate an EVCD file for more than one instance by specifying the instance names separated by a space. You can also specify multiple dumpports commands in the same command file. dumpvars [level] [instance instance1 instance2 ....] Specify an instance for which a VCD file has to be generated. [level] is a numeric value indicating the number of levels to traverse down the specified instance. If not specified, or if the value specified is "0", then all the instances under the specified instance will be dumped. You can generate a VCD file for more than one instance by specifying the instance names separated by a space. You can also specify multiple dumpvars commands in the same command file.
If this command is not specified or the command has no arguments, then a VCD file will be generated for the whole design. dumpvcdports [level] instance [instance1 instance2 ....] Specify an instance whose port values are dumped to a VCD file. [level] is a numeric value indicating the number of levels to traverse down the specified instance. If not specified, or if the value specified is "0", then the port values of all the instances under the specified instance will be dumped. You can generate a dump file for more than one instance by specifying the instance names separated by a space. You can also specify multiple dumpvcdports commands in the same command file. Note: dumpvcdports splits the inout ports of type wire into two separate variables: - one shows the value change information driven into the port. VCS adds a suffix _DUT to the basename of this variable. - the other variable shows the value change information driven out of the port. VCS adds a suffix _TB to the basename of this variable. dutsuffix DUT_suffix Specify a string to change the suffix added to the variable name that shows the value change date driven out of the inout port. The default value is _DUT. The suffix can also be enclosed within double quotes.
tbsuffix TB_suffix Specify a string to change the suffix added to the variable name that shows the value change date driven into the inout port. The default value is _TB. The suffix can also be enclosed within double quotes. starttime start_time Specify the start time to start dumping the value change data to the VCD file. If this command is not specified, the start time will be the start time of the VPD file. Note: Only one +start command is allowed in a command file. endtime end_time Specify the end time to stop dumping the value change data to the VCD file. If this command is not specified, the end time will be the end time of the VPD file. Note: Only one +end command is allowed in a command file, and must be equal to or greater than the start time. Limitations dumpports is mutually exclusive with either the dumpvars or dumpvcdports commands. The reason for this is that dumpports generates an EVCD file while both dumpvars and dumpvcdports generates standard VCD files. Escaped identifiers must include the trailing space. Any error parsing the file will cause the translation to terminate.
Signal group test is from a VPD file from the first half of a simulation, signal group test_1 is from a VPD file for the second half of a simulation, and signal group test_2 is from the merged VPD file. The syntax is as shown below:
vpdmerge [-h] [-q] [-hier] [-v] -o merged_VPD_filename input_VPD_filename input_VPD_filename ...
-o merged_VPD_filenames Specifies the name of the output merged VPD file. This option is required. -q Specifies quiet mode, disables the display of most output to the terminal. -hier Specifies that you are merging VPD files for different parts of the design, instead of the default condition, without this option, which is merging VPD files from different simulation times. -v Specifies verbose mode, enables the display of warning and error messages. Restrictions The vpdmerge utility includes the following restrictions: To read the merged VPD file, DVE must have the same or later version than that of the vpdmerge utility. VCS must have written the input VPD files on the same platform as the vpdmerge utility. The input VPD files cannot contain delta cycle data (different values for a signal during the same time step). The input VPD files cannot contain named events. The merged line stepping data does not always accurately replay scope changes within a time step.
If you are merging VPD files from different parts of the design, using the -hier option, the VPD files must be used for distinctly different parts of the design, they cannot contain information for the same scope. You cannot use the vpdmerge option on two vpd files, which are created based on timing, for both timing & hierarchy (using the hier option) based merging.
Limitations The verbose option -v may not display error or warning messages in the following scenarios: If the reference signal completely or coincidentally overlaps the compared signal. During hierarchy merging, if the design object already exists in the merged file.
During hierarchy merging, the -hier option may not display error or warning messages in the following scenarios. If the start and end times of the two dump files are the same. If the datatype of the hierarchical signal in the dump files do not match.
Value Conflicts If the vpdmerge utility encounters conflicting values for the same signal, with the same hierarchical name, in different input VPD files, it does the following when writing the merged VPD file: If the signals have the same end time, vpdmerge uses the values from the first input VPD file that you entered on the command line.
If the signals have different end times, vpdmerge uses the values for the signal with the greatest end time. In cases where there are value conflicts, the -v option displays messages about these conflicts.
8
Performance Tuning 1
VCS delivers the best performance during both compile-time and runtime by reducing the size of the simulation executable, and the amount of memory consumed for compilation and simulation. By default, it is optimized for the following types of designs: Designs with many layers of hierarchy Gate-level designs Structural RTL-level designs - Using libraries where the cells are RTL-level code Designs with extensive use of timing such as delays, timing checks, and SDF back annotation, particularly to INTERCONNECT delays
However, depending on the phase of your design cycle, you can finetune VCS for a better compile-time and runtime performance.
This chapter describes the following sections: Compile-time Performance Compile-time performance plays a very important role when you are in the initial phase of your design development cycle. In this phase, you may want to modify and recompile the design to observe the behavior. Since, this phase involves lot many recompiling cycles, achieving a faster compilation is important. For additional information, see the section entitled, Compile-time Performance . Runtime Performance Runtime performance is important in regression phase or in the final phase of the design development cycle. For additional information, see the section entitled, Runtime Performance .
Compile-time Performance
You can improve compile-time performance in the following ways: Incremental Compilation Compile Once and Run Many Times Parallel Compilation
Incremental Compilation
During compilation, VCS builds the design hierarchy. By default, when you recompile the design, VCS compiles only those design units that have changed since the last compilation. This is called incremental compilation.
The incremental compilation feature is the default in VCS. It triggers recompilation of design units under the following conditions: Changes in the command-line options. Change in the target of a hierarchical reference. Change in the ports of a design unit. Change in the functional behavior of the design. Change in a compile-time constant such as a parameter.
The following conditions do not cause VCS to recompile a module: Change of time stamp of any source file. Change in file name or grouping of modules in any source file. Unrelated change in the same source file. Nonfunctional changes such as comments or white space.
Run the same test with different seeds. Create a softlink of the executable and the .daidir or .db.dir directory in a different directory, to run multiple simulations in parallel.
Parallel Compilation
You can improve the compile-time performance by specifying the number of parallel processes VCS can launch for the native code generation phase of the compilation. You should specify this using the compile-time option -j[no_of_processes], as shown below:
% vcs -j[no_of_processes] [options] top_entity/module/ config
For example, the following command line will fork off two parallel processes to generate a binary executable:
% vcs -j2 top
Runtime Performance
VCS runtime performance is based on the following: Coding Style (see Chapter 3, "Modeling Your Design"). Access to the internals of your design at runtime, using PLIs, UCLI, debugging using GUI, dumping waveforms etc.
Note: The configuration file is a general purpose file that has other purposes, such as specifying ACC write capabilities. Therefore, to enable Radiant Technology optimizations with a configuration file, you must also include the +rad compile-time option. The Configuration File Syntax The configuration file contains one or more statements that set Radiant optimization attributes, such as enabling or disabling optimization on a type of design object, such as a module definition, a module instance, or a signal. The syntax of each type of statement is as follows:
module {list_of_module_identifiers} {list_of_attributes};
or
instance {list_of_module_identifiers_and_hierarchical_names} {list_of_attributes};
or
Usage: module Keyword that specifies that the attributes in this statement apply to all instances of each module in the list, specified by module identifier. list_of_module_identifiers A comma separated list of module identifiers enclosed in curly braces: { } list_of_attributes A comma separated list of Radiant optimization attributes enclosed in curly braces: { } instance Keyword that specifies that the attributes in this statement apply to: - All instances of each module in the list specified by module identifier. - All module instances in the list specified by their hierarchical names. - The individual signals in the list specified by their hierarchical names. list_of_module_identifiers_and_hierarchical_nam es
A comma separated list of module identifiers, hierarchical names of module instances, or signals enclosed in curly braces: { } Note: Follow the Verilog syntax for signal names and hierarchical names of module instances. tree Keyword that specifies that the attributes in this statement apply to all instances of the modules in the list, specified by module identifier, and also apply to all module instances hierarchically under these module instances. depth An integer that specifies how far down the module hierarchy, from the specified modules, you want to apply Radiant optimization attributes. You can specify a negative value. A negative value specifies descending to the leaf level and counting up levels of the hierarchy to apply these attributes. This specification is optional. Enclose this specification in parentheses: () The valid Radiant optimization attributes are as follows: noOpt Disables Radiant optimizations on the module instance or signal. noPortOpt Prevents port optimizations such as optimizing away unused ports on a module instance.
Opt Enables all possible Radiant optimizations on the module instance or signal. PortOpt Enables port optimizations such as optimizing away unused ports on a module instance. Statements can use more than one line and must end with a semicolon. Verilog style comments characters /* comment */ and // comment can be used in the configuration file. Configuration File Statement Examples The following are examples of statements in a configuration file. module statement example
module {mod1, mod2, mod3} {noOpt, PortOpt};
This module statement example disables Radiant optimizations for all instances of modules mod1, mod2, and mod3, with the exception of port optimizations. multiple module statement example
module {mod1, mod2} {noOpt}; module {mod1} {Opt};
In this example, the first module statement disables radiant optimizations for all instances of modules mod1 and mod2 and then the second module statement enables Radiant optimizations for all instances of module mod1. VCS processes statements in the order
in which they appear in the configuration file so the enabling of optimizations for instances of module mod1 in the second statement overrides the first statement. instance statement example
instance {mod1} {noOpt};
In this example, mod1 is a module identifier so the statement disables Radiant optimizations for all instances of mod1. This statement is the equivalent of:
module {mod1} {noOpt};
In this example, the module statement disables Radiant optimizations for all instances of module mod1. The instance statement disables Radiant optimizations for the following: Hierarchical instance mod1.mod2_inst1.mod3_inst1 Hierarchical signal mod1.mod2_inst1.reg_a
The statement enables Radiant Technology optimizations for the instances of modules mod1 and mod2 and for all the module instances hierarchically under these instances. second tree statement example
tree (0) {mod1,mod2} {Opt};
This modification of the previous tree statement includes a depth specification. A depth of 0 means that the attributes apply no further down the hierarchy than the instances of the specified modules, mod1 and mod2.
module top
A tree statement with a depth of 0 is the equivalent of a module statement. third tree statement example You can specify a negative value for the depth value. If you do this, specify ascending the hierarchy from the leaf level. For example:
tree (-2) {mod1, mod3} {Opt};
This statement specifies looking down the module hierarchy under the instances of modules mod1 and mod3 to the leaf level and counting up from there. (Leaf level module instances contain no module instantiation statements.)
module top
In this example, the instances of mod1111, mod12, and mod3 are at a depth of -1 and the instances of mod111 and mod1 are at a depth of -2. The attributes do not apply to the instance of mod11 because it is at a depth of -3. fourth tree statement example You can disable Radiant optimizations at the leaf level under specified modules. For example:
tree(-1) {mod1, mod2} {noOpt};
This example disables optimizations at the leaf level, the instances of modules mod1111, mod12, and mod21, under the instances of modules mod1 and mod2.
Known Limitations Radiant Technology is not applicable to all simulation situations. Some features of VCS are not available when you use Radiant Technology. These limitations are: Back-annotating SDF Files You cannot use Radiant Technology if your design back-annotates delay values from either a compiled or an ASCII SDF file at runtime. SystemVerilog Radiant Technology does not work with SystemVerilog design construct code. For example, structures and unions, new types of always blocks, interfaces, or things defined in $root. The only SystemVerilog constructs that work with Radiant Technology are SystemVerilog assertions that refer to signals with Verilog-2001 data types, not the new data types in SystemVerilog. Potential Differences in Coverage Metrics VCS supports coverage metrics with Radiant Technology and you can enter both the +rad and -cm compile-time options. However, Synopsys does not recommend comparing coverage between two simulation runs when only one simulation was compiled for Radiant Technology. The Radiant Technology optimizations, though not changing the simulation results, can change the coverage results.
Compilation Performance With Radiant Technology Using Radiant Technology incurs longer incremental compile times because the analysis performed by Radiant Technology occurs every time you recompile the design even when only a few modules have changed. However, VCS only performs the code generation phase on the parts of the design that have actually changed. Therefore, the incremental compile times are longer when you use Radiant Technology but shorter than a full recompilation of the design.
Usage Model
Step1: Using the runtime option +vcs+learn+pli. Compilation
% vcs [vcs_options] Verilog_files
Simulation
% simv [sim_options] +vcs+learn+pli
Simulation
% simv [sim_options]
Impact on Performance
Options like -debug_pp, -debug, and -debug_all disable VCS optimizations and also impact the performance. The -debug_pp option has less performance impact than the -debug or -debug_all options. The following table describes these options and their performance impact: Table 8-1 Performance Impact of -debug_pp, -debug, and -debug_all
Description Use this option to generate a dump file. You can also use this option to invoke UCLI and DVE with some limitations. This has less performance impact when compared to -debug or -debug_all Use this option if you want to use the force command at the UCLI prompt, and for more debug capabilities. This option enables all debug capabilities, and therefore will have a huge performance impact.
Options -debug_pp
-debug -debug_all
See the section Compiling or Elaborating the Design in Debug Mode on page 1 for more information. Note that using extensive user interface commands, like force or release at runtime, will have an huge impact on the performance. To improve the performance, Synopsys recommends you to convert these user interface commands to HDL files and to compile and simulate them along with the design. Contact Synopsys Support Center ([email protected]) or your Synopsys Application Consultant for further assistance.
9
Gate-level Simulation
This chapter contains the following sections: SDF Annotation Precompiling an SDF File SDF Configuration File Delays and Timing Using the Configuration File to Disable Timing Using the timopt Timing Optimizer Using Scan Simulation Optimizer Negative Timing Checks
SDF Annotation
The OVI Standard Delay File (SDF) specification provides a standard ASCII file format for representing and applying delay information. VCS supports the OVI versions 1.0, 1.1, 2.0, 2.1, and 3.0 of this specification. In the SDF format a tool can specify intrinsic delays, interconnect delays, port delays, timing checks, timing constraints, and pulse control (PATHPULSE). When VCS reads an SDF file it back-annotates delay values to the design, that is, it adds delay values or changes the delay values specified in the source files. Following are ways to back-annotate the delays specified in the SDF file: Using Unified SDF Feature Using $sdf_annotate System Task Using -xlrm Option for SDF Retain, Gate Pulse Propagation, and Gate Pulse Detection Warning
Simulation
% simv [run_options]
For more information, see Options for Specifying Delays and SDF Files
Where: "sdf_file" Specifies the path to the SDF file. module_instance Specifies the scope where back-annotation starts. The default is the scope of the module instance that calls $sdf_annotate. "sdf_configfile" Specifies the SDF configuration file. For more information on the SDF configuration file, refer to the SDF Configuration File section.
Gate-level Simulation 9-3
"sdf_logfile" Specifies the SDF log file to which VCS sends error messages and warnings. By default, VCS displays no more than ten warning and ten error messages about back-annotation and writes no more than that in the log file you specify with the -l option. However, if you specify an SDF log file with this argument, the SDF log file receives all messages about back-annotation. You can also use the +sdfverbose runtime option to enable the display of all back-annotation messages. "mtm_spec" Specifies which delay values of min:typ:max triplets VCS backannotates. Specify MINIMUM, TYPICAL, MAXIMUM or TOOL_CONTROL (default). "scale_factors" Specifies the multiplier for the minimum, typical and maximum components of delay triplets. It is a colon separated string of three positive, real numbers "1.0:1.0:1.0" by default. "scale_type" Specifies the delay value from each triplet in the SDF file for use before scaling. Possible values: "FROM_TYPICAL", "FROM_MIMINUM", "FROM_MAXIMUM", "FROM_MTM" (default). The usage model to simulate a design using $sdf_annotate is the same as the basic usage model as shown below: Compilation
% vcs [elab_options] top_cfg/entity/module
Simulation
% simv [run_options]
See Options for Specifying Delays and SDF Files on page 25.
Using -xlrm Option for SDF Retain, Gate Pulse Propagation, and Gate Pulse Detection Warning
The following sections explain how to use the new features added under the -xlrm option: Using Optimistic Mode in SDF Using Gate Pulse Propagation Generating Warnings During Gate Pulses
The output using the -xlrm alt_retain option (new behavior) is:
time= 10 , d1=0,d2=0, qout=0 time= 100 , d1=1,d2=0, qout=0 // since there is no logic change on "qout", no retain "x" seen time= 200 , d1=0,d2=0, qout=0 time= 300 , d1=0,d2=1, qout=0 time= 400 , d1=1,d2=1, qout=0 time= 406 , d1=1,d2=1, qout=x // since there is logic change on "qout", retain "x" propagated time= 410 , d1=1,d2=1, qout=1
module dut(qout,dinA,dinB); output qout; input dinA; input dinB; xor #10 inst(qout,dinA,dinB); endmodule
Under the -xlrm gd_pulseprop option, if the pulse width on a gate is equal to the gate delay, VCS always propagates the pulse as shown below:
0 qout=x, dinA=1 dinB=1 10 qout=0, dinA=0 dinB=1 20 qout=1, dinA=0 dinB=0 30 qout=0, dinA=0 dinB=1 40 qout=1, dinA=0 dinB=0 50 qout=0, dinA=0 dinB=0
Under the -xlrm gd_pulsewarn option, if the pulse width on a gate is equal to the gate delay, VCS generates the following warning message:
Gate-level Simulation 9-7
0 qout=x, dinA=1 dinB=1 Warning-[PWIWGD] Pulse Width Identical With Gate Delay verilogfile.v, 42 top.mid_inst.dut_inst At time 10, pulse width identical with gate delay "10" is detected 10 qout=0, dinA=0 dinB=1 20 qout=1, dinA=0 dinB=0
By default, the +csdf+precompile option creates the precompiled SDF file in the same directory as the ASCII text SDF file and differentiates the precompiled version by appending "_c" to its extension. For example, if the /u/design/sdf directory contains a design1.sdf file, using the +csdf+precompile option creates the precompiled version of the file named design1.sdf_c in the / u/design/sdf directory. After you have created the precompiled version of the SDF file, you no longer need to include the +csdf+precompile option on the vcs command line unless there is a change in the SDF file. Continuing to include it, however, such as in a script that you run every time you compile your design, would have no effect when the precompiled version is newer than the ASCII text SDF file, but would create a new precompiled version of the SDF file whenever the ASCII text SDF file changes. Therefore this option is intended to be used in scripts for compiling your design. When you recompile your design, VCS finds the precompiled SDF file in the same directory as the SDF file specified in the $sdf_annotate system task. You can also specify the precompiled SDF file in the $sdf_annotate system task. The +csdf+precompile option also supports zipped SDF.
MIPD (module-input-delay) approximation policy for cases of overlapping annotations to the same input port.
Additionally, there is a mapping command you can use to redirect the target of IOPATH and TIMINGCHECK statements from the scope of the INSTANCE to a specific IOPATH or TIMINGCHECK in its sub hierarchy for all instances of a specified module type.
NETDELAY DEVICE
Timing-checks
module path pulse delay module path pulse reject/error delay module path delay module input port delay module input port delay or, intermodule path delay when +multisource_int_delays specified module input port delay primitive and module path delay $setup timing-check limit $hold timing-check limit $setup and $hold timing-check limit $recovery timing-check limit
Table 9-1
$skew timing-check limit $width timing-check limit $period timing-check limit ignored ignored ignored ignored ignored
approx_command
The INTERCONNECT_MPID keyword selects the INTERCONNECT delays in the SDF file that are mapped to MIPDs in VCS. It can specify one of the following to VCS: MINIMUM Annotates, to the MIPD for the input or inout port instance, the shortest delay of all the INTERCONNECT delay value entries in the SDF file that specify a connection to the input or inout port.
MAXIMUM Annotates, to the MIPD for the input or inout port instance, the longest delay of all the INTERCONNECT delay value entries in the SDF file that specify a connection to the input or inout port. AVERAGE Annotates, to the MIPD for the input or inout port instance, the average delay of all the INTERCONNECT delay value entries in the SDF file that specify a connection to the input or inout port. LAST Annotates, to the MIPD for the input or inout port instance, the delays in the last INTERCONNECT entry in the SDF file that specifies a connection to the input or inout port. The default approximation is MAXIMUM. Syntax:
INTERCONNECT_MIPD = MINIMUM | MAXIMUM | AVERAGE | LAST;
Example:
INTERCONNECT_MIPD=LAST;
mtm_command
Annotates the minimum, typical, or maximum delay value. Specifies one of the following keywords: MINIMUM Annotates the minimum delay value TYPICAL Annotates the typical delay value
MAXIMUM Annotates the maximum delay value TOOL_CONTROL Delay value is determined by the command line options of the Verilog tool (+mindelays, +typdelays, or +maxdelays) The default for min_typ_max is TOOL_CONTROL. Syntax:
MTM = MINIMUM | TYPICAL | MAXIMUM | TOOL_CONTROL;
Example:
MTM=MAXIMUM;
scale_command
SCALE_FACTORS - Set of three real number multipliers that scale the timing information in the SDF file to the minimum, typical, and maximum timing information that is backannotated to the Verilog tool. The multipliers each represent a positive real number, for example 1.6:1.4:1.2 SCALE_TYPE - Selects one of the following keywords to scale the timing specification in the SDF file to the minimum, typical, and maximum timing that is backannotated to the Verilog tool: FROM_MINIMUM Scales from the minimum timing specification in the SDF file. FROM_TYPICAL Scales from the typical timing specification in the SDF file. FROM_MAXIMUM Scales from the maximum timing specification in the SDF file.
FROM_MTM Scales directly from the minimum, typical, and maximum timing specifications in the SDF file. Syntax:
SCALE_FACTORS = number : number : number; SCALE_TYPE = FROM_MINIMUM | FROM_TYPICAL | FROM_MAXIMUM | FROM_MTM;
Example:
SCALE_FACTORS=100:0:9; SCALE_TYPE=FROM_MTM; SCALE_FACTORS=1.1:2.1:3.1; SCALE_TYPE=FROM_MINIMUM;
ctrlw = 0; in = 1'bx; //stabilize at x; #100 in = 1; // x-1 #100 ctrl = 1; // 1-z #100 ctrl = 0; // z-1 #100 in = 0; // 1-0 #100 ctrl = 1; // 0-z #100 ctrl = 0; // z-0 #100 in = 1'bx; // 0-x #100 ctrl = 1; // x-z #100 ctrl = 0; // z-x #100 in = 0; // x-0 #100 in = 1; // 0-1 #100 in = 1'bx; // 1-x end endmodule `celldefine module sub(o1,o2,i1,i2,c1,c2); output o1,o2; input i1,i2; input c1,c2; bufif0 Z(o1,i1,c1); bufif0 (o2,i2,c2); specify (i1,c1 *> o1) = (1,2,3,4,5,6); // 01 = 1, 10 = 2, 0z = 3, z1 = 4, 1z = 5, z0 = 6 if (i2==1'b1) (i2,c2 *> o2) = (7,8,9,10,11,12); // 01 = 7, 10 = 8, z1 = 10, 1z = 11, z0 = 12 endspecify subsub X (); endmodule `endcelldefine module subsub(oa,ob,ib,ia); input ia,ib;output oa,ob; specify (ia *> oa) = 99.99; (ib *> ob) = 2.99; endspecify endmodule SDF File: test.sdf (DELAYFILE
(SDFVERSION "3.0") (DESIGN "sdftest") (DATE "July 14, 1997") (VENDOR "Synopsys") (PROGRAM "manual") (VERSION "4.0") (DIVIDER .) (VOLTAGE ) (PROCESS "") (TEMPERATURE ) (TIMESCALE 1 ns) (CELL (CELLTYPE "sub") (INSTANCE *) (DELAY (ABSOLUTE (IOPATH i1 o1 (10:11:12)(13:14:15)(16:17:18)(19:20:21)(22:23:24)(25:26:2 7)) (COND (i2==1) (IOPATH i2 o2 (10:11:12)(13:14:15)(16:17:18)(19:20:21)(22:23:24)(25:26:2 7))) )) ) ) SDF Configuration File: sdf.cfg PATHPULSE=IGNORE; INTERCONNECT_MIPD=MAXIMUM; MTM=TOOL_CONTROL; SCALE_FACTORS=100:0:9; SCALE_TYPE=FROM_MTM; MTM = TYPICAL; SCALE_TYPE=FROM_MINIMUM; SCALE_FACTORS=1.1:2.1:3.1;
At time 0, a pulse three time units wide begins on the input port. This pulse is narrower than the module path delay of seven time units, but this pulse propagates through the module and appears on the output
port after seven time units. Similarly, another narrow pulse begins on the input port at time 3 and it also appears on the output port seven time units later. You can apply transport delays on all module path delays and all SDF INTERCONNECT delays back-annotated to a net from an SDF file. For more information on SDF back-annotation, see SDF Annotation . Inertial delays, in contrast, filter out all pulses that are narrower than the delay. Figure 9-2 shows the waveforms for the same input and output ports when you have not enabled transport delays for module path delays. Figure 9-2 Inertial Delay Waveforms
The pulse that begins at time 0 that is three time units wide does not propagate to the output port because it is narrower than the seven time unit module path delay. Neither does the narrow pulse that begins at time 3. Note that the wide pulse that begins at time 6 does propagate to the output port. Gates, switches, MIPDs, and continuous assignments only have inertial delays, which are the default type of delay for module path delays and INTERCONNECT delays back-annotated from an SDF file to a net.
Figure 9-3
In the example illustrated in Figure 9-3, the following occurs: 1. At time 3 the input terminal changes to 0. This is the leading edge of a three time unit wide pulse. This event schedules a value change to 0 on the output terminal at time 8 because there is a #5 delay specification for the gate. 2. At time 6 the input terminal toggles to 1. This implementation keeps the scheduled transition on the output terminal at time 8 but alters the value change to a value of 1. 3. At time 8 the output terminal transitions to 1. This transition might be unexpected because all pulses on the input have been narrower than the delay, but this is how this implementation works. There is now no event scheduled on the output and a new event can now be scheduled. 4. At time 9 the input terminal toggles to 0 and the implementation schedules a transition of the output to 0 at time 14. 5. At time 12 the input terminal toggles to 1 and the value change scheduled on the output at time 14 changes to a 1. 6. At time 14 the output is already 1 so there is no value change. The narrow pulse on the input between time 9 and 12 is filtered out. This implementation was devised for these narrow pulses. There is now no event scheduled for the output.
7. At time 15 the input toggles to 0 and this schedules the output to toggle to 0 at time 20. Inertial Delays for Module Path Delays and INTERCONNECT Delays The implementation of inertial delays for module path delays and SDF INTERCONNECT delays is as follows: if the event scheduled by the leading edge of a pulse is scheduled for a later simulation time, or in other words, has not yet occurred, then the event scheduled by the trailing edge at the end of the specified delay and at a new simulation time, replaces the event scheduled by the leading edge. All narrow pulses are filtered out. Note: - SDF INTERCONNECT delays follow this implementation if you include the +multisource_int_delays compile-time option. If you do not include this option, VCS uses an MIPD to model the SDF INTERCONNECT delay and the delay uses the inertial delay implementation for MIPDs. - VCS enables more complex and flexible pulse control processing when you include the +pulse_e/number and +pulse_r/number options. See Pulse Control on page 22.
You can specify transport delays on a net to which you backannotate SDF INTERCONNECT delays with the +transport_int_delays compile-time option. For this option to work, you must also include the +pulse_int_e/number and +pulse_int_r/number compile-time options. See Pulse Control on page 22. The +pulse_e/number, +pulse_r/number, +pulse_int_e/ number, and +pulse_int_r/number options define specific thresholds for pulse width, which allow you to tell VCS to filter out only some of the pulses and let the other pulses through. See Pulse Control on page 22.
Pulse Control
So far weve seen that with pulses narrower than a module path or INTERCONNECT delay, you have the option of filtering all of them out by using the default inertial delay or allowing all of them to propagate through, by specifying transport delays. VCS also provides a third option - pulse control. With pulse control you can: Allow pulses that are slightly narrower than the delay to propagate through. Have VCS replace even narrower pulses with an X value pulse on the output and display a warning message. Have VCS then filter out and ignore pulses that are even narrower that the ones for which it propagates an X value pulse and displays an error message.
You specify pulse control with the +pulse_e/number and +pulse_r/number compile-time options for module path delays and the +pulse_int_e/number and +pulse_int_r/number compile-time options for INTERCONNECT delays. The +pulse_e/number options number argument specifies a percentage of the module path delay. VCS replaces pulses whose widths that are narrower than the specified percentage of the delay with an X value pulse on the output or inout port and displays a warning message. Similarly, the +pulse_int_e/number options number argument specifies a percentage of the INTERCONNECT delay. VCS replaces pulses whose widths are narrower than the specified percentage of the delay with an X value pulse on the inout or output port instance that is the load of the net to which you back-annotated the INTERCONNECT delay. It also displays a warning message. The +pulse_r/number options number argument also specifies a percentage of the module path delay. VCS filters out the pulses whose widths are narrower than the specified percentage of the delay. With these pulses there is no warning message; VCS simply ignores these pulses. Similarly, the +pulse_int_r/number options number argument specifies a percentage of the INTERCONNECT delay. VCS filters out pulses whose widths are narrower than the specified percentage of the delay. There is no warning message with these pulses. You can use pulse control with transport delays (see Pulse Control with Transport Delays on page 24) or inertial delays (see Pulse Control with Inertial Delays on page 26).
When a pulse is narrow enough for VCS to display a warning message and propagate an X value pulse, you can set VCS to do one of the following: Place the starting edge of the X value pulse on the output, as soon as it detects that the pulse is sufficiently narrow, by including the +pulse_on_detect compile-time option. Place the starting edge on the output at the time when the rising or falling edge of the narrow pulse would have propagated to the output. This is the default behavior.
See Specifying Pulse on Event or Detect Behavior on page 31. Also when a pulse is sufficiently narrow to display a warning message and propagate an X value pulse, you can have VCS propagate the X value pulse but disable the display of the warning message with the +no_pulse_msg runtime option.
(and display a warning message) and filter out pulses that are narrower than 50% of the delay, enter the +pulse_e/80 and +pulse_r/50 or +pulse_int_e/80 and +pulse_int_r/50 compile-time options. Figure 9-4 shows the waveforms for the input and output ports for an instance of a module that models a buffer with a ten time unit module path delay. The vcs command line contains the following compile-time options:
+transport_path_delays +pulse_e/80 +pulse_r/50
Figure 9-4
In the example illustrated in Figure 9-4 the following occurs: 1. At time 20, the input port toggles to 1. 2. At time 29, the input port toggles to 0 ending a nine time unit wide value 1 pulse on the input port. 3. At time 30, the output port toggles to 1. The nine time unit wide value 1 pulse that began at time 20 on the input port is propagating to the output port because we have enabled transport delays and nine time units is more than 80% of the ten time unit module path delay.
4. At time 39, the input port toggles to 1 ending a ten time unit wide value 0 pulse. Also, at time 39 the output port toggles to 0. The ten time unit wide value 0 pulse that began at time 29 on the input port is propagating to the output port. 5. At time 46, the input port toggles to 0 ending a seven time unit wide value 1 pulse. 6. At time 49, the output port transitions to X. The seven time unit wide value 1 pulse that began at time 39 on the input port has propagated to the output port, but VCS has replaced it with an X value pulse because seven time units is less than 80% of the module path delay. VCS issues a warning message in this case. 7. At time 56, the input port toggles to 1 ending a ten time unit wide value 0 pulse. Also, at time 56, the output port toggles to 0. The ten time unit wide value 0 pulse that began at time 46 on the input port is propagating to the output port. 8. At time 60, the input port toggles to 0 ending a four time unit wide value 1 pulse. Four time units is less than 50% of the module path delay, therefore, VCS filters out this pulse and no indication of it appears on the output port.
There is a special implementation of inertial delays with pulse control for module path delays and INTERCONNECT delays. In this implementation, value changes on the input can schedule two events on the output. The first of these two scheduled events always causes a change on the output. The type of value change on the output is determined by the following: If the first event is scheduled by the leading edge of a pulse whose width is equal to or wider than the percentage specified by the +pulse_e/number option, the value change on the input propagates to the output. If the pulse is not wider than the percentage specified by the +pulse_e/number option, but is wider that the percentage specified by the +pulse_r/number option, the value change is replaced by an X value. If the pulse is not wider than the percentage specified by the +pulse_r/number option, the pulse is filtered out.
The second scheduled event is always tentative. If another event occurs on the input before the first event occurs on the output, that additional event on the input cancels the second scheduled event and schedules a new second event. Figure 9-5 shows the waveforms for the input and output ports for an instance of a module that models a buffer with a ten time unit module path delay. The vcs command line contains the following compile-time options:
+pulse_e/0 +pulse_r/0
In this example, specifying 0 percentages means that the trailing edge of all pulses can change the second scheduled event on the output. Specifying 0 does not mean that all pulses propagate to the output because this implementation has its own way of filtering out short pulses. Figure 9-5 Pulse Control with Inertial Delays
In the example illustrated in Figure 9-5 the following occurs: 1. At time 20, the input port transitions to 0. This schedules a transition to 0 on the output port at time 30, ten time units later as specified by the module path delay. This is the first scheduled event on the output port. This event is not tentative, it will occur. 2. At time 23, the input port toggles to 1. This schedules a transition to 1 on the output port at time 33. This is the second scheduled event on the output port. This event is tentative. 3. At time 26, the input port toggles to 0. This cancels the current scheduled second event and replaces it by scheduling a transition to 0 at time 36. The first scheduled event is a transition to 0 at time 30 so the new second scheduled event isnt really a transition on the output port. This is how this implementation filters out narrow pulses. 4. At time 29, the input port toggles to 1. This cancels the current scheduled second event and replaces it by scheduling a transition to 1 at time 39.
5. At time 30, the output port transitions to 0. The second scheduled event on the output becomes the first scheduled event and is therefore no longer tentative. 6. At time 39, the output port toggles to 1. Typically, however, you will want to specify that VCS replace or reject certain narrow pulses. Figure 9-6 shows the waveforms for the input and output ports for an instance of the same module with a ten time unit module path delay. The vcs command line contains the following compile-time options: +pulse_e/60 +pulse_r/40 Figure 9-6 Pulse Control with Inertial Delays and a Narrow Pulses
In the example illustrated in Figure 9-6 the following occurs: 1. At simulation time 20, the input port transitions to 0. This schedules the first event on the output port, a transition to 0 at time 30. 2. At simulation time 30, the input port toggles to 1. This schedules the output port to toggle to 1 at time 40. Also, at simulation time 30, the output port transitions to 0. It doesnt matter which of these events happened first. At the end of this time there is only one scheduled event on the output.
3. At simulation time 36, the input port toggles to 0. This is the trailing edge of a six time unit wide value 1 pulse. The pulse is equal to the width specified with the +pulse_e/60 option so VCS schedules a second event on the output, a value change to 0 on the output at time 46. 4. At simulation time 40, the output toggles to 1 so now there is only one event scheduled on the output, the value change to 0 at time 46. 5. At simulation time 46, the input toggles to 1 scheduling a transition to 1 at time 56 on the output. Also at time 46, the output toggles to 0. There is now only one event scheduled on the output. 6. At time 50, input port toggles to 0. This is the trailing edge of a four time unit wide value 1 pulse. The pulse is not equal to the width specified with the +pulse_e/60 option, but is equal to the width specified with the +pulse_r/40 option, therefore, VCS changes the first scheduled event from a change to 1 to a change to X at time 56 and schedules a second event on the output, a transition to 0 at time 60. 7. At time 56, the output transitions to X and VCS issues a warning message. 8. At time 60, the output transitions to 0. Pulse control sometimes blurs the distinction between inertial and transport delays. In this example, the results would have been the same if you also included the +transport_path_delays option.
In this example, you include the +pulse_e/100 and +pulse_r/0 options. The scheduling problem is that the leading edge of the pulse on the input, at time 10, schedules a transition to 0 on the output at time 16; but the trailing edge, at time 11, schedules a transition to 1 on the output at time 15. Obviously, the output has to end up with a value of 1 so VCS cant allow the events scheduled at time 15 and 16 to occur in sequence; if it did, the output would end up with a value of 0. This problem persists when you enable transport delays and whenever the percentage specified in the +pulse_r/number option is low enough to enable the pulse to propagate through the module.
To circumvent this problem, when a later event on the input schedules an event on the output that is earlier than the event scheduled by the previous event on the input, VCS cancels both events on the output. This ensures that the output ends up with the proper value, but what it doesnt do is indicate that something happened on the output between times 15 and 16. You might want to see an error message and an X value pulse on the output indicating there was an undefined event on the output between these simulation times. You see this message and the X value pulse if you include the +pulse_on_event compile-time option, specifying pulse on event behavior, as illustrated in Figure 9-8. Pulse on event behavior calls for an X value pulse on the output after the delay and when there are asymmetrical delays scheduling events on the output that would be canceled by VCS , to output an X value pulse between those events instead. Figure 9-8 Using +pulse_on_event
In most cases where the +pulse_e/number and +pulse_r/ number options already create X value pulses on the output, also including the +pulse_on_event option to specify pulse on event behavior will make no change on the output. Pulse on detect behavior, specified by the +pulse_on_detect compile-time option, displays the leading edge of the X value pulse on the output as soon as events on the input, controlled by the
+pulse_e/number and +pulse_r/number options, schedule an X value pulse to appear on the output. Pulse on detect behavior differs from pulse on event behavior in that it calls for the X value pulse to begin before the delay elapses. Figure 9-9 illustrates pulse on detect behavior. Figure 9-9 Using +pulse_on_detect
In this example, by including the +pulse_on_detect option, VCS causes the leading edge of the X value pulse on the output to begin at time 11 because of an unusual event that occurred on the output between times 15 and 16 because of the rise at simulation time 11. Using pulse on detect behavior can also show you when VCS has scheduled multiple events for the same simulation time on the output by starting the leading edge of an X value pulse on the output as soon as VCS has scheduled the second event. For example, a module that models a buffer has a rise time module path delay of 10 time units and a fall time module path delay of 4 time units. Figure 9-10 shows the waveforms for the input and output port when you include the +pulse_on_detect option.
In the example illustrated in Figure 9-10 the following occurs: 1. At simulation time 0 the input port transitions to 0 scheduling the first event on the output, a transition to 0 at time 4. 2. At time 4 the output transitions to 0. 3. At time 10 the input transitions to 1 scheduling a transition to 1 on the output at time 20. 4. At time 16 the input toggles to 0 scheduling a second event on the output at time 20, a transition to 0. This event also is the trailing edge of a six time unit wide value 1 pulse so the first event changes to a transition to X. There is more than one event for different value changes on the output at time 20, so VCS begins the leading edge of the X value pulse on the output at this time. 5. At time 20 the output toggles to 0, the second scheduled event at this time. If you did not include the +pulse_on_detect option, or substituted the +pulse_on_event option, you would not see the X value pulse on the output between times 16 and 20. Pulse on detect behavior does not just show you when asymmetrical delays schedule multiple events on the output. Other kinds of events can cause multiple events on the output at the same simulation time, such as different transition times on two input ports and different
module path delays from these input ports to the output port. Pulse on detect behavior would show you an X value pulse on the output starting when the second event was scheduled on the output port.
timescale 1 ns / 1 ns module design (out,in); output out; input in; wire int1,int2; assign #4 out=int2; buf #3 buf2 (int2,int1), buf1 (int1,in); specify (in => out) = 7; endspecify endmodule
In Example 9-1, the module path delay is seven time units, but the delay specifications distributed along that path add up to ten time units.
If you include the +delay_mode_path compile-time option, VCS ignores the delay specifications in the primitive instantiation and continuous assignment statements and uses only the module path delay. In Example 9-1, it would use the seven time unit delay for propagating signal values through the module. If you include the +delay_mode_distributed compile-time option, VCS ignores the module path delays and uses the delay in the delay specifications in the primitive instantiation and continuous assignment statements. In Example 9-1, it uses the ten time unit delay for propagating signal values through the module. There are other modes that you can specify: If you include the +delay_mode_unit compile-time option, VCS ignores the module path delays and changes the delay specification in all primitive instantiation and continuous assignment statements to the shortest time precision argument of all the timescale compiler directives in the source code. (The default time unit and time precision argument of the timescale compiler directive is 1 s). In Example 9-1 the timescale compiler directive has a precision argument of 1 ns. VCS might use this 1 ns as the delay, but if the module definition is used in a larger design and there is another timescale compiler directive in the source code with a finer precision argument, then VCS uses the finer precision argument. If you include the +delay_mode_zero compile-time option, VCS changes all delay specifications and module path delays to zero. If you include none of the compile-time options described in this section, when, as in Example 9-1, the module path delay does not equal the distributed delays along the path, VCS uses the longer of the two.
You enable timopt with the +timopt+clock_period compile-time option, where the argument is the shortest clock period (or clock cycle) of the clock signals in your design. For example:
+timopt+100ns
This options specifies that the shortest clock period is 100ns. timopt first displays the number of sequential devices that it finds in the design and the number of these sequential devices to which it might be able to apply optimizations. For example:
Total Sequential Elements : 2001 Total Sequential Elements 2001, Optimizable 2001
timopt then displays the percentage of identified sequential devices to which it can actually apply optimizations followed by messages about the optimization process.
TIMOPT optimized 75 percent of the design Starting TIMOPT Delay optimizations Done TIMOPT Delay Optimizations DONE TIMOPT
The next step is to simulate the design and see if the optimizations applied by timopt produce a satisfactory increase in performance. If you are not satisfied there are additional steps that you can take to get more optimizations from timopt. If timopt was able to identify all the clock signals and all the sequential devices with an absolute certainty it simply applies its optimizations. If timopt is uncertain about a number of clock signals and sequential devices then you can use the following process to maximize timopt optimizations:
1. timopt writes a configuration file named timopt.cfg in the current directory that lists the signals and sequential devices that it finds questionable. 2. You review and edit this file, validating that the signals in the file are, or are not, clock signals and that the module definitions in it are, or are not, sequential devices. If you do not need to make any changes in the file, go to step 5. If you do make changes, go to step 3. 3. Compile your design again with the +timopt+clock_period compile-time option. timopt will make the additional optimizations that it did not make, because it was unsure of the signals and sequential devices in the timopt.cfg file that it wrote during the first compilation. 4. Look at the timopt.cfg file again: - If timopt wrote no new entries for potential clock signals or sequential devices, go to step 5. - If timopt wrote new entries, but you make no changes to the new entries, go to step 5. - If you make modifications to the new entries, return to step 3. 5. timopt does not need to look for any more clock signals and it can assume that the timopt.cfg file correctly specifies clock signal and sequential devices. At this point, it just needs to apply the latest optimizations. Compile your design one more time, including the +timopt compile-time option, but without its +clock_period argument.
6. You now simulate your design using timopt optimizations. timopt monitors the simulation and makes its optimizations based on its analysis of the design and information in the timopt.cfg file. During simulation, if it finds that its assumptions are incorrect, for example the clock period for a clock signal is incorrect, or there is a port for asynchronous control on a module for a sequential device, timopt displays a warning message similar to the following:
+ Timopt Warning: for clock testbench.clockgen..clk: TimePeriod 50ns Expected 100ns
You can remove the comment marks for the module definitions that are, in fact, model sequential devices and which provide the clock port, clock polarity, and optionally asynchronous ports. A modified list might look like the following:
flop { jknpn } { CP, true};
flop { jknpc } { CP, true, CLN}; flop { tfnpc } { CP, true, CLN};
In this example, CP is the clock port and the keyword true indicates that the sequential device is triggered on the posedge of the clock port and CLN is an asynchronous port. If you uncomment any of these module definitions, then timopt might identify additional clock signals that drive these sequential devices. To enable timopt to do this: 1. Remove the clock signal entries from the timopt.cfg file. 2. Recompile the design with the same +timopt+clock_period compile-time option. timopt will write new clock signal entries in the timopt.cfg file.
These clock signals have a period of 100ns or longer. This time value comes from the +clock_period argument that you added to the +timopt compile-time option when you first compiled the design. The entry for the signal test.badClock is commented out because it connects to a small percentage of the sequential devices in the design. In this instance, it is only 1 of the 2001 sequential devices that it identified in the design. The entry for the signal
test.goodClock is not commented out because it connects to a large percentage of the sequential devices. In this instance, it is 2000 of the 2001 sequential devices in the design. If a commented out clock signal is a clock signal that you want timopt to use when it optimizes the design in a subsequent compilation, then remove the comment characters preceding the signals hierarchical name.
For example, for a design with shortest clock period of 100ns, you can supply the list of scan flops in the file scanopt.cfg using the format specified in the following section, and then use the following compile-time option. -scanopt=100ns,cfg This enables the optimizer to pick up the scan flops specified in the configuration file and use for its optimization. The optimizer also determines the length of the scan chain(s) on its own. If there are multiple scan chains, the minimal scan length is chosen for optimizations.
The section between BEGIN_FLOP and END_FLOP corresponds to one particular scan flop. The field <scan_cell_name> corresponds to the name of scan flop (scan cell). Multiple sections can be used to specify multiple scan flops. The section between BEGIN_PORT and END_PORT corresponds to ports of the scan flop. Specifying Q_PORT, D_PORT, TI_PORT, and TE_PORT are mandatory, whereas QN_PORT could be optional.
Gate-level Simulation 9-43
ScanOpt Assumptions
Combinational Path Delays By default, the optimizer assumes that the worst case delay for any combinational path in the design is not more than five times the shortest clock period and applies the optimizations. The following banner is printed at the compile time to indicate this assumption to you: ScanOpt assumes that no combinational path has worst-case delay more than 5 clock period. Please use, -scanopt=<clock_period>,cdel=<overriding_value> to override the assumed value For example, for a design with shortest clock period of 100ns, if the default value of 5 is to be overridden with a value of 10, you can use the following compile-time option. -scanopt=100ns,cdel=10 Length of Test Cycles The optimizer assumes that the simulation remains in the test mode for at least the scan chain length times the shortest clock period. Any violation of this assumption is automatically detected during the simulation, and the following error message is displayed quitting the simulation. Error: Simulation has been aborted due to fatal violation of ScanOpt assumptions. Please refer to the documentation for more details. To get around this error, please rerun simulation with -noscanopt switch
For example, if the inferred length of scan chain in the design is 5000 and the short clock period is 100ns, then the Test enable signal(s) should remain in test mode for at least 500000ns (that is, 5000 * 100ns). Note: The -noscanopt option can be used at runtime, thereby avoiding re-compilation of the design.
In this example, VCS reports the timing violation if there is a transition on signal data less that 10 time units before, or less than 11 time units after, a rising edge on signal clock. When there is a timing violation, VCS toggles a notify register, in this example, notifyreg. You could use this toggling of a notify register to output an X value from a device, such as a sequential flop, when there is a timing violation.
Figure 9-11
clock data event data setup hold limit limit violation window
10 0 11
data event
In this example, both the setup and hold limits have positive values. When this occurs, the violation window straddles the reference event. There are cases where the violation window cannot straddle the reference event at the inputs of an ASIC cell. Such a case occurs when: The data event takes longer than the reference event to propagate to a sequential device in the cell Timing must be accurate at the sequential device You need to check for timing violations at the cell boundary
It also occurs when the opposite is true, that is, when the reference event takes longer than the data event to propagate to the sequential device.
When this happens, use the $setuphold timing check in the top-level module of the cell to look for timing violations when signal values propagate to that sequential device. In this case, you need to use negative setup or hold limits in the $setuphold timing check. Figure 9-12 ASIC Cell with Long Propagation Delays on Reference Events
causes long clock data delay causes short delay clk d q
When this occurs, the violation window shifts at the cell boundary so that it no longer straddles the reference event. It shifts to the right when there are longer propagation delays on the reference event. This right shift requires a negative setup limit:
$setuphold (posedge clock, data, -10, 31, notifyreg);
data event
In this example, the $setuphold timing check is in the specify block of the top-level module of the cell. It specifies that there is a timing violation if there is a data event between 10 and 31 time units after the reference event on the cell boundary. This is giving the reference event a head start at the cell boundary, anticipating that the delays on the reference event will allow the data events to catch up at the sequential device inside the cell. Note: When you specify a negative setup limit, its value must be less than the hold limit.
Figure 9-14 ASIC Cell with Long Propagation Delays on Data Events
clock data causes short delay causes long delay clk d q
The violation window shifts to the left when there are longer propagation delays on the data event. This left shift requires a negative hold limit:
$setuphold (posedge clock, data, 31, -10, notifyreg);
Figure 9-15 illustrates this scenario. Figure 9-15 Negative Hold Limit
reference event clock data event data setup limit violation window
31 10
data event
hold limit
In this example, the $setuphold timing check is in the specify block of the top-level module of the cell. It specifies that there is a timing violation if there is a data event between 31 and 10 time units before the reference event on the cell boundary.
Gate-level Simulation 9-50
This is giving the data events a head start at the cell boundary, anticipating that the delays on the data events will allow the reference event to catch up at the sequential device inside the cell. Note: When you specify a negative hold limit, its value must be less than the setup limit. To implement negative timing checks, VCS creates delayed versions of the signals that carry the reference and data events and an alternative violation window where the window straddles the delayed reference event. You can specify the names of the delayed versions by using the extended syntax of the $setuphold system task, or by allowing VCS to name them internally. The extended syntax also allows you to specify expressions for additional conditions that must be true for a timing violation to occur.
The following additional arguments are optional: timestamp_cond This argument specifies the condition which determines whether or not VCS reports a timing violation.
In the setup phase of a $setuphold timing check, VCS records or stamps the time of a data event internally so that when a reference event occurs, it can compare the times of these events to see if there is a setup timing violation. If the condition specified by this argument is false, VCS does not record or stamp the data event so there cannot be a setup timing violation. Similarly, in the hold phase of a $setuphold timing check, VCS records or stamps the time of a reference event internally so that when a data event occurs, it can compare the times of these events to see if there is a hold timing violation. If the condition specified by this argument is false, VCS does not record or stamp the reference event so there cannot be a hold timing violation. timecheck_cond This argument specifies the condition which determines whether or not VCS reports a timing violation. In the setup phase of a $setuphold timing check, VCS compares or checks the time of the reference event with the time of the data event to see if there is a setup timing violation. If the condition specified by this argument is false, VCS does not make this comparison and so there is no setup timing violation. Similarly, in the hold phase of a $setuphold timing check, VCS compares or checks the time of a data event with the time of a reference event to see if there is a hold timing violation. If the condition specified by this argument is false, VCS does not make this comparison and so there is no hold timing violation. delayed_reference_signal The name of the delayed version of the reference signal.
delayed_data_signal The name of the delayed version of the data signal. The following example demonstrates how to use the extended syntax:
$setuphold(ref, data, -4, 10, notifr1, stampreg===1, , d_ref, d_data);
In this example, the timestamp_cond argument specifies that reg stampreg must equal 1 for VCS to stamp or record the times of data events in the setup phase or stamp the times of reference events in the hold phase. If this condition is not met, and stamping does not occur, VCS will not find timing violations no matter what the time is for these events. Also in the example, the delayed versions of the reference and data signals are named d_ref and d_data. You can use these delayed signal versions of the signals to drive sequential devices in your cell model. For example:
module DFF(D,RST,CLK,Q); input D,RST,CLK; output Q; reg notifier; DFF_UDP d2(Q,dCLK,dD,dRST,notifier); specify (D => Q) = 20; (CLK => Q) = 20; $setuphold(posedge CLK,D,-5,10,notifier,,,dCLK,dD); $setuphold(posedge CLK,RST,-8,12,notifier,,,dCLK, dRST); endspecify endmodule primitive DFF_UDP(q,clk,data,rst,notifier); output q; reg q; input data,clk,rst,notifier;
q 0 1 0 x ; ; ; ; ; ;
In this example, the DFF_UDP user-defined primitive is driven by the delayed signals dClk, dD, dRST, and the notifier reg.
reference_event Typically the reference event is the active edge on a control signal, such as a clear signal. Specify the active edge with the posedge or negedge keyword. data_event Typically, the data event occurs on a clock signal. Specify the active edge on this signal with the posedge or negedge keyword. recovery_limit Specifies how much time must elapse after a control signal, such as a clear signal toggles from its active state (the reference event), before there is an active clock edge (the data event). removal_limit Specifies how much time must elapse after an active clock edge (the data event), before the control signal can toggle from its active state (the reference event). notifier A register whose value VCS toggles when there is a timing violation.
timestamp_cond This argument specifies the condition which determines whether or not VCS reports a timing violation. In the recovery phase of a $recrem timing check, VCS records or stamps the time of a reference event internally so that when a data event occurs it can compare the times of these events to see if there is a recovery timing violation. If the condition specified by this argument is false, VCS does not record or stamp the reference event so there cannot be a recovery timing violation. Similarly, in the removal phase of a $recrem timing check, VCS records or stamps the time of a data event internally so that when a reference event occurs, it can compare the times of these events to see if there is a removal timing violation. If the condition specified by this argument is false, VCS does not record or stamp the data event so there cannot be a removal timing violation. timecheck_cond This argument specifies the condition which determines whether or not VCS reports a timing violation. In the recovery phase of a $recrem timing check, VCS compares or checks the time of the data event with the time of the reference event to see if there is a recovery timing violation. If the condition specified by this argument is false, VCS does not make this comparison and so there is no recovery timing violation.
Similarly, in the removal phase of a $recrem timing check, VCS compares or checks the time of a reference event with the time of a data event to see if there is a removal timing violation. If the condition specified by this argument is false, VCS does not make this comparison and so there is no removal timing violation. delayed_reference_signal The name of the delayed version of the reference signal, typically a control signal. delayed_data_signal The name of the delayed version of the data signal, typically a clock signal.
If you include the +neg_tchk compile-time option but also include the +notimingcheck or +nospecify compile-time options, VCS does not compile the $setuphold and $recrem timing checks into the simv executable. However, it does create the signals that you specified in the delayed_reference_signal and delayed_data_signal arguments, and you can use these to drive sequential devices in the cell. Note that there is no delay on these "delayed" arguments and they have the same transition times as the signals specified in the reference_event and data_event arguments. Similarly, if you include the +neg_tchk compile-time option and then include the +notimingcheck runtime option instead of the compile-time option, you disable the $setuphold and $recrem timing checks that VCS compiled into the executable. At compile time, VCS creates the signals that you specified in the delayed_reference_signal and delayed_data_signal arguments, and you can use them to drive sequential devices in the cell, but the +notimingcheck runtime option disables the delay on these delayed versions.
Example 9-2
`timescale 1ns/1ns module top; reg clk, d; reg rst; wire q; dff dff1(q, clk, d, rst); initial begin $monitor($time,,clk,,d,,q); rst = 0; clk = 0; d = 0; #100 clk = 1; #100 clk = 0; #10 d = 1; #90 clk = 1; #1 clk = 0; // width violation #100 $finish; end endmodule module dff(q, clk, d, rst); output q; input clk, d, rst; reg notif; DFF_UDP(q, d_clk, d_d, d_rst, notif); specify $setuphold(posedge clk, d, -10, 20, notif, , , d_clk, d_d); $setuphold(posedge clk, rst, 10, 10, notif, , , d_clk, d_rst); $width(posedge clk, 5, 0, notif); endspecify endmodule
primitive DFF_UDP(q,data,clk,rst,notifier); output q; reg q; input data,clk,rst,notifier; table // clock data rst notifier state q // -----------------------------r 0 0 ? : ? : 0 r 1 0 ? : ? : 1 f ? 0 ? : ? : ? ? r ? : ? : 0 ? * ? ? : ? : ? ? ? * : ? : x endtable endprimitive
; ; ; ; ; ;
In this example, if you include the +neg_tchk compile-time option, the $width timing check uses the delayed version of signal clk, named d_clk, and the following sequence of events occurs: 1. At time 311, the delayed version of the clock transitions to 1, causing output q to toggle to 1. 2. At time 312, the narrow pulse on the clock causes a width violation:
"test1.v", 31: Timing violation in top.dff1 $width( posedge clk:300, : 301, limit: 5);
The timing violation message looks like it occurs at time 301, but you do not see it until time 312. 3. Also at time 312, reg notif toggles from X to 1. This changes output q from 1 to X. There are no subsequent changes on output q.
If you include both the +neg_tchk and +old_ntc compile-time options, the $width timing check does not use the delayed version of signal clk, causing the following sequence of events to occur: 1. At time 301, the narrow pulse on signal clk causes a width violation:
"test1.v", 31: Timing violation in top.dff1 $width( posedge clk:300, : 301, limit: 5);
2. Also at time 301, the notifier reg named notif toggles from X to 1. In turn, this changes the output q of the user-defined primitive DFF_UDP and module instance dff1 from 0 to X. 3. At time 311, the delayed version of signal clk, named d_clk, reaches the user-defined primitive DFF_UDP, thereby changing the output q to 1, erasing the X value on this output.
Figure 9-17 Other Timing Checks Not Using the Delayed Versions
The timing violation, as represented by the X value, is lost to the design. If a module path delay that is greater than ten time units was used for the module instance, the X value would not appear on the output at all. For this reason, Synopsys does not recommend using the +old_ntc compile-time option. It exists only for unforeseen circumstances.
Checking Conditions
VCS evaluates the expressions in the timestamp_cond and timecheck_cond arguments either when there is a value change on the original reference and data signals at the cell boundary, or when the value changes propagate from the delayed versions of these signals at the sequential device inside the cell. It decides when to evaluate the expressions depending on which signals are the operands in these expressions. Note the following:
If the operands in these expressions are neither the original nor the delayed versions of the reference or data signals, and if these operands are signals that do not change value between value changes on the original reference and data signals and their delayed versions, then it does not matter when VCS evaluates these expressions. If the operands in these expressions are delayed versions of the original reference and data signals, then you want VCS to evaluate these expressions when there are value changes on the delayed versions of the reference and data signals. VCS does this by default. If the operands in these expressions are the original reference and data signals and not the delayed versions, then you want VCS to evaluate these expressions when there are value changes on the original reference and data signals. To specify evaluating these expressions when the original reference and data signals change value, include the +NTC2 compile-time option.
VCS does not change the value of the notifier register if you have assigned a Z value to it.
As documented in the OVI SDF3.0 specification: TIMINGCHECK statements in the SDF file back-annotate timing checks in the model which match the edge and condition arguments in the SDF statement. If the SDF statement specifies SCOND or CCOND expressions, they must match the corresponding timestamp_cond or timecheck_cond in the timing check declaration for backannotation to occur. If there is no SCOND or CCOND expressions in the SDF statement, all timing checks that otherwise match are back-annotated.
This specifies that the propagation delays on the reference event (a rising edge on signal clock), are more than 10 but less than 20 time units more than the propagation delays on the data event (any transition on signal data). So when VCS creates the delayed signals, del_clock and del_data, and the alternative violation window that straddles a rising edge on del_clock, VCS uses the following relationship:
20 > (delay on del_clock - delay on del_data) > 10
There is no reason to make the delays on either of these delayed signals any longer than they have to be so the delay on del_data is 0 and the delay on del_clock is 11. Any delay on del_clock between 11 and 19 time units would report a timing violation for the $setuphold timing check.
Multiple timing checks, that share reference or data events, and specified delayed signal names, can define a set of delay relationships. For example:
$setuphold(posedge del_CP, $setuphold(posedge del_CP, $setuphold(posedge del_CP, CP,D,-10,20, notifier, , , del_D); CP,TI,20,-10, notifier, , , del_TI); CP,TE,-4,8, notifier, , , del_TE);
In this example: The first $setuphold timing check specifies the delay on del_CP is more than 10 but less than 20 time units more than the delay on del_D. The second $setuphold timing check specifies the delay on del_TI is more than 10 but less than 20 time units more than the delay on del_CP. The third $setuphold timing check specifies the delay on del_CP is more than 4 but less than 8 time units more than the delay on del_TE.
Therefore: The delay on del_D is 0 because its delay does not have to be more than any other delayed signal. The delay on del_CP is 11 because it must be more than 10 time units more than the 0 delay on del_D.
The delay on del_TE is 4 because the delay on del_CP is 11. The 11 makes the possible delay on del_TE larger than 3, but less than 7. The delay cannot be 3 or less, because the delay on del_CP is less than 8 time units more that the delay on del_TE. VCS makes the delay 4 because it always uses the shortest possible delay. The delay on del_TI is 22 because it must be more than 10 time units more that the 11 delay on del_CP.
In unusual and rare circumstances, multiple $setuphold and $recrem timing checks, including those that have no negative limits, can make the delays on the delayed versions of these signals mutually exclusive. When this happens, VCS repeats the following procedure until the signals are no longer mutually exclusive: 1. Sets one negative limit to 0. 2. Recalculates the delays of the delayed signals.
When these conditions are met, the default behavior of VCS is to replace the negative delay values with zeros so that the violation windows overlap. Consider the following code example:
timescale 1ns/1ns module top; reg in1, clk; wire out1; FD1 fd1_1 ( .d(in1), .cp(clk), .q(out1) );
initial begin $sdf_annotate("overlap1.sdf"); in1 = 0; #45 in1=1; end initial begin clk=0; #50 clk = 1; #50 clk = 0; end endmodule module FD1 (d, cp, q); input d, cp; output q; wire q; reg notifier; reg q_reg; always @(posedge cp) q_reg = d; assign q = q_reg; specify $setuphold( posedge cp, negedge d, 40, 30, notifier); $setuphold( posedge cp, posedge d, 20, 10, notifier); endspecify endmodule
The SDF file contains the following to back-annotate negative delay values:
(CELL (CELLTYPE "FD1") (INSTANCE top.fd1_1) (TIMINGCHECK (SETUPHOLD (negedge d) (posedge cp) (40) (-30)) (SETUPHOLD (posedge d) (posedge cp) (20) (-10)) ) )
The violation windows and the transitions that occur on signals top.fd1_1.cp and top.fd1_1.d are shown in Figure 9-18.
data event
hold limit
30 20
20 30
10 40
5 45
0 50
The $setuphold timing checks now specify: A violation window for a falling edge on signal d between 40 and 30 time units before a rising edge on signal cp A violation window for a rising edge on signal d between 20 and 10 time units before a rising edge on signal cp
The testbench module top applies stimulus so that the following transitions occur: 1. A rising edge on signal d at time 45 2. A rising edge on signal cp at time 50
The rising edge on signal d at time 45 is not inside the violation window for a rising edge on signal d. If you include the +overlap compile-time option, you will not see a timing violation. This behavior is desired because there is no transition in the violation windows so VCS should not display a timing violation. The +overlap option tells VCS not to change the violation windows, just like it would if the windows overlapped. If you omit the +overlap option, VCS does what Verilog simulators traditionally do, which is both pessimistic and inaccurate: 1. During compilation, VCS replaces the -30 and -10 negative delay values in the $setuphold timing checks with 0 values. It displays the following warning:
Warning: Negative Timing Check delays did not converge, Setting minimum constraint to zero and using approximation solution ( "sourcefile",line_number_of__second_timing_check)
VCS alters the violation windows: - For the falling edge, the window starts 40 time units before the reference event and ends at the reference event. - For the rising edge, the window starts 20 time units before the reference event and also ends at the reference event. VCS alters the windows so that they overlap or converge. 2. During simulation, at time 50 (reference event), VCS displays the timing violation message:
"sourcefile.v", line_number_of_second_timing_check: Timing violation in top.fd1_1 $setuphold( posedge cp:50 posedge d:45, limits (20,0) );
The rising edge on signal d is in the altered violation window for a rising edge on d that starts 20 time units before the reference event and now ends at the reference event. The rising edge on signal d occurs five time units before the reference event.
10
Coverage 1
VCS monitors the execution of the HDL code during simulation. The verification engineers can determine which part of the code has not been tested yet so that they can focus their efforts on those areas to achieve 100% coverage. VCS offers two coverage techniques to test your HDL code. Code coverage and Functional coverage.
Code Coverage
The following coverage metrics are classified as code coverage: Line Coverage This metric measures statements in your HDL code that have been executed in the simulation.
Coverage 10-1
Toggle Coverage This metric measures the bits of logic that have toggled during simulation. A toggle simply means that a bit changes from 0 to 1 or from 1 to 0. It is one of the oldest metrics of coverage in hardware design and can be used at both the register transfer level (RTL) and gate level. Condition Coverage This metric measures how the variables or sub-expressions in the conditional statements are evaluated during simulation. It can find the errors in the conditional statements that cannot be found by other coverage analysis. Branch Coverage This metric measures the coverage of expressions and case statements that affect the control flow (such as the if-statement and while-statement) of the HDL. It focuses on the decision points that affect the control flow of the HDL execution. FSM Coverage This metric verifies that every legal state of the state machine has been visited and that every transition between states has been covered.
For more information about coverage technology and how you can generate the coverage information for your design, click the link Coverage Technology User Guide if you are using the VCS Online Documentation. If you are using the PDF interface, click this link cov_ug.pdf to view the Coverage Technology User Guide PDF documentation.
Functional Coverage
Functional coverage checks the overall functionality of the implementation. To perform functional coverage, you must define the coverage points for the functions to be covered in the DUT. VCS
Coverage 10-2
supports both NTB and SystemVerilog covergroup model. Covergroups are specified by the user. They allow the system to monitor values and transitions for variables and signals. They also enable cross coverage between variables and signals. For more information about NTB or SystemVerilog functional coverage models, see the VCS Native Testbench Language Reference Manual or the VCS SystemVerilog Language Reference Manual respectively in the Testbench category in the VCS Online Documentation.
Coverage 10-3
Compile for branch coverage assert Compile for SystemVerilog assertion coverage. For more information on Coverage options, click the link Coverage Technology Reference Manual if you are using the VCS Online Documentation. If you are using the PDF interface, click the link cov_ref.pdf to view the Coverage Technology Reference Manual PDF documentation.
Coverage 10-4
11
Using OpenVera Native Testbench
OpenVera Native Testbench is a high-performance, single-kernel technology in VCS that enables: Native compilation of testbenches written in OpenVera and in SystemVerilog. Simulation of these testbenches along with the designs.
This technology provides a unified design and verification environment in VCS for significantly improving overall design and verification productivity. Native Testbench is uniquely geared towards efficiently catching hard-to-find bugs early in the design cycle, enabling not only completing functional validation of designs with the desired degree of confidence, but also achieving this goal in the shortest time possible.
Native Testbench is built around the preferred methodology of keeping the testbench and its development separate from the design. This approach facilitates development, debug, maintenance and reusability of the testbench, as well as ensuring a smooth synthesis flow for your design by keeping it clean of all testbench code. Further, you have the choice of either compiling your testbench along with your design or separate from it. The latter choice not only saves you from unnecessary recompilations of your design, it also enables you to develop and maintain multiple testbenches for your design. This chapter describes the high-level, object-oriented verification language of OpenVera, which enables you to write your testbench in a straightforward, elegant and clear manner and at a high level essential for a better understanding of and control over the design validation process. Further, OpenVera assimilates and extends the best features found in C++ and Java along with syntax that is a natural extension of the hardware description languages. Adopting and using OpenVera, therefore, means a disciplined and systematic testbench structure that is easy to develop, debug, understand, maintain and reuse. Thus, the high-performance of Native Testbench technology, together with the unique combination of the features and strengths of OpenVera, can yield a dramatic improvement in your productivity, especially when your designs become very large and complex. This chapter includes the following topics: Usage Model Key Features
Usage Model
As any other VCS applications, the usage model to simulate OpenVera testbench includes the following steps: Compilation
% vcs [ntb_options] [compile_options] file3.v file4.v file1.vr file2.vr
Simulation
% simv [run_options]
Example
In this example, we have an interface file, a Verilog design arb.v, OpenVera testbench arb.vr, all instantiated in a Verilog top file, arb.test_top.v.
//Interface #ifndef INC_ARB_IF_VRH #define INC_ARB_IF_VRH interface arb { input clk CLOCK; output [1:0] output input [1:0] grant } // end of interface #endif //Verilog module: arb.v module arb ( clk, reset, request, grant) ; input [1:0] request ;
output [1:0] grant ; input reset ; input clk ; parameter IDLE = 2, GRANT0 = 0, GRANT1 = 1; reg last_winner ; reg winner ; reg [1:0] grant ; reg [1:0] next_grant ; reg [1:0] state, nxState; ... endmodule //OpenVera Testbench: arb.vr #define OUTPUT_EDGE PHOLD #define OUTPUT_SKEW #1 #define INPUT_SKEW #-1 #define INPUT_EDGE PSAMPLE #include <vera_defines.vrh>
#include "arb.if.vrh" program arb_test { // start of top block ... } // end of program arb_test
Note: You can find the complete example in the following path:
$VCS_HOME/doc/examples/testbench/ov/Tutorial/ arb
Usage Model
Compilation
% vcs -ntb arb.v arb.vr arb.test_top.v
Simulation
% simv
Name of the design file. -c Specifies the clock input of the design.
-template Can be omitted. -program Optional. Use it to specify program name. -simcycle Optional. Use this to override the default cycle value of 100. -vcs vcs_compile-time_options Optional. Use it to supply a VCS compile-time option. Multiple -vcs vcs_compile-time_options options can be used to specify multiple options. Use this option only for Verilog on top designs.
Example
An example SRAM model is used in this demonstration of using the template generator to develop a testbench environment. For details on the OpenVera verification language, refer to the OpenVera Language Reference Manual: Native Testbench. Design Description The design is an SRAM whose RTL Verilog model is in the file sram.v. It has four ports: - ce_N (chip enable) - rdWr_N (read/write enable) - ramAddr (address) - ramData (data)
Using OpenVera Native Testbench 11-6
During a read operation, when ce_N is driven low and rdWr_N is driven high, ramData is continuously driven from inside the SRAM with the value stored in the SRAM memory element specified by ramAddr. During a write operation, when both ce_N and rdWr_N are driven low, the value driven on ramData from outside the SRAM is stored in the SRAM memory element specified by ramAddr. At all other times, ce_N is driven high, and as a result, ramData gets continuously driven from inside the SRAM with the high-impedance value Z. Generating the Testbench Template, the Interface, and the Toplevel Verilog Module from the Design As previously mentioned, Native Testbench provides a template generator to start the process of constructing a testbench. The template generator is invoked on sram.v as shown below:
% ntb_template -t sram sram.v
Where: The t option is followed with the top-level design module name, which is sram, in this case. sram is the name of the module. sram.v is the name of the file containing the top-level design module. If the design uses a clock input, then the c option is to be used and followed with the name of the clock input. Doing so provides a clock input derived from the system-clock for the interface and the design. In this example, there is no clock input required by the design.
Template generator generates the following files: sram.vr.tmp sram.if.vrh sram.test_top.v sram.vr.tmp This is the template for testbench development. The following is an example, based on the sram.v file of the output of the previous command line:
//sram.vr.tmp #define OUTPUT_EDGE PHOLD #define OUTPUT_SKEW #1 #define INPUT_SKEW #-1 #define INPUT_EDGE PSAMPLE #include <vera_defines.vrh> // define interfaces, and verilog_node here if necessary
#include "sram.if.vrh" // define ports, binds here if necessary // declare external tasks/classes/functions here if //necessary // declare verilog_tasks here if necessary // declare class typedefs here if necessary program sram_test { // start of top block // define global variables here if necessary // Start of sram_test // Type your test program here: // // Example of drive: // @1 sram.ce_N = 0 ; // // // Example of expect: // @1,100 sram.example_output == 0 ; // } // end of program sram_test
sram.if.vrh This is the interface file which provides the basic connectivity between your testbench signals and your designs ports and/or internal nodes. All signals going back and forth between the
testbench and the design go through this interface. The following is the sram.if.vrh file which results from the previous command line:
//sram.if.vrh #ifndef INC_SRAM_IF_VRH #define INC_SRAM_IF_VRH interface sram { output ce_N output rdWr_N output [5:0] ramAddr inout [7:0] ramData OUTPUT_EDGE OUTPUT_SKEW; } // end of interface sram #endif
Notice that, for example, the direction of ce_N is now "output" instead of "input". The signal direction specified in the interface is from the point of view of the testbench and not the DUT. This file must be modified to include the clock input. sram.test_top.v This is the top-level Verilog module that contains the testbench instance, the design instance, and the system-clock. The system clock can also provide the clock input for both the interface and the design. The following is the sram.test_top.v file that results from the previous command line:
//sram.test_top.v module sram_test_top; parameter simulation_cycle = 100; reg wire SystemClock; ce_N;
wire rdWr_N; wire [5:0] ramAddr; wire [7:0] ramData; `ifdef SYNOPSYS_NTB sram_test vshell( .SystemClock (SystemClock), .\sram.ce_N (ce_N), .\sram.rdWr_N (rdWr_N), .\sram.ramAddr (ramAddr), .\sram.ramData (ramData) ); `else vera_shell vshell( .SystemClock (SystemClock), .sram_ce_N (ce_N), .sram_rdWr_N (rdWr_N), .sram_ramAddr (ramAddr), .sram_ramData (ramData) ); `endif `ifdef emu /* DUT is in emulator, so not instantiated here */ `else sram dut( .ce_N (ce_N), .rdWr_N (rdWr_N), .ramAddr (ramAddr), .ramData (ramData) ); `endif initial begin SystemClock = 0; forever begin #(simulation_cycle/2) SystemClock = ~SystemClock; end end endmodule
Figure 11-1 shows how the three generated files and the design connect and fit in with each other in the final configuration. Figure 11-1 Testbench and Design Configuration
Testbench Development and Description Your generated testbench template, sram.vr.tmp, contains a list of macro definitions for the interface, include statements for the interface file and the library containing predefined tasks and functions, comments indicating where to define or declare the various parts of the testbench, and the skeleton program shell that will contain the main testbench constructs. Starting with this template, you can develop a testbench for the SRAM and rename it sram.vr. An example testbench is shown in Example 11-2. Example 11-2 Example testbench for SRAM, sram.vr
// macro definitions for Interface signal types and skews
// // // //
// include the library of predefined // functions and tasks // include the Interface file // start of program sram_test declare, initialize address (for driving ramAddr during Write and Read) declare rand_bits (for driving ramData during Write) declare data_result (for receiving ramData during Read)
reg [5:0] address = 6'b00_0001; // // // reg [7:0] rand_bits; // // reg [7:0] data_result; // // @(posedge sram.clk); rand_bits = random();
// move to the first posedge of clock // initialize rand_bits with a random // value using the random() function // // // // // // // // move to the next posedge of clock, drive ramAddr with the value of address disable SRAM by driving ce_N high drive ramData with rand_bits and keep it ready for a Write drive rdWr_N low and keep it ready for a Write
@1 sram.ramAddr = address;
@1 sram.ce_N = 1'b0;
// move to the next posedge of clock, // and enable a SRAM Write by driving // ce_N low printf("Cycle: %d Time: %d \n", get_cycle(), get_time(0)); printf("The SRAM is being written at ramAddr: %b Data written: %b \n", address, sram.ramData); @1 sram.ce_N = 1'b1; sram.rdWr_N = 1'b1; sram.ramData = 8'bzzzz_zzzz; // // // // // // move to the next posedge of clock, disable SRAM by driving ce_N high drive rdWr_N high and keep it ready for a Read drive a high-impedance value on ramData
@1 sram.ce_N = 1'b0;
// move to the next posedge of clock, // enable a SRAM Read by driving ce_N
// low @1 sram.ce_N = 1'b1; // move to the next posedge of clock, // disable SRAM by driving ce_N high data_result = sram.ramData; // sample ramData and receive the data // from SRAM in data_result printf("Cycle: %d Time: %d\n",get_cycle(), get_time(0)); printf("The SRAM is being read at ramAddr: %b Data read : %b \n", address, data_result); } // end of program sram_test
The main body of the testbench is the program, which is named sram_test. The program contains three data declarations of type reg in the beginning. It then moves execution through a Write operation first and then a Read operation. The memory element of the SRAM written to and read from is 6b 00_0001. The correct functioning of the SRAM implies data that is stored in a memory element during a Write operation must be the same as that which is received from the memory element during a Read operation later. The example testbench only demonstrates how any memory element can be functionally validated. For complete functional validation of the SRAM, the testbench would need further development to cover all memory elements from 6b00_0000 to 6b11_1111. Interface Description The generated if.vrh file has to be modified to include the clock input. The modified interface is shown in Example 11-3. Interface for SRAM, sram.if.vrh Example 11-3
#ifndef INC_SRAM_IF_VRH #define INC_SRAM_IF_VRH interface sram {
input clk output ce_N output rdWr_N output [5:0] ramAddr inout [7:0] ramData } // end of interface sram #endif
CLOCK; // add clock OUTPUT_EDGE OUTPUT_SKEW; OUTPUT_EDGE OUTPUT_SKEW; OUTPUT_EDGE OUTPUT_SKEW; INPUT_EDGE OUTPUT_EDGE OUTPUT_SKEW;
The interface consists of signals that are either driven as outputs into the design or sampled as inputs from the design. The clock input, clk, is derived from the system clock in the top-level Verilog module. Top-level Verilog Module Description The generated top-level module has been modified to include the clock input for the interface and eliminate code that was not relevant. The clock input is derived from the system clock. Example 11-4 shows the modified top-level Verilog module for the SRAM. Example 11-4 Top-level Verilog Module, sram.test_top.v
module sram_test_top; parameter simulation_cycle = 100; reg SystemClock; wire ce_N; wire rdWr_N; wire [5:0] ramAddr; wire [7:0] ramData; wire clk = SystemClock;/* Add this line. Interface clock input derived from the system clock*/ `ifdef SYNOPSYS_NTB sram_test vshell( .SystemClock (SystemClock), .\sram.clk(clk), .\sram.ce_N (ce_N), .\sram.rdWr_N (rdWr_N), .\sram.ramAddr (ramAddr), .\sram.ramData (ramData) ); `else
vera_shell vshell( .SystemClock (SystemClock), .sram_ce_N (ce_N), .sram_rdWr_N (rdWr_N), .sram_ramAddr (ramAddr), .sram_ramData (ramData) ); `endif // design instance sram dut( .ce_N (ce_N), .rdWr_N (rdWr_N), .ramAddr (ramAddr), .ramData (ramData) ); // system-clock generator initial begin SystemClock = 0; forever begin #(simulation_cycle/2) SystemClock = ~SystemClock; end end endmodule
The top-level Verilog module contains the following: The system clock, SystemClock. The system clock is contained in the port list of the testbench instance. The declaration of the interface clock input, clk, and its derivation from the system clock.
The testbench instance, vshell. The module name for the instance must be the name of the testbench program, sram_test. The instance name can be something you choose. The ports of the testbench instance, other than the system clock, refer to the interface signals. The period in the port names separates the interface name from the signal name. A backslash is appended to the period in each port name because periods are not normally allowed in port names. The design instance, dut.
Compiling Testbench With the Design And Running The VCS command line for compiling both your example testbench and design is the following: Compilation
% vcs -ntb sram.v sram.test_top.v sram.vr
Simulation
% simv
Key Features
VCS supports the following features for OpenVera testbench: Multiple Program Support Separate Compilation of Testbench Files Class Dependency Source File Reordering Using Encrypted Files Functional Coverage Using Reference Verification Methodology Performance Profiler
Configuration File
The configuration file contains the program construct. The program keyword is followed by the OpenVera program file (.vr file) containing the testbench program and all the OpenVera program files needed for this program. For example:
//configuration file program main1.vr main1_dep1.vr main1_dep2.vr ... main1_depN.vr [NTB_options ] program main2.vr main2_dep1.vr main2_dep2.vr ... main2_depN.vr [NTB_options ] program mainN.vr
In this example, main1.vr, main2.vr and mainN files each contain a program. The other files contain items such as definitions of functions, classes, tasks and so on needed by the program files. For example, the main1_dep1.vr, main1_dep2.vr .... main1_depN.vr files contain definitions relevant to main1.vr. Files main2_dep1.v, main2_dep2.vr ... main2_depN.vr contain definitions relevant to main2.vr, and so forth.
Specifying one OpenVera program on the command line, and the rest in the configuration file You can specify one program in the configuration file and the other program file at the command prompt.
% vcs -ntb -ntb_opts config=configfile main2.vr
In the previous example, main1.vr is specified in the configuration file and main2.vr is specified on the command line along with the files needed by main2.vr.
Any NTB options mentioned at the command prompt, in addition to the configuration file, are applicable to all OpenVera programs. In the configuration file, you may specify the NTB options in one line separated by spaces, or on multiple lines.
program file1.vr -ntb_opts no_file_by_file_pp
Some NTB options specific for OpenVera code compilation, such as -ntb_cmp and -ntb_vl, affect the VCS flow after the options are applied. If these options are specified in the configuration file, they are ignored. The following options are allowed for multiple program use. -ntb_define macro -ntb_incdir directory -ntb_opts no_file_by_file_pp -ntb_opts tb_timescale=value -ntb_opts dep_check -ntb_opts print_deps -ntb_opts use_sigprop -ntb_opts vera_portname See the appendix on Compile-time Options or Elaboration Options for descriptions of the these options.
Separate compilation of the testbench generates two files: The compiled testbench in a shared object file, libtb.so. This shared object file is the one to be loaded on simv at runtime. A Verilog shell file (.vshell) that contains the testbench shell module. Since the testbench instance in the top-level Verilog module now refers to this shell module, the shell file has to be compiled along with the design and the top-level Verilog module. The loaded shared object testbench file is automatically invoked by the shell module during simulation.
The following steps demonstrate a typical flow involving separate compilation of the testbench: 1. Compile the testbench in VCS to generate the shared object (libtb.so) file containing the compiled testbench and the Verilog testbench shell file.
Using OpenVera Native Testbench 11-23
2. Compile the HDL along with the top-level Verilog module and the testbench shell (.vshell) file to generate the executable simv. 3. Load the testbench on simv at runtime. Important: The following ntb_opts options must be used for both steps of the compilation (the testbench compilation and the design compilation): -ntb_opts use_sigprop -ntb_opts dw_vip -ntb_opts aop
Usage Model
Testbench Compilation
% vcs -ntb_cmp [other_ntb_options] file1.vr file2.vr
Compilation
% vcs -ntb_vl [ntb_options] [compile_options] file1.vr file2.vr file3.v file4.v
Simulation
% simv +ntb_load=PATH/libtb.so [run_options]
PATH is the directory where the libtb.so and .vshell files are created. You can specify PATH by using the -ntb_spath option while compiling the testbench.
Example
Design files: top.v mid.v, bot.v Testbench file: tb.vr
Using OpenVera Native Testbench 11-24
By default, files are processed in the order specified (or wildcard-expanded by the shell). This is a global option, and affects all Vera input files, including those preceding it, and those named in -f file.list.
When using the option ntb_opts print_deps in addition to ntb_opts dep_check with vcs, the reordered list of source files is printed on standard output. This could be used, for example, to establish a baseline for further testbench development. For example, assume the following files and declarations:
b.vr: class Base {integer i;} d.vr: class Derived extends Base {integer j;} p.vr: program test {Derived d = new;}
File d.vr depends on file b.vr, since it contains a class derived from a class in b.vr, whereas p.vr depends on neither, despite containing a reference to a class declared in the former. The p.vr file does not participate in inheritance relationships. The effect of dependency ordering is to properly order the files b.vr and d.vr, while leaving files without class inheritance relationships alone. The following command lines result in reordered sequences.
% vcs ntb ntb_opts dep_check d.vr b.vr p.vr % vcs ntb ntb_opts dep_check p.vr d.vr b.vr
The first command line yields the order b.vr d.vr p.vr, while the second line yields, p.vr b.vr d.vr.
Circular Dependencies
With some programming styles, source files can appear to have circular inheritance dependencies in spite of correct inheritance trees being cycle-free. This can happen, for example, in the following scenario:
a.vr: class Base_A {...} class Derived_B extends Base_B {...}
In this example, classes are derived from base classes that are in the other file, respectively, or more generally, when the inheritance relationships project onto a loop among the files. This is, however, an abnormality that should not occur in good programming styles. VCS will detect and report the loop, and will use a heuristic to break it. This may not lead to successful compilation, in which case you can use the -ntb_opts print_deps option to generate a starting point for manual resolution; however, if possible, the code should be rewritten.
Functional Coverage
The VCS implementation of OpenVera supports the covergroup construct. For more information about the covergroup and other functional coverage model, see the section "Functional Coverage Groups" in the VCS OpenVera Language Reference Manual.
Simulation
% simv [run_options]
For details on the use of RVM, see the Reference Verification Methodology User Guide. Though the manual descriptions refer to Vera, NTB uses a subset of the OpenVera language and all language specific descriptions apply to NTB. Differences between the usage of NTB and Vera are: NTB does not require header files (.vrh) as described in the Reference Verification Methodology User Guide chapter Coding and Compilation.
NTB parses all testbench files in a single compilation. The VCS command-line option -ntb_opts rvm must be used with NTB.
Limitations
The handshake configuration of notifier is not supported (since there is no handshake for triggers/syncs in NTB). RVM enhancements for assertion support in Vera 6.2.10 and later are not supported for NTB. If there are multiple consumers and producers, there is no guarantee of fairness in reads from channels, etc.
Performance Profiler
The NTB Performance Profiler aids in writing more efficient OpenVera code. When performance profiling is turned on, NTB tracks: The time spent in each function, task and program The time spent in the HDL simulator and in testbench internal Predefined methods OpenVera fork join block Predefined procedures Testbench garbage collection
The NTB profile report is dumped in the vcs.prof log file. Note: The current profiler and the +prof compile-time option will be replaced by the unified profiler and the -simprofile compiletime option in the next release of VCS. The unified profiler is now an LCA feature, see The Unified Simulation Profiler.
right = 0; result = 0; result = a.pack(arr,index,left,right,0); } program MyTest { integer k = 0, j = 0; repeat (20) { fork { for (j = 0; j < 200; j++) { k = k + 1; MyPack(k); } } { for(j = 1; j < 100000; j++) k ++; DPI_call(1, 2); } join all } } //C-file: dpi.c #include <svdpi.h> static int tmp; static void do_activity(int j) {
int i; for( i = 0; i < 200000; i++ ) { tmp ^= j + i; } } void DPI_call(int a, int b) { int i; for( i = 0; i < 1000; i++ ) { i +=b; i *=a; do_activity( i ); } }
============================================================================== TOP LEVEL VIEW ============================================================================== TYPE %Totaltime -----------------------------------------------------------------------------DPI 97.98 PLI 0.00
VCD 0.00 KERNEL 0.00 MODULES 0.00 PROGRAMS 1.90 PROGRAM GC 0.11 ASSERTION KERNEL 0.00 ------------------------------------------------------------------------------
Reporting limit is 0.50% ============================================================================== MODULE VIEW ============================================================================== (index) Module %%Totaltime No of Instances Definition -----------------------------------------------------------------------------------------------------------------------------------------------------------
============================================================================== PROGRAM VIEW ============================================================================== Program(index) %Totaltime No of Instances Definition -----------------------------------------------------------------------------MyTest_p (1) 1.90 2 dpi.vr:26. ------------------------------------------------------------------------------
______________________________________________________________________________
============================================================================== TOP-LEVEL CONSTRUCT VIEW -----------------------------------------------------------------------------Construct %Totaltime -----------------------------------------------------------------------------Program Thread 0.90 Object Pack 0.84 Program Task 0.17
______________________________________________________________________________
============================================================================== // Simulation memory: 6316085 bytes ============================================================================== TOP LEVEL VIEW ============================================================================== TYPE Memory %Totalmemory -----------------------------------------------------------------------------DPI 2068 0.03 PLI 0 0.00 VCD 0 0.00 KERNEL 1638725 25.95 MODULES 0 0.00 PROGRAMS 9349992 148.03 ------------------------------------------------------------------------------
============================================================================== PROGRAM VIEW ============================================================================== Program(index) Memory %Totalmemory No of Instances Definition -----------------------------------------------------------------------------MyTest_p (1) 9349992 148.03 2 dpi.vr:26. -----------------------------------------------------------------------------**************************End of vcs.prof****************************
The vcs.prof log file shown in Example 13-7 provides the following information: The DPI function in dpi.c consumed 97.98% of the total time.
Fork A::pack MyPack Program Thread Object Pack Program Task 0.90 0.84 0.17 47.06 44.12 8.82 dpi.vr : 39-43. dpi.vr : 23 dpi.vr : 11-23
The fork-join block defined in test.vr:39-43 consumed 0.90% of the total time.
The predefined class method, pack(), invoked at test.vr:23 consumed 0.84% of the total time. The task MyPack()defined at test.vr:11:23 consumed 0.17% of the total time.
The time reported for construct is the exclusive time consumed by the construct itself. Time spent in dependants is not reported.
12
Using SystemVerilog 1
VCS supports the SystemVerilog language as defined in the IEEE 1800-2009 standard. For information on SystemVerilog constructs, see the SystemVerilog Language Reference Manual. This chapter describes the following: Usage Model Using VMM with SV Debugging SystemVerilog Designs Functional Coverage Newly implemented SystemVerilog Constructs Extensions to SystemVerilog
Usage Model
The usage model to compile and simulate your design with SystemVerilog files is as follows: Compilation
% vcs -sverilog [compile_options] Verilog_files
Simulation
% simv [simv_options]
To analyze SV files, use the option -sverilog with vcs as shown in the above usage model.
Simulation
% simv [simv_options]
To analyze SV files using VMM, use the option -sverilog and -ntb_opts rvm with vcs as shown in the above usage model. For more information on VMM, refer to the Verification Methodology Manual for SystemVerilog.
Thread debugging Setting breakpoints Mailbox related information Semaphore related information
For detailed information on the UCLI commands, see the UCLI User Guide.
Functional Coverage
The VCS implementation of SystemVerilog supports the covergroup construct, which you specify as the user. These constructs allow the system to monitor values and transitions for variables and signals. They also enable cross coverage between variables and signals. If you have covergroups in your design, VCS collects the coverage data during simulation and generates a database, simv.vdb. Once you have simv.vdb, you can use the Unified Report Generator to generate text or HTML reports. For more information about
covergroups, see the VCS SystemVerilog LRM. For more information about functional coverage generated in VCS, see the Coverage Technology User Guide.
constraint cons { // Newly implemented variant x1 == arr.sum() with (item * item); x2 == arr.sum(x) with (x + x); // // x3 x4 Previously implemented variant Supported in older releases == arr.sum() with (arr[item.index] * arr[item.index]); == arr.sum(x) with (arr[x.index] + arr[x.index]);
} endclass
The first variant is implemented in this release. For a discussion and examples of aggregate methods in constraints using the with construct, see IEEE Std 1800-2009, section 7.12.4 Iterator index querying. As specified in the standard, the entire with expression must be in parentheses.
Debugging During Initialization SystemVerilog Static Functions and Tasks in Module Definitions
You can tell VCS to enable UCLI debugging when initialization begins for static SystemVerilog tasks and functions in module definitions with the -ucli=init runtime option and keyword argument. This debugging capability enables you to do, among other things, to set breakpoints during initialization.
If you omit the =init keyword argument and just enter the -ucli runtime option, the UCLI begins after initialization and you cant debug inside static initialization routines during initialization. Note: - Debugging static SystemVerilog tasks and functions in program blocks during initialization does not require the =init keyword argument. - This feature does not apply to SystemC code. When you enable this debugging VCS displays the following prompt indicating that the UCLI is in the initialization phase:
init%
During the initialization the run UCLI command with the 0 argument (run 0), or the -nba or -delta options runs VCS until initialization ends. As usual, after initialization, the run 0 command and argument runs the simulation until the end of the current simulation time. During initialization the following restrictions apply: UCLI commands that alter the simulation state, such as a force command, create an error condition. Attaching or configuring Cbug, or in other ways enabling C, C++, or SystemC debugging during initialization is an error condition. The following UCLI commands are not allowed during initialization:
Using SystemVerilog 12-7
session management commands: save and restore signal and variable commands: force, release, and call The signal value and memory dump specification commands: memory -read/-write and dump The coverage commands: coverage and assertion Example If we have the following small code example:
module mod1; class C; static int I=F(); static function int F(); logic log1; begin log1 = 1; $display("%m log1=%0b",log1); $display("In function F"); F = 10; end endfunction endclass endmodule
If we simulate this example, with just the -ucli runtime option, we see the following:
Command: simv =ucli Chronologic VCS simulator copyright 1991-year Contains Synopsys proprietary information. Compiler version version-number; Runtime version versionnumber; simulation-start-date-time mod1.\C::F log1=1 In function F
V C S
S i m u l a t i o n
R e p o r t 0.0Mb
VCS executed the $display tasks right away and the simulation immediately ran to completion. If we simulate this example, with just the -ucli=init runtime option and keyword argument, we see the following:
Command: simv -ucli=init Chronologic VCS simulator copyright 1991-year Contains Synopsys proprietary information. Compiler version version-number; Runtime version versionnumber; simulation-start-date-time init%
Notice that VCS has not executed the $display system tasks yet and the prompt is init%. We can set a breakpoint, for example:
init% stop -in \C::F 1
The breakpoint halts VCS. If we run the simulation up to the end of the initialization phase with the run 0 UCLI command again, we see the following:
Now VCS executes the $display system tasks and changes the prompt to ucli%.
The explicit form is implemented in this release. The following code example shows these two forms of external constraint prototypes.
class Class1; rand int int1,int2; constraint imp_ext_cnstr_proto1; extern constraint exp_ext_cnstr_proto2; ... endclass
The external constraint block, or body, for these prototypes must be at the same hierarchical level as the class and follow the class definition. The following are external constraint blocks or bodies for these external constraint prototypes:
constraint Class1::imp_ext_cnstr_proto1 { int1 inside {0, [3:5], [7:31]};} constraint Class1::exp_ext_cnstr_proto2 { int2 dist {100 := 1, 101 := 2};}
Besides the extern keyword, the difference between the implicit and explicit forms is how VCS responds when the external constraint block or body for a prototype is missing: With the implicit form, VCShandles a missing external constraint block as an empty constraint block. This is not an error condition and VCSjust outputs a warning message, for example:
Warning-[BCNACMBP] Missing constraint definition doc_example.sv, 6 prog, "constraint imp_ext_cnstr_proto1;" The constraint imp_ext_cnstr_proto1 declared in the class Class1 is not defined. Provide a definition of the constraint body imp_ext_cnstr_proto1 or remove the constraint declaration imp_ext_cnstr_proto1 from the class declaration Class1.
With a missing external constraint block for the implicit form, because it is not an error condition, VCScontinues to compile or elaborate and generates the simv executable. If you dont notice the warning message you might expect to see the missing constraint block constraining the values of the random variables. With the explicit form, a missing external constraint block is an error condition, for example:
Error-[SV_MEECD] Missing explicit external constraint def doc_example.sv, 7 prog, "constraint exp_ext_cnstr_proto2;" The explicit external constraint 'exp_ext_cnstr_proto2' declared in the class 'Class1' is not defined. Provide a definition of the constraint body 'exp_ext_cnstr_proto2' or remove the explicit external constraint declaration 'exp_ext_cnstr_proto2' from the class declaration 'Class1'.
With a missing external constraint block for the explicit form, because it is an error condition, VCS does not compile or elaborate. Using an Empty Constraint Block You can use the implicit form of a constraint prototype, without the corresponding constraint block, in a subclass to remove a constraint from a base class, for example:
module top; class C; rand int x; constraint protoC_1 { x < 5; } constraint protoC_2 { x > 3; } endclass class CD extends C; rand int y; constraint protoC_1;
// this subclass constraint protoCD_1 { x < 6; } // applying a new constraint // on x endclass C ci = new; CD cdi = new; int res1; int res2; initial begin repeat (20) begin res1 = ci.randomize(); // here x can have value 4 only res2 = cdi.randomize(); // here x can have values 4 and 5 if ((res1 == 1) && (res2 == 1)) $display("niru>> ci.x=%d cdi.x=%d",ci.x, cdi.x); end end endmodule
The Explicit Form in Previous Releases In previous releases the explicit form was an error condition and VCS displayed the following:
Error-[SE] Syntax error Following verilog source has syntax error : "doc_example.sv", 7: token is 'constraint' extern constraint exp_ext_cnstr_proto2; ^ System verilog keyword 'constraint' is not expected to be used in this context.
These constructs are described in The Verilog LRM, IEEE Std 13642005 in the following sections: 12.4 Generate constructs 12.4.1 Loop generate constructs 12.4.2 Conditional generate constructs The following are examples of these constructs in a program block:
program prog; ... generate reg reg1; endgenerate if (1) logic log1; genvar gv1; for(gv1=1; gv1<10; gv1++) logic log2; case (param1) 0 : logic log3; ... endcase endprogram
The first is a generate region, specified with the generate and endgenerate keywords inside a program block:
generate reg reg1; endgenerate
The third is a generate loop variable declared with the genvar keyword, followed by a for loop for that variable:
genvar gv1; for(gv1=1; gv1<10; gv1++) logic log2;
In previous releases these constructs would have resulted in the following error messages:
Error-[NYI] Not Yet Implemented source_filename, line_number Feature is not yet supported: Generate Block inside Program Error-[NYI] Not Yet Implemented source_filename, line_number Feature is not yet supported: Generate Variable declaration inside Program
for (genvar i = 0; i < 1; i++) begin a1: assert final (1); end endgenerate generate for (i = 0; i < 1; i++) begin a1: assert final (1); end endgenerate endmodule
This error condition was ignored in previous releases. To fix this error please declare genvar i in module scope.
You can also: disable and re-enable randomization in an unpacked struct with the rand_mode() method. use in-line random variable control to specify the randomized variables with an argument to the randomize() method.
module test(); typedef struct { bit [1:0] b1; integer i1; } ST1; ST1 st1; initial repeat (4) begin std::randomize(st1); #10 $display("\n\n\t at %0t",$time); $display("\t st1.b1 is %0d",st1.b1); $display("\t st1.i1 is %0d",st1.i1); end endmodule
This example randomizes struct instance st1. The $display system tasks display the following:
In the previous version of VCS, this example would result in the following error messages at compile-time:
Error-[UARC] Unsupported argument to randomize call doc_ex1.sv, 13 "st1" Arg #1 of std::randomize "st1" is unsupported unpacked struct or array of unpacked struct
Error-[SV-FNYI] Feature not yet implemented doc_ex1.sv, 13 SystemVerilog feature not yet implemented. unpacked structure(s) in system function calls Expression: std::randomize(st1)
Here is another code example that randomizes members of an unpacked struct and uses constraints:
Example 12-2
module test; typedef struct { rand byte aa; byte bb; } ST; ST st; bit [3:0] c; initial begin std::randomize(st.bb);
// std randomization on a // struct member std::randomize(st) with { st.aa > 10; }; // support st.aa in with block std::randomize(c,st) with { st.aa > c; }; $display("\n\n\t at %0t",$time); $display("\t st.aa is %0d",st.aa); $display("\t st.bb is %0d",st.bb); $display("\t bit c is %0d",c); end endmodule
Example 12-3
module test; typedef struct { byte a0; byte b0; } ST0; typedef struct {
byte aa; ST0 st0; } ST_NONE; typedef struct { rand byte aa; byte bb; } ST_PART; typedef struct { rand byte aa; randc byte bb; } ST_ALL; ST_NONE st; ST_PART st1; ST_ALL st2; initial begin repeat (5) begin // random variables: std::randomize(st);
// random variables: st1.aa st.bb std::randomize(st1) with {st1.aa>st1.bb;}; // random variables: st2.aa st2.bb std::randomize(st2); $display("st %p",st); $display("st1 %p",st1); $display("st2 %p",st2); end end endmodule
This example randomizes unpacked struct instance st1. The $display system tasks display the following:
st '{aa:54, st0:'{a0:60, b0:125}}
st1 '{aa:-125, bb:-126} st2 '{aa:-9, bb:-90} st '{aa:27, st0:'{a0:-75, b0:-6}} st1 '{aa:-37, bb:-47} st2 '{aa:-106, bb:49} st '{aa:-60, st0:'{a0:-86, b0:-60}} st1 '{aa:-71, bb:-103} st2 '{aa:-120, bb:-15} st '{aa:44, st0:'{a0:-50, b0:5}} st1 '{aa:-69, bb:-96} st2 '{aa:96, bb:95} st '{aa:122, st0:'{a0:-94, b0:-16}} st1 '{aa:-2, bb:-63} st2 '{aa:18, bb:-12}
module test(); typedef struct { rand bit [1:0] b1; rand integer i1; } ST1; class CC; rand ST1 st1; endclass CC cc = new; initial repeat (4) begin cc.randomize(); #10 $display("\n\n\t at %0t",$time); $display("\t cc.st1.b1 is %0d",cc.st1.b1); $display("\t cc.st1.i1 is %0d",cc.st1.i1);
end endmodule
This example randomizes instance cc of class CC that contains unpacked struct ST. The $display system tasks display the following:
at 10 cc.st1.b1 is 3 cc.st1.i1 is -1241023056
In the previous version of VCS, this example would result in the following error messages at compile-time:
Error-[SV-RISNYI] Rand in Struct Not Yet Implemented doc_ex2.sv, 4 The qualifier 'rand' was seen in a struct. This is not yet supported. Please remove the 'rand' declaration.
Error-[SV-RISNYI] Rand in Struct Not Yet Implemented doc_ex2.sv, 5 The qualifier 'rand' was seen in a struct. This is not yet
Using SystemVerilog 12-22
Here is another code example: Example 12-5 Another Example of the Class Randomize Method randomize()
module test; typedef struct { bit[3:0] c; randc bit[1:0] d; } ST0; typedef struct { rand bit[5:0] a; rand bit[5:0] b; rand ST0 st0; bit [5:0] e; }ST; class CC; rand ST st; endclass CC cc = new; initial begin repeat (10) begin // random variables: cc.st.a cc.st.b and cc.st.st0.d // state variables: cc.st.e and cc.st.st0.c cc.randomize() with { st.a<10 ; st.b>10; st.a+st.b==64;}; $display("st %p",cc.st); end end endmodule
This example randomizes class instance cc according to the constraint that follows the with keyword. The $display system task displays the following:
st st st st st st st st st st '{a:'h7, '{a:'h8, '{a:'h1, '{a:'h1, '{a:'h1, '{a:'h8, '{a:'h9, '{a:'h9, '{a:'h7, '{a:'h8, b:'h39, b:'h38, b:'h3f, b:'h3f, b:'h3f, b:'h38, b:'h37, b:'h37, b:'h39, b:'h38, st0:'{c:'h0, st0:'{c:'h0, st0:'{c:'h0, st0:'{c:'h0, st0:'{c:'h0, st0:'{c:'h0, st0:'{c:'h0, st0:'{c:'h0, st0:'{c:'h0, st0:'{c:'h0, d:'h0}, d:'h1}, d:'h3}, d:'h2}, d:'h0}, d:'h1}, d:'h2}, d:'h3}, d:'h3}, d:'h1}, e:'h0} e:'h0} e:'h0} e:'h0} e:'h0} e:'h0} e:'h0} e:'h0} e:'h0} e:'h0}
module test(); typedef struct { rand integer i1; } ST1; class CC; rand ST1 st1; endclass CC cc = new; initial repeat (10) begin
cc.randomize(); #10 $display("\n\t at %0t",$time); $display("\t cc.st1.i1 is %0d",cc.st1.i1); end initial begin #55 cc.rand_mode(0); #20 cc.rand_mode(1); end endmodule
In this example the rand_mode() method, with its arguments, disables and re-enables randomization in class instance cc. The $display system tasks display the following:
at 10 cc.st1.i1 is -902462825 at 20 cc.st1.i1 is -1241023056 at 30 cc.st1.i1 is 69704603 at 40 cc.st1.i1 is -1877783293 at 50 cc.st1.i1 is -795611063 at 60 cc.st1.i1 is 629780255 at 70 cc.st1.i1 is 629780255 at 80 cc.st1.i1 is 629780255
In this example randomization is disabled at simulation time 55 and re-enabled at simulation time 75, enabling new random values at simulation time 90. In the previous version of VCS, this example would result in the following error messages at compile-time:
Error-[SV-RISNYI] Rand in Struct Not Yet Implemented doc_ex3.sv, 4 The qualifier 'rand' was seen in a struct. This is not yet supported. Please remove the 'rand' declaration. 1 error
Here is another code example: Example 12-7 Another Example of Disabling and Re-enabling Randomization with the rand_mode() Method
module test; typedef struct { bit[3:0] c; randc bit[1:0] d; } ST0; typedef struct { rand bit[5:0] a; rand bit[5:0] b; rand ST0 st0; bit [5:0] e; }ST;
n1;
initial begin cc.st.rand_mode(0); repeat (10) begin // random variables: cc.n1 // state variables: all members of cc.st cc.randomize(); $display("turn off st %p , cc.n1 %b", cc.st,cc.n1); end cc.st.rand_mode(1); cc.st.st0.rand_mode(0); repeat (10) begin // random variables: cc.n1 cc.st.a cc.st.b // state variables: cc.st.e cc.st.st0.c cc.st.st0.d cc.randomize(); $display("turn off st.st0 %p , cc.n1 %b", cc.st,cc.n1); end cc.st.st0.rand_mode(1); end endmodule
In this example the rand_mode() method disables randomization in unpacked struct instance cc.st.st0 and then re-enables it. The $display system tasks displays the following:
turn turn turn turn off off off off st st st st '{a:'h0, '{a:'h0, '{a:'h0, '{a:'h0, b:'h0, b:'h0, b:'h0, b:'h0, st0:'{c:'h0, st0:'{c:'h0, st0:'{c:'h0, st0:'{c:'h0, d:'h0}, d:'h0}, d:'h0}, d:'h0}, e:'h0} e:'h0} e:'h0} e:'h0} , , , , cc.n1 cc.n1 cc.n1 cc.n1 111 000 011 011
turn turn turn turn turn turn turn turn turn turn turn turn turn turn turn turn
off off off off off off off off off off off off off off off off
st '{a:'h0, b:'h0, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 001 st '{a:'h0, b:'h0, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 111 st '{a:'h0, b:'h0, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 111 st '{a:'h0, b:'h0, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 011 st '{a:'h0, b:'h0, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 001 st '{a:'h0, b:'h0, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 100 st.st0 '{a:'h39, b:'h17, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 010 st.st0 '{a:'h26, b:'h1f, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 001 st.st0 '{a:'h9, b:'h3, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 010 st.st0 '{a:'h23, b:'he, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 101 st.st0 '{a:'h21, b:'h18, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 000 st.st0 '{a:'h34, b:'h1d, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 001 st.st0 '{a:'h2f, b:'h27, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 011 st.st0 '{a:'h2f, b:'h17, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 100 st.st0 '{a:'hd, b:'h34, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 010 st.st0 '{a:'h27, b:'h11, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 010
module test(); typedef struct { rand integer i1; } ST1; typedef struct { rand integer i1; } ST2; class CC; rand ST1 st1; rand ST2 st2; endclass CC cc = new; initial
Using SystemVerilog 12-28
begin #10 cc.randomize(); $display("\n\t at sim time %0t",$time); $display("\t cc.st1.i1 is %0d",cc.st1.i1); $display("\t cc.st2.i1 is %0d",cc.st2.i1); #10 cc.randomize(st1); $display("\n\t at sim time %0t",$time); $display("\t cc.st1.i1 is %0d",cc.st1.i1); $display("\t cc.st2.i1 is %0d",cc.st2.i1); #10 cc.randomize(null); $display("\n\t at sim time %0t",$time); $display("\t cc.st1.i1 is %0d",cc.st1.i1); $display("\t cc.st2.i1 is %0d",cc.st2.i1); #10 cc.randomize(st2); $display("\n\t at sim time %0t",$time); $display("\t cc.st1.i1 is %0d",cc.st1.i1); $display("\t cc.st2.i1 is %0d",cc.st2.i1); end endmodule
This example supplies the randomize() method with arguments for unpacked struct instances st1 and st2 and the null keyword. 1. At simulation time 20 randomization is limited to st1. 2. At simulation time 30 randomization is turned off. 3. At simulation time 40 randomization is limited to st2. The $display system tasks displays the following:
at sim time 10 cc.st1.i1 is -902462825 cc.st2.i1 is -1241023056 at sim time 20 cc.st1.i1 is 69704603 cc.st2.i1 is -1241023056
at sim time 30 cc.st1.i1 is 69704603 cc.st2.i1 is -1241023056 at sim time 40 cc.st1.i1 is 69704603 cc.st2.i1 is -1877783293
At simulation 20 a new random value is in st1 but not st2. At simulation time 30 there are no new random values. At simulation time 40 a new random value is in st2 but not st1. In the previous version of VCS, this example would result in the following error messages at compile-time:
Error-[SV-RISNYI] Rand in Struct Not Yet Implemented doc_ex4.sv, 4 The qualifier 'rand' was seen in a struct. This is not yet supported. Please remove the 'rand' declaration.
Error-[SV-RISNYI] Rand in Struct Not Yet Implemented doc_ex4.sv, 8 The qualifier 'rand' was seen in a struct. This is not yet supported. Please remove the 'rand' declaration. 2 errors
Here is another code example: Example 12-9 Another Example of In-line Random Variable Control
} ST0; typedef struct { rand bit[5:0] a; rand bit[5:0] b; rand ST0 st0; bit [5:0] e; }ST; class CC; ST st; rand bit[2:0] endclass CC cc = new; initial begin // random variables: cc.n1 // state variables: all members of cc.st repeat (5) begin cc.randomize(); $display("default st %p , cc.n1 %b",cc.st,cc.n1); end // random variables: cc.st.a cc.st.b cc.st.st0.d // state variables: cc.n1 cc.st.e cc.st.st0.c repeat (5) begin cc.randomize(st); $display("inline st %p , cc.n1 %b",cc.st,cc.n1); end end endmodule
n1;
In this example the randomize() method is called without an argument and then with the st struct instance argument. The $display system tasks display the following:
default st '{a:'h0, b:'h0, st0:'{c:'h0, d:'h0}, e:'h0} , default st '{a:'h0, b:'h0, st0:'{c:'h0, d:'h0}, e:'h0} , default st '{a:'h0, b:'h0, st0:'{c:'h0, d:'h0}, e:'h0} , cc.n1 111 cc.n1 000 cc.n1 011
default st '{a:'h0, b:'h0, st0:'{c:'h0, d:'h0}, e:'h0} , default st '{a:'h0, b:'h0, st0:'{c:'h0, d:'h0}, e:'h0} , inline st '{a:'h1f, b:'h27, st0:'{c:'h0, d:'h0}, e:'h0} , inline st '{a:'h11, b:'h34, st0:'{c:'h0, d:'h1}, e:'h0} , inline st '{a:'h17, b:'h2a, st0:'{c:'h0, d:'h2}, e:'h0} , inline st '{a:'h1f, b:'h9, st0:'{c:'h0, d:'h3}, e:'h0} , inline st '{a:'h3, b:'h12, st0:'{c:'h0, d:'h3}, e:'h0} ,
cc.n1 011 cc.n1 001 cc.n1 001 cc.n1 001 cc.n1 001 cc.n1 001 cc.n1 001
VCS executes the second $display system task after it executes the randomize() method with the st argument.
Limitation
Random class objects as members of an unpacked struct are not yet implemented (NYI), for example:
module test; class CC0; rand int a; endclass typedef struct { rand bit[5:0] a; rand bit[5:0] b; rand CC0 cc0; }ST; endmodule
The wait fork statement blocks process execution flow until all immediate child subprocesses (processes created by the current process, excluding their descendants) have completed their execution. For backwards compatibility reasons, by default, VCS blocks the process execution flow until all child subprocesses, not just the immediate child subprocesses, have completed their execution. It also waits only for those processes that are created by the current task or process that contains the wait fork statement. You can specify that VCS be compliant with the standard and block process execution flow only for immediate child subprocesses and wait for processes created by the current process (even if the wait fork is contained within a task) with the -ntb_opts sv_dwfork compile-time option and keyword argument. The following code example shows the difference in behavior for wait fork.
program A; task t1(); #1 $display($time,," T1_1 \n"); endtask task t2(); fork #1 $display($time,," T2_1 \n"); #9 $display($time,," T2_2 \n"); join_any endtask task disp(); fork t1(); t2(); join_any wait fork; $display($time,,"After Wait fork");
endtask initial begin fork #1 $display($time,," Initial Thread 1 \n"); #5 $display($time,," Initial Thread 2 \n"); join_any disp(); end endprogram
It executes this line at simulation time 10, even though the fork for this $display system task is not an immediate child subprocess of task disp(). The $display system tasks, by default, displays the following:
1 2 2 5 10 10 Initial Thread 1 T1_1 T2_1 Initial Thread 2 T2_2 After Wait fork
If you include the -ntb_opts sv_dwfork compile-time option and keyword argument, the $display system tasks displays the following:
1 Initial Thread 1 2 T1_1 2 T2_1 5 Initial Thread 2 5 After Wait fork
fork #1 $display($time,," Initial Thread 1 \n"); #5 $display($time,," Initial Thread 2 \n"); join_any disp(); #10 $display($time,, "End"); end endprogram
By default, disable fork does not disable the fork in the process, but only disables the fork in the task in which it is present, to give the output:
1 Initial Thread 1 2 disp_T1 2 After disable fork 5 Initial Thread 2 12 End
With the -ntb_opts sv_dwfork option, disable fork disables the fork in the process also, giving the output:
1 Initial Thread 1 2 disp_T1 2 After disable fork 12 End
wait() Statement with a Static Class Member Variable Parameters and Localparams in Classes SystemVerilog Math Functions Streaming Operators
Description SystemVerilog defines extensive randomization methods and operators for class members. Most modeling methodologies recommend the use of classes for randomization. However, there are situations where the data to be randomized is not available in a class. SystemVerilog provides the std::randomize() function to randomize variables that are not class members. The std::randomize() function can be used in the following scopes: module function task
class method
Arguments to std::randomize() can be of integral types including: integer bit vector enumerated type
Object handles and strings cannot be used as arguments to std::randomize(). The variables passed to std::randomize() must be visible in the scope where the function is called. Cross-module references are not allowed as arguments to the std::randomize() function. All constraint expressions currently available with obj.randomize() in VCS can be used as constraints in the constraint-block. Only constraints specified in the constraint block are honored. Any rand mode specified on the class members is ignored when std::randomize() is called with the given class member. The pre_randomize() and post-randomize() tasks are not called when std::randomize() is used within a class member function. The std:: prefix must be explicitly specified for the randomize() call. The std::randomize() function is supported in VCS. Files containing std::randomize() calls can be compiled with vlogan.
The function using std::randomize() can be declared in a task inside a package that can be imported into modules and programs. Example
module M; bit[11:0] addr; integer data; function bit genAddrData(); bit success; success = std::randomize(addr, data); return success; endfunction function bit genConstrainedAddrData(); bit success; success = std::randomize(addr, data) with {addr > 1000; addr + data < 20000;}; return success; endfunction endmodule
The genAddrData function uses std::randomize(addr, data) to assign random values to addr and data variables. The std::randomize() function randomizes any variables that are visible in the scope. The getConstrainedAddrData() function uses std::randomize(addr, data) to assign random values to addr and data variables. In this case there is an additional constraint given to the call, which is that addr is greater than 1,000 and addr+data is less than 20,000.
This is a bounded queue assignment. VCS copies the items in q2 into q1 until q1 is full or until all the items in q2 are copied into q1. The bound number of items in the queues remain as you declared them.
q.push_front(new_item)
If adding a new item to the front of a full bounded queue, VCS deletes the last item in the back of the queue.
q.push_back(new_item)
If the bounded queue is full, a new item cant be added to the back of the queue and the queue remains the same.
q1 === q2
A bounded queue comparison behaves the same as an unbounded queue, the bound sizes should be the same when the two bounded queues are equal. Limitation for SystemVerilog Bounded Queues Bounded queues are not supported in constraints.
Hyperbolic cosine Hyperbolic tangent Arc-hyperbolic sine Arc-hyperbolic cosine Arc-hyperbolic tangent Ceiling of log base 2 of n (as integer)
Streaming Operators
Streaming operators can be applied to any bit-stream data types consists of the following: Any integral, packed, or string type Unpacked arrays, structures, or class of the above types Dynamically sized arrays (dynamic, associative, or queues) of any of the above types
The expr_target and expr_i can be any primary expressions of any streamed data types. The slice determines the size of each block measured in bits. If specified, it may be either a constant integral expression, or a simple type. The << or >> determines the order in which blocks of data are streamed.
Streaming Concatenation
expr_target = {>>slice1 {expr1, expr2, {<< slice2{expr3, expr4}}}
If the unpacked operation includes unbounded dynamically sized types, the process is greedy. The first dynamically sized items is resized to accept all the available data (excluding subsequent fixed sized items) in the stream; any remaining dynamically sized items are left empty. Streaming Concatenation
{>>slice1 {expr1, expr2, {<< slice2{expr3, expr4}}} = expr_src;
Error Conditions
Compile time error for associative arrays as assignment target Run time error for Any null class handles in packing and unpacking operations
Extensions to SystemVerilog
This section contains descriptions of Synopsys enhancements to SystemVerilog. This section contains the following topics: Unique/Priority Case/IF Final Semantic Enhancements Single-Sized Packed Dimension Extension Covariant Virtual Function Return Types Self Instance of a Virtual Interface
$time, cond, a); #0 cond = 0; a=a+1; v1++; v2++; $display("\n TIME %0d ns: cond value %0b, a value %0d", $time, cond, a); end endmodule
Example 12-11
//test.sv module top; reg cond; bit [7:0] a = 0,b; always_comb begin unique if (a == 0 || a == 1) $display ("A is 0 or 1"); else if (a == 2) $display ("A is 2"); end initial begin #100; a = 1; #100 a = 2; #100 a = 3; #0 a++; #0 a++; #0 a++; #10 $finish;
end endmodule
Example 12-12 unique case used with nested loop inside function
//test.sv module top; int i,j; reg [1:0][2:0] a, b, c; bit flag; function foo; for (int i=0; i<2; i++) for (int j=0; j<3; j++) unique case (a[i][j]) 0: b[i][j] = 1'b0; 1: b[i][j] = c[i][j]; endcase endfunction : foo always_comb begin for(i=0; i<4; i++) begin if (i==2) foo(); end end initial begin a = 6'b00x011; end endmodule : top
Note: The following limitations must be noted while using -xlrm uniq_prior_final feature for loop indices: - It must be written in for statement. The while and do...while are not supported. - The loop bounds must be compile-time constants. - for(i= lsb; i<msb; i++) - Here, lsb and msb must be compile-time constant, or will become constant when upper loops get unrolled. - No other drivers of the loop variable must be in the loop body. VCS also supports unique/prior final in a for loop that can not be unrolled at compile time. For example, if you have a for loop whose range could not be determined at compile-time and if there are errors during the last evaluation of such a for loop, VCS still reports the error. However, loop index information will not be provided. Even if multiple failures occur in different iterations, VCS reports only the last one.
Important: Use unique/priority case/if statement only inside always block, continuous assign, or inside a function. If you use it in other places, the final semantic will be ignored.
v1 = 1'b0; v2 = 1'b0; #1; end always_comb begin unique case(sel) v1: $display($time, " Hello"); v2: $display($time, " World"); endcase end endmodule
Simulation Output:
%> vcs -sverilog test.sv -R 0 Priority checker OFF 0 Hello 0 Hello 1 Priority checker ON 1 Hello RT Warning: More than one conditions match in 'unique case' statement. "system_task_control_warning.sv", line 28, for m. Line 29 & 30 are overlapping at time 1.
VCS expands the packed dimension [4] into [0:3]. For packed MDAs, for example:
bit [4][4] a;
VCS expands the packed dimensions [4][4] into [0:3][0:3]. You can use this extension in several ways. The following is an example of using this extension in a user defined type:
typedef reg [8] DREG;
The following is an example of using this extension in a structure, union, and enumerated type:
struct packed { DREG [20][20] arr4; } [2][2] st1; union packed { DBIT [20][20] arr5; } [2][2] un1; enum logic [8] {IDLE, XX=8'bxxxxxxxx, S1=8'bzzzzzzzz, S2=8'hff} arr3;
The following is an example of a user-defined structure and union with a packed memory or MDA:
typedef bit [2][24] DBIT; typedef reg [2][24] DREG; typedef struct packed { DBIT [20][20] arr1; } ST; ST [2][2] st;
Using SystemVerilog 12-55
You can also use this extension for specifying module ports, for example:
module mux2( input wire [3] a, input wire [3] b, output logic [3] y);
You can use this extension in the parameter list of a user-defined function or task, for example:
function automatic integer factorial (input [32] operand);
You can use this extension in the definition of a parameter, for example:
parameter reg [2][2][2] p2 = 8;
Error Conditions The following are error conditions for this extension: Using the dollar sign ($) as the size, for example:
reg [8:$] a; reg [$] b;
Using basic data types other than bit, reg, and wire, for example:
typedef shortint [8] DREG;
Without covariant types, the signature of the Derived::clone() above would have to be the same as in the Base class, like the following:
class Derived extends Base; virtual function Base clone(); Derived d = new this; return d; endfunction endclass
This would lead to code like the following for users of the class:
Using SystemVerilog 12-57
Derived d = new; Base b = d.clone(); // automatic down-cast to Base Derived d2; if(!($cast(d2, b))) begin b = null; $error(...) // some exception end
In this example the virtual interface named vi is initialized with the expression:
vi = interface::self();
The interface::self() expression enables you provide a string variable that is effectively the %m format specification of the interface instance that VCS MX returns for assignment to the virtual interface variable. You use the interface::self() expression to initialize virtual interface variables in methodologies like UVM and VMM. It enables you to write components that are configurable with a string is the %m of the virtual interface that the component drives or monitors. The expression interface::self() must be entered precisely, otherwise it is a syntax error. Also notice the required delay (in this case #1) in the initialization of virtual interface vi. This delay is required to prevent a race condition. This implementation is in accordance with the SystemVerilog IEEE STD 1800-2009 section 9.7 Fine-grain process control which specifies: The self() function returns a handle to the current process, that is, a handle to the process making the call. SVA-bind is supported with self instances of virtual interfaces. Note: A self instance of a virtual interface is not supported in Partition Compile. The following conditions are required for a self instance of a virtual interface: The self instance must be defined in the scope. The virtual interface type in the interface declaration must be the same as the interface that includes itself.
Within an interface, you can only use the virtual interface::self() expression can be used in a context that is valid for initializing a virtual interface. Any other use of the interface::self() expression results in a compilation error. Within an interface, the virtual interface::self() expression in a context that is valid for initializing a virtual interface. Any other use of the interface::self() expression results in a compilation error.
UVM Example
The following is an example of a self instance of a virtual interface:
/* interface definition */ interface bus_if; //ports. //signal declaration. initial begin uvm_resource_db#(virtual bus_if)::set("*", $sformatf("%m"), interface::self()); end endinterface
/* instantiated bus interface in design. */ //Add "bus()" to module called "top". bind top bus_if bus();
/*Example config_db usage: */ if(!uvm_config_db#(virtual bus_if)::get(this, "", "top.bus", bus)) `uvm_error("TESTERROR", "no bus interface available"); else 'uvm_info("build", "got bus_if", UVM_LOW)
OR
/*Example resource_db usage: */ if(!uvm_resource_db#(virtual bus_if)::read_by_type(get_full_name(), bus, this)) `uvm_error("TESTERROR", "no bus interface available"); else 'uvm_info("build", "got bus_if", UVM_LOW)
13
Aspect Oriented Extensions 1
Aspect-Oriented Programming (AOP) methodology complements the OOP methodology using a construct called aspect or an aspectoriented extension (AOE) that can affect the behavior of a class or multiple classes. In AOP methodology, the terms aspect and aspect-oriented extension are used interchangeably. Aspect oriented extensions in SV allow testbench engineers to design testcase more efficiently, using fewer lines of code. AOP addresses issues or concerns that prove difficult to solve when using Object-Oriented Programming (OOP) tow write constrainedrandom test benches. Such concerns include: 1. Context-sensitive behavior. 2. Unanticipated extensions.
3. Multi-object protocols. In AOP these issues are termed cross-cutting concerns as they cut across the typical divisions of responsibility in a given programming model. In OOP, the natural unit of modularity is the class. Some of the cross cutting concerns, such as "Multi-object protocols", cut across multiple classes and are not easy to solve using the OOP methodology. AOP is a way of modularizing such cross-cutting concerns. AOP extends the functionality of existing OOP derived classes and uses the notion of aspect as a natural unit of modularity. Behavior that affects multiple classes can be encapsulated in aspects to form reusable modules. As potential benefits of AOP are achieved better in a language where an aspect unit can affect behavior of multiple classes and therefore can modularize the behavior that affects multiple classes, AOP ability in SV language is currently limited in the sense that an aspect extension affects the behavior of only a single class. It is useful nonetheless, enabling test engineers to design code that efficiently addresses concerns "Context-sensitive behavior" and "Unanticipated extensions". AOP is used in conjunction with object-oriented programming. By compartmentalizing code containing aspects, cross-cutting concerns become easy to deal with. Aspects of a system can be changed, inserted or removed at compile time, and become reusable. It is important to understand that the overall verification environment should be assembled using OOP to retain encapsulation and protection. NTB's Aspect-Oriented Extensions should be used only for constrained-random test specifications with the aim of minimizing code. SVs Aspect-Oriented Extensions should not be used to:
Code base classes and class libraries Debug, trace or monitor unknown or inaccessible classes Insert new code to fix an existing problem
For information on the creation and refinement of verification test benches, see the Reference Verification Methodology User Guide.
Aspect-Oriented Extensions in SV
In SV, AOP is supported by a set of directives and constructs that need to be processed before compilation. Therefore, an SV program with these Aspect oriented directives and constructs would need to be processed as per the definition of these directives and constructs in SV to generate an equivalent SV program that is devoid of aspect extensions, and consists of traditional SV. Conceptually, AOP is implemented as pre-compilation expansion of code. This chapter explains how AOE in SV are directives to SV compiler as to how the pre-compilation expansion of code needs to be performed. In SV, an aspect extension for a class can be defined in any scope where the class is visible, except for within another aspect extension. That is, aspect extensions can not be nested. An aspect oriented extension in SV is defined using a new top-level extends directive. Terms aspect and extends directive have been used interchangeably throughout the document. Normally, a class is extended through derivation, but an extends directive defines modifications to a pre-existing class by doing in-place extension of the class. in-place extension modifies the definition of a class by adding new member fields and member methods, and changing the
behavior of earlier defined class methods, without creating any new subclasse(s). That is, SVs Aspect-Oriented Extensions change the original class definition without creating subclasses. These changes affect all instances of the original class that was extended by AOEs. An extends directive for a class defines a scope in SV language. Within this scope exist the items that modify the class definition. These items within an extends directive for a class can be divided into the following three categories. Introduction Declaration of a new property, or the definition of a new method, a new constraint, or a new coverage group within the extends directive scope adds (or introduces) the new symbol into the original class definition as a new member. Such declaration/ definition is called an introduction. Advice An advice is a construct to specify code that affects the behavior of a member method of the class by weaving the specified code into the member method definition. This is explained in more detail later. The advice item is said to be an advice to the affected member method. Hide list: Some items within an extends directive, such as a virtual method introduction, or an advice to virtual method may not be permissible within the extends directive scope depending upon the hide permissions at the place where the item is defined. A hide list is a construct whose placement and arguments within the extends directive scope controls the hide permissions. There could be multiple hide lists within an extends directive.
dominate_list ::= dominates(extends_identifier {,extends_identifier}); extends_item_list ::= extends_item {extends_item} extends_item ::= class_item | advice | hide_list
class_item ::= class_property | class_method | class_constraint | class_coverage | enum_defn advice ::= placement procedure placement ::= before | after | around procedure ::= | optional_method_specifiers task task_identifier(list_of_task_proto_formals); | optional_method_specifiers function function_type function_identifier(list_of_function_proto_formals) endfunction advice_code ::= [stmt] {stmt} stmt ::= statement | proceed ; hide_list ::= hide([hide_item {,hide_item}]); hide_item ::= // Empty | virtuals | rules
The symbols in boldface are keywords and their syntax are as follows: extends_identifier
Name of the aspect extension. class_identifier Name of the class that is being extended by the extends directive. dominate_list Specifies extensions that are dominated by the current directive. Domination defines the precedence between code woven by multiple extensions into the same scope. One extension can dominate one or more of the other extensions. In such a case, you must use a comma-separated list of extends identifiers.
dominates(extends_identifier {,extends_identifier});
A dominated extension is assigned lower precedence than an extension that dominates it. Precedence among aspects extensions of a class determines the order in which introductions defined in the aspects are added to the class definition. It also determines the order in which advices defined in the aspects are woven into the class method definitions thus affecting the behavior of a class method. Rules for determination of precedence among aspects are explained later in Precedence on page 16. class_property Refers to an item that can be parsed as a property of a class. class_method Refers to an item that can be parsed as a class method. class_constraint
Refers to an item that can be parsed as a class constraint. class_coverage Refers to an item that can be parsed as a coverage_group in a class. advice_code Specifies to a block of statements. statement Is an SV statement. procedure_prototype A full prototype of the target procedure. Prototypes enable the advice code to reference the formal arguments of the procedure. opt_method_specifiers Refers to a combination of protection level specifier (local, or protected), virtual method specifier (virtual), and the static method specifier (static) for the method. task_identifier Name of the task. function_identifier Name of the function. function_type
Data type of the return value of the function. list_of_task_proto_formals List of formal arguments to the task. list_of_function_proto_formals List of formal arguments to the function. placement Specifies the position at which the advice code within the advice is woven into the target method definition. Target method is either the class method, or some other new method that was created as part of the process of weaving, which is a part of pre-compilation expansion of code. The overall details of the process of weaving are explained in Pre-compilation Expansion details. The placement element could be any of the keywords, before, after, or around, and the advices with these placement elements are referred to as before advice, after advice and around advice, respectively. proceed statement The proceed keyword specifies an SV statement that can be used within advice code. A proceed statement is valid only within an around block and only a single proceed statement can be used inside the advice code block of an around advice. It cannot be used in a before advice block or an after advice block. The proceed statement is optional. hide_list
Specifies the permission(s) for introductions to hide a symbol, and/ or permission(s) for advices to modify local and protected methods. It is explained in detail in Section , hide_list details, on page 13-30.
The following table shows the rest of the steps involved in weaving of the advice for each type of placement element (before, after, and around). Table 13-1
Element
before
Placement Elements
Description
Inserts a new method-call statement that calls an advice method. The statement is inserted as the first statement to be executed before any other statements. Creates a new method A with the target method prototype, with its first statement being a call to the target method. Second statement with A is a new method call statement that calls the advice method. All the instances in the input program where the target method is called are replaced by newly created method calls to A. A is replaced as the new target method. All the instances in the input program where the target method is called are replaced by newly created method calls to the advice method.
after
around
Within an extends directive, you can specify only one advice can be specified for a given placement element and a given method. For example, an extends directive may contain a maximum of one before, one after, and one around advice each for a class method Packet::foo of a class Packet, but it may not contain two before advices for the Packet::foo. Example 13-1 before Advice Target method:
class packet; task myTask(); $display("Executing original code\n"); endtask
endclass
Advice:
before task myTask (); $display("Before in aoe1\n"); endtask
Note that the SV language does not impose any restrictions on the names of newly created methods during pre-compilation expansion, such as mytask_before. Compilers can adopt any naming conventions such methods that are created as a result of the weaving process. Example 13-2 after Advice
Target method:
class packet; task myTask(); $display("Executing original code\n"); endtask endclass
Advice:
after task myTask (); $display("Before in aoe1\n"); endtask
As a result of weaving, all the method calls to myTask() in the input program code are replaced by method calls to myTask_newTarget(). Also, myTask_newTarget replaces myTask as the target method for myTask(). Example 13-3 around Advice
Target method:
class packet; task myTask(); $display("Executing original code\n"); endtask endclass
Advice:
around task myTask (); $display("Around in aoe1\n"); endtask
task myTask_around(); $display("Around in aoe1\n"); endtask task myTask(); $display("Executing original code\n"); endtask
As a result of weaving, all the method calls to myTask() in the input program code are replaced by method calls to myTask_around(). Also, myTask_around() replaces myTask() as the target method for myTask(). During weaving of an around advice that contains a proceed statement, the proceed statement is replaced by a method call to the target method. Example 13-4 around Advice with proceed
Target method:
class packet; task myTask(); $display("Executing original code\n"); endtask endclass
Advice:
around task myTask (); proceed; $display("Around in aoe1\n"); endtask
As a result of weaving, all the method calls to myTask() in the input program code are replaced by method calls to myTask_around(). The proceed statement in the around code is replaced with a call to the target method myTask(). Also, myTask_around replaces myTask as the target method for myTask().
Precedence
Precedence is specified through the dominate_list (see dominate_list on page 7) There is no default precedence across files; if precedence is not specified, the tool is free to weave code in any order. Within a file, dominance established by dominate_lists always overrides precedence established by the order in which extends directives are coded. Only when the precedence is not established after analyzing the dominate lists of directives, is the order of coding used to define the order of precedence. Within an extends directive there is an inherent precedence between advices. Advices that are defined later in the directive have higher precedence that those defined earlier. Precedence does not change the order between adding of introductions and weaving of advices in the code. Precedence defines the order in which introductions to a class are added to the class, and the order in which advices to methods belonging to a class are woven into the class methods. Example 13-5 Precedence Using dominates
// Beginning of file test.sv class packet; // Other member fields/methods //... task send(); $display("Sending data\n"); endtask endclass program top ;
initial begin packet p; p = new(); p.send(); end endprogram extends aspect_1(packet) dominates (aspect_2, aspect_3); after task send(); // Advice 1 $display("Aspect_1: send advice after\n"); endtask endextends extends aspect_2(packet); after task send() ; // Advice 2 $display("Aspect_2: send advice after\n"); endtask endextends
extends aspect_3(packet); around task send(); // Advice 3 $display("Aspect_3: Begin send advice around\n"); proceed; $display("Aspect_3: End send advice around\n"); endtask before task send(); // Advice 4 $display("Aspect_3: send advice before\n"); endtask endextends // End of file test.sv
In Example 13-5, multiple aspect extensions for a class named packet are defined in a single SV file. As specified in the dominating list of aspect_1, aspect_1 dominates both aspect_2 and aspect_3.
Aspect Oriented Extensions 13-17
As per the dominating lists of the aspect extensions, there is no precedence order established between aspect_2 and aspect_3, and since aspect_3 is coded later in Input.vr than aspect_2, aspect_3 has higher precedence than aspect_2. Therefore, the precedence of these aspect extensions in the decreasing order of precedence is: {aspect_1, aspect_3, aspect_2} This implies that the advice(s) within aspect_2 have lower precedence than advice(s) within aspect_3, and advice(s) within aspect_3 have lower precedence than advice(s) within aspect_1. Therefore, advice 2 has lower precedence than advice 3 and advice 4. Both advice 3 and advice 4 have lower precedence than advice 1. Between advice 3 and advice 4, advice 4 has higher precedence as it is defined later than advice 3. That puts the order of advices in the increasing order of precedence as: {2, 3, 4, 1}. Adding of Introductions Target scope refers to the scope of the class definition that is being extended by an aspect. Introductions in an aspect are appended as new members at the end of its target scope. If an extension A has precedence over extension B, the symbols introduced by A are appended first. Within an aspect extension, symbols introduced by the extension are appended to the target scope in the order they appear in the extension.
There are certain rules according to which an introduction symbol with the same identifier name as a symbol that is visible in the target scope, may or may not be allowed as an introduction. These rules are discussed later in the chapter. Weaving of advices An input program may contain several aspect extensions for any or each of the different class definitions in the program. Weaving of advices needs to be carried out for each class method for which an advice is specified. Weaving of advices in the input program consists of weaving of advices into each such class method. Weaving of advices into a class method A is unrelated to weaving of advices into a different class method B, and therefore weaving of advices to various class methods can be done in any ordering of the class methods. For weaving of advices into a class method, all the advices pertaining to the class method are identified and ordered in the order of increasing precedence in a list L. This is the order in which these advices are woven into the class method thereby affecting the runtime behavior of the method. The advices in list L are woven in the class method as per the following steps. Target method is initialized to the class method. a. Advice A that has the lowest precedence in L is woven into the target method as explained earlier. Note that the target method may either be the class method or some other method newly created during the weaving process. b. Advice A is deleted from list L. c. The next advice on list L is woven into the target method. This continues until all the advices on the list have been woven into list L.
It would become apparent from the example provided later in this section how the order of precedence of advices for a class method affects how advices are woven into their target method and thus the relative order of execution of advice code blocks. Before and after advices within an aspect to a target method are unrelated to each other in the sense that their relative precedence to each other does not affect their relative order of execution when a method call to the target method is executed. The before advices code block executes before the target method code block, and the after advice code block executes after the target method code block. When an around advice is used with a before or after advice in the same aspect, code weaving depends upon their precedence with respect to each other. Depending upon the precedence of the around advice with respect to other advices in the aspect for the same target method, the around advice either may be woven before all or some of the other advices, or may be woven after all of the other advices. As an example, weaving of advices 1, 2, 3, 4 specified in aspect extensions in Example 13-5 leads to the expansion of code in the following manner. Advices are woven in the order of increasing precedence {2, 3, 4, 1} as explained earlier. Example 13-6 After Weaving Advice-2 of Class packet
// Beginning of file test.sv program top ; packet p; p = new(); p.send_Created_a(); endprogram class packet; ... // Other member fields/methods ... task send(); p$display("Sending data\n);
endtask task send_Created_a(); send(); send_after_Created_b(); endtask task send_after_Created_b(); $display("Aspect_2: send advice after\n"); endtask endclass extends aspect_1(packet) dominates (aspect_2, aspect_3); after task send(); // Advice 1 $display("Aspect_1: send advice after\n"); endtask endextends extends aspect_3(packet); around task send(); // Advice 3 $display("Aspect_3: Begin send advice around\n"); proceed; $display("Aspect_3: End send advice around\n"); endtask before task send(); // Advice 4 $display("Aspect_3: send advice before\n"); endtask endextends // End of file test.sv
This Example 13-6 shows what the input program looks like after weaving advice 2 into the class method. Two new methods send_Created_a and send_after_Created_b are created in the process and the instances of method call to the target method packet::send are modified, such that the code block from advice 2 executes after the code block of the target method packet::send. Example 13-7 After Weaving Advice-3 of Class packet
// Beginning of file test.sv program top;
packet p; p = new(); p.send_around_Created_c(); endprogram class packet; ... // Other member fields/methods ... task send(); $display("Sending data\n); endtask task send_Created_a(); send(); send_after_Created_b(); endtask task send_after_Created_b(); $display("Aspect_2: send advice after\n"); endtask task send_around_Created_c(); $display("Aspect_3: Begin send advice around\n"); send_Created_a(); $display("Aspect_3: End send advice around\n"); endtask endclass extends aspect_1(packet) dominates (aspect_2, aspect_3); after task send(); // Advice 1 $display("Aspect_1: send advice after\n"); endtask endextends extends aspect_3(packet); before task send(); // Advice 4 $display("Aspect_3: send advice before\n"); endtask endextends // End of file test.sv
This Example 13-7 shows what the input program looks like after weaving advice 3 into the class method. A new method send_around_Created_c is created in this step and the instances of
method call to the target method packet::send_Created_a are modified, such that the code block from advice 3 executes around the code block of method packet::send_Created_a. Also note that the proceed statement from the advice code block is replaced by a call to send_Created_a. At the end of this step, send_around_Created_c becomes the new target method for weaving of further advices to packet::send. Example 13-8 After Weaving Advice-4 of Class packet
// Beginning of file test.sv program top; packet p; p = new(); p.send_around_Created_c(); endprogram class packet; ... // Other member fields/methods ... task send(); $display("Sending data\n); endtask task send_Created_a(); send(); send_after_Created_b(); endtask task send_after_Created_b(); $display("Aspect_2: send advice after\n"); endtask task send_around_Created_c(); send_before_Created_d(); $display("Aspect_3: Begin send advice around\n"); send_after_Created_a(); $display("Aspect_3: End send advice around\n"); endtask task send_before_Created_d(); $display("Aspect_3: send advice before\n");
endtask endclass extends aspect_1(packet) dominates (aspect_2, aspect_3); after task send(); // Advice 1 $display("Aspect_1: send advice after\n"); endtask endextends // End of file test.sv
This Example 13-8 shows what the input program looks like after weaving advice 4 into the class method. A new method send_before_Created_d is created in this step and a call to it is added as the first statement in the target method packet::send_around_Created_c. Also note that the outcome would have been different if advice 4 (before advice) was defined earlier than advice 3 (around advice) within aspect_3, as that would have affected the order of precedence of advice 3 and advice. In that scenario the advice 3 (around advice) would have weaved around the code block from advice 4 (before advice), unlike the current outcome. Example 13-9 After Weaving all{2,3,4,1} Advices of Class packet
// Beginnning of file test.sv program top; packet p; p = new(); p.send_Created_f(); endprogram class packet; ... // Other member fields/methods ... task send(); $display("Sending data\n); endtask task send_Created_a();
send(); send_Created_b(); endtask task send_after_Created_b(); $display("Aspect_2: send advice after\n"); endtask task send_around_Created_c(); send_before_Created_d(); $display("Aspect_3: Begin send advice around\n"); send_after_Created_a(); $display("Aspect_3: End send advice around\n"); endtask task send_before_Created_d(); $display("Aspect_3: send advice before\n"); endtask task send_after_Created_e(); $display("Aspect_1: send advice after\n"); endtask task send_Created_f(); send_around_Created_c(); send_after_Created_e() endtask endclass // End of file test.sv
This Example 13-9 shows the input program after weaving of all four advices {2, 3, 4, 1}. New methods send_after_Created_e and send_Created_f are created in the last step of weaving and the instances of method call to packet::send_around_Created_c were replaced by method call to packet::send_Created_f. When executed, output of this program is:
Aspect_3: send advice before Aspect_3: Begin send advice around Sending data Aspect_2: send advice after Aspect_3: End send advice around Aspect_1: send advice after
When aoe1 dominates aoe2, as in func1, the output when the program is executed is:
Executing original code around in aoe2 around in aoe1
Example 13-11
// Begin file test.sv class foo; int i; task myTask(); $display("Executing original code\n"); endtask endclass extends aoe1 (foo); around task myTask(); proceed; $display("around in aoe1\n"); endtask endextends extends aoe2 (foo) dominates (aoe1); around task myTask(); proceed; $display("around in aoe2\n"); endtask endextends program top; foo f; initial begin f = new(); f.myTask(); end endprogram // End file test.sv
On the other hand, when aoe2 dominates aoe1 as in this Example 13-11, the output is:
Executing original code around in aoe1 around in aoe2
Symbol Resolution Details: As introductions and advices defined within extends directives are pre-processed as a pre-compilation expansion of the input program, the pre-processing occurs earlier than final symbol resolution stage within a compiler. Therefore, it possible for AOE code to reference symbols that were added to the original class definition using AOEs. Because advices are woven after introductions have been added to the class definitions, advices can be specified for introduced member methods and can reference introduced symbols. An advice to a class method can access and modify the member fields and methods of the class object to which the class method belongs. An advice to a class function can access and modify the variable that stores the return value of the function. Furthermore, members of the original class definition can also reference symbols introduced by aspect extensions using the extern declarations (?). Extern declarations can also be used to reference symbols introduced by an aspect extension to a class in some other aspect extension code that extends the same class. An introduction that has the same identifier as a symbol that is already defined in the target scope as a member property or member method is not permitted. Examples: Example 13-12 before Advice on Class Task
// Begin file test.sv class packet; task foo(integer x); //Formal argument is "x" $display("x=%0d\n", x); endtask endclass
extends myaspect(packet); // Make packet::foo always print: "x=99" before task foo(integer x); x = 99; //force every call to foo to use x=99 endtask endextends program top; packet p; initial begin p = new(); p.foo(100); end endprogram // End file test.sv
The extends directive in Example 13-12 sets the x parameter inside the foo() task to 99 before the original code inside of foo() executes. Actual argument to foo() is not affected, and is not set unless passed-by-reference using ref. Example 13-13 after Advice on Class Function
// Begin file test.sv class packet ; function integer bar(); bar = 5; $display("Point 1: Value = %d\n", bar); endfunction endclass extends myaspect(packet); after function integer bar(); $display("Point 2: Value = %d\n", bar); bar = bar + 1; // Stmt A $display("Point 3: Value = %d\n", bar); endfunction endextends program top ;
Aspect Oriented Extensions 13-29
packet p; initial begin p = new(); $display("Output is: %d\n", p.bar()); end endprogram // End file test.sv
An advice to a function can access and modify the variable that stores the return value of the function as shown in Example 13-13, in this example a call to packet::bar returns 6 instead of 5 as the final return value is set by the Stmt A in the advice code block. When executed, the output of the program code is:
Point 1: Value = 5 Point 2: Value = 5 Point 3: Value = 6 Output is: 6
hide_list details The hide_list item of an extends_directive specifies the permission(s) for introductions to hide symbols, and/or advice to modify local and protected methods. By default, an introduction does not have permission to hide symbols that were previously visible in the target scope, and it is an error for an extension to introduce a symbol that hides a global or super-class symbol. The hide_list option contains a comma-separated list of options such as:
The virtuals option permits the hiding (that is, overriding) of virtual methods defined in a super class. Virtual methods are the only symbols that may be hidden; global, and file-local tasks and functions may not be hidden. Furthermore, all introduced methods must have the same virtual modifier as their overridden superclass and overriding sub-class methods. The rules option permits the extension to suspend access rules and to specify advice that changes protected and local virtual methods; by default, extensions cannot change protected and local virtual methods. An empty option list removes all permissions, that is, it resets permissions to default. In Example 13-14, the print method introduced by the extends directive hides the print method in the super class.
program test; packet tr; pbase base; initial begin tr = new(); tr.print(); base = tr; base.print(); end endprogram
As explained earlier, there are two types of hide permissions: a. Permission to hide virtual methods defined in a super class (option virtuals) is referred to as virtuals-permission. An aspect item is either an introduction, an advice, or a hide list within an aspect. If at an aspect item within an aspect, such permission is granted, then the virtuals-permission is said to be on or the status of virtuals-permission is said to be on at that aspect item and at all the aspect items following that, until a hide list that forfeits the permission is encountered. If virtuals-permission is not on or the status of virtuals-permission is not on at an aspect item, then the virtuals-permission at that item is said to be off or the status of virtuals-permission at that item is said to be off b. Permission to suspend access rules and to specify advice that changes protected and local virtual methods (option "rules") is referred to as rules-permission. If within an aspect, at an aspect item, such permission is granted, then the rules-permission is said to be on or the status of rules-permission is said to be on at that aspect item and at all the aspect items following that, until a hide list that forfeits the permission is encountered. If rules-permission is not on or the status of rules-permission is not on at an aspect item, then the rules-permission at that item is said to be off or the status of rules-permission at that item is said to be off.
Permission for one of the above types of hide permissions does not affect the other. Status of rules-permission and hide-permission varies with the position of an aspect item within the aspect. Multiple hide_list(s) may appear in the extension. In an aspect, whether an introduction or an advice that can be affected by hide permissions is permitted to be defined at a given position within the aspect extension is determined by the status of the relevant hide permission at the position. A hide_list at a given position in an aspect can change the status of rules-permission and/or virtuals-permission at that position and all following aspect items until any hide permission status is changed again in that aspect using hide_list. Example 13-15 illustrates how the two hide permissions can change at different aspect items within an aspect extension. Example 13-15 Hide Permissions
class pbase; virtual task print1(); $display("pbase::print1\n"); endtask virtual task print2(); $display("pbase::print2\n"); endtask endclass class packet extends pbase; task foo(); rules_test(); endtask local virtual task rules_test(); $display("Rules-permission example\n"); endtask endclass
extends myaspect(packet);
// At this point within the myaspect scope, // virtuals-permission and rules-permission are both off. hide(virtuals); // Grants virtuals-permission // virtuals-permission is on at this point within aspect, // and therefore can define print1 method introduction. virtual task print1(); $display("packet::print1\n."); endtask hide(); // virtuals-permission is forfieted
hide(rules); // Grants rules-permission // Following advice permitted as rules-permission is on before local virtual task rules_test(); $display("Advice to Rules-permission example\n"); endtask hide(virtuals); // Grants virtuals-permission // virtuals-permission is on at this point within aspect, // and therefore can define print2 method introduction. virtual task print2(); $display("packet::print2\n."); endtask endextends program test; packet tr; initial begin tr = new(); tr.print1(); tr.foo(); tr.print2(); end endprogram
Examples Introducing new members into a class: Example 13-16 shows how AOE can be used to introduce new members into a class definition. myaspect adds a new property, constraint, coverage group, and method to the packet class. Example 13-16 Introducing New Member
class packet; rand bit[31:0] hdr_len; endclass extends myaspect(packet); integer sending_port; event cg_trigger; constraint con2 { hdr_len == 4; } covergroup cov2 @(cg_trigger); coverpoint sending_port; endgroup task print_sender(); $display("Sending port = %0d\n", sending_port); endtask endextends program test; packet tr; initial begin tr = new(); void'(tr.randomize()); tr.sending_port = 1; tr.print_sender(); -> tr.cg_trigger; end
endprogram
As mentioned earlier, new members that are introduced should not have the same name as a symbol that is already defined in the class scope. So, AOE defined in the manner shown in Example 13-17 will is not allowed, as the aspect myaspect defines x as one of the introductions when the symbol x is already defined in class foo. Example 13-17 Non-permissible Introduction
class foo; rand integer myfield; integer x; endclass extends myaspect(foo); integer x ; constraint con1 { myfield == 4; } endextends
program test; foo tr; initial begin tr = new(); $display("Non-permissible introduction error....!"); void'(tr.randomize()); end endprogram
Examples of advice code In Example 13-18, the extends directive adds advices to the packet::send method.
In Example 13-19, extends directive myaspect adds advice to turn off constraint c1 before each call to the foo::pre_randomize method.
In Example 13-20, extends directive myaspect adds advice to set a property named valid to 0 after each call to the foo::post_randomize method. Example 13-20 Change Property Value After post-randomize()
class foo; integer valid; rand integer myfield; constraint c1 { myfield inside {[0:6]}; }
endclass extends myaspect(foo); after function void post_randomize(); if (myfield > 6) valid = 0; else valid = 1; endfunction endextends program test; foo tr; initial begin tr = new(); void'(tr.randomize()); $display("valid = %0d ", tr.valid); end endprogram
Example 13-21 shows an aspect extension that defines an around advice for the class method packet::send. When the code in example is compiled and run, the around advice code is executed instead of original packet::send code. Example 13-21 Changing Test Functionality Using around Advice
// Begin file test.sv class packet; integer len; task setLen( integer i); len = i; endtask task send(); $display("Sending data\n."); endtask endclass program test;
Aspect Oriented Extensions 13-39
packet p; initial begin p = new(); p.setLen(5000); p.send(); p.setLen(10000); p.send(); end endprogram
extends myaspect(packet); around task send(); if (len < 8000) proceed; else $display("Dropping packet\n"); endtask endextends // End file test.sv
This Example 13-21 also demonstrates how the around advice code can reference properties such as len in the packet object p. When executed the output of the above example is,
Sending data Dropping packet
14
Using Constraints
This chapter explains VCS support for the following constraints features: Inconsistent Constraints on page 2 Constraint Debug on page 3 Constraint Debug Using DVE on page 16 Constraint Guard Error Suppression on page 16 Array and XMR Support in std::randomize() on page 20 XMR Support in Constraints on page 22 State Variable Index in Constraints on page 25 Using Soft Constraints in SystemVerilog on page 26 Using DPI Function Calls in Constraints on page 37
Inconsistent Constraints
VCS correctly identifies inconsistent constraints while trying to find the minimal set causing the inconsistency. VCS supports two options to find inconsistent constraints: binary search and linear search. You can use two new options to set larger timeout values. The default timeout values for each iteration of the constraint solver are 100 seconds for the binary search and 10 seconds for the linear search. You can set larger timeout values in seconds. For example:
simv +ntb_binary_debug_solver_cpu_limit=200 simv +ntb_linear_debug_solver_cpu_limit=20
Note: If the constraint solver timeout value is too low, VCS may not be able to find the minimal set of conflicting constraints. If the solver timeout value is too high, performance may degrade while finding a conflict. Therefore, setting optimal timeout values is important. Inconsistent constraints are non-fatal by default. VCS continues to run after a constraint failure. Use the +ntb_stop_on_constraint_solver_error=0|1 option, where 1 enables stop on first error and 0 disables stop on first error to control how VCS handles these inconsistencies. For example, to make VCS stop the simulation on the first constraint failure, use the following command line:
simv +ntb_stop_on_constraint_solver_error=1
When VCS detects inconsistent constraints, the default printing mode only displays the failure subset. For example: The solver failed when solving following set of constraints
rand integer rand integer rand integer constraint c { ( x < 1 ) ; ( x in { 3 , } y; z; x; // // rand_mode = ON // rand_mode = ON // rand_mode = ON (from this) (constraint_mode = ON)
5 , 7 : 11 } ) ;
You can use the +ntb_enable_solver_trace_on_failure=0|1|2|3 runtime option as follows: 0 1 2 3 Print a one-line failure message with no details. Print only the failure subset (this is the default). Print the entire constraint problem and failure subset. Print only the failure problem. This is useful when the solver fails to determine the minimum subset.
Constraint Debug
Generally, there are two kinds of constraint debug scenarios. In the first scenario, VCS solves the random variables but the user wishes to get a better understanding how the random variables are solved. This is about debugging the solved values. In the second scenario, VCS either times out when solving or solves after a long time. This is about performance debug.
The following sections describe the VCS features that can help with these kinds of constraint debug. - Partition on page 4 - Randomize Serial Number on page 6 - Solver Trace on page 7 - Test Case Extraction on page 13 - Using multiple +ntb_solver_debug arguments on page 15 - Summary for +ntb_solver_debug on page 15
Partition
Whether it is std::randomize or the randomization of a class object, it generally involves one or more state and random variables. Constraints are used to describe relationships that between these variables. An important concept of constrained randomization is the notion of partitions. In other words, a randomize call is partitioned into one or more smaller constraint problems to solve. At run time, VCS groups all the related random variables involved in each randomization into one or more partitions. If there are no constraints between two random variables, they are not solved in the same partition. Here is an example to illustrate this concept:
class myClass; rand int x; rand int y; rand int z; rand byte a; rand byte b; bit c; constraint m { x > z;
myClass obj = new; obj.randomize(); // 1st randomize() call obj.randomize() with {x!=y;}; // 2nd randomize() call
For the first randomize call, the following constraints are used to solve the five random variables: x, y, z, a, and b and VCS creates three partitions for these random variables.
x > z; c -> a == b; y > 0; // from the constraint block m // from the constraint block m // from the constraint block n
The random variables x and z are grouped in one partition because of a constraint (x > z) relating the two together. The random variables a and b are grouped in another partition because of the constraint (c -> a == b). There are no constraints between y and any other random variable. So y is on a third partition of its own. Because the random variables from different partitions are not constrained together, they do not have to be solved in any particular order. For the second randomize() call, a new constraint is added in the inline constraint (that is randomize() with). Here are the four constraints for the same 5 random variables.
x c y x
// // // // //
from the constraint block m from the constraint block m from the constraint block n from the inline constraint randomize() with ..
For this second randomize call, two partitions are created. The first partition has the random variables: x, y, and z because the following constraints relate all three together: (x > z), (y > 0), and (x != y). The second partition has the random variables a and b because of the (c -> a == b) constraint.
After each randomization completes, VCS prints the randomize serial number along with some run time and memory data for the randomize() call.
Using a randomize serial number provides a mechanism to focus the constraint debug on a specific randomize() call. If the randomize serial number is used together with the partition number, it is the specified partition within the specified randomize call that becomes the focus for the constraint debug. To specify the nth partition of the mth randomize call, the notation m.n is used.
Solver Trace
To get more insight to how VCS solves a randomize call, you can enable solver trace reporting by using the +ntb_solver_debug=trace runtime option. Here is an example of the solver trace:
// Part.sv class C; rand byte x, y, z, m, n, p, q; constraint imply { x > 3 -> y > p; z < bigadd ( x, q ); n != 0; } function byte bigadd (byte a, b); return (a + b); endfunction endclass program automatic test; C obj = new; initial begin repeat (5) begin obj.randomize() with { m == z; };
// C1 // C2 // C3
// C4
For this example, let us determine the partitions that will be created by the solver. The SystemVerilog LRM mandates that function arguments must be solved first in order to compute the function that is used to constraint other random variables. In other words, separate partitions must be created for (x, q) and then for z. The constraint expression C1 relates the random variables, x, y, p together. So they are solved together in one partition. The constraint expression C2 using function call in constraint requires that z is solved in a different partition from x and q. Since the random variable q is not related to any other random variables, q is solved in a partition on its own. Similarly, the random variable n is not related to any other random variables, n is solved in another partition on its own. The constraint expression C4 is an inline constraint relating the two random variables, m and z, together. Therefore, m and z will be solved together in one partition. Given the above descriptions, you can see four partitions will be created. Partition 1 to solve x, y, p together Partition 2 to solve n alone Partition 3 to solve q alone Partition 4 to solve z and m together
To compile and run this example and enable solver trace for the third randomize call:
vcs sverilog part.sv simv +ntb_solver_debug=trace +ntb_solver_debug_filter=3
Part of the solver trace will show the partition information. Here is a part of the solver trace from the command above.
======================================================= SOLVING constraints At file part.sv, line 20, serial 3 Rng state is: 01x0z11xzxxx11zx1xz0zx100zxxzzz0zxxzzzzxzzzxxzxzzzzzxzzzzz xxzxxz Virtual class C, Static class C Solving Partition 1 (mode = 2) rand bit signed [7:0] y; // rand_mode = ON rand bit signed [7:0] p; // rand_mode = ON rand bit signed [7:0] x; // rand_mode = ON ... Solving Partition 2 (mode = 2) rand bit signed [7:0] n; // rand_mode = ON ... Solving Partition 3 (mode = 2) rand bit signed [7:0] q; // rand_mode = ON ...
Solving Partition 4 (mode = 2) bit signed [7:0] fv_3 /* this .C::bigadd( x , q ) */ = -127; rand bit signed [7:0] z; // rand_mode = ON rand bit signed [7:0] m; // rand_mode = ON
It is required to specify the randomize() call(s) and/or partitions(s) to report the solver trace details. For example: The following command reports the solver trace for the second randomize() call and all partitions within this randomize() call of the simulation.
simv +ntb_solver_debug=trace +ntb_solver_debug_filter=2
The following command reports the solver trace for the third partition of the fifth randomize() call of the simulation.
simv +ntb_solver_debug=trace +ntb_solver_debug_filter=5.3
If the solver trace is to be enabled for multiple randomize calls, you can specify the list of random serial and, optionally, partition numbers in a comma separated list for the +ntb_solver_debug_filter option. For example: the following command reports the solver traces for the following randomize() calls and their partitions: Serial number 2, all partitions of this second randomize() call Serial number 5, just the third partition of this fifth randomize() call Serial number 10, all partitions of this tenth randomize() call Serial number 15, just the 30th partition of this 15th randomize() call.
The following command reports the solver traces for the randomize() calls or partitions listed in a text file, for example if serial_trace.txt is the file name.
simv +ntb_solver_debug=trace \ +ntb_solver_debug_filter=file:serial_trace.txt
The following command reports the solver traces for all randomize() calls in the simulation. Be aware that this may produce a lot of data if there are many randomize() calls in the simulation.
simv +ntb_solver_debug=trace +ntb_solver_debug_filter=all
or
simv +ntb_solver_debug=trace_all
The +ntb_solver_debug_filter is not needed on the second simv command line. Note: Reporting solver traces for all randomize() calls can generate very large data files. Using the +ntb_solver_debug=trace and +ntb_solver_debug_filter=serial_num|file options and arguments limit the solver trace reports to the one(s) on which you want to focus the constraint debug.
Constraint debugging capability is also in DVE, including a similar solver trace capability to understand the details of a randomize() call and many graphical user interface features, such as cross probing, search, and filters to make debugging constraints faster and easier. For more information see the DVE User Guide.
Constraint Profiler
To debug any performance related issues, profiling is required to identify the top consumers of time/memory. VCS provides a constraint profiler feature that can be enabled by using the +ntb_solver_debug=profile runtime option and keyword argument.
simv +ntb_solver_debug=profile
This simv command line runs the simulation and collects runtime and memory data on each of the randomize() calls in the simulation. The randomize calls/partitions that take the most time and memory will be listed out in a constraint profile report in the file simv.cst/html/profile.xml, where simv is the name of the simulation executable. To view the constraint profile report in simv.cst/html/ profile.xml, open the file with the Firefox or Chrome web browser. Viewing this file in Internet Explorer on Windows is not supported. The random serial numbers for the randomize calls and/or partitions that take the most time are listed in the simv.cst/ serial2trace.txt file.
This extracts a test case for each of the partitions of the randomize() call. Extracted test cases are saved in the simv.cst/testcases directory, where simv is the name of the simulation executable. The extracted test cases follow this naming convention:
extracted_r_serial#_p_partition#.sv
Once extracted, you can follow the commands below to compile and run the standalone test case. For example, to simulate the extracted test case for the third partition of the second randomize() call of the original design:
-R
Similar to reporting solver traces for a single partition or for multiple randomize() calls and their partitions, you can enable test case extraction for these too. For example:
simv +ntb_solver_debug=extract \ +ntb_solver_debug_filter=5.3 simv +ntb_solver_debug=extract \ +ntb_solver_debug_filter=2,5.3,10,15.30 simv +ntb_solver_debug=extract \ +ntb_solver_debug_filter=file:serial_trace.txt
Note: You can only extract test cases from a partition. If VCS fails before any partition is created, test case extraction does not work. When VCS encounters a randomize() call that has no solution or has constraint inconsistencies, VCS MX automatically extracts a test for it and saves the extracted test case using the following naming convention:
simv.cst/testcases/ extracted_r_serial#_p_partition#_inconsistency.sv
When VCS fails to solve a randomize() call due to solver time outs, test case extraction is also automatically enabled for it and VCS saves the extracted test case using the following naming convention:
simv.cst/testcases/ extracted_r_serial#_p_partition#_timeout.sv
+ntb_solver_debug=serial
The serial number assignment to the randomizations in a simulation provides a method to identify the randomize() calls to be debugged next. Once identified, you can use this runtime option with appropriate arguments to report the trace and extract test cases. The constraint profiler also uses the same identification method to provide feedback to you which specific randomize() calls to optimize for best performance improvements.
+ntb_solver_debug=trace
This enables solver trace reporting for the specified randomize() calls. This helps the user to understands how VCS solves the random variables for given randomize calls. The +ntb_solver_debug_filter option is required to specify a list of randomize() calls for which to enable the solver trace.
+ntb_solver_debug=profile
This enables constraint profiling for the simulation at runtime. The profile report provides important information to you which randomize calls should be targeted for improving constraint performance to bring down the total simulation run time or memory.
+ntb_solver_debug=extract
This enables test case extraction for the specified randomize calls. This creates standalone test cases for you to compile and run outside of the original design. This should help quicker turnaround time to experiment possible fixes as it is faster to compile and run a smaller test case. The +ntb_solver_debug_filter option is required to specify a list of randomize calls for which to enable test case extraction.
Accessing null pointer obj.x in constraints. Please make sure variable obj.x is allocated.
Guarded constraints are defined in the SystemVerilog LRM (section 13.4; especially sections 13.4.5, 13.4.6, and 13.4.12). The VCS constraint solver does not distinguish between implication (LRM section 13.4.5) and if-else constraints (LRM section 13.4.6). They are equivalent representations in the VCS constraint solver. We call them guarded constraints in this document. Hence, the two formats shown in Example 14-1 are equivalent inside the VCS constraint solver. Example 14-1 Guarded Expressions
if (a | b | c) { obj.x == 10; }
In Example 14-1, the expression inside the if condition (or the left side of the implication operator) is the guard expression. The remaining part of the expression (the right side of the implication operator) is the implied expression. Note: If there are other types of errors or conflicts, VCS does not guarantee suppression of those errors in the implied expression of the guard constraint.
The LRM says that the implication operator (or the if-else statement) should be at the top level of each constraint. Therefore, a constraint may have at most one guard (or one implication operator).
VCS flattens the guard expression into the following equivalent code:
if (a && b && c) { obj.x == 10; }
In the above example, if a is false, and b has an error (for example, a null address error), VCS still generates the error message.
In the above example, if a | b | c is false, and array has an error (for example, a null address error), VCS still generates the error message.
Note: VCS does not support multidimensional, variable-sized arrays. Array elements are also supported as arguments to std::randomize(). VCS supports all types of XMRs: class XMRs package XMRs interface XMRs
You can use arrays, array elements, and XMRs as arguments to std::randomize(). Syntax
integer fa[3]; success= std::randomize(fa); success= std::randomize(fa[2]); success= std::randomize(pkg::xmr);
Example
module test; integer i, success; integer fa[3]; initial begin foreach(fa[i]) $display("%d %d\n", i, fa[i]); success = std::randomize(fa); foreach(fa[i]) $display("%d %d\n", i, fa[i]); end endmodule
When std::randomize() is called, VCS ignores any rand mode specified on class member arrays or array elements that are used as arguments. This is consistent with how std::randomize() is specified in the SystemVerilog LRM. This means that for purposes of std::randomize() calls, all arguments have rand mode ON, and none of them are randc.
Error Conditions
If you specify an argument to a std::randomize() array element which is outside the range of the array, VCS prints the following error message:
Error-[CNST-VOAE] Constraint variable outside array error
Random variables are not allowed as part of an array index. If you specify an XMR argument in a std::randomize() call, and that XMR that cannot be resolved, VCS prints an error message.
Syntax
constraint general { varxmr1 == 3; pkg::varxmr2 == 4; } c.randomize with { a.b == 5; }
pkg::C inst = new; endpackage module test; import pkg::*; initial begin inst.randomize() with {pkg::C::stren == STRONG;}; $display("%d", pkg::C::stren); end endmodule
Functional Clarifications XMR resolution in constraints (that is, choosing to which variable VCS binds an XMR variable) is consistent with XMR resolution in procedural SystemVerilog code. VCS first tries to resolve an XMR reference in the local scope. If the variable is not found in the local scope, VCS searches for it in the immediate upper enclosing scope, and so on, until it finds the variable. If you specify an XMR variable that cannot be resolved in any parent scopes of the constraint/scope where it is used, VCS errors out and prints an error message.
For randomize without a list of arguments (obj.randomize) variables declared as non-random, or declared as random but with rand mode OFF, are considered to be state variables.
Array Index
The variable (or supported expression) used for an array index must be an integral data type. If the value of the expression or the state variable evaluates out of bounds, comes to a negative index value, references a non-existent array member, or contains X or Z, VCS issues a runtime error message.
Soft Constraint Prioritization on page 28 Soft Constraints Defined in Classes Instantiated as rand Members in Another Class on page 30 Soft Constraints Inheritance Between Classes on page 32 Soft Constraints in AOP Extensions to a Class on page 32 Soft Constraints in View Constraints Blocks on page 34 Discarding Lower-Priority Soft Constraints on page 35
Note: If you use the word soft as the name of a random variable or a named value for an enumerated type in a constraint context, VCS issues an error message when the -xlrm soft compilation option is used, because it treats soft as a keyword to provide the soft constraint functionality. If soft constraint functionality is not required and the -xlrm soft option is not used, VCS treats soft as a regular SystemVerilog identifier.
In this schema, soft constraints in any extends blocks applied to a class are assigned the highest priority.
In this documentation, we use the following notation to describe the priority of a given soft constraint (SC): priority(SCx) If the following is true: priority(SC2) > priority(SC1) then VCS disables constraint SC1 before constraint SC2 when there is a conflict.
In Example 14-5, priority(SC2) > priority(SC1). Example 14-5 SC2 Higher Priority than SC1
Example 14-6
class A; rand int x; constraint c1 { soft x == 2; } // SC1 endclass class B; rand int x; constraint c2 { soft x == 5; } // SC2 constraint c3 { soft x == 3; } // SC3 endclass class C; rand int x; rand A objA; rand B objB; constraint c4 constraint c5 constraint c6 function new(); objA = endfunction endclass
{ soft x == objA.x; } // SC4 { soft objA.x < objB.x; } // SC5 { soft x == 4; } // SC6 new; objB = new;
program test; C objC; initial begin objC = new; objC.randomize(); $display(objC.x); /// should print "4" $display(objC.objA.x); // should print "4" $display(objC.objB.x); // should print "5" end endprogram
For array members where objects are allocated prior to randomization, priorities are assigned in increasing order by position in the array, where soft constraints in element N have lower priority than soft constraints in element N+1.
For array members where the objects are allocated during randomization, all soft constraints in allocated objects and their base classes and member classes have the same priority.
class A; rand int x; constraint c1 { soft x > 2; // SC1 } endclass class B extends A; constraint c1 { soft x > 3; // SC2 } endclass
soft x > 2; // SC1 } endclass extends A_aop1(A); constraint c2 { soft x > 3; // SC2 } endextends
VCS assigns priorities to multiple soft constraints in a single extends block in the same manner as in a class. By default, VCS assigns extends blocks appearing later in a given file higher priority than those appearing earlier. The prioritization between extends blocks in different files depends on compilation order. You can explicitly define priorities between extends blocks using the dominates keyword. If extends block A is described as explicitly dominating extends block B, then the constraints in A have higher priority than those in B. For example, in Example 14-9, priority(SC5) > priority(SC4) > priority(SC3) > priority(SC2) > priority(SC1). Example 14-9 SC5 Higher Priority than SC1
class A; rand int x; constraint c1 { soft x > 2; // SC1 } endclass extends A_aop2(A) dominates (A_aop1); constraint c3 { soft x > 4; // SC3 }
constraint c4 { soft x == 5; // SC4 } endextends extends A_aop4(A); constraint c5 { soft x == 5; // SC5 } endextends extends A_aop1(A); constraint c2 { soft x > 3; // SC2 } endextends
soft b == 1; // SC3 }
class A; rand int x; constraint A1 {soft x == 3;} constraint A2 {disable soft x;} // discard soft constraints constraint A3 {soft x inside {1, 2};} endclass initial begin A a= new(); a.randomize(); end
In Example 14-11, constraint A2 tells the solver to discard all soft constraints of lower priority on random variable x. This results in constraint A1 being discarded. Now, only the last constraint (A3) needs to be honored. This example results in random variable x taking the values 1 and 2. A disable soft constraint causes lower-priority soft constraints to be discarded even when they are not in conflict with other constraints. This feature allows you to introduce fresh soft constraints which replace default values specified in preceding soft constraints (see Example 14-12).
In Example 14-12, the disable soft constraint preceding the soft dist in block B2 causes the lower-priority constraint on variable x in block B1 to be discarded. Now, the solver assigns the values 5 and 8 to x with equal distribution (the result from the fresh constraint: soft x dist {5,8}). Compare the behavior of Example 14-12 with Example 14-13, where the disable soft constraint is omitted. Example 14-13 Specifying Additional Soft Constraints
class B; rand int x; constraint B1 {soft x == 5;} constraint B3 {soft x dist {5, 8};} endclass initial begin B b = new(); b.randomize(); end
In Example 14-13, the soft dist constraint in block B3 can be satisfied with a value of 5, so the solver assigns x the value 5. If you want the distribution weights of a soft dist constraint to be
satisfied regardless of the presence of lower-priority soft constraints, you should first use a disable soft to discard those lower-priority soft constraints.
Example 14-14 shows a pure DPI function in C. Example 14-14 Pure DPI Function in C
#include <svdpi.h> int dpi_func (int a, int b) { return (a+b); // Result depends solely on its inputs. }
Example 14-15 shows how to call a pure DPI function from constraints. Example 14-15 Invoking a Pure DPI Function from Constraints
import "DPI-C" pure function int dpi_func(int a, int b); class C; rand int ii;
constraint cstr { ii == dpi_func(10, 20); } endclass program tb; initial begin C cc; cc = new; cc.randomize(); end endprogram
import "DPI-C" function int dpi_func(int a, int b); // Error: Only functions explicitly marked as // pure can be called from constraints class C; rand int ii; constraint cstr { ii == dpi_func(10, 20); }
endclass program tb; initial begin C cc; cc = new; cc.randomize(); end endprogram
Similarly, running Example 14-17 with the C code shown in Example 14-14 on page 37 results in an error because context import DPI functions cannot be called from constraints. Example 14-17 Invoking a context DPI Function from Constraints
import "DPI-C" context function int dpi_func(int a, int b); // Error: Calling 'context' DPI function // from constraint is illegal. class C; rand int ii; constraint cstr { ii == dpi_func(10, 20); } endclass program tb; initial begin C cc; cc = new; cc.randomize(); end endprogram
Calling an import DPI function that is explicitly marked pure (as shown in Example 14-14 on page 37) has undefined behavior if the actual implementation of the function does things that are not pure, such as: Calling DPI exported functions/tasks. Accessing SystemVerilog data objects other than the functions actual arguments (for example, via VPI calls).
For example, Example 14-18 has undefined behavior (and may even cause a crash). Example 14-18 Non-pure DPI Function in C
#include <stdio.h> #include <stdlib.h> #include "svdpi.h" int readValueOfBFromFile(char * file) { int result = 0; char * buf = NULL; FILE * fp = fopen(file, "r"); // Read the content of the file in 'buf' here... ... if (buf) return strlen(buf); else return 0; } int dpi_func () { char * str = getenv("ENV_VAL_OF_A"); int a = str ? atoi(str) : -1; int b = readValueOfBFromFile("/some/file"); int c; svScope scp = svGetScopeFromName("$unit"); if (scp == NULL) {
fprintf(stderr, "FATAL: Cannot set scope to $unit\n"); exit(-1); } svSetScope(scp); c = export_dpi_func(); return (a+b+c); }
Example 14-19 shows a DPI function marked pure that is actually doing non-pure activities. This results in an error. Example 14-19 DPI Function Marked pure but Non-pure Activities
import "DPI-C" pure function int dpi_func(); export "DPI-C" function export_dpi_func; function int export_dpi_func(); return 10; endfunction class C; rand int ii; constraint cstr { ii == dpi_func(); } endclass program tb; initial begin C cc; cc = new; cc.randomize(); end endprogram
So make sure that DPI functions called from constraints explicitly use the pure keyword. Also make sure that the DPI function corresponding foreign language implementation is indeed pure (that is, has no side effects).
Using Constraints 14-41
You do not need to set any special compilation or runtime switches to make this work.
VCS does not create implicit constraints that guarantee the array indexed by the variable (or expression) is valid. You must properly constrain or set the variable value so that the array is correctly addressed. VCS also supports associative array indices. The indexes of these arrays may be integral data types or strings if the associative array is string-indexed. However, you cannot use expressions for associative arrays.
15
Extensions for SystemVerilog Coverage
The extensions for SystemVerilog coverage include the following: Support for Reference Arguments in get_coverage() Functional Coverage Methodology Using the SystemVerilog C/ C++ Interface
You can use the get_coverage() and get_inst_coverage() predefined methods to query on coverage during the simulation run, so that you can react to the coverage statistics dynamically. The get_coverage() and get_inst_coverage() methods both accept, as optional arguments, a pair of integer values passed by reference.
get_inst_coverage() method
When the optional arguments are entered with the method in coverpoint scope or cross scope, the get_inst_coverage() method assigns to the first argument the value of the covered bins, and assigns to the second argument the number of bins for the given coverage item. These two values correspond to the numerator and the denominator used for calculating the coverage score (before scaling by 100). In covergroup scope, the get_inst_coverage() method assigns to the first argument the weighted sum of coverpoint and cross coverage, rounded to the nearest integer, and assigns to the second argument the sum of the weights of the coverpoint or cross items.
get_coverage() method
The numerator and denominator assigned by the get_coverage() method depend on the scope. In covergroup scope, get_coverage() assigns to its first argument the weighted sum of the coverage of merged coverpoints and crosses.
In coverpoint or cross scope the first argument to get_coverage() is assigned the number of covered bins in the merged coverpoint or cross, and the second argument is assigned the total number of bins. In all cases, weighted sums are rounded to the nearest integer and the second argument is set to the sum of weights.
Functional coverage is very important in verifying correct functionality of a design. SystemVerilog natively supports functional coverage in RTL code.
However, because C/C++ code is now commonly used in a design (with PLI, DPI, DirectC, and so on), there is no systematic approach to verify the functionality of C/C++. The SystemVerilog C/C++ interface feature provides an application programming interface (API) so that C/C++ code can use the SystemVerilog functional coverage infrastructure to verify its coverage. Note: When you use the SystemVerilog C/C++ interface feature, you need include the header file svCovgAPI.h.
Figure 15-1 SystemVerilog C/C++ Functional Coverage Flow RTL & C Coverage
Testbench (C++)
C-API
DPI DPI
Wrapper Module
DPI is the SystemVerilog Direct Programming Interface. See SystemVerilog DPI in the SystemVerilog Language Reference Manual for VCS/VCS MX for details and examples of using DPI. VPI is the Verilog Procedural Interface. See SystemVerilog VPI Object Model in the SystemVerilog Language Reference Manual for VCS/VCS MX for information about using VPI with SystemVerilog. Covergroups are defined in SystemVerilog, and then they are used to track the functional coverage of C/C++ code through the C-API (C Application Programming Interface). There are two major parts to C/ C++ functional coverage interface: Covergroup(s) The C/C++ testbench using those covergroups
Covergroup Definition
The following section lists the covergroup limitations for C/C++ functional coverage. Covergroups Cannot have a sampling clock. Must be declared in $unit. Cannot be inside another scope (for example, modules, programs, and so on). Must not be instantiated anywhere in else SystemVerilog code. Arguments can only be in int, enum (base type int), and bit vector types. The SystemVerilog-to-C data-type mapping is compliant with DPI. Table 15-1 shows the mapping of the supported types: SystemVerilog-to-C Data-Type Mapping by DPI
SystemVerilog int bit bit[m:n] enum int C int unsigned char svBitVec32 int
Table 15-1
Definitions must appear in files that are separate from the DUT because the definitions are compiled separately with the VCS command-line option -c_covg.
After you define the covergroups, compile them with -c_covg (that is, -c_covg <covergroup_file>). If you have multiple covergroup files, you must precede each of them with the -c_covg option (that is, -c_covg <cov_file1> -c_covg <cov_file2> ).
Extensions for SystemVerilog Coverage 15-6
The options -sverilog and +vpi are also needed when compiling with -c_covg. After compiling the covergroups to be used with C/C++, the C-API allows for the allocation of covergroup handles, manual triggering of the covergroup sample, and the ability to de-instance and free the previously declared covergroup handle. The following is a list of the C-API functions: svCovgNew / svCovgNew2 svCovgSample / svCovgSample2 svCovgDelete
Detailed specifications for these functions appear in C/C++ Functional Coverage API Specification . The following examples demonstrate the use model.
C Testbench: test.c
int my_c_testbench () { svCovgHandle cgh; // C variables int data; int count;
Compile Flow
Compile the coverage model (covg.sv) using -c_covg together with the design and the C testbench This step assumes that you invoke the C testbench from the design dut.sv through some C interface (for example, DPI, PLI, and so on). For example:
vcs sverilog dut.sv test.c c_covg +vpi covg.sv
Runtime
At runtime (executing simv), the functional coverage data is collected and stored in the coverage database.
vl Represents a C predefined data structure (va_list) for maintaining a list of arguments. Description Create a covergroup instance using the covergroup and instance names. If no error, return svCovgHandle, otherwise return NULL. The C variable sampling type (either reference or value) is specified using refType. The sampling type is stored in svCovgHandle. The svCovgNew2 function is similar to svCovgNew except that you provide it with a va_list, instead of a variable number of arguments (represented by ) to svCovgNew. For value sampling, pass values for non-reference and reference arguments in the order specified in the covergroup declaration, and set refType to SV_SAMPLE_VAL. For reference sampling, pass values for non-reference arguments and addresses for reference arguments in the order specified in the covergroup declaration. References must remain valid during the life of the covergroup instance. Set refType to SV_SAMPLE_REF. Type checking is not performed for arguments. It is your responsibility to pass correct values and addresses. int svCovgSample(svCovgHandle ch, args ); int svCovgSample2(svCovgHandle ch, va_list vl); Parameters ch Handle to a covergroup instance created by svCovgNew().
Extensions for SystemVerilog Coverage 15-10
args A variable number of arguments for sampling a covergroup by value, if refType = SV_SAMPLE_VAL in svCovgNew(). vl Represents a C predefined data structure (va_list) for maintaining a list of arguments. Description Sample a covergroup instance using the sampling style stored in svCovgHandle and return 1 (TRUE) if no error, otherwise return 0 (FALSE). The svCovgSample2 function is similar to svCovgSample except that you provide a va_list, instead of a variable number of arguments (represented by ), to svCovgSample. For value sampling, provide values for reference arguments in the order specified in the covergroup declaration. Type checking is not performed for value arguments. It is your responsibility to pass correct values. For reference sampling, use stored addresses for reference arguments in svCovgHandle. int svCovgDelete(svCovgHandle ch); Parameters ch Handle to a covergroup instance created by svCovgNew() (or svCovgNew2).
Description Delete a covergroup instance and return 1 (TRUE) if no error, otherwise return 0 (FALSE).
16
OpenVera-SystemVerilog Testbench Interoperability 1
The primary purpose of OpenVera-SystemVerilog interoperability in VCS Native Testbench is to enable you to reuse OpenVera classes in new SystemVerilog code without rewriting OpenVera code into SystemVerilog. This chapter describes: Scope of Interoperability Importing OpenVera types into SystemVerilog Using the SystemVerilog package import syntax to import OpenVera data types and constructs into SystemVerilog.
Data Type Mapping The automatic mapping of data types between the two languages as well as the limitations of this mapping (some data types cannot be directly mapped).
Connecting to the Design Mapping of SystemVerilog modports to OpenVera where they can be used as OpenVera virtual ports.
Scope of Interoperability
The scope of OpenVera-SystemVerilog interoperability in VCS Native Testbench is as follows: Classes defined in OpenVera can be used directly or extended in SystemVerilog testbenches. Program blocks must be coded in SystemVerilog. The SystemVerilog interface can include constructs like modports and clocking blocks to communicate with the design. OpenVera code must not contain program blocks, bind statements, or predefined methods. It can contain classes, enums, ports, interfaces, tasks, and functions.
OpenVera code can use virtual ports for sampling, driving, or waiting on design signals that are connected to the SystemVerilog testbench.
Allows one to use openvera_class_name in SystemVerilog code in the same way as a SystemVerilog class. This includes the ability to: Create objects of type openvera_class_name Access or use properties and types defined in openvera_class_name or its base classes Invoke methods (virtual and non-virtual) defined in openvera_class_name or its base classes Extend openvera_class_name to SV classes
However, this does not import the names of base classes of openvera_class_name into SystemVerilog (that requires an explicit import). For example:
// OpenVera class Base { . .
. task foo(arguments) { . . . } virtual task (arguments) { . . . } class Derived extends Base { virtual task vfoo(arguments) { . . . } } // SystemVerilog import OpenVera::Derived; Derived d = new; // OK initial begin d.foo(); // OK (Base::foo automatically // imported) d.vfoo(); // OK end Base b = new; // not OK (don't know that Base is a //class name)
The previous example would be valid if you add the following line before the first usage of the name Base.
import OpenVera::Base;
Continuing with the previous example, SystemVerilog code can extend an OpenVera class as shown below:
// SystemVerilog import OpenVera::Base;
class SVDerived extends Base; virtual task vmt() begin . . . end endtask endclass
Note: - If a derived class redefines a base class method, the arguments of the derived class method must exactly match the arguments of the base class method. - Explicit import of each data type from OpenVera can be avoided by a single import OpenVera::*.
// OpenVera class Base { integer i; . . . } class wrappedBase { public Base myBase; } // SystemVerilog import OpenVera::wrappedBase; class extendedWrappedBase extends wrappedBase; . . . endclass
In this example, myBase.i can be used to refer to this member of Base from the SV side. However, if SV also needs to use objects of type Base, then you must include:
import OpenVera::Base;
Once OpenVera gets an id for a mailbox/semaphore it can save it into any integer type variable. Note that however if get_id is invoked for a mailbox, the mailbox can no longer be garbage collected because VCS has no way of knowing when the mailbox ceases to be in use. Typed mailboxes (currently not supported), when they are supported in SystemVerilog can be passed to OpenVera code using the same method as untyped mailboxes above. However, if the OpenVera code attempts to put an object of incompatible type into a typed mailbox, a simulation error will result. Bounded mailboxes (currently not supported), when they are supported in SystemVerilog can be passed to OpenVera code using the same method as above. OpenVera code trying to do mailbox_put into a full mailbox will result in a simulation error. To use an OpenVera mailbox in SystemVerilog, you need to get a handle to the mailbox object using a system function call. The system function $get_mailbox returns this handle:
function mailbox $get_mailbox(int id);
Events
The OpenVera event data type is equivalent to the SystemVerilog event data type. Events from either language can be passed (as method arguments or return values) to the other language without any conversion. The operations performed on events in a given language are determined by the language syntax: An event variable can be used in OpenVera in sync and trigger. An event variable event1 can be used in SystemVerilog as follows:
event1.triggered //event1 triggered state property ->event1 @(event1) //trigger event1 //wait for event1
Strings
OpenVera and SystemVerilog strings are equivalent. Strings from either language can be passed (as method arguments or return values) to the other language without any conversion. In OpenVera, null is the default value for a string. In SystemVerilog, the default
value is the empty string (""). It is illegal to assign null to a string in SystemVerilog. Currently, NTB-OV treats "" and null as distinct constants (equality fails).
Enumerated Types
SystemVerilog enumerated types have arbitrary base types and are not generally compatible with OpenVera enumerated types. A SystemVerilog enumerated type will be implicitly converted to the base type of the enum (an integral type) and then the bit-vector conversion rules (section 2.5) are applied to convert to an OpenVera type. This is illustrated in the following example:
// SystemVerilog typedef reg [7:0] formal_t; // SV type equivalent to // 'reg [7:0]' in OV typedef enum reg [7:0] { red = 8'hff, blue = 8'hfe, green = 8'hfd } color; // Note: the base type of color is 'reg [7:0]' typedef enum bit [1:0] { high = 2'b11, med = 2'b01, low = 2'b00 } level; color c; level d = high; Foo foo; ... foo.vera_method(c); // OK: formal_t'(c) is passed to // vera_method. foo.vera_method(d); // OK: formal_t'(d) is passed to // vera_method. // If d == high, then 8'b00000011 is // passed to vera_method. // OpenVera class Foo { ... task vera_method(reg [7:0] r) { ... } }
The above data type conversion does not involve a conversion in data representation. An enum can be passed by reference to OpenVera code but the formal argument of the OpenVera method must exactly match the enum base type (for example: 2-to-4 value conversion, sign conversion, padding or truncation are not allowed for arguments passed by reference; they are OK for arguments passed by value). Enumerated types with 2-value base types will be implicitly converted to the appropriate 4-state type (of the same bit length). See the discussion in 2.5 on the conversion of bit vector types. OpenVera enum types can be imported to SystemVerilog using the following syntax:
import OpenVera::openvera_enum_name;
Note: SystemVerilog enum methods such as next, prev and name can be used on imported OpenVera enums. Enums contained within OV classes are illustrated in the following example:
OpenVera-SystemVerilog Testbench Interoperability 16-11
class OVclass{ enum Opcode {Add, Sub, Mul}; } import OpenVera::OVclass; OVclass::Opcode SVvar; SVvar=OVclass::Add;
OpenVera
integer reg [7:0] reg [15:0] integer reg [63:0] reg [abs(m-n)+1:0] reg [abs(m-n)+1:0] reg [63:0]
Change in sign?
Note: If a value or sign conversion is needed between the actual and formal arguments of a task or function, then the argument cannot be passed by reference.
Arrays
Arrays can be passed as arguments to tasks and functions from SystemVerilog to OpenVera and vice-versa. The formal and actual array arguments must have equivalent element types, the same number of dimensions with corresponding dimensions of the same length. These rules follow the SystemVerilog LRM. A SystemVerilog fixed array dimension of the form [m:n] is directly mapped to [abs(m-n)+1] in OpenVera. An OpenVera fixed array dimension of the form [m] is directly mapped to [m] in SystemVerilog.
Rules for equivalency of other (non-fixed) types of arrays are as follows: A dynamic array (or Smart queue) in OpenVera is directly mapped to a SystemVerilog dynamic array if their element types are equivalent (can be directly mapped). An OpenVera associative array with unspecified key type (for example integer a[]) is equivalent to a SystemVerilog associative array with key type reg [63:0] provided the element types are equivalent. An OpenVera associative array with string key type is equivalent to a SystemVerilog associative array with string key type provided the element types are equivalent.
Other types of SystemVerilog associative arrays have no equivalent in OpenVera and hence they cannot be passed across the language boundary.
Yes No Yes
A 2-valued array type in SystemVerilog cannot be directly mapped to a 4-valued array in OpenVera. However, a cast may be performed as follows:
// OpenVera class Foo { . . . task vera_method(integer array[5]) { . . . } . . . } // SystemVerilog int array[5]; typedef integer array_t[5]; import OpenVera::Foo; Foo f; . . . f.vera_method(array); // Error: type mismatch f.vera_method(array_t'(array)); // OK . . .
Virtual Modports
VCS supports a reference to a modport in an interface to be declared using the following syntax.
virtual interface_name.modport_name virtual_modport_name;
For example:
interface IFC; wire a, b; modport mp (input a, output b); endinterface
. IFC ifc(clk); // use this to connect to DUT and TB mpg mpg(ifc); dut dut(...); . . endmodule
VCS supports the following extensions that allow the clocking block name to be omitted from vmp.cb.a.
// Example-1 interface IFC(input clk); wire a, b; clocking cb @(posedge clk); input a; input b; endclocking modport mp (import cb.a, import cb.b); endinterface program mpg(IFC ifc); . . . virtual IFC.mp vmp; . . . vmp = i.mp; @(vmp.a); // cb can be omitted; 'cb.a' is // imported into the modport . endprogram module top(); . . IFC ifc(clk); // use this to connect to DUT and TB mpg mpg(ifc); dut dut(...); .
. endmodule // Example-2 interface IFC(input clk); wire a, b; bit clk; clocking cb @(posedge clk); input a; input b; endclocking modport mp (import cb.*); // All members of cb // are imported. // Equivalent to the // modport in // Example-1. endinterface program mpg(IFC ifc); . . IFC i(clk); . . . virtual IFC.mp vmp; . . . vmp = i.mp; @(vmp.a); // cb can be omitted; //'cb.a' is imported into the modport endprogram module top(); . . IFC ifc(clk); // use this to connect to DUT and TB mpg mpg(ifc); dut dut(...); . .
endmodule
A SystemVerilog modport can be implicitly converted to an OpenVera virtual port provided the following conditions are satisfied: The modport and the virtual port have the same number of members. Each member of the modport converted to a virtual port must either be: (1) a clocking block, or (2) imported from a clocking block using the import syntax above. For different modports to be implicitly converted to the same virtual port, the corresponding members of the modports (in the order in which they appear in the modport declaration) be of bit lengths. If the members of a clocking block are imported into the modport using the cb.* syntax, where cb is a clocking block, then the order of those members in the modport is determined by their declaration order in cb.
Example
// OpenVera port P { clk; a; b; } class Foo { P p; task new(P p_) { p = p_; } task foo() { . . .
@(p.$clk); . variable = p.$b; p.$a = variable; . . . } } // SystemVerilog interface IFC(input clk); wire a; wire b; clocking clk_cb @(clk); input #0 clk; endclocking clocking cb @(posedge clk); output a; input b; endclocking modport mp (import clk_cb.*, import cb.*); // modport // can aggregate signals from multiple clocking blocks. endinterface: IFC program mpg(IFC ifc); import OpenVera::Foo; . . virtual IFC.mp vmp = ifc.mp; Foo f = new(vmp); // clocking event of ifc.cb mapped to // $clk in port P // ifc.cb.a mapped to $a in port P // ifc.cb.b mapped to $b in port P . f.foo(); . .
. endprogram module top(); . . IFC ifc(clk); // use this to connect to DUT and TB mpg mpg(ifc); dut dut(...); . . endmodule
Note: In the above example, you can also directly pass the vmp modport from an interface instance:
Foo f = new(ifc.mp);
Notes to Remember
Blocking Functions in OpenVera
When a SystemVerilog function calls a virtual function that may resolve to a blocking OpenVera function at runtime, the compiler cannot determine with certainty if the SystemVerilog function will block. VCS issues a warning at compile time and let the SystemVerilog function block at runtime. Besides killing descendant processes in the same language domain, terminate invoked from OpenVera will also kill descendant processes in SystemVerilog. Similarly, disable fork invoked from SystemVerilog will also kill descendant processes in OpenVera. wait_child will also wait for SystemVerilog descendant processes and wait fork will also wait for OpenVera descendant processes.
Functional Coverage
There are some differences in functional coverage semantics between OpenVera and SystemVerilog. These differences are currently being eliminated by changing OpenVera semantics to conform to SystemVerilog. In interoperability mode, coverage_group in OpenVera and covergroup in SystemVerilog will have the same (SystemVerilog) semantics. Non-embedded coverage group can be imported from Vera to SystemVerilog using the package import syntax (similar to classes). Coverage reports will be unified and keywords such as coverpoint, bins will be used from SystemVerilog instead of OpenVera keywords. Here is an example of usage of coverage groups across the language boundary:
// OpenVera class A { B b; coverage_group cg { sample x(b.c); sample y(b.d); cross cc1(x, y); sample_event = @(posedge CLOCK); } task new() { b = new; } }
// SystemVerilog import OpenVera::A; initial begin A obj = new; obj.cg.option.at_least = 2; obj.cg.option.comment = "this should work; @(posedge CLOCK); $display("coverage=%f", obj.cg.get_coverage()); end
Usage Model
Any `define from the OV code will be visible in SV once they are explicitly included. Note: OV #define must be rewritten as `define for ease of migration to SV. Compilation
% vcs [compile_options] -sverilog -ntb_opts interop [other_NTB_options] file4.sv file5.vr file2.v file1.v
Simulation
% simv [simv_options]
Note: - If RVM class libs are used in the OV code, use -ntb_opts rvm with vlogan command line. - Using -ntb_opts interop -ntb_opts rvm with vcs, automatically translates rvm_ macros in OV package to vmm_ equivalents.
OpenVera-SystemVerilog Testbench Interoperability 16-24
Limitations
Classes extended/defined in SystemVerilog cannot be instantiated by OpenVera. OpenVera verification IP will need to be compiled with the NTB syntax and semantic restrictions. These restrictions are detailed in the Native Testbench Coding Guide, included in the VCS release. SystemVerilog contains several data types that are not supported in OpenVera including real, unpacked-structures, and unpackedunions. OpenVera cannot access any variables or class data members of these types. A compiler error will occur if the OpenVera code attempts to access the undefined SystemVerilog data member. This does not prevent SystemVerilog passing an object to OpenVera, and then receiving it back again, with the unsupported data items unchanged. When using VMM RVM Interoperability, you should only register VMM or RVM scenarios with a generator in the same language. You can instantiate an OpenVera scenario in a SystemVerilog scenario, but only a SystemVerilog scenario can be registered with a SystemVerilog generator. You cannot register OpenVera Multi-Stream Scenarios on a SystemVerilog Multi-Stream Scenario Generator (MSSG).
17
Using SystemVerilog Assertions 1
Using SystemVerilog Assertions (SVA) you can specify how you expect a design to behave and have VCS display messages when the design does not behave as specified.
assert property (@(posedge clk) req |-> ##2 ack) else $display ("ACK failed to follow the request);
The above example displays, "ACK failed to follow the request", if ACK is not high two clock cycles after req is high. This example is a very simple assertion. For more information on how to write assertions, refer to Chapter 17 of SystemVerilog Language Reference Manual. VCS allows you to: Control the SVAs Enable or Disable SVAs
This chapter describes the following: Using SVAs in the HDL Design Controlling SystemVerilog Assertions Viewing Results Enhanced Reporting for SystemVerilog Assertions in Functions Controlling Assertion Failure Messages
Note: Synopsys recommends you to use the gcc compiler for Solaris platform.
This section describes the usage model to compile and simulate the design with SVA checkers. For more information on SVA checker libraries and list of available checkers, see the SystemVerilog Assertions Checker Library Reference Manual.
The usage model to simulate the design with SVA checkers is as follows: Compilation
% vcs [vcs_options] -sverilog +define+ASSERT_ON \ +incdir+$VCS_HOME/packages/sva y $VCS_HOME/packages/sva +libext+.v \ Verilog_source_files
Simulation
% simv [simv_options]
For more information on SVA checker libraries and a list of available checkers, see the SystemVerilog Assertions Checker Library Reference Manual.
The bind statement for Verilog targets can be used anywhere within your Verilog source file. For example:
//Verilog file module dev (...); ... endmodule bind dev dev_checker dc1 (.clk(clk), .a(a), .b(b));
As shown in the above example, the bind statement is specified in the same Verilog file. The usage model to simulate the design is as shown below: Compilation
% vcs -sverilog [compile_options] Verilog_files
Simulation
% simv [run_options]
As shown in Example 2, you can use SVA pragmas as //sv_pragma at the beginning of all SVA lines, or you can use the following to mark a block of code as SVA code:
/* sv_pragma sequence s2; @(posedge clk) sig3 ##[1:3] sig4; endsequence */
Usage Model
The usage model to compile and simulate the designs having inlined assertions is as follows: Note: If you have your assertions inlined using //sv_pragma, use the analysis option -sv_pragma as shown above. Compilation
% vcs -sv_pragma [compile_options] Verilog_files
Simulation
% simv [run_options]
Note: The -assert quiet and -assert report=<file_name> options do not require the use of the -assert enable_hier or -assert enable_diag options at compile time. To enable dumping assertion information in a VPD file, use the -assert dve option. This option also allows you to view assertion information in the assertion pane in DVE (for more information, see the DVE User Guide.) To disable all SVAs in the design, use the -assert disable compilation option. To disable only the SVAs specified in a file, use the -assert disable_file=<file_name> compilation option. To disable assertion coverage, use the -assert disable_cover compilation option. By default, when you use the -cm assert option, VCS enables monitoring your assertions for coverage, and writes an assertion coverage database during simulation.
Disable dumping of SVA information in the VPD file You can use the -assert dumpoff option to disable the dumping of SVA information to the VPD file during simulation (for additional information, see Options for SystemVerilog Assertions on page 8).
Following are the tasks VCS allows you to do during the runtime: Terminate simulation after certain number of assertion failures You can use either the -assert finish_maxfail=N or assert global_finish_maxfail=N runtime option to terminate the simulation if the number of failures for any assertion reaches N or if the total number of failures from all SVAs reaches N, respectively. Show both passing and failing assertions By default, VCS reports only failures. However, you can use the -assert success option to enable reporting of successful matches, and successes on cover statements, in addition to failures. Limit the maximum number of successes reported You can use the -assert maxsuccesses=N option to limit the total number of reported successes to N. Disable the display of messages when assertions fail You can use the -assert quiet option to disable the display of messages when assertions fail. Enable or disable assertions during runtime
You can use the -assert hier=file_name option to enable or disable the list of assertions in the specified file. Generate a report file You can use the -assert report=file_name option to generate a report file with the specified name. For additional information, see Options for SystemVerilog Assertions on page 8. You can enter more than one keyword, using the plus + separator. For example:
% vcs -assert maxfail=10+maxsucess=20+success ...
However, you cannot combine the elaboration assert arguments and runtime assert arguments. Both should be specified separately as shown below:
% vcs -assert disable+dumpoff -assert maxfail=10+maxsucess=20+success ...
Note: Enter these system tasks in an initial block. Do not enter these system tasks in an always block.
The $assert_monitor system task is analogous to the standard $monitor system task in that it continually monitors specified assertions and displays what is happening with them (you can have it only display on the next clock of the assertion). The syntax is as follows:
$assert_monitor([0|1,]assertion_identifier...);
Where: 0 Specifies reporting on the assertion if it is active (VCS is checking for its properties) and for the rest of the simulation reporting on the assertion or assertions, whenever they start. 1 Specifies reporting on the assertion or assertions only once, the next time they start. If you specify neither 0 or 1, the default is 0. assertion_identifier... A comma separated list of assertions. If one of these assertions is not declared in the module definition containing this system task, specify it by its hierarchical name. Consider the following assertion:
property p1; @ (posedge clk) (req1 ##[1:5] req2); endproperty a1: assert property(p1);
For property p1 in assertion a1, a clock tick is a rising edge on signal clk. When there is a clock tick VCS checks to see if signal req1 is true, and then to see if signal req2 is true at any of the next five clock ticks. In this example simulation, signal clk initializes to 0 and toggles every 1 ns, so the clock ticks at 1 ns, 3 ns, 5 ns and so on.
The display is about the assertion with the hierarchical name test.a1. It is in the source file named design.v and declared on line 27.
5ns: tracing "test.a1" started at 5ns: attempt starting found: req1 looking for: req2 or any
At simulation time, 5 ns VCS is tracing test.a1. An attempt at the assertion started at 5 ns. At this time, VCS found req1 to be true and is looking to see if req2 is true one to five clock ticks after 5 ns. Signal req2 doesnt have to be true on the next clock tick, so req2 not being true is okay on the next clock tick; thats what looking for or any means, anything else than req2 being true.
5ns: tracing "test.a1" started at 3ns: trace: req1 ##1 any looking for: req2 or any failed: req1 ##1 req2
The attempt at the assertion also started at 3 ns. At that time, VCS found req1 to be true at 3 ns and it is looking for req2 to be true some time later. The assertion failed in that req2 was not true one clock tick later. This is not a true failure of the assertion at 3 ns, it can still succeed in two more clock ticks, but it didnt succeed at 5 ns.
5ns: tracing "test.a1" started at 1ns: trace: req1 ##1 any[* 2 ] looking for: req2 or any failed: req1 ##1 any ##1 req2
The attempt at the assertion also started at 1 ns. [* is the repeat operator. ##1 any[* 2 ] means that after one clock tick, anything can happen, repeated twice. So the second line here says that req1 was true at 1 ns, anything happened after a clock tick after 1 ns (3 ns) and again after another clock tick (5 ns) and VCS is now looking for req2 to be true or anything else could happen. The third line here says the assertion failed two clock ticks (5 ns) after req1 was found to be true at 1 ns.
The $assert_monitor_off and $assert_monitor_on system tasks turn off and on the display from the $assert_monitor system task, just like the $monitoroff and $monitoron system turn off and on the display from the $monitor system task.
Using OpenVera System Tasks These system tasks are as follows: $ova_set_category("assertion_full_hier_name", category) or $ova_set_category(assertion_full_hier_name, category) System task that sets the category level attributes of an assertion. The category level is an unsigned integer from 0 to 224 - 1. Note: These string arguments, such as the full hierarchical name of an assertion, can be enclosed in quotation marks or not. This is true when using these system tasks with SVA. They must be in quotation marks when using them with OVA. $ova_get_category("assertion_full_hier_name") or $ova_get_category(assertion_full_hier_name) System function that returns an unsigned integer for the category. Using Assertion System Tasks You can use the following assertion system tasks to set the category and severity attributes of assertions:
$assert_set_severity("assertion_full_hier_name", severity)
Sets the severity level attributes of an assertion. The severity level is an unsigned integer from 0 to 255.
$assert_set_category("assertion_full_hier_name", category)
Sets the category level attributes of an assertion. The category level is an unsigned integer from 0 to 224 - 1. You can use the following system tasks to retrieve the category and severity attributes of assertions:
$assert_get_severity("assertion_full_hier_name")
Returns an unsigned integer for the category. After specifying these system tasks and functions, you can start or stop the monitoring of assertions based upon their specified category or severity. For details on starting and stopping assertions, see Stopping and Restarting Assertions By Category . Note: VCS also supports use of OpenVera system tasks and functions to categorize assertions namely: $ova_set_category, $ova_get_category The use model is identical to the assertion tasks.
Using Attributes
You can prefix an attribute in front of an assert statement to specify the category of the assertion. The attribute must begin with the category name and specify an integer value, for example:
(* category=1 *) a1: assert property (p1); (* category=2 *) a2: assert property (s1);
The value you specify can be an unsigned integer from 0 to 224 - 1, or a constant expression that evaluates to 0 to 224 - 1. You can use a parameter, localparam, or genvar in these attributes. For example:
parameter p=1; localparam l=2; . . . (* category=p+1 *) a1: assert property (p1); (* category=l *) a2: assert property (s1); genvar g; generate for (g=0; g<1; g=g+1) begin:loop (* category=g *) a3: assert property (s2); end endgenerate
Note: In a generate statement the category value cannot be an expression, the attribute in the following example is invalid:
genvar g; generate
for (g=0; g<1; g=g+1) begin:loop (* category=g+1 *) a3: assert property (s2); end endgenerate
If you use a parameter for a category value, the parameter value can be overwritten in a module instantiation statement. You can use these attributes to assign categories to both named and unnamed assertions. For example:
(* category=p+1 *) a1: assert property (p1); (* category=l *) assert property (s1);
The attribute is retained in a tokens.v file when you use the -Xman=0x4 compile-time option and keyword argument.
There are system tasks for both OpenVera and SystemVerilog assertions that allow you to use a mask to determine if a category of assertions should be stopped or restarted. These system tasks are $ova_category_stop and $ova_category_start. They have matching syntax.
$ova_category_stop(categoryValue, maskValue[,globalDirective]);
Where: categoryValue Because there is a maskValue argument, this argument is now the result of an anding operation between the assertion categories and the maskValue argument. If the result matches this value, these categories stop. As seen in Stopping and Restarting Assertions By Category , without the maskValue argument, this argument is the value you specified in $ova_set_category system tasks or category attribute. maskValue A value that is logically anded with the category of the assertion. If the result of this and operation matches the categoryValue, VCS stops monitoring the assertion. globalDirective Can be either of the following values: 0 Enables an $ova_category_start system task, that does not have a globalDirective argument, to restart the assertions stopped with this system task.
1 Prevents an $ova_category_start system task that does not have a globalDirective argument from restarting the assertions stopped with this system task.
$ova_category_start(categoryValue, maskValue[, globalDirective]);
Where: categoryValue Because there is a maskValue argument, this argument now is the result of an anding operation between the assertion categories and the maskValue argument. If the result matches this value, these categories start. As seen in Stopping and Restarting Assertions By Category , without the maskValue argument, this argument is the value you specified in $ova_set_category system tasks or category attribute. maskValue A value that is logically anded with the category of the assertion. If the result of this and operation matches the categoryValue, VCS starts monitoring the assertion. globalDirective Can be either of the following values: 0 Enables an $ova_category_stop system task, that does not have a globalDirective argument, to stop the assertions started with this system task.
1 Prevents an $ova_category_stop system task that does not have a globalDirective argument from stopping the assertions started with this system task. Examples This first example stops the odd numbered categories:
$ova_set_category(top.d1.a1,1); $ova_set_category(top.d1.a2,2); $ova_set_category(top.d1.a3,3); $ova_set_category(top.d1.a4,4); . . . . $ova_category_stop(1,h1);
The categories are masked with the maskValue argument and compared with the categoryValue argument:
bits category 1 maskValue result category 2 maskValue result category 3 maskValue result 001 1 1 010 1 0 011 1 1 1 match 1 no match 1 match categoryValue
100 1 0 1 no match
1. VCS looks at the least significant bit of each category and logically ands that LSB to the maskValue argument, which is 1. 2. The results of these anding operations, 1 or true for categories 1 and 3, and 0 or false for categories 2 and 4, is compared to the categoryValue, which is 1, there is a match for categories 1 and 3. 3. VCS stops the odd numbered categories. This additional example uses the globalDirective argument:
$ova_set_category(top.d1.a1,1); $ova_set_category(top.d1.a2,2); $ova_set_category(top.d1.a3,3); $ova_set_category(top.d1.a4,4); . . . $ova_category_stop(1,h1,0); $ova_category_stop(0,h1,1); . . . $ova_category_start(1,h1); $ova_category_start(0,h1);
In this example: 1. The two $ova_category_stop system tasks first stop the odd numbered assertions and then the even numbered ones. The first $ova_category_stop system task has a globalDirective argument that is 0, the second has a globalDirective argument that is 1.
2. The first $ova_category_start system task can restart the odd numbered assertions, but the second $ova_category_start system task cannot start the even numbered assertions. Starting and Stopping Assertions Using Assertion System Tasks There are assertions system tasks for starting and stopping assertions. These system tasks are as follows: Stopping Assertions by Category or Severity
$assert_category_stop(categoryValue, [maskValue[,globalDirective]]);
Stops all assertions associated with the specified severity level. where, categoryValue Since there is a maskValue argument, it is now the result of an anding operation between the assertion categories and the maskValue argument. If the result matches this value, these categories stop. Without the maskValue argument, this argument is the value you specify in $assert_set_category system tasks or category attributes. maskValue
A value that is logically anded with the category of the assertion. If the result of this and operation matches the categoryValue, VCS stops monitoring the assertion. globalDirective Can be either of the following values: 0 Enables an $assert_category_start system task that does not have a globalDirective argument, to restart the assertions stopped with this system task. 1 Prevents an $assert_category_start system task that does not have a globalDirective argument from restarting the assertions stopped with this system task. Starting Assertions by Category or Severity
$assert_category_start(categoryValue, [maskValue[,globalDirective]]);
Starts all assertions associated with the specified severity level. The severity level is an unsigned integer from 0 to 255. where, categoryValue
Since there is a maskValue argument, this argument is the result of an anding operation between the assertion categories and the maskValue argument. If the result matches this value, these categories start. Without the maskValue argument, this argument is the value you specify in $assert_set_category system tasks or category attributes. maskValue A value that is logically anded with the category of the assertion. If the result of this and operation matches the categoryValue, VCS starts monitoring the assertion. globalDirective Can be either of the following values: 0 Enables an $assert_category_stop system task (that does not have a globalDirective argument) to stop the assertions started with this system task. 1 Prevents an $assert_category_stop system task that does not have a globalDirective argument from stopping the assertions started with this system task. Example Showing How to Use MaskValue Example 17-1 stops the odd numbered categories Example 17-1 MaskValue Numbering:
$assert_set_category(top.d1.a1,1); $assert_set_category(top.d1.a2,2);
The categories are masked with the maskValue argument and compared with the categoryValue argument as shown in the following table.
bits categoryValue category 1 maskValue result category 2 maskValue result category 3 maskValue result category 4 maskValue result 001 1 1 010 1 0 011 1 1 100 1 0 1 no match 1 match 1 no match 1 match
1. VCS logically ands the category value to the maskValue argument, which is 1. 2. The result of the and operation is true for categories 1 and 3 as per the calculation shown above. The result is false for categories 2 and 4.
3. VCS stops all the assertions which result in a true match with the and operation. Example 17-2 uses the globalDirective argument. Example 17-2 Mask Value with Global Directive
The assertions that are stopped or started with globalDirective value 1, cannot be restarted or stopped with a call to $assert_category_start, without using the globalDirective argument. The above code cannot restart assertions. The assertions can only be restarted with a call to $assert_category_start with globalDirective, as follows:
$assert_category_start(1,'h1,1);
or
$assert_category_start(1,'h1,0);
Note: VCS also supports use of OpenVera system tasks and functions to categorize assertions namely: $ova_set_category, $ova_get_category The use model is identical to the assertion tasks.
Using SystemVerilog Assertions 17-26
Viewing Results
By default, VCS reports only assertion of the failures. However, you can use the -assert success runtime option to report both pass and failures. Assertion results can be viewed: Using a Report File Using DVE
For information on viewing assertions in DVE, refer to the "Using the Assertion Pane" chapter, in the DVE user guide.
"design.v", 157: top.cnt_in.a2: started at 22100ns failed at 22700ns Offending '(busData == mem[$past(busAddr, 3)])'
Expression that failed (only with failure of check assertions)
Introduction
In earlier releases, when assertions were present inside functions, assertion path names were reported based on the position of the function call in the source file. For example, consider the following code:
module top; bit b, a1, a2, a3, a4, a5; function bit myfunc(input bit k); $display("FUNC name: %m"); AF: assert #0(k && !k); return !k; endfunction always_comb a1=myfunc(b); always_comb begin: A begin: B a2=myfunc(b); begin a3=myfunc(!b); end end end
But the problem with this type of naming convention is, when code changes, the output of the simulation also changes. To overcome this limitation, a new naming convention is implemented under the -assert funchier compile-time option. This new naming convention is implemented as follows: Function names are generated based on the named blocks under which the functions are called. Each function name is appended with an index (index=0, 1, 2, 3...), where index 0 is given to the first function call, index 1 is given to the second function call, and so on. For unnamed blocks, the function name is based on the closest named block. If there is no named scope around the function call, then a module scope is used as a named block with an empty name. Each assertion status reporting message contains the file name and line number of the function caller.
Usage Model
Use the -assert funchier option to enable the new function naming convention, as shown in the following command:
% vcs -sverilog -assert funchier+svaext
If you run the above code using this command, it generates the following output:
"top.v", "top.v", "top.v", "top.v", "top.v", 5: top.myfunc_2.AF ("top.v", 18): started ...... 5: top.myfunc_1.AF ("top.v", 17): started ...... 5: top.\A.B.myfunc_1.AF ("top.v", 13): started ... 5: top.\A.B.myfunc_0.AF ("top.v", 12): started .... 5: top.myfunc_0.AF ("top.v", 9): started ......
Introduction
Earlier releases did not provide the flexibility to control the display of default messages for assertion (SVA, OVA, or PSL) failures, based on the presence of an action block (for SVA) or a user message (for OVA and PSL). Also, there was no control over whether these assertion failures contributed to the failure counts for assert [global_]finish_maxfail, or affected simulation if
$ova_[severity|category]_action(<severity_or_category>, finish) was specified.
You can now use the options described in the following topics to enable additional controls on failure messages, and to terminate the simulation and compilation of OVA case pragmas.
In addition to the default message, an extra message is displayed by default, for PSL assertions that have a severity (info, warning, error, or fatal) associated with them. This message is considered as a user message, and no default message is displayed, if you use the assert no_default_msg[=PSL] option. Example Consider the following assertion: As1: assert property (@(posedge clk) P1) else $info(As1 fails); By default, VCS displays the following information for each assertion failure:
"sva_test.v", 15: top.As1: started at 5s failed at 5s Offending 'a' Info: "sva_test.v", 15: top.As1: at time 5 As1 fails
If you use the assert no_default_msg option at runtime, it disables the default message, and displays only the user message, as shown below:
Info: "sva_test.v", 15: top.As1: at time 5 As1 fails
Excludes failures on SVA assertions with fail action blocks for computation of failure count in the assert [global_]finish_maxfail=N runtime option. This option also excludes failures of these assertions for termination of simulation, if you use the following command:
$ova_[severity|category]_action(<severity_or_category>, finish)
Note: This option does not affect OVA case violations and OVA or PSL assertions, with or without user messages. Specifying $fatal() in the fail action block of an SVA assertion or in a fatal severity associated with a PSL assertion, results in termination of simulation irrespective of whether this option is used or not. This option is useful when you want to exclude failures of assertions having fail action blocks, from adding up to the global failure count, for the assert [global]_finish_maxfail=N option. Example Consider the following assertion: As1: assert property (@(posedge clk) P1) else $info(As1 fails);
If you use the assert global_finish_maxfail=1 option at runtime, then the simulation terminates at the first As1 assertion failure. Now, if you use assert global_finish_maxfail=1 assert no_fatal_action at runtime, then the failure of assertion As1 does not cause the simulation to terminate. ova_enable_case_maxfail Includes OVA case violations in computation of global failure count for the assert global_finish_maxfail=N option. Note: The assert finish_maxfail=N option does not include OVA case violations. This option maintains a per-assertion failure count for termination of simulation. Example Consider an OVA case pragma, as shown in the following code, to check the case statements for full case violations:
reg [2:0] mda[31:0][31:0]; //ova full_case on; initial begin for(i = 31; i >= 0; i = i - 1) begin for(j = 0; j <= 31; j = j + 1) begin case(mda[i][j]) 1: begin testdetect[i][j] = 1'b1; end endcase #1; end end end
The above code violates full case check. Therefore, case violations are displayed as follows:
Select expression value when violation happened for last iteration : 3'b000 Ova [0]: "ova_case_full.v", 20: Full case violation at time 9 in a Failed in iteration: [ 31 ] [ 9 ]
By default, these violations are not considered in the failure count for the assert global_finish_maxfail=N option. But if you use the -ova_enable_case_maxfail option at runtime, then the case violations are added in the failure count.
//ova full_case on; /* case pragma*/ always @(negedge clock) case (opcode) //ova check_bool (alu_out>10, "ddd", negedge clock); /* assertion pragma */ 3'h0: alu_out = accum; 3'h1: alu_out = accum; 3'h2: alu_out = accum + data; 3'h3: alu_out = accum & data; 3'h4: alu_out = accum ^ data; 3'h5: alu_out = data; 3'h6: alu_out = accum; endcase
The above code contains both OVA case pragmas and assertions. This option ignores the OVA assertion pragmas, and compiles only the case pragmas.
18
Using Property Specification Language 1
VCS supports the Simple Subset of the IEEE 1850 Property Specification Language (PSL) standard. Refer to Section 4.4.4 of the IEEE 1850 PSL LRM for the subset definition. You can use PSL along with SystemVerilog Assertions (SVA), SVA options, SVA system tasks, and OpenVera (OV) classes.
Examples
The following example shows how to inline PSL in Verilog using the //psl and /*psl */ pragmas.
module mod; .... // psl a1: assert always {r1; r2; r3} @(posedge clk); /* psl A2: assert always {a;b} @(posedge clk); ... */ endmodule
The following example shows how to use vunit to include PSL in the design.
vunit vunit1 (verilog_mod) { a1: assert always {r1; r2; r3} @(posedge clk); }
Usage Model
If you inline the PSL code, you must compile it with the -psl option. If you use vunit, you must compile the file that contains the vunit with the -pslfile option. You do not need to use this option if the file has the .psl extension. Compilation
% vcs -psl [vcs_options] Verilog_files
Simulation
% simv
Examples
To simulate the PSL code inlined in a Verilog file (test.v), execute the following commands:
% vcs -psl test.v % simv
To simulate the vunit specified in an external file with the .psl extension (checker.psl), execute the following commands:
% vcs dev.v checker.psl % simv
To simulate the vunit specified in an external file without the .psl extension (checker.txt), execute the following commands:
% vcs dev.v -pslfile checker.txt % simv
To simulate both the PSL code inlined in a Verilog file (test.v), and the vunit specified in an external file (checker.psl or checker.txt), execute the following commands:
% vcs -psl -test.v checker.psl % simv
or
% vcs -psl -test.v -pslfile checker.txt % simv
For information on all assertion options, see Appendix B, Compile Time Options. You can control PSL assertions in any of the following ways: Using the $asserton, $assertoff, or $assertkill SVA system tasks. Using NTB-OpenVera assert classes.
Note that VCS treats the assume PSL directive as the assert PSL directive. Discovery Visual Environment (DVE) supports PSL assertions. The PSL assertion information displayed by VCS is similar to SystemVerilog assertions.
Limitations
The VCS implementation of PSL has the following limitations: VCS does not support binding vunit to an instance of a module or entity. VCS does not support the following data types in your PSL code -- shortreal, real, realtime, associative arrays, and dynamic arrays. VCS does not support the union operator and union expressions in your PSL code. Clock expressions have the following limitations: - You must not include the rose() and fell() built-in functions. - You must not include endpoint instances. Endpoint declarations must have a clocked SERE with either a clock expression or default clock declaration. VCS does not support the %for and %if macros. VCS supports only the always and never FL invariance operators in top-level properties. Ensure that you do not instantiate top-level properties in other properties. VCS supports all LTL operators, except sync_abort and async_abort. You can apply the abort operator only to the top property. VCS does not support the assume_guarantee, restrict, and restrict_guarantee PSL directives.
19
Using SystemC 1
The VCS SystemC Co-simulation Interface enables VCS and the SystemC modeling environment to work together when simulating a system described in the Verilog and SystemC languages. VCS contains a built-in SystemC simulator that is compatible with OSCI SystemC 2.2 (IEEE 1666). You also have the option of installing the OSCI SystemC simulator and having VCS run it to co-simulate using the interface. See Using a Customized SystemC Installation on page 67. With the interface, you can use the most appropriate modeling language for each part of the system, and verify the correctness of the design. For example, the VCS SystemC Co-simulation Interface allows you to: Use a SystemC module as a reference model for the Verilog RTL design under test in your testbench
Using SystemC 19-1
Verify a Verilog netlist after synthesis with the original SystemC testbench Write test benches in SystemC to check the correctness of Verilog designs Import legacy Verilog IP into a SystemC description Import third-party Verilog IP into a SystemC description Export SystemC IP into a Verilog environment when only a few of the design blocks are implemented in SystemC Use SystemC to provide stimulus to your design
The VCS /SystemC Co-simulation Interface creates the necessary infrastructure to co-simulate SystemC models with Verilog models. The infrastructure consists of the required build files and any generated wrapper or stimulus code. VCS writes these files in subdirectories in the ./csrc directory. To use the interface, you dont need to do anything to these files. During co-simulation, the VCS /SystemC Co-simulation Interface is responsible for: Synchronizing the SystemC kernel and VCS Exchanging data between the two environments
Note: The unified profiler (an LCA feature) can report CPU time profile information about the SystemC part or parts of a design. See the chapter in the LCA features documentaion. There are examples of Verilog instantiated in SystemC and SystemC instantiated in Verilog in the $VCS_HOME/doc/examples/systemc directory.
The interface supports the following compilers: - Linux: gcc 3.4.6 and gcc 4.2.2 compilers - Solaris: SC 8.0, and gcc 3.3.2
The VCS / SystemC Co-simulation Interface supports 32-bit, as well as 64-bit (VCS flag -full64) simulation. The gcc 4.2.2, gcc 3.4.6 compilers along with a matching set of GNU tools are available on the Synopsys FTP server for download. For more information, e-mail [email protected].
This chapter describes the following sections: Overview Verilog Design Containing Verilog Modules and SystemC Leaf Modules SystemC Designs Containing Verilog Modules SystemC Only Designs Considerations for Export DPI Tasks Specifying Runtime Options to the SystemC Simulation Using a Port Mapping File Using a Data Type Mapping File Combining SystemC with Verilog Configurations Parameters Debugging Mixed Simulations Using DVE or UCLI Transaction Level Interface
Delta-cycles Using a Customized SystemC Installation Using Posix threads or quickthreads Extensions Installing VG GNU Package Static and Dynamic Linking Limitations Incremental Compile of SystemC Source Files TLI Direct Access Aligning VMM and SystemC Messages Exchanging Data Between SystemVerilog and SystemC Using Byte Pack/Unpack Using Direct Program Interface Based Communication Improving VCS-SystemC Compilation Speed Using Precompiled C++ Headers Increasing Stack and Stack Guard Size Using HDL and SystemC Sync Loops Controlling Simulation Run From sc_main UCLI Save Restore Support for SystemC-on-top and PureSystemC Enabling Unified Hierarchy for VCS and SystemC Aligning VMM and SystemC Messages
UVM Message Alignment Introducing TLI Adapters Using VCS UVM TLI Adapters
Overview
VCS /SystemC Co-simulation Interface supports the following topologies: Verilog designs containing SystemC modules In this topology, you have a Verilog testbench and instances of SystemC and Verilog. You can also have many other SystemC modules in the design. To instantiate a SystemC module in your Verilog design, create a Verilog wrapper and instantiate the wrapper in your Verilog testbench. You can use the syscan utility to create a Verilog wrapper for your SystemC module. To see the usage model and an example, refer to the section entitled, Verilog Design Containing Verilog Modules and SystemC Leaf Modules. SystemC designs containing Verilog modules In this topology, you have a SystemC testbench and instances of Verilog. You can also have many other SystemC modules in the design. To instantiate a Verilog design in your SystemC module, create a SystemC wrapper and instantiate the wrapper in your SystemC module. You can use the vlogan executable to create a SystemC wrapper for your Verilog design units. To see the usage model and an example, refer to the section entitled, SystemC Designs Containing Verilog Modules. For information on limitations, see Limitations.
Figure 19-1 VCS DKI Communication of a Verilog Design Containing SystemC Modules
Managed by the tool HDL environment HDL source code clk reset in rdy_read out SystemC interface to the HDL environment clk reset in rdy_read
Block 2 Block 1
DKI
Block 1
Block 2
Block 3
out
Usage Model
The usage model to simulate a design having a Verilog testbench with SystemC and Verilog instances involves the following steps: 1. Wrapper Generation 2. Compilation 3. Simulation Wrapper Generation
% syscan [options] file1.cpp:sc_module_name
For additional information, see Generating Verilog Wrappers for SystemC Modules.
Compilation
% vcs -sysc [compile_options] file1.v file2.v
Simulation
% simv [runtime_options]
Where: filename[:modulename] [filename[:modulename]]* Specifies all the SystemC files in the design. There is no limit to the number of files. Include :modulename, for those SystemC modules which are directly instantiated in your Verilog design. If :modulename is omitted, the .cpp files are compiled and added to the design's database so the final vcs command is able to bring together all the modules in the design. You do not need to add -I$VCS_HOME/ include or -I$SYSTEMC/include. [options] These can be any of the following: -cflags "flags" Passes flags to the C++ compiler.
-cpp path_to_the_compiler Specifies the location of the C++ compiler. If you do specify this option, VCS uses the following compilers by default: - Linux : g++ - SunOS : CC (native Sun compiler) Note: - See the VCS Release Notes for details on all supported compiler versions. -full64 Enables compilation and simulation in 64-bit mode. -debug_all Prepares SystemC source files for interactive debugging. Along with -debug_all, use the -g compiler flag. -port port_mapping_file Specifies a port mapping file. See Using a Port Mapping File on page 39. -Mdir=directory_path Specifies an alternate directory for 'csrc'. -help|-h Displays the syntax, options, and examples of the syscan command. -v Displays the version number.
Using SystemC 19-10
-o name The syscan utility uses the specified name instead of the module name as the name of the model. Do not enter this option when you have multiple modules on the command line. Doing so results in an error condition. -V Displays code generation and build details. Use this option if you encounter errors, or are interested in the flow that builds the design. -vcsi Prepares all SystemC interface models for simulation with VCSi -f filename Specifies a file containing one or more filename[:modulename] entries, as if these entries were on the command line. -verilog Generates wrapper for the specified language. -verilog is the default. -tlm2 Add to the compiler call include directives for header files of the TLM 2.0.1 installation (located at $VCS_HOME/etc/ systemc/tlm). These include directories have precedence over other include directories specified with syscan -cflags "-I/my/tlm2/include".
Note: You do not specify the data type mapping file on the command line. For detailed information, see Using a Data Type Mapping File on page 40. The following example generates a Verilog wrapper:
syscan -cflags "-g" sc_add.cpp:sc_add
Example
In this example, you have a Verilog testbench, a SystemC module, stimulus, and a Verilog module, display.
// SYSTEMC MODULE: stimulus #include <systemc.h> #include "stimulus.h" void stimulus::entry() { cycle++; // sending some reset values if (cycle<25) { reset.write(SC_LOGIC_1); input_valid.write(SC_LOGIC_0); } else { reset.write(SC_LOGIC_0); input_valid.write( SC_LOGIC_0 ); // sending normal mode values if (cycle%60==0) { input_valid.write(SC_LOGIC_1); sample.write( send_value1.to_int() ); printf("Stimuli : %d\n", send_value1.to_int()); send_value1++; }; } }
//Verilog module: display module display (output_data_ready, result); input output_data_ready; input [31:0] result; integer counter; ... endmodule
//Verilog testbench: tb module testbench (); parameter PERIOD = 20; reg clock; wire reset; wire input_valid; wire [31:0] sample; wire output_data_ready; wire [31:0] result; // Stimulus is the SystemC model. stimulus stimulus1(.sample(sample), .input_valid(input_valid), .reset(reset), .clk(clock)); // Display is the Verilog model. display display1(.output_data_ready(output_data_ready), .result(result)); ... endmodule
Note: You can find the same example with a run script in the $VCS_HOME/doc/examples/systemc/ directory.
The usage model for the above example is shown below: Wrapper Generation
% syscan stimulus.cpp:stimulus
For additional information, see Generating Verilog Wrappers for SystemC Modules. Compilation
% vcs -sysc tb.v display.v
Simulation
% simv
This will force the Verilog kernel to have the same values as the default values from the SystemC kernel. If this is not possible (for example, because you need a higher resolution in a Verilog module), then change the default values of the SystemC kernel as shown in the next section.
The user defined main routine must look like the following:
// File user_main.cpp int user_main_function(int argc, char **argv) { // you have access to the argc,argv arguments: for (int i = 0; i < (argc-1); ++i) std::cerr << Arg[" << i << "] = " << argv[i] << "\n"; // do other init-stuff here... return 0; } extern "C" int sc_main_register(int (*)(int, char **)); static int my_sc_main = sc_main_register(user_main_function); // end-of user_main.cpp
DKI
Block 1
Block 2
Block 3
Usage Model
The usage model to simulate a design having a SystemC testbench with SystemC and Verilog instances involves the following steps:
For additional information, see Generating a SystemC Wrapper for Verilog Modules. Compilation
% syscsim Verilog_files other_C++_source_files [compile_options]
Simulation
% simv [runtime_options]
An optional port mapping file. If you do not provide this file, the interface uses the default port mapping definition. For details of the port mapping file, see Using a Port Mapping File on page 39. An optional data type mapping file. If you dont write a data type mapping file, the interface uses the default file in the VCS installation. For details of the data type mapping files, see Using a Data Type Mapping File on page 40.
Here the options are: -sc_model modulename file.v Specifies the module name and its Verilog source file. -cpp path_to_the_compiler Specifies the location of the C compiler. If you omit -cpp path, your environment will find the following compilers as defaults: - Linux : g++ - SunOS : CC (native Sun compiler)
Note: -See the VCS Release Notes for more details on supported compiler versions. -You can override the default compilers in your environment by supplying a path to the g++ compiler. For example:
-cpp /usr/bin/g++
-sc_portmap port_mapping_file Specifies a port mapping file. For additional information, see Using a Port Mapping File on page 39. -Mdir=directory_path Works the same way that the -Mdir VCS compile-time option works. If you are using the -Mdir option with VCS, you should use the -Mdir option with vlogan to redirect the vlogan output to the same location that VCS uses. -V Displays code generation and build details. Use this option if you are encountering errors or are interested in the flow that builds the design. For example, the following command line generates a SystemC wrapper and interface file for a Verilog module display:
vlogan -sc_model display display.v
Example
In this example, we have SystemC testbench sc_main, another SystemC module, stimulus, and a Verilog module display.
// SystemC module: stimulus #include <systemc.h> #include "stimulus.h" void stimulus::entry() { cycle++; // sending some reset values if (cycle<25) { reset.write(SC_LOGIC_1); input_valid.write(SC_LOGIC_0); } else { reset.write(SC_LOGIC_0); input_valid.write( SC_LOGIC_0 ); // sending normal mode values if (cycle%60==0) { input_valid.write(SC_LOGIC_1); sample.write( send_value1.to_int() ); send_value1++; }; } } //Verilog module: display module display (output_data_ready, result); input output_data_ready; input [31:0] result; integer counter; ... endmodule
<systemc.h> "stimulus.h" "fir.h" "display.h" //Header file for Verilog module display
int sc_main(int argc , char *argv[]) { sc_clock clock ("CLK", 20, .5, 0.0); sc_signal<sc_logic> reset; sc_signal<sc_logic> input_valid; sc_signal<sc_lv<32> > sample; sc_signal<sc_logic> output_data_ready; sc_signal<sc_lv<32> > result; display display1("display1" ); stimulus stimulus1("stimulus1" ); stimulus1.reset(reset); stimulus1.input_valid(input_valid); stimulus1.sample(sample); stimulus1.clk(clock.signal()); fir1.reset(reset); fir1.input_valid(input_valid); fir1.sample(sample); fir1.output_data_ready(output_data_ready); fir1.result(result); fir1.clk(clock.signal()); display1.output_data_ready(output_data_ready); display1.result(result); display1.input_valid(input_valid); display1.sample(sample); sc_start(); return 0; }
See $VCS_HOME/doc/examples/systemc/ for examples. The usage model for the above example is shown below:
Wrapper Generation
% vlogan -sysc -sc_model display display.v
For additional information, see Generating a SystemC Wrapper for Verilog Modules on page 21. Compilation
% syscsim -sysc stimulus.cpp
Simulation
% simv
Compilation Scheme
When SystemC is at the top of the design hierarchy and you instantiate Verilog code in the SystemC code, the compilation of the simulation is done in the following two steps: The first step is to create a temporary simulation executable that contains all SystemC parts, but does not yet contain any HDL parts. VCS then starts this temporary executable to find out which Verilog instances are really needed. All SystemC constructors and end_of_compilation() methods are executed; however, simulation does not start. VCS creates the final version of the simv file containing SystemC, as well as all HDL parts. The design is now fully compiled and ready to simulate.
As a side effect of executing the temporary executable during step 1, you will see that the following message is printed:
Error-[SC-VCS-SYSC-ELAB] SystemC elaboration error
The design could not be fully elaborated due to an early exit of the SystemC part of the design. The SystemC part must execute the constructors of the design. Please find the details in the SystemC chapter of the VCS documentation.
In case your simulation contains statements that should NOT be executed during step 1, guard these statements with a check for environment variable SYSTEMC_ELAB_ONLY or, with the following function:
extern "C" bool hdl_elaboration_only()
Both will be set/yield true only during this extra execution of simv during step 1. For example, guard statements like this:
sc_main(int argc, char* argv[]) { // instantiate signals, modules, ... ModuleA my_top_module(...); // <-- must always be executed // run simulation if (! hdl_elaboration_only()) { ... open log file for simulation report ... } sc_start(); // <-- must always be executed if (! hdl_elaboration_only()) { ... close log file ... } return 0; }
If you guard statements as mentioned above, make sure that all module constructors and at least one call of sc_start() will be executed. VCS needs to know the entire SystemC module hierarchy during step 1, which in turn means that all SystemC module constructors must be executed. If your simulation checks the command line arguments argc + argv, then you have two choices. Either guard these statements with an IF-statement as shown above. Alternatively, provide the simv command line arguments used during elaboration using the VCS argument -syscelab. Example: For non Unified Use Model (UUM) use model:
syscsim main.cpp ... -syscelab A ...
or, in UUM:
vcs -sysc sc_main ... -syscelab A ...
You can specify -syscelab multiple times. White space within the arguments is not preserved, instead the arguments are broken up into multiple arguments; multiple arguments can also be enclosed within double quotes, for example with -syscelab "1 2 3". If your SystemC design topology (the set of SystemC instances) depends on simv runtime arguments, then you MUST provide the relevant arguments with -syscelab. The SystemC design topology during step 1 and the final execution of simv must be identical.
Note that the -syscelab option is only supported when SystemC is at the top of the design hierarchy. If Verilog is at the top, then syscelab is neither needed nor supported.
Usage Model
The usage model to simulate a pure SystemC design involves the following steps: 1. Compilation 2. Simulation Compilation
% syscan <SystemC source files(s)> % vcs -sysc [compile_options] sc_main
Simulation
% simv [runtime_options]
Example 1:
% % % % syscan adder.cpp syscan foo.cpp bar.cpp xyz.cpp main.cpp vcs -sysc sc_main ./simv -gui
Example 2:
% % % % syscan -cpp g++ -cflags -g adder.cpp syscan -cpp g++ -cflags -g foo.cpp bar.cpp xyz.cpp syscan -cpp g++ -cflags -g main.cpp vcs -sysc sc_main \ -cpp g++ -cflags -g \ extra_file.o -ldflags "-L/u/me/lib -labc" % ./simv -ucli
Restrictions
The following compilation options are not supported for pure SystemC simulation: -sverilog: Pure SystemC simulation will not have any SV files. -ntb*: Pure SystemC simulation will not have any OV files. -ova*: Pure SystemC simulation will not have any OV files. -cm*: Coverage related options are not supported. -comp64: Cross-compilation is not supported. However, pure SystemC simulation is supported in 32-bit and 64-bit mode. -e: The name of the main routine must always be sc_main.
-P: Pure SystemC simulation will not have any HDL files.
stack [-up|-down] continue/step/next/finish run [time] The following UCLI and DVE features are not supported for SystemC objects: Viewing schematics Using force, release commands Tracing [active] drivers, and loads The UCLI command next -end is not supported. Commands that apply to HDL objects only
In case of a Control-C (i.e., SIGINT), CBug will always take over and report the current location.
Using SystemC 19-30
When the simulation stops somewhere in the System C or VCS kernel, between execution of user processes, then a dummy file is reported as the current location. This happens, for example, immediately after the init phase. This dummy file contains a description about this situation and instructions how to proceed (i.e., Set BP in SystemC source file, click continue).
This command forces the Verilog kernel to have the same values as the default values from the SystemC kernel. If this is not possible (for example, because you need a higher resolution in a Verilog module), then change the default values of the SystemC kernel as shown in the following section.
This is necessary for each export DPI task or function that is used by SystemC or C code. Only the name of function must be specified, and formal arguments are neither needed nor allowed. Multiple space-separated function names can be specified in one call of syscan -export_DPI. It is allowed to call syscan -export_DPI any number of times. A function name can be specified multiple times.
Example Assume that you want to instantiate the following SystemVerilog module inside a SystemC module:
//myFile.v module vlog_top; export "DPI" task task1; import "DPI" context task task2(input int A); export "DPI" function function3; task task1(int n); ... endtask function int function3(int m); ... endfunction // int endmodule
You must do the following steps before you can compile the simulation:
syscan -export_DPI task1 syscan -export_DPI function3
This will locate export_DPI functions task1 and functions3 in the myFile.v file. Note: syscan does not apply a complete Verilog or SystemVerilog parser, but instead does a primitive string search in the specified file. The following restrictions apply: The entire export_DPI declaration must be written in one line (no line breaks allowed) `include statements are ignored Macros are ignored
VCS will compile the design even if the source files do not comply to the above restrictions. However, syscan will be unable to extract some or all of the export_DPI declarations. In this case, use syscan -export_DPI [function-name].
It is important to use an archive (file extension .a) and not an object file (file extension .o).
Options -Mlib and -Mdir are available in all configurations, meaning for SystemC designs containing Verilog modules, and also for Verilog designs containing SystemC modules.
Function sc_main() will receive arguments "a b e f g". The VCS simulator kernel will receive arguments "c d -ucli".
bit_vector specifies a vector (multi-bit) unsigned Verilog port (bit-vector is a valid alternative) signed specifies a Verilog port that is also a reg or a net declared with the signed keyword and propagates a signed value.
SystemC types are restricted to the sc_clock, sc_bit, sc_bv, sc_logic, sc_lv, sc_int, sc_uint, sc_bigint, and sc_biguint data types. Native C/C++ types are restricted to the bool, char, uchar, short, ushort, int, uint, long, and ulong data types.
ports, you can create one or more default mappings for a particular type that will be used for all ports, rather than having to create a port map for every port of each new HDL wrapper model. Data type mapping files map types, so that ALL ports of that type on ALL instances will now be assigned the specified mapping. The data type mapping file is named cosim_defaults.map. The interface looks for and reads the data mapping file in the following places and in the following order: 1. In $VCS_HOME/include/cosim 2. In your $HOME/.synopsys_ccss directory 3. In the current directory. An entry in a later file overrules an entry in an earlier file. Each entry for a SystemC type has the following: 1. It begins with the keyword Verilog. 2. It is followed by the bit width. For vectors, an asterisk (*) is a wildcard to designate vectors of any bit width not specified elsewhere in the file. 3. The corresponding Verilog type using keywords that specify if it is scalar, unsigned vector, or signed port, the same keywords used in the port mapping file. 4. The SystemC or Native C++ type. Example 19-2 shows an example of a data type mapping file.
Example 19-2
################################################## # Mappings between SystemC and Verilog datatypes ################################################## Verilog * bit_vector sc_bv Verilog 1 bit bool Verilog * bit_vector int Verilog * signed int Verilog 1 bit sc_logic Verilog 1 bit sc_bit Verilog * bit_vector char Verilog * bit_vector uchar Verilog * bit_vector short Verilog * bit_vector ushort Verilog * bit_vector uint Verilog * bit_vector long Verilog * bit_vector ulong
Verilog-on-top, SystemC
A Verilog-on-top design with SystemC is specified like any other design, where the analysis of the Verilog files, by means of vlogan, must use the libmap option. Added to it is a Verilog source file, containing the configurations. A configuration consists of a config scope. Example:
config use_A; design top; // name of the Verilog top-entity default liblist workA; // library where the top-entity is analyzed // different mappings of verilog instances: instance top.v_mod.inst1 use workA.v_sub; // verilogsubtractor instance top.v_mod.inst3 use workA.s_sub; // SystemCsubtractor endconfig
config use_B; design top; default liblist workA; // no overrule for ...inst1 instance top.v_mod.inst2 use workA.s_sub; // SystemCsubtractor instance top.v_mod.inst3 use workA.s_sub; // SystemCsubtractor endconfig
The name of the Verilog top-entity is obligatory. The default liblist statement defines where this Verilog top-entity is analyzed, by means of the libmap option of vlogan. The instances are defined by their logical hierarchical name within the design hierarchy.
For setting up a design with Verilog configurations, there must be at least one call to syscan like the one given below:
%> syscan s_sub.cpp:s_sub
Above command generates an interface model, which has to be instantiated in Verilog. The libmap option for vlogan requires a correct setting of the synopsys_sim.setup file. See the VCS and VCS MX user guides for details.
The following example shows how to compile a design containing Verilog and SystemC:
%> %> %> %> %> syscan s_sub.cpp:s_sub -sysc=2.2 vlogan v_sub.v -libmap liblist.map -sverilog vlogan v_design.v -libmap liblist.map -sverilog vlogan v_configs.v -libmap liblist.map -sverilog vcs -sverilog -top use_B -sysc=2.2
The used configuration for the design is specified with the option "-top <config-name>". When a different configuration is to be used, or a configuration has changed, it is sufficient to re-analyze the verilog file containing the changed configuration, and redo the elaboration.
SystemC-on-top, Verilog
A SystemC-on-top design with Verilog is specified like any other design, where the analysis of the Verilog files, by means of vlogan, must use the libmap option. Added to it is a Verilog source file, containing the configurations. The following example shows a configuration with a SystemC-on-top topology:
config use_SysC_A; design sYsTeMcToP; // name of the default SystemC top entity default liblist workA; // library where the top-entity is analyzed // different mappings of verilog instances: instance sYsTeMcToP.v_mod.inst1 use workA.v_sub; // verilog-subtractor instance sYsTeMcToP.v_mod.inst2 use workA.v_add; // verilog-adder instance sYsTeMcToP.\sctop.sc2 .v_mod.inst3 use workA.v_add; endconfig
config use_SysC_B; design sYsTeMcToP; default liblist workA; instance sYsTeMcToP.v_mod.inst2 use workA.v_sub; / / verilog-subtractor instance sYsTeMcToP.\sctop.sc2 .v_mod.inst3 use workA.v_add; endconfig
The name of the SystemC top-entity is hard coded as sYsTeMcToP and cannot be changed. Note that only Verilog modules can be reconfigured; it is not possible to reconfigure a SystemC instance . Also note that it is not possible to re-configure a Verilog-instance to a SystemC-instance. How to specify the pathname for a Verilog instance depends on the position of the instance within the design hierarchy. Use a normal path for Verilog modules that are instantiated at the top-level inside the sc_main() function and that are not a subinstance of a SystemC model. Example:
"instance sYsTeMcToP.v_mod.inst1"
But you must use a partially escaped path name for Verilog instances that are sub-instances of SystemC modules. The path name has to be split into two parts, where the first part contains only SystemC instances, and a second part contain Verilog instances. The first part has be specified as an extended Verilog identifier. Example:
instance sYsTeMcToP.\sctop.sc2 .v_mod.inst3 use workA.v_add;
The first part consists two SystemC instances, sctop and sc2. These instances must be specified as "\sctop.sc2 ".
Note that the space at the end is important and must not be omitted. The second part consist of two Verilog instances, v_mod and inst3 and must not be escaped. Note: Writing the configuration as given below is not supported:
instance sYsTeMcToP.sctop.sc2.v_mod.inst3 use workA.v_add;
The used configuration is specified with the -top <config-name> option. Note: The argument sc_main specifies that the design topology is SystemC-on-top. When a different configuration is to be used, or a configuration has changed, it is sufficient to re-analyze the verilog file containing the changed configuration, and redo the elaboration.
Limitations
The following limitation apply:
A Verilog-on-top design must contain at least one SystemC instance, when no configurations are used. Later on, this SystemC instance can be configured to something else. The name of the SystemC-top entity is hard coded to sYsTeMcToP. The interfaces of the modules must match. The results are unpredicted otherwise. It is the user's responsibility to keep the consistence here.
Parameters
Parameters are supported between Verilog and SystemC. The parameter values that are specified for a SystemC instance in Verilog are automatically passed to the SystemC domain.
Parameters in Verilog
Supported parameter types in Verilog are signed and unsigned integers and the real data type. For SystemVerilog, the string parameter type is also supported. Parameters are part of a module declaration and can be used like:
parameter parameter parameter parameter parameter parameter parameter msb = 7; e = 7, f = 5; foo = 8; bar = foo + 42; av_delay = (e + f) / 2; signed [3:0] mux_selector = 3; real pi = 314e-2; string hi_there = "Verilog String Parameter";
Parameters in SystemC
In SystemC, there is no standard definition for parameters. Therefore, a special parameter class is defined for that purpose. The supported types must match the types as being using in (System)Verilog , so the supported datatypes are int, double and std::string. Within SystemC the parameters must be initialized with a default value inside the class constructor. Example:
#include "systemc.h" #include "snps_hdl_param.h" SC_MODULE(sysc_foo) { // declarative part hdl_param<int> msb; hdl_param<int> e, f; hdl_param<double> av_delay; hdl_param<std::string> hi_there; // initialization part SC_CTOR(sysc_foo) : HDL_PARAM(msb, 42), HDL_PARAM(e, 3), HDL_PARAM(f, 4),HDL_PARAM(av_delay, "123.456"), HDL_PARAM(hi_there, "SystemC String Parameter") { ... } };
Verilog-on-Top, SystemC-down
The instantiation of a parameterized SystemC module inside Verilog is the same as for any other Verilog module:
sysc_foo #(11, 2, 3, 12.21, "Verilog-override") foo1(...); sysc_foo #(.av_delay(44.33), .e(-9)) foo2(...); sysc_foo foo3(...); // using all default parameter values
Within the SystemC constructor, the values of the parameters can be obtained by:
// SC_CTOR(sysc_foo) : HDL_PARAM(...)... { int l_msb = msb.get(); double delay = av_delay.get(); std::string str = hi_there.get(); }
SystemC-on-Top, Verilog
Within SystemC there are two ways to instantiate a foreign module: using the default constructor, and using separate setting calls for the parameters, or using a fully specified constructor, where each parameter must be assigned a value.
The instantiation can be in any SystemC module and/or in the sc_main routine:
#include "v_add.h" // verilog module int sc_main(int, char **) { v_add m_v1("v1", 3 /* incr value */, 1.01 /* factor */, "SystemC Override"); v_add m_v2("v2"); m_v2.incr_value(4); m_v2.factor(0.99);
The hdl_param class defines the ::operator() to initialize the parameters, and the ::get() function for obtaining the final value of the parameter. Parameters can only be initialized once, and cannot be altered after the value of the parameter is obtained by means of the ::get() function.
Namespace
For SystemC-2.2, name spaces are used to define the SystemC hdl_param objects:
namespace sc_snps { template < class T > class hdl_param : public sc_object { ... }; } // namespace sc_snps
This works only for integer and real parameter types. This doesn't work for string parameters.
* -parameters param.lst
with param.lst a list of parameter assignments (see the specific vcs part of this guide discussing parameters).
Debug
The SystemC hdl_param objects are visible as class parameters within a combined hierarchy view (vpd-file). Although parameters are constant and won't change after time == 0, they can be traced. Access with the UCLI get command is supported. Changing the value with the change or force commands is not supported, since parameters are constant after the construction time.
Limitations
The verilog parameters are not compile constants for SystemC. That has a limitation that these can not be used as template arguments for the construction of templatized classes. Example:
SC_CTOR(not_possible) : HDL_PARAM(width, 4) { sc_int<width> *pint = new sc_int<width>; // NOT SUPPORTED } module test( data_in1, data_in2 ); parameter width = 12; input [width-1 : 0] data_in1; // NOT SUPPORTED input [11 : 0] data_in2; endmodule
The following steps outline the general debugging flow. For more information, see The Discovery Visual Environment User Guide and the Unified Command-line Interface User Guide. 1. Compile your VCS with SystemC modules as you normally would, making sure to compile all SystemC files you want to debug. For example, with a design with Verilog on top of a SystemC model:
% syscan -cpp g++ -cflags "-g" my_module.cpp:my_module % vcs -cpp g++ -sysc -debug_all top.v
Note that you must use -debug or -debug_all to enable debugging. 2. Start the debugger. - To start DVE, enter:
simv -gui
3. Attach the C debugger as follows: - In DVE, select Simulator > C/C++ Debugging or enter cbug on the console command line. - In UCLI, enter cbug on the command line. Debugging SystemC source code is enabled and the following message appears:
CBug - Copyright Synopsys Inc. 2003-2009.
Methods and tasks can be blocking as well as non-blocking. Blocking in the context of this document means the call may not return immediately, but consumes simulation time before it returns. However, non-blocking calls always return immediately in the same simulation time. The caller's execution is resumed exactly at the simulation time when the callee returns, so a blocking call consumes the same amount of time in both the language domains SystemC and SystemVerilog. Non-blocking calls always return immediately. The tasks or functions must be reachable through an interface of the specific language domain. This means that for SystemVerilog calling SystemC, the TLI can connect to functions that are members of a SystemC interface class. For SystemC calling SystemVerilog, the TLI can call functions or tasks that are part of a SystemVerilog interface. The usage model of the transaction level interface consists of defining the interface by means of an interface definition file, calling a code generator to create the TLI adapters for each domain, and finally instantiation and binding of the adapters.
section is arbitrary, and the first occurrence of a task or function keyword marks the end of this section. The format of the file is illustrated as follows:
interface if_name direction sv_calls_sc [verilog_adapter name] [systemc_adapter name] [hdl_path XMR-path] [#include "file1.h"] [`include "file2.v"] ... task <method1> input|output|inout|return vlog_type argument_name_1 return input|output|inout|vlog_type argument_name_2 . . . function [return type] method2 input|output|inout vlog_type argument_name_1 . . .
The interface entry defines the name of the SystemVerilog "interface". Similarly, the class entry defines the name of the SystemVerilog "class". For the direction SystemVerilog calling SystemC, the if_name argument must match the name of the SystemC interface class. Specialized template arguments are allowed in this case, for example my_interface<int> or my_interface<32>. For SystemC calling SystemVerilog, if_name must match the SystemVerilog interface name.
The direction field specifies the caller and callee language domains, and defaults to sv_calls_sc. The SystemC calling SystemVerilog direction is indicated by sc_calls_sv. The verilog_adapter and systemc_adapter fields are optional and define the names of the generated TLI adapters and the corresponding file names. File extension .sv is used for the verilog_adapter and file extensions .h and .cpp for the systemc_adapter. The optional #include lines are inserted literally into the generated SystemC header file, and the optional `include lines into the generated SystemVerilog file. The hdl_path field is optional and binds the generated Verilog adapter through an XMR to a fixed Verilog module, Verilog interface, or class instance. Using hdl_path makes it easier to connect to a specific entity, however, the adapter can be instantiated only once, not multiple times. If you want to have multiple connections, then create multiple adapters which differ only by their name. A SystemC method may or may not be blocking, meaning it may consume simulation time before it returns or it will return right away. This distinction is important for the generation of the adapter. Use task for SystemC methods that are blocking or even potentially blocking. Use function for SystemC methods that will not block for sure. Note that functions enable faster simulation than tasks. The lines after task or function define the formal arguments of the interface method. This is done in SystemVerilog syntax. This means that types of the arguments must be valid SystemVerilog types. See Supported Data Types of Formal Arguments on page 65 for more details.
The return keyword is only allowed once for each task. It becomes an output argument on the Verilog side to a return value on the SystemC side. This feature is required because blocking functions in SystemC may return values, while Verilog tasks do not have a return value. The one exception is if the methods of the SystemC interface class use reference parameters. For example, if my_method(int& par)is used, then you need to mark this parameter as inout& in the interface definition file. Note that the & appendix is only allowed for inout parameters. For input parameters, this special marker is not needed and not supported. Pure output parameters that should be passed as reference must be defined as inout in the interface definition file. Example interface definition file for the simple_bus blocking interface:
interface simple_bus_blocking_if direction sv_calls_sc verilog_adapter simple_bus_blocking_if_adapter systemc_adapter simple_bus_blocking_if_adapter #include "simple_bus_blocking_if.h" task burst_read input int unsigned priority_ inout int data[32] input int unsigned start_address input int unsigned length input int unsigned lock return int unsigned status task burst_write input int unsigned priority_ inout int data[32] input int unsigned start_address input int unsigned length input int unsigned lock return int unsigned status
Using SystemC 19-59
This command generates SystemC and SystemVerilog files that define the TLI adapters for each language domain. All generated files can be compiled just like any other source file for the corresponding domain. The files have to be generated again only when the content of the interface definition file changes. TLI adapters for the sv_calls_sc direction can be generated in two different styles. The SystemC part of the generate adapter is the same for both styles, however, the SystemVerilog part is different. If you use the -idf option along with the interface entry in the idf file, then this option creates a SystemVerilog "interface". Similarly, If you use the -idf option along with the class entry in the idf file, then this option creates a SystemVerilog "class". A class is generally easier to connect into the SystemVerilog source code and there are situations where a SystemVerilog testbench allows you to instantiate a class but not an interface. However, if a class is generated, then the TLI adapter can create only one connection of this type between the SystemVerilog and SystemC side. Alternatively, if an interface is generated, then multiple connections can be created (which are distinguished by the integer parameter of the interface).
derived class that defines only these virtual methods. You can copy these methods from the generated adapter code as a starting point and then modify the code according to the debugging requirements. If the adapter is generated again, then the existing code is overwritten and all manual edits are lost. Note: Do not manually modify the code generated by the TLI adapter. Instead, override the debug functions in a derived class.
The SystemC part of the TLI adapter is a plain SystemC module that has a port p over the specified interface name (sc_port if_name p). This module can be instantiated in the systemC design hierarchy, where you can bind the port to the design interface just like any other SystemC module. As mentioned above, there is an optional constructor argument for the point-to-point ID of type int that defaults to zero. There is a second optional constructor argument of type int that specifies the format of debug information that the adapter prints when an interface method is called. If the LSB of this argument is set, the TLI adapter prints messages to stdout. If the next bit (LSB+1) is set, this information is written to an sc_signal<string> that you can display in DVE. For SystemC calling SystemVerilog, the SystemC part of the TLI adapter is an sc_module that you can instantiate within the module where you want to call the Verilog tasks or functions. You can execute the cross-boundary task or function calls by calling the corresponding member function of the SystemC TLI adapter instance. The SystemVerilog portion of the TLI adapter depends on whether the hdl_path field and the following options are used: - The -idf option used along with the interface entry in the idf file. - The -idf option used along with the class entry in the idf file.
combination -idf used along with the interface entry in the idf file, no hdl_path: The Verilog adapter has a port over the interface type, as defined in the interface description file. You can instantiate the adapter module in the Verilog design like any other Verilog module, and the port should be bound to the SystemVerilog interface that implements the tasks or functions to be called.
combination -idf used along with the interface entry in the idf file, with hdl_path path: The Verilog adapter is a Verilog module with no ports. All calls initiated by SystemC are routed through the XMR path to some other Verilog module or interface.
combination -idf used along with the class entry in the idf file, with hdl_path path: The Verilog adapter is a group of task definitions and other statements that must be included in a program with an `include "if_name_sc_calls_sv.sv" statement. Calls initiated by the SystemC side are routed through the XMR path to some class object of the SV testbench.
combination -idf used along with the class entry in the idf file, no hdl-path: This combination is not supported and displays an error message.
It is important to note that Verilog tasks, in contrast to Verilog functions, must always be called from within a SystemC thread context. This is because tasks can consume time, and in order to
synchronize the simulator kernels, wait() is used in the SystemC adapter module. The SystemC kernel throws an error when wait() is called from a non-thread context.
input inout | output input inout | output input inout | output input inout | output input inout | output input inout | output input inout | output input inout | output input inout | output input inout | output
byte byte shortint shortint int int longint longint real real shortreal shortreal chandle chandle string string bit bit logic logic
char char* short int short int* int int* long long long long* double double* float float* void* void** char* char** unsigned char unsigned char* unsigned char unsigned char*
For the integral data types in the above table, the signed and unsigned qualifiers are allowed and mapped to the equivalent C unsigned data type. All array types listed in the above table are passed as pointers to the specific data types. There are two exceptions to this rule: Open arrays, which are only allowed for the SystemVerilog calling SystemC direction, are passed using handles (void *). The SystemVerilog standard defines the rules for accessing the data within these open arrays.
Packed bit arrays with sizes <= 32 in input direction (for example,
input bit [31:0] myarg) are passed by value of type svBitVec32. Basically, this type is an unsigned int, and the individual bits can be accessed by proper masking.
Miscellaneous
The TLI generator uses Perl5 which needs to be installed on the local host machine. Perl5 is picked up in the following order from your installation paths (1=highest priority): 1. use ${SYSCAN_PERL}, if (defined) 2. /usr/local/bin/perl5 3. perl5 from local path and print warning
Delta-cycles
VPD dumping of delta-cycles is supported for SystemC elements, but it needs to be enabled as follows:
Using SystemC 19-66
This function turns on the delta tracing (or, turns off when the argument is 0). This function can be called anywhere, for example in constructors of SystemC classes, and/or in sc_main. Next, make the generated delta-cycles visible in the DVE waveform window as follows: 1. Start the simulator with -gui option. This will pop up DVE. 2. Enable CBug Debugger in the DVE, and then select Simulator -> C/C++ Debugging -> enable. Or, enter CBug in the DVE gui console command line. 3. Select Simulator -> Capture Delta Cycle Values. This will turn it on for DVE. 4. Go with the time-marker somewhere, and then Press right-mouse button. 5. select Expand Time. Now the SystemC delta cycles are shown.
Obtain OSCI SystemC version from www.systemc.org. Set the SYSTEMC environment variable to path of the OSCI SystemC installation. For example:
setenv SYSTEMC /net/user/download/systemc-2.2.0
To create a SystemC 2.2 installation with VCS patches, perform the following series of tasks. There are several files in the $VCS_HOME/etc/systemc-2.2 directories that contain necessary patches. You need to replace all SystemC files from the OSCI installation (*) with the those from $VCS_HOME/etc/systemc-22. (*): here is the location where you need to replace these files with the those from $VCS_HOME For SC 2.2: osci_SC_installation_path/src/sysc/kernel For example, replace:
<your osci SystemC installation>/src/sysc/kernel/ sc_simcontext.cpp
with:
$VCS_HOME/etc/systemc-2.2/sc_simcontext.cpp
Follow the installation instructions provided by OSCI (see file INSTALL which is part the SystemC tar file) and build a SystemC library. Note that you must use ../configure i686-pc-linuxgnu to build a 32-bit Linux installation; call ../configure on other platforms.
Set the SYSTEMC_OVERRIDE VCS environment variable to the userdefined OSCI SystemC library installation path. For example:
setenv SYSTEMC_OVERRIDE /net/user/systemc-2.2.0
Header files must exist in the $SYSTEMC_OVERRIDE/include directory and the libsystemc.a library file must be in the following directories: $SYSTEMC_OVERRIDE/lib-linux/ $SYSTEMC_OVERRIDE/lib-gccsparcos5/ The $SYSTEMC_OVERRIDE environment variable must point to the OSCI SystemC simulator installation. Header files must be located at $SYSTEMC_OVERRIDE/include and library files in: $SYSTEMC_OVERRIDE/lib-linux/libsystemc.a $SYSTEMC_OVERRIDE/lib-gccsparcOS5/libsystemc.a As of March 19, 2007 (SYSTEMC_VERSION 20070314), VcsSystemC 2.2 is binary compatible with OSCI SystemC 2.2.0.
The following API allows you to select or check if pthreads are used (if supported on the platform):
// wish for either pthreads or quickthreads, return true // if wish is granted, return false+produce warning if not // possible. bool sc_snps::request_to_use_pthreads(bool use_pthreads); // use pthreads (true) or quickthreads for SC_[C]THREADS bool sc_snps::use_pthreads();
Function request_to_use_pthreads() must be called before the simulation starts to run for the first time, for example, before the first call of sc_start(). A good position in which to place the statement is at the beginning of the sc_main() function. The function returns true if the request was granted. It returns false if this is not possible and also a warning is printed. Reasons may be the wrong platform (for example, linux 32-bit), or by calling the function too late.
Extensions
The following proprietary extension are available as part of VCS, and not available as part of OSCI SystemC.
Runtime functions Include file systemc_user.h contains the prototypes of functions that can be called during execution of the simulation. Add this line to your source code to make the header file visible:
#include <cosim/bf/systemc_user.h>
GetFullName() Returns the full logical name of the given object or "No Name" on error. The full name can contain hierarchical sub-paths of other domains, like Verilog:
namespace sc_snps { const char *GetFullName(sc_object *obj); }
Note: The corresponding member function sc_core::sc_object::name() defined as part of the SystemC language usually does not return the same string as sc_snps::GetFullName(). Member sc_object::name() does not consider Verilog instances and shows only the path name w.r.t. to the SystemC hierarchy. Alternatively, the GetFullName()function considers the entire Verilog/SystemC instance hierarchy and gives the correct logical name of the SystemC instance inside this hierarchy.
GetName() Returns the instance name (short name) of the given object or return "No Name" on error:
namespace sc_snps { const char *GetName(sc_object *obj); }
Note: The corresponding member function sc_core::sc_object::basename(), defined as part of the SystemC language, usually does not return the same string as sc_snps::GetName(). Asynchronous Reset for Clocked Thread Processes The SystemC standard allows a clocked thread process (SC_CTHREAD) to have an optional synchronous reset. This is specified with the reset_signal_is() function as follows:
SC_CTHREAD( th_1, clk.pos() ); reset_signal_is( syncrst, true );
In addition, VCS supports an optional asynchronous reset, which is specified with the async_reset_signal_is() function. For example:
SC_CTHREAD( th_1, clk.pos() ); async_reset_signal_is( asyncrst, true );
Note: This feature is a VCS-specific extension. It is not a part of the IEEE 1666 OSCI SystemC standard. Note the following points about asynchronous resets:
- Both the synchronous and asynchronous resets are optional. A process can have one, both, or none of these resets. - While you can specify asynchronous resets in any order, ensure that they are within the constructor section (SC_CTOR). - An asynchronous reset cannot be specified more than once. - When the asynchronous reset is specified, the clocked thread process will restart if either of the following conditions are true: - the asynchronous reset is active during the clock edge - the asynchronous reset changes from inactive to active even if there is no clock edge When the synchronous reset is also specified, the process will also restart if the synchronous reset is active during the clock edge. If only the synchronous reset is specified, the behavior is as defined in the IEEE 1666 standard. The syntax of the asynchronous reset function is as follows:
async_reset_signal_is (pin, level)
Where: pin Specifies the signal, which can be either an input port or signal of type bool.
level Defines the level at which the reset becomes active. This feature has the following limitations: - Asynchronous reset can be specified only for a SC_CTHREAD. - Asynchronous resets must be specified during elaboration, preferably within the SC_CTOR section.
Note: Add the -I${VCS_HOME}/include/systemc_version option to C/C++ compiler to compile SystemC files. The archive can be statically linked by just passing the archive as any other file on the vcs command line.
% vcs top.v ./extenv.a
Note: Add the -sysc option to the vcs command line, if the object file is for SystemC.
It begins with the lib keyword, followed by any specified name library_name, followed by .so.version. The version is optional and is user defined. Linker/loader automatically locates and picks the shared object file using -L and -l options as explained below. For example, the library name in libfoo.so or libfoo.so.1 is foo. The commands to create a shared object file are as shown:
% gcc -fPIC -o foo.o -c -I$VCS_HOME/include foo.c % gcc -shared -o libfoo.so foo.o
The shared object file can be dynamically linked by using -LDFLAGS with the -Lpath_to_shared_object and -llibrary_name options on the vcs command line.
-LDFLAGS options
Specifies the library name of the shared object file. If there are more then one shared object located in different directories, you can specify -Lpath_to_the_shared_object multiple times for each directory and -llibrary_name multiple times for each shared object file.
% vcs top.v -LDFLAGS "-L<path_to_libfoo.so> -lfoo -L<path_to_libhello.so> -lhello"
You can also specify the linker options directly to the vcs command line.
% vcs top.v -Lpath_to_libfoo.so -lfoo -Lpath_to_libhello.so -lhello
Analyze your SystemC top file (which is instantiated in HDL design) to create a HDL wrapper.
% syscan sc_top.cpp:sc_top -sysc=2.2
The shared object can be dynamically linked by using the -Lpath_to_shared_object and -llibrary_name options on the vcs command line.
% vcs -sysc=2.2 top.v -Lpath_to_shared_object file -lfoo
Now, for any change in the C/C++/SystemC files, you simply need to rebuild the shared object file with the commands as mentioned above and execute the simv. You do not have to rebuild the simv.
Limitations
The following limitations apply to the VCS/SystemC interface. No Donuts / Sandwiches VCS/SystemC does not support having "donuts" or "sandwiches" in SystemC and Verilog modules. Therefore, you cannot have a SystemC instance that is instantiated under an HDL design unit and itself instantiates another HDL design unit. Similarly, a SystemC-HDL-SystemC instance hierarchy is not supported. In other words, following the design hierarchy from a leaf instance towards the root, you can transition from SystemC to HDL or vice-versa only once. Number of ports There is no limitation regarding the number of port for an interface model. It may have none, one, or multiple ports. You cannot compile mixed designs (SystemC+HDL) in a directory where the directory path/name contains the symbol :. For instance, if you have a : in your directory path/name, as illustrated below, you might face a compilation error. Depending on the complexity of your flow, you might even face an elaboration error.
/remote/vg/work/mixed_design:example/build/
Incremental compile does not require any change in existing compile scripts. VCS automatically figures out when a syscan command needs to trigger compiling a source file with gcc.
Here, all SC source files are compiled. Each invocation of syscan triggers a compilation of the specified SC source files. Object files are stored in csrc/sysc or the mydir/sysc directory if you use the -Mdir mydir option. This is called a full build from scratch. It serves as a basis for later incremental builds.
will compile B1.cpp only if either the file B1.cpp, or a header file has changed since the last invocation of syscan. The dependency check to header files includes any header that is directly or indirectly included by B1.cpp. Note that any compiler option specified with -cflags (such as -Imydir or -DMODE=1) is not considered during the dependency check. If the flags change but the source files remain the same, the files are not recompiled.
Syscan calls can also create a Verilog wrapper. For example, you can use the following command:
% syscan A.cpp:A
Here, source file A.cpp is compiled again if either A.cpp, or a header file has changed. This syscan call also checks if the signature (the set of interface ports) of the interface has changed. If (and only if) the signature has changed, then the interface file is generated and compiled again. The interface file is only created and compiled again when the signature changes. Incremental compilation of SystemC files reduces the time spent in syscan calls. When the remaining commands:
% vlogan top.v ... % vcs -sysc Top ...
are issued again, the Verilog files are analyzed and elaborated again, so these phases of the overall compilation do not benefit directly from the SystemC incremental compilation. However, generation of object code for Verilog files may be skipped by VCS if this feature is enabled.
All SC source files that have previously been compiled with syscan are checked and automatically compiled again if necessary. Finally, the simulation (simv) is linked again. You cannot specify any other VCS option together with -sysc=incr. Only the option -full64 (aka -mode64) can, and must be specified again. You can call syscan before calling vcs -sysc=incr. For example:
% syscan B1.cpp % vcs -sysc=incr
Using this example, if B1.cpp, or a header file has changed, then B1.cpp is compiled again by the syscan call. The subsequent vcs -sysc=incr does not compile B1.cpp in this case. That means issuing the syscan call neither increase nor decrease the TAT; it just triggers the compilation of B1.cpp earlier. If the signature of an SC interface file has changed, VCS prints an error message and aborts the compilation. You need to do a full incremental build in this case. This compile flow applies only when the SC source files change. You must use a full incremental build in all other situations; for example: a Verilog source file has changed the signature of an SC interface file has changed SC models instantiate Verilog models, and the set of instances has changed.
This command has to be specified without any other options except the optional -Mdir argument. It sets a sticky flag which applies to the csrc (or mydir) library. If the flag is present, the final link command uses a shared library. For example:
g++ -o simv ... libcsrc_sysc.so ...
The above example specifies to use a shared library for lib1, but object files for lib2.
Now, you can modify B1.cpp and update just the shared library as follows:
edit B1.cpp // modify src code % syscan -Mdir=lib1 -shared // update shared lib % ./simv // run simulation
recompile all files. You can suppress dependency checking and automatic recompilation using the -sysc=nodep option. For example, if you specify:
% vcs ... -sysc=nodep ...
then the dependency checking for all SC libraries is suppressed. If you specify:
% vcs ... -sysc=nodep:lib1,lib3
then dependency checking for lib1 and lib3 is suppressed, but other libraries are still checked.
Restrictions
On Solaris, gmake (Gnu make) must be installed. Old versions of Sun make cannot be used because they do not understand the Makefiles generated by syscan/vcs.
Accessing SystemC Members from SystemVerilog Using the tli_get_<type> or tli_set_<type> Functions on page 131 Generating C++ Struct Definition from SystemVerilog Class Definition on page 142
TLI Adaptor
The SystemVerilog Transaction Level Interface (TLI) is created automatically and represents the SystemC instance inside the SV world. It allows the user to directly access public member variables and member functions of a SystemC instance. The TLI adaptor is created by calling syscan with specific arguments. It has a collection of SV functions to access SystemC member variables and call methods. These arguments and functions are described in the following sections.
The path refers to the mixed SC or HDL module hierarchy. This path can be absolute, or a relative path name. Consistent with Verilog, a relative path name is resolved relative to the SV module, where the TLI function call occurs.
{ public: int sc_int<10> bool ... }; AAA; BBB; CCC(const char* p1);
SystemC ----------------bool sc_logic char short int int long long double float sc_int<n> sc_uint<n> sc_bigint<n> sc_biguint<n> sc_bv<n> sc_lv<n> std::string char* pointers/references
SV -------------------------bit wire (4-state) byte shortint int longint real shortreal bit[n-1:0] bit[n-1:0] bit[n-1:0] bit[n-1:0] bit[n-1:0] wire[n-1:0] (4-state) string string (copy-by-value) chandle
SystemC char* Type Set method for char* type takes optional bool argument which controls whether to free the current SystemC char* memory or not. Example
SV Code ------function void set_CCC(input string ccc, \ input bit free_mem=0); tli_set_CCC(SC_OBJECT_PATH, CD, free_mem); endfunction Plumbing Code ------------void tli_set_CCC(const char* id, const char* ccc, \
bool free_mem=false); { SCObject* p = tli_adaptor.find_sc_object(id); if (free_mem && p->ccc) free(p->ccc); p->ccc = strdup(ccc); }
The default value for free_mem is false. This could mean a potential memory leak. You need to carefully set this value depending on how SC object is constructed. SystemC Channel Types The following templatized SystemC classes C can be accessed if the template type is supported: sc_signal_in_if sc_signal_inout_if
Classes derived from these classes are also supported. For example: sc_signal sc_signal_resolved datatype is sc_logic sc_signal_rv datatype is sc_lv sc_in sc_out sc_inout sc_buffer
Arrays Arrays are supported. Individual elements can be accessed if the type of the element is generally supported. Accessing entire arrays, or sub-arrays (rows, columns) is not supported. Read or write access takes place with SV function get or set. Whereby, the index(es) are specified as 2nd, 3rd,... etc. arguments. Example SystemC instance definition:
SC_MODULE(ABC) { ... int BBB[10]; bool CCC[1024,500]; ... }; Usage of TLI adaptor in SV code: a = sc_inst0.get_BBB(7); // read BBB[7] b = sc_inst0.get_CCC(700,2); // read CCC[700,2] sc_inst0.set_CCC(!b,700,2); // write CCC[700,2]
SC_FIFO
Class sc_fifo can be accessed if the template argument type is supported. The access functions permit non-blocking access, and support queries for the number of free or stored elements. Access to blocking functions read() and write() is not supported. Example Definition of SystemC instance:
SC_MODULE(ABC) ... sc_fifo<int> FFF; ... };
Access in SV code:
int a, num; num = sc_inst0.get_FFF_num_available(); num = sc_inst0.get_FFF_num_free(); a= sc_inst0.get_FFF(); //function, will not block sc_inst0.set_FFF(a); //function, will not block
Non-SystemC Classes
A SystemC module definition is a C++ class derived from sc_module. It is often specified with a macro SC_MODULE. All SystemC modules are C++ classes, but all C++ classes are not SystemC modules. The C++ classes that are not SystemC modules are referred to as non-SC-classes.
Accessing members of non-SC-classes is not supported. The toplevel class has to be an sc_module derived class.
Sub-classes
A class may have a member which itself is a class. Members of such sub-classes can also be accessed (if they are to be imported, see TLI file below). Members of sub-classes, or sub-sub-classes are accessed by SV functions in the TLI adaptor that reflect the C++ scope name. Example Definition of C++ classes:
class C2 { public: int P; int Q; }; struct C1 { int M; C2 N; }; SC_MODULE(ABC) { ... int AAA; C1 SSS; ... };
Usage in SV code:
a = sc_inst0.get_SSS_get_M (); sc_inst0.set_SSS_set_N_set_Q (a+10);
Only the sub-classes instantiated as regular members are supported. The sub-classes that are connected to the main class as pointers or arrays are not accessible. Example Definition of C++ classes:
struct C1 { int M; C2 N; }; SC_MODULE(ABC) { ... C1 SSS; C1* TTT; C1 UUU[4]; ... };
Members of SSS are accessible, but members of TTT and UUU are not accessible.
Name Clashes
Name clashes can take place in these two types of scenarios: var name clashes var name clashes with method names
In this case, access methods for a.b and a_get_b would be get_a_get_b(). To handle this scenario, use the following rules: Keep the original user methods as is. For example, user method foo::get_A() is accessible as foo.get_A() in SV. In case of name clash, find a new name (based on naming sequence) which does not clash. This is the naming sequence used to find new name: get_A() get_A1() get_A2() ... get_A().
var Name Clashes with Method Names Consider the following example:
class foo { int A; int get_A(); //user defined method };
Now, the generated access method get_A() for variable A clashes with the user-defined method get_A(). Note that the name clash in this case is only in the SV domain. The internal plumbing generated names get_A() (to access A) and call_get_A() (to call get_A()) are unique. To handle this case, keep the get_A() method (for calling get_A()) in the SV domain as is. Change the access method to escaped name \:get_A().
Error Handling
Locating SystemC Instance The hierarchical path specified as an actual parameter of the TLI adaptor is checked during the startup of the simulation. An error is reported and the simulation aborts when the path cannot be resolved to a SystemC instance. Out-of-array Accesses Reading or writing an array element depends on valid data for the indexes. Invalid indexes may accidentally go over the allocated area and access unrelated memory addresses. Such an illegal access may trigger a segmentation fault (SEGV) or page zero signal. Currently, there is no protection against such crashes. Write accesses with invalid indexes may corrupt other memory locations, and do not trigger a signal, so they go unnoticed.
Compile Flow
The TLI adaptor is generated automatically by calling syscan as follows:
syscan -tli <tli-file> <cpp-source-file> [-o <tli-file>] [-cmp]... \
The C++ file is parsed, and most of the necessary data is extracted from there. The TLI file has the function to supplement the information; for example, to define for which classes access functions are to be generated.
The generated files are not automatically compiled or analyzed. This step is under the control of the user. You can specify C++ compiler directives such as include paths. For example:
-cflags -I/some/dir/include
4. By default, all members of inner class members (bar.* in example above) are skipped. 5. Precedence rules: - order of lines is not important - For precedence rules we use the following three types of matchsequences: -name (plain name without any *) -name could name.name -match_all (match_all is single * at any level) -examples are *, *.*, *.*.*, .... -select_pattern (name with a * but not match_all) -examples are nam*, *ame, na*e, name.*ame etc. - precedence from lowest to highest -import member * (match_all) -skip member * (match_all) -import member name* (select_pattern) -skip member name* (select_pattern) -import member name -skip member name - rules with higher precedence override rules with lower precedence. For example, skip member * skips all members even if there is an import member * directive.
6. TLI option syntax - syscan -tli src_file - syscan does not support multiple files with the -tli option. Example
syscan command -------------% syscan -tli foo_file.tli foo.cpp output files -----------foo_file.[h|cpp|sv] foo_file.idf (intermediate file) foo.cpp -----class Bar { int a1, a2, b1, b2, c1, c2; } class Foo { int aname1, aname2, bname1, bname2, cname1, cname2; int x1, x2, y1, y2, z1, z2; Bar* bar; } foo_file.tli ---------------adaptor sc_data // (implicit) import * skip *
import *name* skip bname* import bname1 skip cname2 // (implicit) skip bar.* import bar.c* import bar.b1 skip bar.c1 Is the word "member" accidentally missing? E.g. "skip member *" instead of "skip *" ?
Foo.idf -------adaptor Foo direction sv_to_sc verilog_module tli_Foo systemc_module tli_Foo var var var var int int int int aname1 aname2 bname1 cname1
Debug Flow
The TLI implementation uses the existing CBug debug features given below: Display in combined HDL or SC design hierarchy: All access functions are visible on the SV side as functions or tasks of the SV interface.
Underlying DPI functions of the adaptor are visible in the list of DPI, PLI, or DirectC functions. Cross-step from calling SV statement into adaptor code, and from there into the users C function.
Enhancements to TLI for Providing Access to SystemC/ C++ Class Members from SystemVerilog
The TLI adaptor feature restricts the access to a single member of a struct or class. You can specify this member in the TLI file, as member *.*. The TLI adaptor does not provide a way to access nested members of a struct or class. This topic describes the following enhancements made to the TLI adaptor for accessing struct or class members of a SystemC module from SystemVerilog. Accessing Struct or Class Members of a SystemC Module Object from SystemVerilog Accessing Generic C++ Struct or Class
Access to a member of a SystemC module is only possible if a module is instantiated in the design. An instantiation (object) of the SystemC module can be identified with the hierarchical instance path. The actual TLI adaptor code makes use of this. You can access SystemC module objects (and their members) using the instance path. In this scenario, only the access to an entire struct or class member is missing.
get(logic[7:0]ba[]) Gets the entire structure set(logic[7:0]ba[]) Sets the entire structure set_<member_name>('Value') Sets the Value to the member specified by <member_name> get_<member_name>() Gets the current value of the <member_name>
These functions are extensions to the TLI-2 adaptor code generated for scalar member access. For backward compatibility reasons, the old syntax is still supported. The following SystemC code example illustrates the usage of above functions:
struct simple { int A; sc_int<8> B; } simple; .... SC_MODULE(S){ ..... public: simple P; ...... }
The content of the member variable P of struct type simple is supposed to be exchanged with SystemVerilog. SystemVerilog consists of a corresponding simple-struct compliant class. This class does not display the required `defines for VMM byte packing, as shown in the following example:
Example
class simple_SV; int A; bit[7:0] B; endclass:simple_SV ...... // declare a variable of SV class simple_SV simple_SV cl1; // SV byte pack array logic[7:0]ba[]; tli_S sc(); sc.scSetScopeByName("top.sc_inst1"); .... // get an entire struct from SC and fill it into class object //cl1; sc.P.get(ba); cl1.byte_unpack(ba); ..... // fill an entire struct on the SC side with contents of class object cl1 cl1.byte_pack(ba); sc.P.set(ba); ..... // Current individual struct member access cl1.A = sc.get_P_get_A(); sc.set_P_set_A(cl1.A); // new additional individual member access, old syntax still supported cl1.A = sc.P.get_A(); sc.P.set_A(cl1.A); .............
In the above code, the tli_S interface is generated. This interface must be instantiated by referring to a hierarchical path to an instance of sc_module S in the SystemVerilog source code. You can change the hierarchical path using the interface function scSetScopeByName(). A second interface named tli_S_P is generated, and this is instantiated in the tli_S interface as the member name (P) of the struct within a SystemC module. The interface tli_S_P contains the get(logic[7:0]ba[])and set(logic[7:0]ba[]) functions to set and get the entire struct. You cannot check whether the C++ struct or class is compliant with the SystemVerilog class or not. There is no restriction for you to use only VMM byte pack/unpack when passing the packed byte stream as an argument. You can write your own SystemVerilog pack/unpack routines, but these routines must be VMM byte pack/unpack compatible. The set_<member_name>('Value') and get_<member_name> functions are provided for scalar members of the struct. For example, member A of a struct or class can be accessed as set_A(val) and get_A(). There is no change in the compile steps to generate and compile the generated files compared to the adaptor code generation and byte pack or unpack functionality. Generating Adaptor Code The adaptor code is generated using a syscan call and a TLI input file, as shown in the following command:
% syscan -tli <input_file> <SC/C++_file>
where, <input_file> is the TLI input file <SC/C++_file> is the SystemC/C++ file for which you want to create an adaptor
The adaptor code is the content (the specified directives) of a TLI file, which specifies what is generated. You must use the TLI file with the syscan -tli option. If you specify this option with the TLI file, then the byte pack or unpack routines and VMM classes are generated. There is a change in the TLI input file to inform syscan that the code for the functionality, described above, needs to be generated. For more information on the TLI input file extensions, see Extensions of TLI Input File on page 113.
C++ Functions TLI_UNREGISTER_ID() and TLI_REGISTER_ID() TLI_UNREGISTER_ID(char *) Unregisters the structure or class specified by the passed unique identifier. It does not check whether the unique identifier exists or not. TLI_REGISTER_ID(char *, <class_object_pointer>) Registers the passed pointer to a struct or class object under the given unique identifier. This function has two arguments, a string holding the global unique identifier and a pointer to the struct or class object.
Note: VCS generates an error message when: - A null object pointer to be registered is passed - The unique identifier is already in use, and is independent of the pointer type (address) SystemVerilog function attach_by_id() attach_by_id() Stores the unique identifier in the interface instance. There is no check on whether the identifier exists until the first access with the set or get routines. SystemVerilog set or get function The set() or get() functions do not use a caching mechanism. The pointer stored with the unique identifier is checked for each set or get call. Note: VCS generates an error message when: - An identifier is not set in the interface
- An identifier is not registered - A stored address has the wrong type (not the expected one) The following SystemC code example illustrates the usage of the functions mentioned above:
struct simple { int A; sc_int<8> B; } simple; ....
The content of a variable of the struct type simple is supposed to be exchanged with SystemVerilog. The register or unregister function declarations are in the following file provided by VCS:
tli_global_generic_class_info.h
This file must be included in the C++ code to make use of the register or unregister functions, as shown in the following example: Example
// user must include file with registration/unregistration function // declaration #include "tli_global_generic_class_info.h" ..... simple *P; P = new simple(); // registration of P with global unique id TLI_REGISTER_ID("my_unique_id1", P); ..... // unregister P TLI_UNREGISTER_ID("my_unique_id1");
...... On the SV side we have a corresponding and "simple-struct" compliant class, not showing the required `defines for VMM byte packing class simple_SV; int A; bit[7:0] B; endclass:simple_SV ...... class simple_SV; // SV byte pack array logic[7:0]ba[]; tli_simple P(); P.attach_by_id("my_unique_id1"); .... // get an entire struct from SC and fill it into class object cl1; P.get(ba); cl1.byte_unpack(ba); ..... // fill an entire struct on the SC side with contents of class object cl1 cl1.byte_pack(ba); P.set(ba); ..... // individual member access cl1.A = P.get_A(); P.set_A(cl1.A); .............
The tli_simple interface is generated with the generic C++ access functions in SystemVerilog. This is similar to the interface generated for the C++ struct or class member of a SystemC module. The difference is that there is no function named scSetScopeByName(), and the attach_by_id() function is used. The argument is a string representing a global unique identifier.
Using SystemC 19-112
Access in SystemVerilog is similar to the struct or class members of a SystemC module. There is no change in the compile steps to generate and compile the generated files compared to the adaptor code generation and byte pack or unpack functionality. The adaptor code is generated using the syscan call and a TLI input file. For more information on adaptor code generation, see Generating Adaptor Code on page 108.
You can specify the struct or class members for which pack/unpack adaptor code should be generated, using the above directive. In the case of user-provided code, you must specify the function names of pack and unpack routines and the header file using the function declarations. The adaptor code is generated using the create adaptor directive. The import member directive specifies the struct or class members for which the byte pack/unpack adaptor code should be generated. The create VMM and create packunpack directives generate VMM classes and byte pack/unpack routines for the structs or classes specified using the import member directive. In these cases, the generated pack/unpack routines are used in the adaptor code for pack/unpack of struct or class members. The C++ byte pack/unpack functions are void functions, and have two arguments. The prototypes are: For Pack: (tli_pack_data&, const <class_type>&) For Unpack: (tli_pack_data&, <class_type>&)
Limitations
The following are the limitations of accessing struct or class members of a SystemC module from SystemVerilog: The structs in method calls are not supported sc_fifo and tlm_fifo are not supported Nested classes or structs are not supported
Usage Model
You can access the variables of Verilog instances from the SystemC code by calling the tli_get_<type> (path)or tli_set_<type> (val, path) functions, where <type> = logic|int64|uint64|bv|lv|string, path is the absolute path to the variable in a Verilog instance, and val is the value to be set on the variable. The following topic describes the prototypes of these functions.
These functions either get or set the value and return immediately. You can call them either from SystemC methods or from regular C++ functions. Specify the location of the variable in the code using the absolute path. For example, in tli_get_int64 (top.inst0.D), top.inst0 is the absolute path name of a Verilog instance, whereas D refers to the variable D of that instance. All tli_get_<type> or tli_set_<type> APIs are stored in a header file called systemc_user.h. You should include this header file in the SystemC file which uses these APIs. Also, you must enable the VPI read/write capabilities during VCS elaboration using the -debug option. You can mitigate performance impact by using a tab file instead of -debug at compile time to set the correct read/write permission to certain nets (please see Options for PLI Applications).
Access Functions
The following are the prototypes of tli_get_<type> (path)or tli_set_<type> (val, path) functions:
function sc_logic tli_get_logic (const char* path); function void tli_set_logic (sc_logic val, const char* path); function unsigned long long tli_get_uint64 (const char* path); function void tli_set_uint64 (unsigned long long val, const char* path); function long long tli_get_int64 (const char* path); function void tli_set_int64
(long long val, const char* path); function sc_bv_base tli_get_bv (const char* path); function void tli_set_bv (const sc_bv_base& val, const char* path); function sc_lv_base tli_get_lv (const char* path); function void tli_set_lv (const sc_lv_base& val, const char* path); function std::string tli_get_string (const char* path); function void tli_set_string (const char* val, const char* path);
Typedefs to one of the above supported types Sub-members of classes, interfaces, structures, or unions can be accessed only if they are of the above supported types Parameters (read only)
Unsupported Data Types The following data types cannot be accessed with the tli_get_<type> (path)or tli_set_<type> (val, path) functions: Double, float, real, and all other floating point types Any type of SystemVerilog array SystemVerilog event types
Using any TLI API to access a variable of incompatible type results in an error. For example, accessing a string type using tli_get_int64 or accessing a bit vector using tli_get_logic results in an error.
Usage Example
The following example shows how you can use the TLI APIs to access SystemVerilog variables:
Top.v: module bot; reg [3:0] r = 4b1100; endmodule module top; int i1 = 100000; bot b1(); endmodule
sc_bot.h: #include <systemc.h> #include <systemc_user.h> SC_MODULE(sc_bot) { void Func(); } sc_bot.cpp #include sc_bot.h void sc_bot::Func() { sc_bv_base bv = tli_get_bv(top.b1.r); tli_set_bv(bv.reverse(), top.b1.r); long long val = tli_get_int64(top.i1); tli_set_int64(val+1, top.i1); }
If a 4-state value is accessed with a function that accepts only 2-state values (such as tli_get_bv), then all X and Z bits are converted to 0. Also, If the source vector (on SystemC side) passed to a set function (such as tli_set_bv) is smaller than the destination vector (on Verilog side), then the source vector is padded with 0 bits or sign extended (if it is signed type). If the source is larger than the destination vector, the upper bits are removed. The tli_get_bv and tli_get_lv functions preserve bit width; that is, they return a vector whose size is the same as the actual vector on the Verilog side. Example 19-3 Accessing 4-state value with a function that accepts only 2-state values
tli_get_bv("top.S2.A")
In the above example, if top.S2.A refers to a logic vector of size 8, then this function call converts the 4-state value fetched from the Verilog side to 2-state values (by replacing all X and Z with 0), and returns sc_bv_base<8>. If the variable A has the binary value 8b1x1z0x01, then tli_get_bv() converts all X and Z to 0, and returns the value 10100001 in the sc_bv_base variable. Example 19-4 Padding the upper bits
tli_set_lv(val,"top.S2.A")
In the above example, if val is a logic vector of size 8 and top.S2.A refers to a bit vector of size 20, then this function call first converts all X and Z in val to 0, and then pads the upper 12 bits with 0 and assigns it to the referred variable.
If the variable has the binary value 811xxzz11, then the tli_set_lv() function first converts all X and Z to 0, and then adds 12 zeros, so the resulting value is the binary value 20b00000011000011 or integer value 12. Example 19-5 Accessing signed variables
tli_get_bv("top.S2.B")
In the above example, top.S2.B refers to an 8-bit signed register (reg signed [7:0] B). It has the binary value 8b11111110, which corresponds to hex value 32hfe or decimal value -2. The above example returns sc_bv<8>, which holds the value 8b11111110. The assumption here is that you know the signedness of the referred variable when you call tli_get_bv and convert the retrieved value appropriately. Instead, you can use tli_get_int64 to access signed values less than 64-bit. The tli_get_logic and tli_set_logic functions operate on single-bit variables only. If you pass a vector value to tli_set_logic or try to access a vector value using tli_get_logic, then it results in an error. You can access SystemVerilog string type variables using the tli_get_string and tli_set_string functions only.
Usage Model on page 122 Function Declaration Hierarchy on page 123 Passing Arguments on page 125 Supported Types on page 126 Usage Example on page 126 Compile Flow on page 128 Usage Guidelines on page 129 Limitations on page 130
Introduction
The existing idf file-based mechanism allows you to access variables or function calls on the Verilog side from SystemC class methods. But this mechanism expects you to write an idf file, instantiate the corresponding interfaces in SystemC source files, and access variables or functions using the interface objects. From this release onwards, you can use the TLI-DirectAccess (TLIDA) mechanism to directly access SystemVerilog functions and tasks from SystemC code. This mechanism allows you to easily interact across language boundaries.
Usage Model
Use the following syntax to directly access SystemVerilog functions or tasks from SystemC code:
TLI::<Function declaration hierarchy>::<Function_name> (<design_hierarchy>, <comma separate list of actual arguments>); Following is an example of a TLI function call:
TLI::Mid::Add(top.m1, arg1, arg2);
You must call a function with the design hierarchy string (xmr) as the first argument, followed by the list of actual arguments. Note: The design hierarchy specified in the call should be a string literal (for example, top.m1). You cannot use a variable of type string or char*. You must prefix the function call with the function declaration hierarchy. This hierarchy is the scope where a function is declared in the SystemVerilog design. For more information, see the Function Declaration Hierarchysection. You must include the generated TLI header file tli_sc_calls_sv.h in SystemC files which access the TLI function calls.
Locate the function in a SystemVerilog design and extract its prototype. This prototype is required to automatically generate the corresponding DPI wrappers. Avoid conflicts with other function calls having the same name, but declared in different scopes.
Note: - If there are any conflicts, then the module_name or package_name is the only mandatory item. - Use library_name if a module with the same name exists in a different library, and that module also has a function with same name. - Use class_name, interface_name or named_block_name if a function with the same name is present in two different scopes in the same module. - You must separate all the above-mentioned strings with a scope resolution operator (::).
Passing Arguments
The type of actual arguments passed to the TLI functions should match the corresponding SystemVerilog type used in the function declaration. Following is the list of compatible types: Table 19-1
bit logic reg reg vector logic vector bit vector int shortint longint byte
Compatible Types
SystemC Data Type bool sc_logic sc_logic sc_lv sc_lv sc_bv int short int long int char
Note: - The SystemC compiler generates an error if the sizes of the vectors passed as actual arguments do not match the sizes of the formal parameters. - Use plain types for input arguments and pointers for output or inout arguments. You must allocate enough space for these pointers. Also, use pointers to collect the return values from these function calls.
- Functions can have reference arguments which are treated as inout types on the SystemC side.The SystemVerilog ref semantics are not maintained on the SystemC side. That is, any change to the ref variable in the function or task is not immediately visible on the SystemC side.
Supported Types
The following types are supported: You can call functions having arguments of basic data types from SystemC code. Supported argument types include: all integral types, reg, logic, bit, string, and so on. Bit vectors of basic types are allowed in the argument list. In Verilog- -top designs, the design hierarchy should only consist of Verilog instances. In SystemC top designs, the design hierarchy should start in SystemC and end in Verilog. Donuts are not allowed.
Usage Example
class C; //In $unit scope function int Add( bit [3:0] r1, reg [3:0] r2, output logic [3:0] r3); endfunction endclass module Mid; class C; function int Add( bit [3:0] r1, reg [3:0] r2, output logic [3:0] r3); endfunction function int Sub( bit [3:0] r1, reg [3:0] r2, output logic
[3:0] r3); endfunction endclass; C c1 = new; function int Add( bit [3:0] r1, reg [3:0] r2, , output logic [3:0] r3); endfunction endmodule package P; class C; function int Sub( bit [3:0] r1, reg [3:0] r2, output logic [3:0] r3); endfunction endclass endpackage module top; Mid m1(); C c1 = new; P::C c2 = new; endmodule File: sc_top.cpp #include <tli_sc_calls_sv.h> Sc_bv<4> arg1; Sc_lv<4> arg2; Sc_lv<4>* arg3 = new sc_lv<4>; int* I1 = TLI::Mid::Add(top.m1, arg1, arg2, arg3); int* I2 = TLI::Mid::C::Add(top.m1.c1, arg1, arg2, arg3); int* I3 = TLI::Mid::Sub(top.c1, arg1, arg2, arg3); int* I4 = TLI::$unit::C::Add(top.c1, arg1, arg2, arg3); int* I5 = TLI::P::Sub(top.c2, arg1, arg2, arg3);
In the above example: The int* i = TLI::Mid::Add(top.m1, arg1, arg2, arg3); function call is equivalent to XMR function call top.m1.Add(arg1, arg2). This function call refers to the function Add in module Mid. The int* i = TLI::Mid::C::Add(top.m1.c1, arg1, arg2, arg3); function call is equivalent to XMR function call top.m1.c1.Add(arg1, arg2). This function call refers to the function Add in class C of module Mid. Here, you must mention the class name along with the module name because the module has another function with same name. The int* i = TLI::Mid::Sub(top.m1.c1, arg1, arg2); function call refers to the function Sub in class C of module Mid. Since the function name is unique in the given module scope, there is no need for you to prefix the function call with the class name. However, you can use the class name to call this function, as follows:
res3 = TLI::Mid::C::Sub(top.m1.c1, arg1, arg2);
The int* i = TLI::$unit::C::Add(top.c1, arg1, arg2); function call calls the function Add in class C. This class resides in $unit scope, which is outside of all modules. The int* i = TLI::P::Sub(top.c2, arg1, arg2); function call refers to the function Sub in package P.
Compile Flow
Follow these steps to enable direct function access using TLI: 1. Compile Verilog files using vlogan :
2. Run syscan using the -tli_F option, and then pass all the SystemC files to it (especially the files having TLI function calls). Also, pass all the required include directories using -cflags.
% syscan tli_F sc_top.cpp
Note: This is an extra step required to automatically generate the TLI adaptor code. 3. Compile all SystemC files:
% syscan sc_top.cpp:sc_top
Usage Guidelines
The following are the guidelines for accessing SystemVerilog functions or tasks from SystemC: You must compile all Verilog files before SystemC compilation (with syscan tli_F). You must analyze the SystemC source files having TLI function calls with the syscan -tli_F command before they are compiled with syscan. You should specify all files that contain TLI function calls together to the syscan tli_F command. You may observe some slowdown if this command is run on each file separately.
If there are any changes to the TLI function calls in any of the source files, then you must process the files with the syscan tli_F command before compiling them with syscan. You must include the tli_sc_calls_sv.h file in all source files that access TLI function calls. The widths of the formal arguments should match the widths of actual arguments. Also, the types of arguments should be compatible as per SystemC semantics. For example, you cannot pass a sc_bv vector to a function that expects a logic vector. You must specify appropriate declaration hierarchy to handle conflicting function calls.
Limitations
The following limitations apply when accessing SystemVerilog functions or tasks from SystemC: Compound data types (arrays, structures, classes, and so on), enums, and typedefs are not allowed in function arguments. Floating point types are not allowed as function arguments. Functions declared in nested modules cannot be called from SystemC. Donuts (design hierarchies like Verilog-SC-Verilog) are not supported. The TLI function call and its first argument should be on the same line. That is, the function name and its first argument should not spread over multiple lines.
Accessing SystemC Members from SystemVerilog Using the tli_get_<type> or tli_set_<type> Functions
This section describes how to access the members of SystemC instances from SystemVerilog code by calling the tli_get_<type> or tli_set_<type> functions. This section consists of the following topics: Using the tli_get_<type> and tli_set_<type> Functions on page 131 Prototypes of tli_get_<type> and tli_set_<type> Functions on page 132 Supported Data Types on page 133 Member Variables on page 136 Type Conversion Mechanism on page 138 Compile Flow on page 140
path is the absolute path to the member of a SystemC module instance. For example, top.S2.D refers to member D of SystemC instance top.S2. Only absolute path names are supported. Relative paths are not supported. val is the value to be set on the member variable. member_name is optional. It is the name of the member variable in a SystemC object. If this argument is not specified, then the first argument is considered as the full path of the variable. For more information on this argument, see the Member Variables topic.
The tli_get_<type> and tli_set_<type> functions either get or set the value and return immediately.
function longint tli_get_int64 (input string path, input string m_name = ""); function void tli_set_int64 (input longint val, input string path, input string m_name = ""); function logic[63:0] tli_get_logic64 (input string path, input string m_name = ""); function void tli_set_logic64 (input logic[63:0] val, input string path, input string m_name = ""); function string tli_get_string (input string path, input string m_name = ""); function void tli_set_string (input string val, input string path, input string m_name="", input bit free_mem=0);
These functions can access only the: Objects of a SystemC module, which are derived from sc_core::sc_module. Member variables that are public. You cannot access private and protected members.
Note: You can view all SystemC module instances in the static design hierarchy shown by DVE.
The tli_get_<type> (path [, member_name])or tli_set_<type> (val, path [, member_name]) functions can access the following data types: bool, sc_logic All ANSI integer types. For example, int, signed char, long int, unsigned short int, and so on Native SystemC bit-vectors with a length of no more than 64-bit: sc_int, sc_uint, sc_bigint, sc_biguint, sc_lv, sc_bv Signals and ports: sc_signal<T>, sc_signal_rv, sc_signal_resolved, sc_in<T>, sc_inout<T>, sc_out<T>, sc_inout_rv, sc_inout_resolved Strings of type std::string or char* Sub-members that have one of the above types
Note: - The bool and sc_logic data types are single-bit entities. They can only be accessed using the tli_get_logic and tli_set_logic functions. Z and X are preserved while accessing the sc_logic variable. Using any other tli_get_<type> or tli_set_<type> function for these types results in an error. - The std::string and char* data types can only be accessed through the tli_get_string and tli_set_string functions. Using any other TLI function results in an error.
- The tli_set_string function has a fourth argument free_mem, which applies only if the SystemC variable is of type char*. If the type is free_mem=1, then the TLI does a free()of the current string value before assigning the new value.You must ensure that the value is freed. Sub-members The tli_get_<type> (path [, member_name])or tli_set_<type> (val, path [, member_name]) functions can access the members of sub-classes or sub-structs, if these members contain supported type as int. This corresponds to an import member *.* directive within a TLI file. Example:
struct my_struct2 { int D; }; struct my_struct1 { int C; my_struct2 S2; }; SC_MODULE(foo) { sc_int<40> A; my_struct1 S1; };
In the above example, members A and S1.C of foo are accessible, and are of type int. Members S1 and S1.S2 are not accessible because they refer to entire user-defined structs. Member S1.S2.D is also of type int, but is not accessible if the corresponding source file is compiled with the tli_D flag. This flag makes the first-level (A) and second-level (S1.C) members accessible, but not the third-level (S1.S2.D) or any further levels.
Member S1.S2.D is accessible if the corresponding source file is compiled with an explicit TLI file which specifies to import this thirdlevel member. Unsupported Data Types The tli_get_<type> and tli_set_<type> functions cannot access the following data types: Base types of native SystemC bit-vectors: sc_int_base, sc_uint_base, sc_signed, sc_unsigned, sc_lv_base, and sc_bv_base. Resolved input and output ports: sc_in_rv, sc_out_rv, sc_in_resolved, and sc_out_resolved. Other SystemC channel types. For example, sc_fifo, sc_buffer. Arrays of fixed or varying size. For example, int[8], int[]. Double, float, and all native SystemC fix-point types. For example, sc_fix.
Using any TLI API to access a variable of incompatible type results in an error. For example, accessing string types using tli_get_int64 or accessing a bit vector using tli_get_logic results in an error.
Member Variables
The member_name argument is optional. SystemC instance names have their own name space. They do not clash with other member variables defined in the same class. If sub-members are also
supported, then you might face difficulties in differentiating between member variables. You can overcome these difficulties by using the member_name argument. For example, consider the following code:
struct mystruct { int B; }; SC_MODULE(sub) { // instance top.inst.A int B; }; SC_MODULE(foo) { // instance top.inst sub inst_A; my_struct A; SC_CTOR(foo): inst_A(A) {} };
In the above code, member inst_A forms sub-instance top.inst.A. The constructor (SC_CTOR) defines the hierarchical name of C++ member inst_A to be A. Member inst_A does not clash with member A within class foo, at least for the C++ compiler. However, it constitutes a clash for the hierarchy, such that the path top.inst.A.B can now refer to: Member B of instance top.inst.A Member A.B of instance top.inst
Using any API with the path top.inst.A.B creates ambiguity. This ambiguity is resolved by the optional argument member_name. Example
tli_get_int("top.inst.A.B") // ambiguous situation tli_get_int("top.inst.A", "B") // member B of // instance top.inst.A
tli_set_int(value, "top.inst.A.B")) // member A.B of //instance top.inst tli_set_int(value, "top.inst.A", "B")// member B of //instance top.inst.A tli_get_int("top.inst", "A.B") tli_set_int(value, "top.inst", "A.B")// member A.B of //instance top.inst
Example 19-6
If the above function refers to sc_lv<8> (a vector of 8 bits of four values each), it converts the 4-state value to 2-state values (by replacing all X and Z with 0) and the missing 24 bits are filled with zeros. If the variable A has the binary value 8bxxzz1100, then tli_get_in64() first converts all X and Z to 0 and then adds 24 zeros, so that the resulting value is the binary value 64b0000001100 or integer value 12. Example 19-7 Function returning signed values
If top.S2.B refers to sc_int<8>(signed data type with binary value 8b11111110, which corresponds to hex value 32hfe or decimal value -2), then: tli_get_int64(top.S2.B) returns integer value -2 or hex value 64hffff ffff ffff fffe. tli_get_uint64(top.S2.B) returns the same hex value 64hffff ffff ffff fffe, which corresponds to a very large positive number (18446744073709551490) because tli_get_uint64() always returns an unsigned number. tli_get_logic64(top.S2.B) returns hex value 64h0000 0000 0000 00fe.
Example 19-8
If the variable has the binary value 8b11xxzz11, then tli_set_logic64() first converts all X and Z to 0, and then adds 12 zeros. Therefore, the resulting value is the binary value 20b00000011000011 or integer value 195.
Compile Flow
Access for tli_get_<type> or tli_set_<type> must be enabled during compilation of SystemC source files with syscan. Using tli_D Option Use the -tli_D option along with syscan, as shown below:
% syscan -tli_D <source file>
Access is enabled for all SystemC module classes that are present during compilation of the source file. If this option is used for compiling the top-most model of an entire SystemC design tree, then all SystemC modules are supported. Example
File bottom.h: SC_MODULE(bottom) {}; File middle.h: #include bottom.h SC_MODULE(middle) { bottom inst; }; File top.h: #include middle.h SC_MODULE(top) { middle inst; } File top.cpp: #include top.h
Calling syscan tli_D top.cpp enables tli_get_<type> or tli_set_<type> access for any instance of SystemC module types top, middle, or bottom. Using the tli_D option is convenient; however, it may also be expensive in terms of extra compilation time because there is no limit to the number of SystemC modules for which tli_get_<type> or tli_set_<type> support is built. Therefore, a warning message is generated when the total number of variables from all SystemC modules exceeds 2000. Modifying SystemC Code The information needed for tli_get_<type> or tli_set_<type> is stored in the tli_<source_body_file_name>_DirectAccessM.cpp file, which is automatically generated. It must be included at the end of the cpp file from which it was generated. Example
File top.cpp: #include top.h at the end of the file add: #include tli_top_DirectAccessM.cpp
Modifying SystemVerilog Code You must analyze and import the TLI package where all tli_get_<type> or tli_set_<type> functions are defined. Example Analyze the package:
TLI Directive (create directaccess) The tli_D option only creates information needed for the tli_get_<type> or tli_set_<type> functions. For example, it does not create any helper code to call member functions. If this is needed, then you must call syscan with an explicit TLI file.
where, -v is the verbose switch. The generated C++ struct is also printed to stdout. <file_name> is the SystemVerilog input file. -class <class_name> specifies the SystemVerilog class, for which a corresponding C++ struct is generated. -o <output_header_file> is an optional argument. If specified, the C++ struct is created in this file.
As shown in the above command example, the struct generator requires a SystemVerilog file and the class name, for which the corresponding C++ struct should be created, as inputs. Therefore, a SystemVerilog class is required in the specified SystemVerilog file. The SystemVerilog file is read for all data members in the class, and the corresponding C++ data types are generated in a struct. The name of the C++ struct is tli_struct_<class_name>. If you do not specify an output file, then the file name is tli_struct_<class_name>.h; else it is same as the name specified with the -o option.
A comment is printed in the preceding line of each C++ struct data member. This comment contains information about the SystemVerilog input file, line number, and the complete line of the corresponding SystemVerilog class data member.
Table 19-2
SystemVerilog Data Type shortint signed int int[] int[size1] int unsigned int signed longint longint[] longint[size1] longint unsigned longint signed bit[nr-1:0] logic[nr-1:0] integer
The following call generates a C++ struct named tli_struct_my_payload in the tli_struct_my_payload.h file:
Using SystemC 19-145
Limitations
The following are the limitations of creating a C++ struct from a SystemVerilog class: The syscan -tli_gen_struct option cannot recognize legal SystemVerilog class definitions. For example, the following types are not supported: - User-defined structs - Enums - Multidimensional arrays
Note: Data members that could not be converted are created in a comment. By default, the data type is void, and appears as shown below: // TODO: void <variable_name>; The typedef, function, and task constructs cannot be converted to any C++ construct. The syscan script ignores these constructs if they are specified in the SystemVerilog class definition. Splitting data member definitions over multiple lines is not supported. Preprocessor directives are not supported.
This chapter contains the following sections: Use Model Supported Data Types Mapping of SystemC/C++ and SystemVerilog/VMM Data Types Usage Examples Using Pack and Unpack Functions Using Code Generator
Use Model
To pack and unpack the data type values using the APIs in SystemC/ C++: 1. Include the tli_packunpack.h header file. 2. Create a class object tli_pack_data which contains the API to provide the pack and unpack functionality. 3. Use the pack operator ( << ) or the pack() function to put data into the byte array. This operator converts data into a byte stream. Similarly, use the unpack operator ( >> ) or unpack() function to extract data from the byte array. This operator converts the data of the byte stream into the type coming along with the variable declaration. Note: The class tli_pack_data provides pack and unpack functionality using: - The << and >> operators for basic data types.
- The pack() and unpack() functions for 1-dim arrays (fixed size and dynamic) of the supported basic data types.
sc_ufixed, sc_ufix sc_bit Struct or Classes: These types cannot be supported by the API. The pack or unpack routines must be written with the knowledge of a single member. Unions Pointer
SystemVerilog Type logic[nr:0][] logic[nr:0][size] reg reg[] reg[size] reg[nr:0] reg[nr:0][] reg[nr:0][size] byte byte[] byte[size] shortint shortint[] shortint[size] int int[] int[size] longint longint[] longint[size] integer integer[] integer[size] sc_lv<nr+1>*
SystemC/C++ Type sc_lv<nr+1>[size], std::vector<sc_lv<nr+1> >[size] sc_logic sc_logic* sc_logic[size], std::vector<sc_logic>[size] sc_lv<nr+1> sc_lv<nr+1>* sc_lv<nr+1>[size], std::vector<sc_lv<nr+1> >[size] signed char signed char* signed char[size], std::vector<char>(of size) short short short[size], std::vector<short>(of size) int int* int[size], std::vector<int>(of size) long long long long long long[size], std::vector<long long>(of size) sc_lv<32> sc_lv<32>* sc_lv<32>[size], std::vector<sc_lv<32> >(of size)
Unsigned Versions
byte unsigned shortint unsigned int unsigned long int unsigned unsigned char unsigned short unsigned int unsigned long long
SystemC/C++ Type
Signed Versions
bit signed bit signed[nr:0][size] reg signed reg signed[nr:0[size] logic signed logic signed[nr:0][size] bool, sc_bit (deprecated) sc_bv<nr+1>[size] sc_logic sc_lv<nr+1>[size], std::vector<sc_lv<nr+1> >[size] sc_logic sc_lv<nr+1>[size], std::vector<sc_lv<nr+1> >[size]
The following table lists the data types to map from SystemC/C++ to SystemVerilog/VMM:
SystemC/C++ Type bool bool* bool[size] char char[size] char* char** char*[size] std::string std::string* std::string[size] short short* short[size] int bit bit[] bit[size] byte, bit[7:0] byte[size], bit[7:0][size] string string[] string[size] string string[] string[size] shortint shortint[] shortint[size] int SystemVerilog Type
SystemC/C++ Type int* int[size] long long* long[size] long long long long* long long[size] sc_int<nr> sc_int<nr>* sc_int<nr>[size] sc_bigint<nr> sc_bigint<nr>* sc_bigint<nr>[size] sc_bit sc_bit* sc_bit[size] sc_logic sc_logic* sc_logic[size] sc_bv<nr> sc_bv<nr>* sc_bv<nr>[size] sc_lv<nr> sc_lv<nr>* sc_lv<nr>[size] int[] int[size] longint longint[]
SystemVerilog Type
longint[size] longint longint[] longint[size] bit[nr-1:0] bit[nr-1:0][] bit[nr-1:0[size] bit[nr-1:0] bit[nr-1][] bit[nr-1][size] bit bit[] bit[size] logic, reg logic[], reg[] logic[size], reg[size] bit[nr-1:0] bit[nr-1:0][] bit[nr-1:0][size] logic[nr-1:0], reg[nr-1:0] logic[nr-1:0][], reg[nr-1:0][] logic[nr-1:0][size], reg[nr-1][size]
Unsigned Versions
unsigned char byte unsigned, bit[7:0]
SystemC/C++ Type unsigned char* unsigned char[size] unsigned short unsigned int unsigned long unsigned long long sc_uint<nr> sc_biguint<nr>
SystemVerilog Type byte unsigned[], bit[7:0] byte unsigned[size], bit{7:0][size] shortint unsigned int unsigned longint unsigned longint unsigned bit[nr-1:0] bit[nr-1:0]
Signed Versions
signed char signed char* signed char[size] byte, bit signed[7:0] byte[], bit signed[7:0][] byte[size], bit signed[7:0]size
Note: Byte-packing cannot perform type checking between the byte pack/unpack routines from VMM on one side and the corresponding pack/unpack routines on the SystemC/C++ side. Once data is packed into bytes and sent across, then only the actual values of data members exist without any information about the structure. The function that unpacks the data must match exactly to the one that packed it. If both do not match, then an invalid object results after unpacking. It is not possible to automatically detect this, no error message is printed.
Usage Examples
This section provides examples to use the pack and unpack operators and functions.
// variable declaration for variables supposed to be packed int my_int = 42; std::string my_str = "This is a string"; sc_bv<9> my_sc_bv = 127; // Object of class tli_pack_data tli_pack_data pack_ba; // The pack can be done for these 3 variables in one // statement or in multiple pack-stmts. // First possibility, pack is done in one stmt pack_ba << my_int << my_string << my_sc_bv; // Second possibility, pack is done with 3 stmts pack_ba << my_int; pack_ba << my_string; pack_ba << my_sc_bv;
// First possibility, unpack is done in one stmt pack_ba >> my_int >> my_string >> my_sc_bv; // Second possibility, unpack is done with 3 stmts pack_ba >> my_int; pack_ba >> my_string; pack_ba >> my_sc_bv;
Single pack() function to be used for 1-dim arrays (fixed and/or dynamic). Following is the syntax:
template <class T> tli_pack_data& pack(const T& val, unsigned int nrOfElems= 0)
Two unpack() functions (one for fixed size arrays and one for dynamic arrays (pointers)), as shown below:
template <class T> tli_pack_data& unpackArray(T& val, bool isCharArray=false) template <class T> tli_pack_data& unpackDynArray(T& val, bool isCharArray=false)
Note: The pack()and unpack()functions support only arrays of string types. They do not support const char*, char*, or std::string. Arrays (fixed or dynamic) are packed using the pack()function. In case of a dynamic array, you should provide the number of array elements as second argument to this function. If the number of array elements to be packed is given in the pack routine for a fixed size array, then only the first given number elements of the array are packed. For unpacking an array with fixed size, you must use the unpackArray() function. You can use the unpackDynArray() function for unpacking an array with dynamic size (pointer), if the array is not allocated. This method allocates appropriate memory, even if you have allocated memory before calling the unpackDynArray() function.
Use the unpackArray()function for unpacking an array with dynamic size, if the array is allocated before calling an unpack routine. The unpackDynArray()function always allocates memory. The following example with arrays of type int illustrates this scenario: Example 19-11 Using Pack and Unpack Functions
// variable decl. and init. used for pack int my_arr[3] = {2,3,4}; int* my_ptr = new int[3]; my_ptr[0] = 6; my_ptr[1] = 7; my_ptr[2] = 8; // int int* int* variable decl. used for unpack my_t_arr[3]; my_t_ptr_null = 0; my_t_ptr_all = new int[3];
tli_pack_data pack_ba; // PACK the different int variables pack_ba.pack(my_arr); pack_ba.pack(my_ptr, 3); pack_ba.pack(my_arr); pack_ba.pack(my_ptr, 3); // UNPACK // to unpack into "int[3]" the following method has // to be used pack_ba.unpackArray(my_t_arr); // to unpack into "the NULL-pointer of int*" the following // method has to be used. pack_ba.unpackDynArray(my_t_ptr_null); // to unpack into "allocated int* pointer" the method // "unpackArray" should be used pack_ba.unpackArray(my_t_ptr_all); // Calling "unpackDynArray" will allocate new memory, // and the address of my_t_ptr_all will not be the same // after the call of unpackDynArray. pack_ba.unpackDynArray(my_t_ptr_all);
Naming Convention
The following naming conventions are used for the following sections of this chapter:
Table 0-1. Naming Conventions Name C side SV side Class Complex Data types Description Refers to C domain which can be C, C++, or SystemC application. Refers to the SystemVerilog, whereby the application is expected to use VMM. Refers to a user-defined C++ class or C struct on the C side. On the SV side, it refers to a SV class. Complex data types are the types which require additional arguments in the pack/unpack routines. For example, enum, length of a dynamic array. These types are not supported in the provided pack/unpack routines, such as structs and multi dimensional arrays. These data types require manual corrections or modifications in the generated code. Simple data types are the non-pointer built-in data types, such as, std::string, std::vector and fixed-size arrays.
Input Files
The code generator requires the following two input files to create source code automatically: TLI file C source file containing the struct or class
TLI File The TLI file defines the name of the class. It provides instructions to generate the corresponding SV/VMM class and the pack or unpack routines. This TLI file is used to create adaptor code. The adaptor
code for the specified module or class is generated using the keyword adaptor followed by class_name. The syntax is as follows: adaptor <class_name> You can modify or extend the above syntax as follows: The class name is specified with the class keyword The target, for which code is created, is specified with the keyword create. Target can be one of the following: - adaptor - VMM - packunpack The adaptor code generation is invoked with create adaptor statement after the class_name is specified with class class_name. Following is an example for creating adaptor code:
class <class_name> create adaptor
The VMM class and the vmm_data_member defines are created for the members found in the class specified with the class keyword using create VMM. The pack and unpack functions for the members of the class specified with the class keyword are created
using create packunpack.Therefore, VMM class and pack and unpack code generation is invoked if the TLI file contains the following commands:
class <class_name> create VMM create packunpack
Note: Only the parts of code which are specified with the create keyword are generated. For example, for the following TLI file, only the VMM class is created:
class <class_name> create VMM
C source file containing the struct or class The provided C, C++, or SystemC source file contains the class definition.
Output Files
Generated SV class The SV VMM class declaration together with vmm_data_member defines are created in the tli_vmm_class_name file. This file contains: VMM class member declaration VMM vmm_data_member defines
This generated file should be included in the SV file which will pack or unpack the class members.
Generated C files Two files are generated for the C pack or unpack functions: A header file with pack or unpack function definition and another with the function bodies. The following are the names of these two functions: tli_conv2_pack_class_name tli_conv2_unpack_class_name The following are the signatures of these two functions: - The first argument is an object of tli_pack_data. - The second argument is the class (with the members to be packed or unpacked). The following are the names of the generated files: tli_packunpack_class_name.h tli_packunpack_class_name.cpp The generated header file should be included in the file in which the conversion (pack/unpack) happens.
sc_logic sc_bv, sc_lv Array types: std::vector of types listed above and 1-dim fixed-size arrays of types listed above
Note: - The const char* data type is not supported. You cannot unpack a variable of this data type into the same data type. - Pointer of C scalar types are seen as dynamic arrays, and mapped to SV open array data types. The byte packing on the C side requires the size of the dynamic arrays. The size cannot be automatically detected, so the code generated is put into comment. C data types, which are not based directly on scalar types, are mapped to a chandle data type. A chandle cannot be packed/unpacked by VMM, so this code is generated in comment.
Compile Flow
Perform the following steps to compile: 1. Generate the VMM class and the C pack/unpack routines. This step does not compile the C sources. The following syscan command generates the VMM-class declaration (with the vmm_data_member defines) and the pack and unpack functions. syscan -tli tli_input_file class_header.h Where, tli_input_file specifies the class_name (followed by the class keyword) and whether the VMM and/or class pack/ unpack functions have to be created (create keyword). The file class_header.h contains the class definition of the class to be packed or unpacked. 2. Compile the generated pack and unpack functions and the source file containing the class to be packed or unpacked, after manually correcting the generated files (SV and C) which contains complex data types. This is done with the following syscan call: syscan -tlm2 class_source.cpp tli_packunpack_class_name.cpp 3. Generate interface for the class which will pack or unpack the class. Include the include statement of the generated header file tli_packunpack_class_name.h in the test_class.h file, as shown below: syscan -tlm2 -debug_all test_class.cpp:test_class_name Other syscan calls for files required for building and running the simulation.
4. Create an executable with the vcs command line by passing .sv files (test.sv and tli_packunpack.sv). vcs -sverilog -sysc -debug_all -ntb_opts rvm timescale=1ns/1ps ${VCS_HOME}/etc/systemc/tlm/ tli/tli_packunpack.sv test.sv -o simv1
Code Generation The struct contains a dynamic array, data. You must manually modify the generated code, if you want to pack this struct member. Invoke the code generator with the syscan command:
Using SystemC 19-166
syscan -tli memaccess.tli memaccess.h The following files are generated: VMM-SV file: tli_vmm_MemAccess.sv C files: tli_packunpack_MemAccess.h, tli_packunpack_MemAccess.cpp
The following is the generated C source file, tli_packunpack_MemAccess.cpp, with the two function bodies:
#include "tli_packunpack.h" #include "memaccess.h" // pack/unpack routines for public members of class MemAccess void tli_conv2_pack_MemAccess(tli_pack_data& P, const MemAccess& MemAccess_obj) { P << MemAccess_obj.adr; P << MemAccess_obj.RW; // TODO: handled as dynamic array, length is missing // TODO: P.pack(MemAccess_obj.data, data_length()); P << MemAccess_obj.len; } void tli_conv2_unpack_MemAccess(tli_pack_data& P, MemAccess& MemAccess_obj) { P >> MemAccess_obj.adr; P >> MemAccess_obj.RW; // TODO: handled as dynamic array, corresponding pack routine must be fixed before // TODO: P.unpackDynArray(MemAccess_obj.data, true); P >> MemAccess_obj.len; }
Manual Modifications The input struct contains a member with a complex data type, so the generated code must be modified manually. The member data is a dynamic array, therefore the assumption of the code generator is correct.
The generated code for this data member contains to be uncommented in the VMM class declaration and in the C pack and unpack functions. The second argument of the byte pack call of complex data must get the correct variable name containing the size of the data. After manual corrections, the tli_vmm_MemAccess.sv file appears, as shown below:
// VMM class for C++ class MemAccess `include "vmm.sv" class MemAccess extends vmm_data; int unsigned adr; bit RW; byte unsigned data[]; int len; `vmm_data_member_begin(MemAccess) `vmm_data_member_scalar(adr, DO_ALL) `vmm_data_member_scalar(RW, DO_ALL) `vmm_data_member_scalar_da(data, DO_ALL) `vmm_data_member_scalar(len, DO_ALL) `vmm_data_member_end(MemAccess) endclass:MemAccess
MemAccess& MemAccess_obj) { P << MemAccess_obj.adr; P << MemAccess_obj.RW; P.pack(MemAccess_obj.data, MemAccess_obj.len); P << MemAccess_obj.len; } void tli_conv2_unpack_MemAccess(tli_pack_data& P, MemAccess& MemAccess_obj) { P >> MemAccess_obj.adr; P >> MemAccess_obj.RW; P.unpackDynArray(MemAccess_obj.data, true); P >> MemAccess_obj.len; }
You must compile the generated and corrected C file tli_packunpack_MemAccess.cpp, using the syscan command: syscan -tlm2 tli_packunpack_MemAccess.cpp SystemC Module Using Byte Packing The SystemC module, which is instantiated, requires two byte pack includes, tli_packunpack.h and tli_packunpack_MemAccess.h.
SC_MODULE(BusModel) { sc_in<bool> clock; SC_CTOR(BusModel) : clock("clock") { m_mem = new unsigned char[m_size]; for (int n=0; n<m_size; n++) m_mem[n] = n % 100; SC_THREAD(do_transactions); sensitive_pos << clock; } void do_transactions(); private: static const int m_size; unsigned char* m_mem; }; #endif
The BusModel method do_transaction calls for byte packing the function tli_conv2_pack_MemAccess( pba, trans) and for unpacking tli_conv2_unpack_MemAccess( pba, trans),
where pba is a tli_pack_data object and trans is a MemAccess instantiation. With the tli_pack_data upload and download functions, the byte buffer is loaded or sent from or to SV.
#include <BusModel.h> void BusModel::do_transactions() { tli_pack_data pba; MemAccess trans; while(1) { // get next transaction wait(); wait(5,SC_NS); pba.download(0); tli_conv2_unpack_MemAccess(pba, trans); // execute transaction for (int n=0; (n<trans.len) && ((trans.adr+n)<m_size); n++) { if (trans.RW) { trans.data[n] = m_mem[trans.adr + n]; } else { m_mem[trans.adr + n] = trans.data[n]; } } wait(10,SC_NS); pba.reset(); tli_conv2_pack_MemAccess(pba, trans); pba.upload(0); } } const int BusModel::m_size = 1000;
With the following syscan command, the interface file is generated and the BusModel source code is compiled. syscan -tlm2 -debug_all BusModel.cpp:BusModel
Using SystemC 19-172
The provided SV package with the tli_upload and tli_download tasks is analyzed with the following command: vlogan -sverilog ${VCS_HOME}/etc/systemc/tlm/tli/ tli_packunpack.sv Verilog Module Using Byte Packing The Verilog module top is in file top.v, and it includes the generated VMM file tli_vmm_MemAccess.sv. It imports the tli_packunpack package using the tli_upload and tli_download tasks. The Verilog module top instantiates the SystemC module BusModel, and data exchange happens with byte packing/unpacking of MemAccess class.
`include "tli_vmm_MemAccess.sv" import tli_packunpack::*; module top; reg clock; BusModel ref_model(clock); MemAccess trans; pB bytes; chandle ID; int n; initial clock=0; always #50 clock=!clock; initial begin ID = null; trans = new; @(posedge clock); trans.adr = 98; trans.RW = 1'b1; trans.len = 5; trans.data = new[trans.len]; trans.byte_pack( bytes ); tli_upload( bytes, ID ); #20 ; tli_download(bytes, null); trans.byte_unpack(bytes); for (n=0; n<trans.len; n=n+1) $display("trans.data[%3d]=%d", n, trans.data[n]); #100 $finish; end endmodule // top
The file top.v is analyzed using the following command: vlogan -sverilog -ntb_opts rvm top.v
Building simulation The simulation simv is then build using the following vcs command: vcs -sysc -debug_all top -timescale=1ns/1ps
The following command creates a wrapper for a Verilog module to be instantiated in SystemC:
% vlogan -sysc=2.2 -sysc=dpi_if my_vlog.v -sc_model \ my_vlog
You can use both PLI- and DPI-based interfaces within the same simulator. That is, you can use one SystemC model using the DPIbased interface and another SystemC model using the PLI-based interface, within the same simulator.
Where,
<target_directory> is the user-specified path. If specified, this
Note: The above command creates the precompiled header files systemc.h and systemc, if they do not exist. Otherwise, it uses the precompiled header files which are already present.
If you mention target_directory, then the g++ call first searches this directory for precompiled header files.This ensures that you get the best performance improvement, and that the precompiled header files are used if they exist. If you do not specify a directory, then g++ creates a precompiled header file in each of the following two directories:
./csrc/sysc/prec/$hostname/<SC_version>/<GCC_version>/ <VCS_version>/systemc_.h.gch/ ./csrc/sysc/prec/$hostname/<SC_version>/<GCC_version>/ <VCS_version>/systemc_.gch/
The file name is based on the compile-time options (for example, m32_fPIC for -m32 fPIC). If -Mdir is specified as an argument to syscan prec, then the directory structure appears as follows:
<mdir_path>/prec/$hostname/<SC_version>/<GCC_version>/ <VCS_version_id>/systemc_.h.gch/
and
<mdir_path>/prec/$hostname/<SC_version>/<GCC_version>/ <VCS_version_id>/systemc_.gch/
If you specify a directory name with the -prec option, then the precompiled header files are generated in the subdirectory prec/ systemc_.h.gch/ and in prec/systemc_.gch/ of the specified directory. If you use -Mdir with -prec with a path, then the -Mdir option is ignored for the location of the precompiled headers.
The generation of the precompiled header files is done using make files, so that in case of no change, a precompiled header file is not generated again.
These commands use the precompiled header files created by the above command:
% vlogan sverilog my_top.sv % vcs -sysc my_top
Compile flags are not the same SystemC-related defines passed with -D as argument(s) of the -cflags option are not the same $VCS_HOME (version) changes SystemC version changes Host changes (different system include files)
If the -prec option is called with a user-specified path, then a sanity check is done if precompiled header files are already generated at the specified location. If any of the above-mentioned changes takes place, an appropriate message is generated, and the creation and usage of precompiled header files is skipped. This occurs for VCS, gcc, SystemC version, and host name changes. If the changes are only in compile flags, then the precompiled header files are generated if they do not exist.
Limitations
Limitations of GNU Precompiled Header Files The following are the limitations of the GNU precompiled header files: The option used for creating the precompiled header file and the actual must be the same. If not, the precompiled header file is skipped. Only one precompiled header file can be used in one compilation step. Any C token before a precompiled header file is skipped.
The g++ used for creating the precompiled header file and the actual g++ must be the same compiler binary. Any macro defined before the precompiled header file must be the same when creating and using it.
If there are SystemC-related defines in front of a SystemC header file, you must create the precompiled SystemC header file with the same defines (names and values) using the -D option (as part of cflags in a syscan prec command). The defines in front of a SystemC header file must match the set of defines used in the precompiled header file creation step. If no matching precompiled file is found, the ASCII version of the SystemC header file is used.
The most likely thing to change is the name of the host. If the host name is part of the path (like /some_dir/${hostname}/), then the precompiled header files can be used. The downside is that the precompiled header files are created in this specific directory with the information used by VCS, SystemC, and gcc version. You must call the syscan executable with the -prec option with the same path. Any change in the compile flags (passed with cflags) invokes the creation of precompiled header files, if they do not exist for the changed combination of compile flags.
One way to increase the size is calling the sc_stack_size() method, as described in the SystemC LRM. VCS provides an additional way to modify the stack size and stack guard size using runtime options described in the following sections. This allows you to extend the stack size without the need to recompile the simulation.
The signed_number passed with this option must be in the range between 64 KB and 10 MB, else VCS generates a warning message. If the size is less than 64 KB, then this option has no effect on the stack size, and the default stack size (60 KB) is used. If you explicitly specify a size of 10 MB or less using the sc_stack_size() method in the SystemC source code, then this option can only increase this limit by using the larger of sc_stack_size() and -sysc=stacksize. If you specify more than 10 MB with sc_stack_size(), then this option does not override this setting. The decision on which size to use is done individually for each SC thread. Example
simv -sysc=stacksize:1024k
This runtime option increases the stack size of all SC_THREADs, SC_CTHREADs, and spawned functions to at least 1 MB.
If the size is less than 4 KB, then this option has no effect on the stack guard size, and the default size of 4 KB is used. If the signed_number is greater than 1 MB, then the stack guard is increased accordingly, but a warning is generated. Example
simv -sysc=stackguardsize:100k
This runtime option increases the stack guard size to 100 KB.
If the crash goes away, then there is a chance that a stack overrun has occurred before. If so, then leave the stack at its previous size (which is too small), but increase the stack guard size to a large value (for example, 200 MB).
This increases the chance for the simulation to abort with an SEGV on the first time, when a stack overrun occurs. Compile all SystemC source code with debug information, and start the simulation from a debugger such as gdb or from DVE/CBug, as shown below:
syscan -cflags -g file1.cpp file2.cpp ... ... gdb simv (gdb) run -sysc=stackguardsize:200M ... SEGV occurred in file1.cpp line 123 ...
Identify the SC thread that used more memory and increase its stack size by calling sc_stack_size() in the constructor. For more information on sc_stack_size(), see the SystemC LRM.
Run Time
The simulation speed may be affected by using the fine-grained sync loop. The difference depends on the individual design, so there is no simple rule-of-thump. However, there is a general tendency that simulations will run slower when using the fine-grained sync loop.
Example Syntax
vlogan verilog_dut.v verilog_top.v syscan -sysc=22 ./stimulus.cpp:stimulus ./ gen_clk.cpp:gen_clk -cflags "-g" vcs top -sysc=22 -sysc=newsync -debug_all -cflags "-g" simv -ucli -i dump.tcl
Restrictions
The fine-grained SC/HDL sync loop is an LCA feature and has several restrictions: (IMPORTANT) No return from first sc_start() call: The execution flow will not return from the first call of sc_start(). All statements located after this call will never be executed. Furthermore, the program will never return from function sc_main(). This means that multiple calls to sc_start() are not supported. Also, class destructors may not be executed because VCS will call exit() before sc_main() returns. Note that no warning is printed if there are multiple sc_start() calls or other important statements after the first sc_start() call. SystemC 2.2 must be used: an error is printed if another SystemC version is used. Pure SystemC mode (=no HDL modules) is not supported. An error is printed when the fine-grained sync loop is used is this situation.
The time resolution between SystemC and HDL must match. An error is printed and the simulation is aborted during startup of simv when this restriction is violated. SystemC inout ports are not supported in combination with the fine-grained sync loop: no error message is printed and the simulation may hang.
Note: In previous releases, VCS started the simulation with a call to sc_start () and kept running until the simulation terminated. Therefore, control never came back to the sc_main() function. To revert back to the old flow, use -sysc=nomulti_start. This feature removes the following restrictions on coding style inside sc_main() that were required for the save/restore feature: No need to use dynamic allocation for sc_objects inside sc_main(). However, it is recommended to use dynamic allocation to avoid stack overflow in the sc_main thread. Multiple sc_start() calls are supported and statements located after sc_start() are executed.
Note: The function sc_main() is treated as a thread in VCS-SystemC cosimulation. The sc_main thread is run with the default stack size, which is usually 10 MB. At times, the sc_main function may create several SystemC objects and hence consume a huge amount of stack space. So, the following three ways are provided to alter the stack size of the sc_main thread. Use the runtime switch -sysc=stacksize:1024k to set the stack size. This is the same switch used to set the stack size for SC_THREADS. Since the sc_main thread is usually heavier compared to SC_THREADS, VCS allocates 16 times to the value specified with this switch.
Use the environment variable setenv VCS_SYSC_STACKSIZE 1024k to set the stack size. This is just an alternative to the above switch. Here also, VCS allocates 16 times to the specified value. The runtime switch takes precedence over this environment setting. Use the following API call to set the stack size:
sc_snps::sc_set_stack_size_sc_main(const char* size_string)
You can call this API and specify the stack size as a string (for example, 1024k). Call this routine before the sc_main() function gets called. You can do this by placing this function call in a static initializer outside the sc_main function. Note that the header file systemc_user.h must be included since the namespace sc_snps is declared in the header file. Example static int tmp = sc_snps::sc_set_stack_size_sc_main("1024K"); When you use any or all of the above methods to alter the stack size, the final size is the maximum value of: The default size Size set using runtime switch or environment variable Size set using the API call
Since VCS executes sc_main within a thread, you should use dynamic allocation for the sc_object created inside sc_main and thus minimize the stack utilization.
Two of the above conditions can be detected before the design gets cleaned up, but the last condition cannot be detected before the design gets freed up. Once the sc_main returns, all sc_objects that are statically allocated are deleted. Therefore, the SystemC kernel cannot issue end_of_simulation callbacks on these deleted sc_objects. Therefore, you must add an sc_stop() call at the end of the sc_main() function (before returning from it). Example 19-12 shows a code snippet with multiple sc_start calls. Example 19-12 Multiple sc_start Calls
int sc_main(...) { ... sc_start(t); /* Execute till time t */ ... sc_start(t1); /* Execute till time t1 */ ... sc_stop(); /* Call end_of_simulation routines for sc_modules */ return 0; }
The sc_start() call starts the simulation and continues until simulation terminates. Control never comes back to the sc_main() function after sc_start() is called. Therefore, do not place any statements after the sc_start() call (these statements are never executed).
Example 19-13 shows the supported coding style. Example 19-13 Supported SystemC Coding Style for Save and Restore
int sc_main(int argc, char* argv[]) { static int isRestore = 0; if (isRestore == 0) { isRestore = 1; sc_core::sc_set_time_resolution(100, SC_PS); Stimuli* stim_inst = new Stimuli("stim_inst"); CPU_BFM* dut = new CPU_BFM("stim_inst"); } sc_start(); return 0; }
-save_file <file name> | <directory name> Saves all open files in writable mode, and all files that open in read-only mode, depending on the option you specify: - With <file name>, saves the specified open file in read/write mode. - WIth <directory name>, saves all files in the specified directory open in read/write mode. -save_file_skip <file name> | <directory name> This allows you to skip saving one or more files depending on the option: - With <file name>, skips saving the specified file that is open in read/write mode. - WIth <directory name>, skips all files in the specified directory that are open in read/write mode.
where, <file_with_pathmaps>:
<old_directory_path_name>:<new_directory_path_name>
switch, the internal structure for how the SystemC-on-top design is implemented changes. The SystemC unified hierarchy flow is not active by default (except for the partition compile with SystemC-ontop flow). Otherwise, you need to be explicitly activated the unified hierarchy flow using: sysc=unihier or -sysc=show_sc_main
For example, if you elaborate your SystemC design in the usual way:
% vcs -sysc
the SystemC unified hierarchy flow is not active. This is the default. But if you use the -sysc=unifier switch to elaborate your SystemC design:
% vcs -sysc -sysc=unihier
the SystemC unified hierarchy flow is active. When you open a SystemC-on-top design with DVE, you see the correct logical design structure: all SystemC, Verilog, and VHDL instances are visible and located in the correct structure. This structure is also properly displayed when you dump the design using UCLI dump commands or traverse the design using UCLI scope commands (or with the MHPI interface). All these interfaces are aware of SystemC.
However, there are other APIs that expose the underlying implementation and show a different picture of the hierarchy, because they are not aware of SystemC. For example: XMR paths within Verilog source code %m within a Verilog display statement DPI access functions VPI, and so on
These APIs do not have a concept of SystemC and are therefore unable to deal with the SystemC layer on top in HDL-SC cosimulation. These APIs expose: How the SystemC and Verilog/VHDL parts are internally combined in the HDL-SC cosimulation environment. Implementation details that do not reflect the logical structure. For example, if you add the following statement in your design:
$display("Inst '%m' of Verilog module VLOG_BOT"); //vlog child vlog_bot module vlog_bot{.} //SystemC child sc_mod SC_MODULE(sc_mod){ vlog_bot vlog_inst_A; SC_CTOR(sc_top) : vlog_inst_A(vlog_inst_A) {..} }; //SystemC top module sc_top SC_MODULE(sc_top){ //instantiate vlog_mod and sc_mod here
vlog_bot vlog_inst_0; sc_mod sc_inst_1; sc_mod sc_inst_2; SC_CTOR(sc_top) : vlog_inst_0(vlog_inst_0), sc_inst_1(sc_inst_1), sc_inst_2(sc_inst_2) { } }; int sc_main(int argc, char** argv) { sc_top sc_top_o(sc_top); sc_start(100,SC_NS) }
Note: The sYsTeMcToP at the beginning is not part of the logical hierarchy, but exposes an implementation detail. Also, the usage of Verilog escaped identifiers with character \. Remember that the %m exposes implementation details, including details that may change from one VCS release to another or even within a release from one patch to the next.
But if you need to use any other API (for example, VPI or the %m) the new SystemC unified hierarchy flow (option -sysc=unihier) is important because it aligns the internal implementation structures as much as possible with the logical structure. The instance tree is visible to APIs that deal only with Verilog and/or VHDL and it has the correct logical structure. SystemC instances appear as dummy Verilog instances on all locations needed to represent the logical structure. In the example above, the $display statement now prints:
Inst 'SC_TOP.SC_INST_1.VLOG_INST_A' of Verilog module VLOG_BOT Inst 'SC_TOP.SC_INST_2.VLOG_INST_A' of Verilog module VLOG_BOT Inst 'SC_TOP.VLOG_INST_0' of Verilog module VLOG_BOT
Note: Only the SystemC instances are represented as Verilog instances. SystemC ports, signals, processes, and so on are not represented. The Verilog modules representing SystemC instances are therefore mostly empty.
The reported hierarchy may change when top-level modules are changed. The sc_main may come or go. This could be problematic for automated tests or UCLI scripts because reported path names change. To prevent this problem, add the -sysc=show_sc_main option to the elaboration; this ensures that sc_main is always used. For example:
% vcs -sysc=show_sc_main
Note: Using the -sysc=show_sc_main option implies the SystemC unified hierarchy flow. You dont need to add the sysc=unihier option.
Not available for donut designs (Verilog-SystemC-Verilog). Only available with UUM flow (not with non-UUM flow).
Introduction
Both SystemC and VMM contain APIs, which control the functionality of a message (info, warning, and error). Both concepts are similar, but the APIs and underlying implementation is completely independent. For example, if you want to skip all warnings or redirect warnings into a log file, then you must call both the SystemC and VMM APIs. This is tedious.
The scenario explained in the following use model, enables you to decide whether you want to align SystemC messages with VMM or not.
Use Model
To align VMM messages with SystemC: 1. Instantiate the tli_vmm_sc_msg_align module in the top module 2. Include the tli_vmm_sc_msg_align.sv file before the SV top module. For Example:
`include "tli_vmm_sc_msg_align.sv" module top; tli_vmm_sc_msg_align vmm_msg_align(); test tb(); sc_top sysc(); endmodule
Only those messages, which are not suppressed from SystemC, are aligned with VMM. If you are registering your own sc_report_handler, then the report_handler will not be aligned with VMM messaging, and the user-defined report handler takes precedence. The default setting for VMM message alignment creates a vmm_log instance for each SystemC process-id (name for a SystemC process). This process-id is the instName of a vmm_log instance. You can change this default behavior to use one vmm_log instance for all SystemC processes and messages, or you can disable the VMM message alignment.
You can disable VMM message alignment, or switch to the usage of one vmm_log for all SystemC processes, only once. There will be no messages generated, and the calls does not have effect on the VMM message behavior. To use a SystemC API, you must include the systemc_user.h file, as shown in the following example. This example shows how to disable the VMM message alignment. Note: Disabling of the VMM message alignment takes place before the start of the simulation.
Example:
#include "systemc_user.h" ... sc_main(...) { ... sc_snps::align_sc_report_with_VMM( sc_snps::NoVMMLog ); ... sc_start(...); ... }
The SystemC messages consists of an ID, which is turned into a prefix of the VMM message. For example, if you have the following message definition:
SC_DEFINE_MESSAGE(TLM_PKG_FAIL, 801, "failure in package processing");
Filtering Messages
All messages generated with SC_REPORT_INFO or similar calls are aligned with VMM. The decision on whether a specific SC message is suppressed or not, is not influenced within the SystemC kernel. If it is normally (no VMM present) suppressed, then it will also be suppressed when VMM is present. If it is normally processed, then this also occurs in context with VMM. An SC message triggers a set of actions within the sc_report_handler. If VMM message alignment is active, and if print to stdout and print to log actions are influenced, then other actions (such as stopping the simulator) proceed as usual. If VMM alignment is active, a message is generated, but not suppressed by the sc_report_handler. This message is forwarded to the VMM message handler, which decides what to do with it. Note: The filter setting for VMM messages influences the type of SC messages that are printed. For example, if you run simv to print only errors, then less severe messages (for example, warnings) are not printed to stdout. This applies to both VMM and SC messages. There are two methods for filtering messages:
Printing messages into a log file. Skipping messages with a specific severity, by influencing the simulator runtime options such as +vmm_log_default and -l.
Perform the following steps to archive the changes in the settings of SystemC-VMM specific to the vmm_log instantiations: 1. Get the actual vmm_log instantiation of a SystemC-instName (SystemC process-id(name)). 2. Call the vmm_log related methods with the appropriate arguments. The following SV-task returns the current vmm_log used by the SystemC-VMM message alignment as the second argument, depending on the vmm_log settings (single or multiple vmm_logs).
tli_util_get_sysc_vmm_log_by_instName(<string>, <vmm_log>);
Where, <string> is the process name. If SystemC-VMM alignment is disabled, then the second task argument, vmm_log, is 0. The task is declared in the tli_vmm_sc_msg_align module. To use this task, the module must be instantiated within the top module. You can then access the task using the following command:
<top_module_name>.<instance_name_of_tli_vmm_sc_msg_align>. tli_util_get_sysc_vmm_log_by_instName(...);
For example, if the name of the top SV module is mentioned as top, then the tli_vmm_sc_msg_align module is instantiated in the top SV module, and the instance name is vmm_msg_align, as shown in the following example:
Example:
... vmm_log log; string process_name = "top.sysc.vmmconn1.driver"; // call task with XMR path starting with top top.vmm_msg_align.tli_util_get_sysc_vmm_log_by_instName (process_name,log); if (log) log.set_verbosity(vmm_log::WARNING_SEV, , , ); ...
If multiple vmm_logs are used (default) and vmm_log is not created, then a vmm_log with the instName provided in the string parameter is created. If VMM message alignment is switched-off, then the return value of vmm_log is 0. The name of the vmm_logs used by SystemC message alignment is SystemC. The instance name for single vmm_log is reporter, and it is process id (process name) for multiple vmm_logs. SystemC can generate messages to stdout, in a specified SC-log file, to both stdout and SC-log file. If VMM message alignment is active, then the messages are not generated in a specified SC-log file. If the SC-message is not suppressed from SystemC, then the VMM message settings decides what and how to print. As a result, the messages are printed to stdout only, and not in a SC-log file. Calling the VMM message handler requires a valid (and existing) SV scope. If there is no VMM-scope, then all SystemC messages are generated using the default sc_report_handler. If you have registered your own report_handler, it will be used for messages even if VMM alignment is active.
Limitations
The default setting, using multiple vmm_logs, can be changed only once, before start of simulation. It can be changed either to use single vmm_log or to switch-off the SystemC-VMM message alignment.
Using an `ifdef - `endif pair around the uvm_msg_align module instantiation, you can control whether you want message alignment enabled or not at compile time (see Example 19-14). Example 19-15 Ifdef for UVM Message Alignment
module top; `ifdef UMV_MSG_ALIGN tli_uvm_sc_msg_align uvm_msg_align(); `endif test tb(); sc_top sysc(); endmodule compile it with "vlogan -sverilog -ntb_opts uvm +define+UMV_MSG_ALIGN top.sv ...
Only those messages are aligned with UVM, which are not suppressed from SystemC. If you are registering your own sc_report_handler, this report handler does not align with UVM messaging. The user-defined report handler takes precedence. The default setting for UVM message alignment is that for each SystemC process-id a UVM report object is created with the process-id as the instName of a UVM report instance. You can change this default behavior to use one UVM report instance for all SystemC processes or you can disable the UVM message alignment.
The following API (see Example 19-16, Example 19-17, and Example 19-18) is provided for SystemC to disable UVM message alignment or change the kind of UVM report object to be used. Example 19-16 Multiple UVM Report Objects for SystemC-UVM Message
sc_snps::align_sc_report_with_UVM(sc_snps::MultipleUVMLogs);
Example 19-17
sc_snps::align_sc_report_with_UVM(sc_snps::SingleUVMLog);
Disabling UVM message alignment or switching to one UVM report object for all SystemC processes can only be done once. Disabling UVM message alignment can only be done before simulation starts. In this case no messages are generated. The calls have no effect on the UVM message behavior. To use the API in SystemC, include the systemc_user.h file at compile time. Example 19-19 shows how to disable UVM message alignment. Note that disabling happens before simulation starts. Example 19-19 Disabling UVM Message Alignment
#include "systemc_user.h" ... sc_main(...) { ... sc_snps::align_sc_report_with_UVM(sc_snps::NoUVMLog); ... sc_start(...); ... }
UVM and SystemC messages both have severities, and the mapping of SystemC severities to UVM is as you might expect: SC_REPORT_INFO maps to UVM info message SC_REPORT_WARNING maps to UVM warning message SC_REPORT_ERROR maps to a UVM error message SC_REPORT_FATAL maps to a UVM fatal message.
The SystemC messages have an ID. For UVM, this ID is prefixed with SC. Here are some examples of converted messages. Assume the following SystemC message definition (as define): SC_DEFINE_MESSAGE(TLM_PKG_FAIL, 801, "failure in package processing"); The following call:
SC_REPORT_INFO(TLM_PKG_FAIL, "Package got lost");
if SystemC, is printed as a UVM message. In the case of single UVM report object:
UVM_INFO my_sc_file.cpp(18) @ 50000: SystemC(reporter) SC-801] failure in package processing : Package got lost
The following SystemC report handler call with an SC message without an ID in a file called my_sc_file.cpp:
SC_REPORT_INFO("failure in package processing", "Package got lost");
results in:
UVM_INFO my_sc_file.cpp(31) @ 50000: SystemC(top.sysc.do_transactions) [SC-NAN] failure in package processing : Package got lost
An SC message triggers a set of actions within the sc_report_handler. If a UVM message alignment is active print to stdout and print to log action is influenced. Other actions (such as stopping the simulator) proceed as usual. If UVM message alignment is active, a message is emitted and not suppressed by the sc_report_handler. Then it is forwarded to the UVM message handler, which decides what to do with it. Note that setting the filter for UVM messages also influences which SC messages are printed. For example, if you tell simv to filter uvm_note, then only more severe messages like warnings, errors, and fatal are printed to stdout. This applies to UVM and SC messages. There are two ways to filter messages. You can print them into a log file and skip messages with a specific severity for SC-messages using the +UVM_VERBOSITY= and -l simulator runtime options.
where, <string> is the process name. If SystemC-UVM alignment is disabled, the returned UVM report object is 0. The function is declared in the package tli_uvm_sc_msg_align_pkg. To use this function, you must include or analyze the provided tli_uvm_sc_msg_align.sv file beforehand. You can access the task explicitly as follows:
uvm_report_object log = tli_uvm_sc_msg_align_pkg::tli_util_uvm_sc_get_log_by_instN ame(<string>);
For example, assuming that the top SV module is named top, the module tli_uvm_sc_msg_align is instantiated in the top SV module, and the instance name is uvm_msg_align, you can access the UVM report object of the SystemC instance as shown in Example 19-20. Example 19-20 Accessing UVM Report Object in SystemC Instance
... uvm_report_object log; string process_name = "top.sysc.uvmconn1.driver"; // call task with package-XMR log = tli_uvm_msg_align_pkg::tli_util_uvm_sysc_get_log_by_instNa me(process_name); if (log) // switch off warnings log.set_report_severity_action(UVM_WARNING, UVM_NO_ACTION); ...
Note the following naming conventions: The name used by SystemC message alignment in a UVM report object is always SystemC. The instance name in case of a single UVM report object is always reporter.
The instance name in case of multiple UVM report objects is the SystemC/nop> process id (process name). VCS TLI Adapters (SystemVerilog - SystemC TLM 2.0) enables transaction-level communication between SystemVerilog (SV) and SystemC (SC). VCS provides a built-in TLI adapter to connect the SV to SystemC OSCI TLM 2.0 interface.
The TLI adapter consists of SV and SystemC adapters. These adapters communicate with each other using Direct Programming Interface (DPI). The SV adapter consists of the following packages: User Package Global Package
The SV interface of TLI adapter is generic and user-extensible. The present SV implementation of TLI adapter connects the following SV interfaces: VMM Channel Interface VMM TLM Interface
Apart from the above two interfaces, you can connect any other SV interface with minimum changes in the TLI adapter. Note: TLI adapters provided by VCS are only for vmm_tlm_generic_payload data objects. If the data objects are of different data type, you must modify the User Package in TLI adapters.
Similarly, SystemC Adapter communicates information from SystemC module to the Global Package. The User Package gets information from the Global Package and process the information to User SV Transaction Level Interface.
SystemC Adapters
The SystemC adapter implements OSCI TLM 2.0 LT/AT initiator or target to connect to the SystemC world.
Global Package
The Global Package is the SV package, where the User Package and TLI SystemC adapters exchange data through the APIs provided by this package. The TLI SystemC adapters transfer the data in either direction across the Global Package using the DPI tasks or functions. The User Package transfers the data across the Global Package using its APIs, as described below. The Global Package provides following tasks and functions: Global Package APIs task put_data (tlmpkt) // SV Producer // tlmpkt is the generic payload type defined by TLI This task performs the following: - Transmits data to the global package - Generates a data event to indicate global package that the data is transmitted
- Waits for the received event from the global package, to make sure data is received by the SystemC world. function put_data_func (tlmpkt) //SV Producer This function transmits data to global package and generates data event. This function can be called from the user package in case of non-blocking communication. task get_resp (tlmpkt) // SV Producer
This task waits for the put response event from the global package to make sure response is received by the global package, and then reads the data response from the global package. task get_data (tlmpkt) // SV Consumer
This task waits for the data event and reads data from the global package. task put_resp (tlmpkt) // SV Consumer
This task calls the send_rsp_to_fifo(chandle sc_obj)dpi imported function to put the response into the SystemC adapter. Except the put_data_func function, which returns immediately, all other tasks are blocking tasks. In addition to the above API functions, the global package also provides the register_unique_id(string) function to register the unique id. The user package should call this function in the implementation of the bind function.
Note: The TLI adaptor can be used with other SV interfaces (other than vmm_channel/vmm_tlm) by modifying the user package. You must not modify the global package implementation while using any SV interface including vmm_channel or vmm_tlm. The vmm_tlm package also supports the AT phase communication between SC and SV. This package uses the phase enum vmm_tlm::phase_e and sync enum vmm_tlm::sync_e of vmm_tlm (similar to the OSCI TLM2 standard). However, you can also use your own phasing by modifying your user package accordingly.
User Package
The VCS TLI adaptor provides the following packages for the VMM channel interface and VMM TLM interface respectively: vmm_channel_binds vmm_tlm_binds
The VCS TLI adaptor supports only the vmm_tlm_generic_payload data objects. For different interface (other than VMM channel or VMM TLM) and data type (other than vmm_tlm_generic_payload), you must modify the user package by implementing conversion functions. User Package for VMM Channel Interface This package imports Global Package and consists of the following: Bind Function Conversion Functions
Processes
Bind Function tli_channel_bind (SV channel object, unique id, direction) This function registers its unique id using the register_unique_id(id) function provided by the global package to register its ID with DPI. The direction argument in the bind function is an enum which indicates the direction SV-SC or SC-SV for both blocking and non-blocking communication. It invokes separate processes based on the direction. Conversion Functions The following conversion functions are implemented to convert vmm_tlm_generic_payload to tlmpkt (generic payload type of TLI) and vice versa. conv_userdata_to_tlmpkt (user data, tlmpkt) If tlmpkt is not allocated before, this function allocates a new object of tlmpkt and converts user data to tlmpkt. conv_tlmpkt_to_userdata(tlmpkt, user data) If user data is not allocated before, this function allocates a new object of vmm generic payload and converts tlmpkt to vmm generic payload. Processes Depending on the direction, one of the following processes will be forked off from the bind function: channel_get_b_process()
Using SystemC 19-223
For more information on the above processes, see VMM Channel Interface Details. User Package for VMM TLM Interface This package imports the Global Package, and consists of the following: Bind function Conversion Functions Processes Target Class
Bind function tli_tlm_bind (SV port/export object, port type, unique id) The SV port/export object is bind to export/port of type specified by you. This function registers its unique id using register_unique_id(id) provided by the global package to register its ID with DPI. The port type in the bind function is an enum define in VMM TLM intf_e, which indicates the type of port/export to be connected to. It invokes separate processes based on this enum value. For more information, see VMM TLM User Guide. Conversion Functions
See "Conversion Functions". Processes Depending on the port type, one of the following processes will be forked off from the bind function: call_transport_process () call_nb_transport_fw_process () call_write_process ()
For more information on the above processes, see VMM Channel Interface Details. Target Class This class provides the implementation of all VMM TLM functions or tasks. b_transport() nb_transport_fw() nb_transport_bw() write()
For more information on the above processes, see VMM Channel Interface Details.
Use Model
This section describes how to use TLI adapters to connect SV to SystemC OSCI TLM2.0 interface. You can have the following SV interfaces with data type as vmm_tlm_generic_payload. VMM Channel Interface (vmm_tlm_generic_payload) VMM TLM Interface (vmm_tlm_generic_payload)
Example: tli_channel_bind(chan_obj,initiator0,SV_SC_B) ; Note: For SC ProducerSV Consumer flow, you should invoke the same bind function with SC_SV_B/SC_SV_NB direction_e enum value. Perform the following steps for SC: 1. In the SC top, include the tli_sc_bindings.h file. #include tli_sc_bindings.h 2. Call the bind function defined in the tli_sc_bindings.h file. tli_tlm_bind_target(tlm::tlm_target_socket<> socket, init_type_e type, std::string unique_id, bool debug_en, bool is_sv_phase) // init_type_e type is the enum inside the header file // is_sv_phase must be true, if SV phasing communication is required, otherwise TLI adapter takes care of phasing on SC side when set to false. For example, if SC has target socket: tli_tlm_bind_target(tgt_socket, LT, initiator0, false, false); Call the following bind function, if SC has the initiator socket:
tli_tlm_bind_initiator(tlm::tlm_initiator_socket< > socket, init_type_e type, std::string unique_id, bool debug_en, bool is_sv_phase) //init_type_e type is the enum inside header file // is_sv_phase must be true, if SV phasing communication is required, otherwise TLI adapter takes care of phasing on SC side when set to false. Example: tli_tlm_bind_initiator(init_socket, LT, initiator1, false, false); Call the following bind function, if SC has analysis port: tli_tlm_bind_analysis_parent (tlm::tlm_analysis_port<> socket, std::string unique_id, bool debug_en) Example: tli_tlm_bind_analysis_parent(anal_port,parent1, false); Call the following bind function, if SC is analysis subscriber: tli_tlm_bind_analysis_subscriber (tlm::tlm_analysis_if<> socket, std::string unique_id, bool debug_en) Example:
tli_tlm_bind_analysis_subscriber(subs_inst, subscriber1, false); Note: Unique id in all the bind functions should be same as given in the corresponding SV bind function.
Note: For SC ProducerSV Consumer flow, you should invoke the same bind function with SC_SV_B/SC_SV_NB direction_e enum value. Perform the following steps for SC: 1. In the SC top, include the tli_sc_bindings.h file. #include tli_sc_bindings.h 2. Call the bind function defined in the tli_sc_bindings.h file. tli_tlm_bind_target(tlm::tlm_target_socket<> socket, init_type_e type, std::string unique_id, bool debug_en, bool is_sv_phase) // init_type_e type is the enum inside the header file // is_sv_phase must be true, if SV phasing communication is required, otherwise TLI adapter takes care of phasing on SC side when set to false. For example, if SC has target socket: tli_tlm_bind_target(tgt_socket, LT, initiator0, false, false); Call the following bind function, if SC has the initiator socket: tli_tlm_bind_initiator(tlm::tlm_initiator_socket< > socket, init_type_e type, std::string unique_id, bool debug_en, bool is_sv_phase) // init_type_e type is the enum inside header file
// is_sv_phase must be true, if SV phasing communication is required, otherwise TLI adapter takes care of phasing on SC side when set to false. Example: tli_tlm_bind_initiator(init_socket, LT, initiator1, false, false); Call the following bind function, if SC has analysis port: tli_tlm_bind_analysis_parent (tlm::tlm_analysis_port<> socket, std::string unique_id, bool debug_en) Example: tli_tlm_bind_analysis_parent(anal_port,parent1, false); Call the following bind function, if SC is analysis subscriber: tli_tlm_bind_analysis_subscriber (tlm::tlm_analysis_if<> socket, std::string unique_id, bool debug_en) Example: tli_tlm_bind_analysis_subscriber(subs_inst, subscriber1, false); Note: Unique id in all the bind functions should be same as given in the corresponding SV bind function.
Implement the conversion functions to convert user data type to tlmpkt (data type for TLI) and tlmpkt to user data type. All the API functions take the type tlmpkt.Therefore, you must convert the data before calling an API.
Note: You must call API functions using the tli_imc object. This is the object of the class tli_interconnect in the global package, where all these APIs are defined.
Bind Function See "VMM Channel Interface" Conversion Functions See VMM Channel Interface Processes Depending on the direction, one of the following processes will be forked off from the bind function: channel_get_b_process()
This process is forked off when the direction is from SV blocking to SC blocking. - This process reads the data from the SV channel using channel.peek(obj). - Converts the data into tlmpkt using a conversion function. - Calls the put_data (tlmpkt obj) API provided by the global package. - Calls the get_resp (tlmpkt obj) API provided by the global package. - Again converts back the tlmpkt to user data object using conversion function. - Indicates the user data::ENDED - Deletes the object from the SV channel using channel.get(obj). channel_get_nb_process() This process is forked off when the direction is from SV nonblocking to SC non-blocking. - This process reads the data from the SV channel using channel.peek(obj). - Converts the data into tlmpkt using a conversion function. - Calls the put_data(tlmpkt obj) API provided by the global package. - Deletes the object from the SV channel using channel.get().
- Forks off a task to call the get_resp(tlmpkt) API and to indicate data::ENDED. channel_put_b_process() This process is forked off when the direction is from SV blocking to SC blocking. - Calls the get_data(tlmpkt obj) API provided by the global package. - Converts the data into user data using conversion function. - Puts the data into SV channel using channel.put(obj). - Calls the put_resp(tlmpkt) API provided by the global package. Since this is blocking, channel.put() is blocked till the SV updates the transaction with a response. channel_put_nb_process() This process is forked off when the direction is from SV nonblocking to SC non-blocking. - Calls the get_data(tlmpkt) API provided by the global package. - Converts the data into user data using conversion function. - Puts the data into SV channel using channel.put(). - Forks off a task to wait for data::ENDED, to convert the data into tlmpkt, and finally, to call the put_resp(tlmpkt) API provided by the global package. For more information on the APIs used above, see Global Package.
Bind Function See VMM TLM interface Conversion Functions See VMM TLM interface Processes Depending on the port type, one of the following processes will be forked off from the bind function. call_transport_process() This process is forked off when SV has blocking export. It must call b_transport() of VMM TLM. - Call the get_data(tlmpkt) API provided by the global package. - Convert data(tlmpkt) to user data using a conversion function.
Using SystemC 19-236
- Call port.b_transport(data). - Convert back the user data to tlmpkt using the conversion function. - Call the put_resp(tlmpkt)API provided by the global package. call_nb_transport_fw_process() This process is forked off when SV has non-blocking forward export. It is required to call nb_transport_fw() of VMM TLM. - Call the get_data(tlmpkt) API provided by the global package. - Convert data(tlmpkt) into user data using a conversion function. - Call port.nb_transport_fw(data) - There is no backward path here. However, since SC requires it, call the API put_resp() with the same object. call_write_process() This process is forked off when SV has analysis export. It is required to call write()of VMM TLM. - Call the get_data(tlmpkt) API provided by the global package. - Convert data(tlmpkt) into user data using a conversion function. - Call port.write(data)
Target Class This class provides the implementation of all VMM TLM functions or tasks. b_transport() This implementation is required when SV has blocking port. - Convert user data to tlmpkt using a conversion function. - Call the put_data(tlmpkt) API provided by the global package. - Call the get_resp(tlmpkt) API provided by the global package. - Convert back the tlmpkt object to user data object of b_transport(). nb_transport_fw() This implementation is required when SV has a non-blocking port. - Convert user data to tlmpkt using a conversion function. - Call the put_data_func(tlmpkt) API provided by the global package. Since put_data API is a blocking task, put_data_func is used here. - Return TLM::ACCEPTED. nb_transport_bw() This implementation is required when SV has non-blocking export. - Get the tlmpkt object from user data obj.
- Call the put_resp(tlmpkt) API. - Return TLM::COMPLETED write() This implementation is required when SV has analysis port. - Convert the user data to tlmpkt using a conversion function. - Call the put_data_func(tlmpkt) API provided by the global package. Since this is a function, the put_data API task cannot be called. Non-blocking Extended Class This class is extended from a base class provided by global package, to support AT phasing function call mechanism. nb_transport_fw_call() This implementation is required when SV has vmm tlm interface with non-blocking target ports and SC is the initiator. - Convert tlmpkt to user data - Call nb_transport_fw()of SV - Convert user data back to tlmpkt nb_transport_bw_call() This implementation is required when SV has vmm tlm interface with non-blocking initiator ports and SC is the target. - Convert tlmpkt to user data - Call nb_transport_bw() of SV
Examples
This section explains different combinations with the help of the examples given below. These examples are located at $VCS_HOME/doc/examples. SV Producer Channel Connected to SC OSCI TLM2.0 LT Consumer SV Producer Channel Connected to SC OSCI TLM2.0 AT Consumer SV Producer VMM_TLM (Blocking Interface) Connected to SC OSCI TLM2.0 LT Consumer SV Producer VMM_TLM (Non-Blocking Interface) Connected to SC OSCI TLM2.0 AT Consumer SC Producer OSCI TLM2.0 LT Connected to SV Channel Consumer SC Producer OSCI TLM2.0 AT Initiator Connected to SV Channel Consumer SC Producer OSCI TLM2.0 LT Connected to SV VMM-TLM (Blocking Interface) Consumer SC Producer OSCI TLM2.0 AT Initiator Connected to SV VMMTLM (Non-Blocking Interface) Consumer SV Producer VMM-TLM (Analysis Port) Connected to SC OSCI TLM2.0 Subscriber SC Producer OSCI TLM2.0 Analysis Parent Connected to SV VMM-TLM Analysis Subscriber
Example-1
SV Producer Channel Connected to SC OSCI TLM2.0 LT Consumer In this example, SV channel acts as a producer and SC OSCI TLM2.0 LT acts as a consumer. SV channel is connected to TLI adaptor using the tli_channel_bind function (see Use Model), similarly SC LT target is connected to TLI adaptor using tli_tlm_bind_target function. This example shows these connections:
Example 19-22
producer.sv
Example-2
SV Producer Channel Connected to SC OSCI TLM2.0 AT Consumer In this example, SV channel acts as a producer and SC OSCI TLM2.0 AT acts as a consumer. SV channel is connected to TLI adaptor using the tli_channel_bind function (see Use Model), similarly SC AT target is connected to TLI adaptor using the tli_tlm_bind_target function. This example shows these connections:
Example-3
SV Producer VMM_TLM (Blocking Interface) Connected to SC OSCI TLM2.0 LT Consumer In this example, SV VMM_TLM acts as a producer and SC OSCI TLM2.0 LT acts as a consumer. SV VMM_TLM is connected to TLI adaptor using the tli_tlm_bind function (see Use Model), similarly SC LT target is connected to TLI adaptor using the tli_tlm_bind_target function. This example shows these connections. For SystemC code snippets, refer Example 19-21 and Example 19-22.
Example-4
SV Producer VMM_TLM (Non-Blocking Interface) Connected to SC OSCI TLM2.0 AT Consumer In this example, SV VMM_TLM acts as a producer and SC OSCI TLM2.0 AT acts as a consumer. SV VMM_TLM is connected to TLI adaptor using the tli_tlm_bind function (see Use Model), similarly SC AT consumer is connected to TLI adaptor using the tli_tlm_bind_target function. This example shows these connections. For SystemC code snippets, refer Example 19-26 and Example 19-27.
Example-5
SC Producer OSCI TLM2.0 LT Connected to SV Channel Consumer In this example, SC OSCI TLM2.0 LT acts as a producer and SV channel acts as a consumer. SV channel is connected to TLI adaptor using the tli_channel_bind function (see Use Model), similarly SC LT producer is connected to TLI adaptor using the tli_tlm_bind_initiator function. This example shows these connections.
Example-6
SC Producer OSCI TLM2.0 AT Initiator Connected to SV Channel Consumer In this example, SC OSCI TLM2.0 AT acts as a producer and SV channel acts as a consumer. SV channel is connected to TLI adaptor using the tli_channel_bind function (see Use Model), similarly SC AT producer is connected to TLI adaptor using the tli_tlm_bind_initiator function. This example shows these connections.
Example-7
SC Producer OSCI TLM2.0 LT Connected to SV VMM-TLM (Blocking Interface) Consumer In this example, SC OSCI TLM2.0 LT acts as a producer and SV VMM TLM acts as a consumer. SV VMM TLM is connected to TLI adaptor using the tli_tlm_bind function (see Use Model), similarly SC LT producer is connected to TLI adaptor using the tli_tlm_bind_initiator function. This example shows these connections. For SystemC code snippets, refer Example 19-30 and Example 19-31.
Example-8
SC Producer OSCI TLM2.0 AT Initiator Connected to SV VMMTLM (Non-Blocking Interface) Consumer In this example, SC OSCI TLM2.0 AT acts as a producer and SV VMM TLM acts as a consumer. SV VMM TLM is connected to TLI adaptor using the tli_tlm_bind function (see Use Model), similarly SC LT producer is connected to TLI adaptor using the tli_tlm_bind_initiator function. This example shows these connections. For SystemC code snippets, refer Example 19-33 and Example 19-34.
Example-9
SV Producer VMM-TLM (Analysis Port) Connected to SC OSCI TLM2.0 Subscriber In this example, SV VMM-TLM analysis port acts as a producer and SC OSCI TLM2.0 analysis subscriber acts as a consumer. SV VMM TLM is connected to TLI adaptor using the tli_tlm_bind function (see Use Model), similarly SC analysis subscriber is connected to TLI adaptor using the tli_tlm_bind_analysis_subscriber function. This example shows these connections.
Example-10
SC Producer OSCI TLM2.0 Analysis Parent Connected to SV VMM-TLM Analysis Subscriber In this example, SC OSCI TLM2.0 analysis parent acts as a producer and SV VMM-TLM analysis subscriber acts as a consumer. SV VMM TLM is connected to TLI adaptor using the tli_tlm_bind function (see Use Model), similarly SC analysis parent is connected to TLI adaptor using the tli_tlm_bind_analysis_parent function. This example shows these connections.
Steps for SV 1. Include the uvm_tlm2_sv_bind.svh file where the UVM SV adapter is defined.
`include uvm_tlm2_sv_bind.svh
2. Import uvm_tlm2_sv_bind_pkg.
import uvm_tlm2_sv_bind_pkg::*;
Here, the second argument indicates the type of socket to which the user socket is connected: - When SV is a blocking initiator, the second argument is UVM_TLM_B_TARGET. - When SV is a non-blocking initiator, the second argument is UVM_TLM_NB_TARGET. - When SV is a blocking target, the second argument is UVM_TLM_B_INITIATOR. - When SV is a non-blocking target, the second argument is UVM_TLM_NB_INITIATOR. Steps for SC 1. Include the file uvm_tlm2_sc_bind.h.
#include uvm_tlm2_sc_bind.h
// SC Initiator
uvm_tlm2_bind_sc_initiator(initiator socket, UVM_TLM_B, (UVM_TLM_NB, if non blocking) unique_id, dbg_prints);
3. Set up the SC pack/unpack functions for user-defined payloads. For user-defined payloads, SC has to provide pack/unpack functions for the following two functions and should compile and link these functions.
void tli_conv2_pack_tlmgp(tli_pack_data& P, T &gp) // T user payload void tli_conv2_unpack_tlmgp(tli_pack_data& P, T &gp)
The implementation of these functions is provided by VCS TLI adapters for the generic payload. For other payload types, you must provide these functions. Use the UVM-SC Byte pack/unpack feature for packing/ unpacking the user fields in the above functions. For more information, see the UVM-SC Byte pack/unpack document.
Here, the second argument indicates the type of socket to which the user socket is connected: - When SV is an analysis parent, the second argument is UVM_TLM_ANALYSIS_EXPORT. - When SV is an analysis subscriber, second argument is UVM_TLM_ANALYSIS_PORT. Steps for SC 1. Include the uvm_tlm2_sc_bind.h file: #include uvm_tlm2_sc_bind.h 2. Call the bind functions in the SystemC-top constructor: // SC subscriber
tli_tlm_bind_analysis_subscriber(user port, unique_id, is_debug_prints, // enables debug messages is_uvm) // Set to 1 if SV has UVM interface
// SC parent
tli_tlm_bind_analysis_parent(user port, unique_id, is_debug_prints, // enables debug messages is_uvm) // Set to 1 if SV has UVM interface
uvm_tlm_blocking Example
In this example, there is one SV blocking initiator connected to one SC LT target and one SC LT initiator connected to one SV blocking target. The example files are shown in Example 19-44, Example 1945, and Example 19-46. SV UVM TLM blocking initiator <-> SC TLM2.0 LT target SV UVM TLM blocking target <-> SC TLM2.0 LT initiator
module top; import uvm_pkg::*; // Import the "uvm_tlm2_sv_bind_pkg" package where adapter // for vmm_channel interface is available. import uvm_tlm2_sv_bind_pkg::* ... endmodule
public: initiator init1; target trgt0; SC_CTOR(sc_top) : trgt0("trgt0"), init1("init1") { // Bind function to connect SV initiator to SC target and // SV target to SC initiator respectively. uvm_tlm2_bind_sc_target(trgt0.target_socket, UVM_TLM_B," port0"); uvm_tlm2_bind_sc_initiator(init1.initiator_socket, UVM_TLM_B," port1"); } };
uvm_tlm_nonblocking Example
In this example there is one SV non-blocking initiator connected to one SC AT target and one SC AT initiator connected to one SV nonblocking target. The example files are shown in Example 19-47, Example 19-48, and Example 19-49. SV UVM TLM non-blocking initiator <->SC TLM2.0 AT target SV UVM TLM non-blocking target <-> SC TLM2.0 AT initiator
{ // Bind function to connect SV initiator to SC target and // SV target to SC initiator respectively. uvm_tlm2_bind_sc_target(trgt0.target_socket, UVM_TLM_NB," port0"); uvm_tlm2_bind_sc_initiator(init1.initiator_socket, UVM_TLM_NB," port1"); } };
uvm_tlm_analysis Example
In this example, there is one SV analysis parent connected to two SC analysis subscribers and one SC analysis parent connected to two SV analysis subscribers: SV UVM TLM analysis parent <-> Two SC TLM2.0 analysis subscribers (2) Two SV UVM TLM analysis subscribers (2) <-> SC TLM2.0 AT analysis parent
`uvm_component_utils(tb_env); initiator initiator0; // SV UVM analysis parent target target0; // SV UVM analysis subscriber1 target target1; // SV UVM analysis subscriber2 typedef uvm_tlm_generic_payload T; typedef uvm_tlm_phase_e P; typedef uvm_tlm_if_base#(T,T) IF; function new(..); endfunction function build_phase(..) // build initiator // build target endfunction function void connect_phase(uvm_phase phase); // Connect function to connect SV parent to two SC //subscribers. uvm_tlm2_sv_bind#(T, P, IF)::connect(initiator0.an_port, UVM_TLM_ANALYSIS_EXPORT, "port0"); uvm_tlm2_sv_bind#(T, P, IF)::connect(initiator0.an_port, UVM_TLM_ANALYSIS_EXPORT, "port1"); uvm_tlm2_sv_bind#(T, P, IF)::connect(target0.socket, UVM_TLM_ANALYSIS_PORT, "ex_port0"); // Connect function to connect two SV targets to SC initiator. uvm_tlm2_sv_bind#(T, P, IF)::connect(target1.socket, UVM_TLM_ANALYSIS_PORT, "ex_port1"); endfunction endclass
class sc_top : public sc_module { public: consumer m_target0; consumer m_target1; parent m_parent; SC_CTOR(sc_top) : m_target0("trgt0"), m_target1("trgt1"), m_parent("parent"); { // Bind functions to connect SV parent to SC subscribers and // SV subscribers to SC analysis parents respectively. tli_tlm_bind_analysis_subscriber(m_target0, "port0", false, true); tli_tlm_bind_analysis_subscriber(m_target1, "port1", false, true); tli_tlm_bind_analysis_parent(m_parent, "ex_port0", false, true); tli_tlm_bind_analysis_parent(m_parent, "ex_port1", false, true); } };
20
C Language Interface 2
It is common to mix C and C++ with both Verilog and VHDL. There are many different mechanisms and what you do will depend on your objective as well as the performance and restrictions of each mechanism. VCS supports the following ways to use C and C++ with your design: VHPI enables you to use foreign architecture-based models written in C language in the VCS MX VHDLUsing DirectC.Using DirectC Using SystemC - See the Using SystemC chapter. Using SystemVerilog DPI routines - See the SystemVerilog LRM. Using PLI Using VPI Routines
Note: PLI1.0 refers to TF and ACC routines, and PLI2.0 refers to VPI.
Using PLI
PLI is the programming language interface (PLI) between C/C++ functions and VCS. It helps to link applications containing C/C++ functions with VCS, so that they execute concurrently. The C/C++ functions in the application use the PLI to read and write delay and simulation values in the VCS executable, and VCS can call these functions during simulation. VCS supports PLI 1.0 and PLI 2.0 routines for the PLI. Therefore, you can use VPI, ACC or TF routines to write the PLI application. See Appendix , "PLI Access Routines". This chapter covers the following topics: Writing a PLI Application Functions in a PLI Application Header Files for PLI Applications PLI Table File Enabling ACC Capabilities
These procedures are not mutually exclusive. It is, for example, quite possible that you have a PLI application that you write and use during the debugging phase of your design. If so, you can write a PLI table file that both: Associates user-defined system tasks or system functions with the functions in your application and limits the scope and operations called by your functions for faster performance. Limits scope and operations of the functions called by the debugging features in VCS.
The function that VCS calls for miscellaneous reasons such as the execution of $stop, $finish, or other reasons such a value change. When VCS calls this function, it passes a reason argument to it that explains why VCS is calling it. You can omit this miscellaneous function.
These are the functions you tell VCS about in the PLI table file; apart from these PLI applications can have several more functions that are called by other functions. Note: You do not specify a function to determine the return value size of a user-defined system function; instead you specify the size directly in the PLI table file.
For PLI applications whose functions call IEEE Standard TF routines as documented in the IEEE Verilog Language Reference Manual. vcs_acc_user.h For PLI applications whose functions call the special ACC routines implemented exclusively for VCS. These header files are located in the $VCS_HOME/your_platform/lib directory.
Syntax
The following is the syntax of the PLI table file:
$name PLI_specifications [access_capabilities]
Here: $name Specify the name of the user-defined system task or function. PLI_specifications Specify one or more specifications such as the name of the C function (mandatory), size of the return value (mandatory only for user-defined system functions), and so on. For a complete list of PLI specifications, see PLI Specifications on page 7. access_capabilities Specify the access capabilities of the functions defined in the PLI application. Use this to control the PLI 1.0 or PLI 2.0 functions ability to access the design hierarchy. See Access Capabilities on page 10 for more information. Synopsys recommends you enable this feature while using PLIs to improve the runtime performance. PLI Specifications The PLI specifications are as follows: call=function Specifies the name of the function defined in the PLI application. This is mandatory. check=function Specifies the name of the check function.
misc=function Specifies the name of the misc function. data=integer Specifies the value passed as the first argument to the call, check, and misc functions. The default value is 0. Use this argument if you want more than one user-defined system task or function to use the same call, check, or misc function. In such a case, specify a different integer for each user-defined system task or function that uses the same call, check, or misc function. size=number Specifies the size of the returned value in bits. While this is mandatory for user-defined system functions, you can ignore or specify 0 for user-defined system tasks. For user-defined system functions, specify a decimal value for the number of bits. For example, size=64. If the user-defined system function returns a real value, specify r. For example, size=r args=number Specifies the number of arguments passed to the user-defined system task or function. minargs=number Specifies the minimum number of arguments. maxargs=number Specifies the maximum number of arguments.
nocelldefinepli Disables the dumping of value change and simulation time data of modules defined under the celldefine compiler directive into a VPD file created by the $vcdpluson system task. This capability is only used for batch simulation. persistent Checks if the specified function is defined in the PLI application, even if the corresponding system task or function is not used in the Verilog file. If the function is not found or defined in the PLI application, VCS exits with an undefined reference error message. Note that if you use the -debug, -debug_all, or -debug_pp options during compilation, VCS performs these checks on every function mapped in the tab file. To ignore this check, which is enabled by the above debug options or the persistent specification, set the PERSISTENT_FLAG environment variable to 1. Example 1
$val_proc call=val_proc check=check_proc misc=misc_proc
In this line, VCS calls the function named val_proc when it executes the associated user-defined system task named $val_proc. It calls the check_proc function at compile-time to see if the user-defined system task has the correct syntax, and calls the misc_proc function in special circumstances like interrupts. Example 2
$set_true size=16 call=set_true
In this line, there is an associated user-defined system function that returns a 15-bit return value. VCS calls the function named set_true when it executes this system function. Note: Do not enter blank spaces inside a PLI specification. The following copy of the last example of PLI specifications does not work:
$set_true size = 16 call = set_true
Access Capabilities You can specify access capabilities in a PLI table file for the following reasons: PLI functions associated with your user-defined system task or system function. To do this, specify the access capabilities on a line in a PLI table file after the name of the user-defined system task or system function and its PLI specifications. See Specifying Access Capabilities for PLI Functions on page 11 for more details. For the debugging features VCS can use. To do this, specify access capabilities alone on a line in a PLI table file, without an associated user-defined system task or system function. See Specifying Access Capabilities for VCS Debugging Features on page 16 for more details.
In many ways, specifying access capabilities for your PLI functions, and specifying them for VCS debugging features, is the same. However, the capabilities that you enable, and the parts of the design to which you can apply them are different.
Specifying Access Capabilities for PLI Functions The format for specifying access capabilities is as follows:
acc=|+=|-=|:=capabilities:module_names[+]|%CELL|%TASK|*
Here: acc Keyword that begins a line for specifying access capabilities. =|+=|-=|:= Operators for adding, removing, or changing access capabilities. The operators in this syntax are as follows: = A shorthand for +=. += Specifies adding the access capabilities that follow to the parts of the design that follow, as specified by module name, %CELL,%TASK, or * wildcard character. -= Specifies removing the access capabilities that follow from the parts of the design that follow, as specified by module name, %CELL,%TASK, or * wildcard character. :=
Specifies changing the access capabilities of the parts of the design that follow, as specified by module name, %CELL,%TASK, or * wildcard character, to only those in the list of capabilities on this specification. A specification with this operator can change the capabilities specified in a previous specification. capabilities Comma-separated list of access capabilities. The capabilities that you can specify for the functions in your PLI specifications are as follows: r or read Reads the values of nets and registers in your design. rw or read_write Both reads from and writes to the values of registers or variables (but not nets) in your design. wn Enables writing values to nets. cbk or callback To be called when named objects (nets registers, ports) change value. cbka or callback_all To be called when named and unnamed objects (such as primitive terminals) change value. frc or force Forces values on nets and registers.
C Language Interface 20-12
prx or pulserx_backannotation Sets pulse error and pulse rejection percentages for module path delays. s or static_info Enables access to static information, such as instance or signal names and connectivity information. Signal values are not static information. tchk or timing_check_backannotation Back-annotates timing check delay values. gate or gate_backannotation Back-annotates delay values on gates. mp or module_path_backannotation Back-annotates module path delays. mip or module_input_port_backannotation Back-annotates delays on module input ports. mipb or module_input_port_bit_backannotation Back-annotates delays on individual bits of module input ports. module_names Comma-separated list of module identifiers (or names). Specifying modules enables, disables, or changes (depending on the operator) the ability of the PLI function to use the access capability in all instances of the specified module.
+ Specifies adding, removing, or changing the access capabilities for not only the instances of the specified modules but also the instances hierarchically under the instances of the specified modules. %CELL Enables, disables, or changes (depending on the operator) the ability of the PLI function to use the access capability in all instances of module definitions compiled under the celldefine compiler directive and all module definitions in Verilog library directories and library files (as specified with the -y and -v analysis options). %TASK Enables, disables, or changes (depending on the operator) the ability of the PLI function to use the access capability in all instances of module definitions that contain the user-defined system task or system function associated with the PLI function. * Enables, disables, or changes (depending on the operator) the ability of the PLI function to use the access capability throughout the entire design. Using wildcard characters could seriously impede the performance of VCS. Note: There are no blank spaces when specifying access capabilities.
The following examples are the PLI specification examples from the previous section with access capabilities added to them. The examples wrap to more than one line, but when you edit your PLI table file, be sure there are no line breaks in these lines. Example 1
$val_proc call=val_proc check=check_proc misc=misc_proc acc+= rw,tchk:top,bot acc-=tchk:top
This example adds the access capabilities for reading and writing to nets and registers, and for back-annotating timing check delays, to these PLI functions, and enables them to do these things in all instances of modules top and bot. It then removes the access capability for back-annotating timing check delay values from these PLI functions in all instances of module top. Example 2
$value_passer size=0 args=2 call=value_passer persistent acc+=rw:%TASK acc-=rw:%CELL
This example adds the access capability to read from and write to the values of nets and registers to these PLI functions. It enables them to do these things in all instances of modules declared in module definitions that contain the $value_passer user-defined system task. The example then removes the access capability to read from and write to the values of nets and registers, from these PLI functions, in module definitions compiled under the celldefine compiler directive and all module definitions in Verilog library directories and library files. Example 3
$set_true size=16 call=set_true acc+=rw:*
This example adds the access capability to read from and write to the values of nets and registers to the PLI functions. It enables them to do this throughout the entire design. Specifying Access Capabilities for VCS Debugging Features The format for specifying these capabilities for VCS debugging features is as follows:
acc=|+=|-=|:=capabilities:module_names[+]|%CELL|*
Here: acc Keyword that begins a line for specifying access capabilities. =|+=|-=|:= Operators for adding, removing, or changing access capabilities. capabilities Comma separated list of access capabilities. module_names Comma-separated list of module identifiers. The specified access capabilities will be added, removed, or changed for all instances of these modules. + Specifies adding, removing, or changing the access capabilities for not only the instances of the specified modules but also the instances hierarchically under the instances of the specified modules.
%CELL Specifies all modules compiled under the celldefine compiler directive and all modules in Verilog library directories and library files (as specified with the -y and -v options.) * Specifies all modules in the design. Using a wildcard character is no more efficient than using the -debug option with vcs. The access capabilities and the interactive commands they enable are as follows:
ACC Capability r or read What it enables your PLI functions to do For specifying reads in your design, it enables commands for performing the following: Creating an alias for another UCLI command (alias) Displaying UCLI help Specifying the radix of displayed simulation values (oformat) Displaying simulation values Descending and ascending the module hierarchy Depositing values on registers Displaying the set breakpoints on signals Displaying the port names of the current location, and the current module instance or scope, in the module hierarchy Displaying the names of instances in the current module instance or scope Displaying the nets and registers in the current scope Moving up the module hierarchy Deleting an alias for another UCLI command
ACC Capability
rw or read_write
For specifying reads and writes in your design but r enables everything that rw does. A longer way to specify this capability is with the read_write keyword. Commands for performing the following: Setting a repeating breakpoint. In other words always halting simulation, when a specified signal changes value Setting a one shot breakpoint. In other words halting simulation the next time the signal changes value but not the subsequent times it changes value Removing a breakpoint from a signal Showing the line number or number in the source code of the statement or statements that causes the current value of a net A longer way to specify this capability is with the callback keyword.
cbk or callback
frc or force
Commands for performing the following: Forcing a net or a register to a specified value so that this value cannot be changed by subsequent simulation events in the design Releasing a net or register from its forced value A longer way to specify this capability is with the force keyword.
Example 1 The following specification enables many interactive commands including those for displaying the values of signals in specified modules and depositing values to the signals that are registers:
acc+=r:top,mid,bot
Notice that there are no blank spaces in this specification. Blank spaces cause a syntax error.
Example 2 The following specifications enable most interactive commands for most of the modules in a design. They then change the ACC capabilities preventing breakpoint and force commands in instances of modules in Verilog libraries and modules designated as cells with the celldefine compiler directive.
acc+=rw,cbk,frc:top+ acc:=rw:%CELL
In this example, the first specification enables the interactive commands that are enabled by the rw, cbk, and frc capabilities for module top, which, in this example, is the top-level module of the design, and all module instances under it. The second specification limits the interactive commands for the specified modules to only those enabled by the rw (same as r) capability.
When you enter this option on the vcs command line, you can also enter C source files, compiled .o object files, or .a libraries on the vcs command line, to specify the PLI application that you want to link with VCS. For example:
vcs -P pli.tab pli.c my_design.v
One advantage to entering .o object files and .a libraries is that you do not have to recompile the PLI application every time you compile your design.
Globally
You can enter the +acc+level_number compile-time option to globally enable ACC capabilities throughout your design. Note: Using the +acc+level_number option significantly impedes the simulation performance of your design. Synopsys recommends that you use a PLI table file to enable ACC capabilities for only the parts of your design where you need them. For more details on doing this, see PLI Table File on page 6. The level_number in this option specifies additional ACC capabilities as follows: +acc+1 or +acc Enables all capabilities except value change callbacks and delay annotation.
+acc+2 Above, plus value change callbacks. +acc+3 Above, plus module path delay annotation. +acc+4 Above, plus gate delay annotation.
The VCS configuration file enables you to enter statements that specify: Using the optimizations of Radiant Technology on part of a design Enabling PLI ACC write capabilities for all memories in the design, disabling them for the entire design, or enabling them for part or parts of the design hierarchy Four state simulation for part of a design
The entries in the configuration file override the ACC write-enabling entries in the PLI table file. The syntax of each type of statement in the configuration file to enable ACC write capabilities is as follows:
set writeOnMem;
or
set noAccWrite;
or
module {list_of_module_identifiers} {accWrite};
or
instance {list_of_module_instance_hierarchical_names} {accWrite};
or
tree [(depth)] {list_of_module_identifiers} {accWrite};
or signal {list_of_signal_hierarchical_names} {accWrite}; Here: set Keyword preceding a property that applies to the entire design. writeOnMem Enables ACC write to memories (any single or multi-dimensional array of the reg data type) throughout the entire design. noAccWrite Disables ACC write capabilities throughout the entire design. accWrite
Enables ACC write capabilities. module Keyword specifying that the accWrite attribute in this statement applies to all instances of the modules in the list, specified by module identifier. list_of_module_identifiers Comma-separated list of module identifiers (also called module names). instance Keyword specifying that the accWrite attribute in this statement applies to all instances in the list. list_of_module_instance_hierarchical_names Comma-separated list of module instance hierarchical names. Note: Follow the Verilog syntax for signal names and hierarchical names of module instances. tree Keyword specifying that the accWrite attribute in this statement applies to all instances of the modules in the list, specified by module identifier, and also applies to all module instances hierarchically under these module instances.
depth An integer that specifies how far down the module hierarchy from the specified modules you want to apply the accWrite attribute. You can specify a negative value. A negative value specifies descending to the leaf level and counting up levels of the hierarchy to apply these attributes. This specification is optional. Enclose this specification in parentheses: () signal Keyword specifying that the accWrite attribute in this statement applies to all signals in the list. list_of_signal_hierarchical_names Comma-separated list of signal hierarchical names.
3. Simulate again with a simv executable in which only the ACC capabilities you need are enabled. Learning What Access Capabilities are Used You include the +vcs+learn+pli runtime option to tell VCS to learn the access capabilities that were used by the modules in your design and write them into a secondary PLI table file named, pli_learn.tab. This file is considered a secondary PLI table file because it does not replace the first PLI table file that you used (if you used one). This file does, however, modify whatever access capabilities are specified in a first PLI table file, or other means of specifying access capabilities, so that you enable only the capabilities you need in subsequent simulations. You should look at the contents of the pli_learn.tab file that VCS writes to see what access capabilities were actually used during simulation. The following is an example of this file:
////////////////// SYNOPSYS INC //////////////// // PLI LEARN FILE // AUTOMATICALLY GENERATED BY VCS(TM) LEARN MODE //////////////////////////////////////////////// acc=r:testfixture //SIGNAL STIM_SRLS:r acc=rw:SDFFR //SIGNAL S1:rw
The following line in this file specifies that during simulation, the read capability was needed for signals in the module named testfixture.
acc=r:testfixture //SIGNAL STIM_SRLS:r
The comment lets you know that the only signal for which this capability was needed was the signal named, STIM_SRLS. This line is in the form of a comment because the syntax of the PLI table file does not permit specifying access capabilities on a signal-by-signal basis. The following line in this file specifies that during simulation, the read and write capabilities were needed for signals in the module named, SDFFR, specifically for the signal named S1.
acc=rw:SDFFR //SIGNAL S1:rw
Signs of a Potentially Significant Performance Gain You might see one of following comments in the pli_learn.tab file:
//!VCS_LEARNED: NO_ACCESS_PERFORMED
This indicates that none of the enabled access capabilities were used during the simulation.
//!VCS_LEARNED: NO_DYNAMIC_ACCESS_PERFORMED
This indicates that only static information was accessed through access capabilities and there was no value change information during simulation. These comments indicate that there is a potentially significant performance gain when you apply the access capabilities in the pli_learn.tab file.
Compiling to Enable Only the Access Capabilities You Need After you have run the simulation to learn what access capabilities were actually used by your design, you can then recompile the design with the information you have learned, so the resulting simv executable uses only the access capabilities you require. When you recompile your design, include the +applylearn compile-time option. If, for some reason, you renamed the pli_learn.tab file that VCS writes when you include the +vcs+learn+pli runtime option, specify the new filename in the compile-time option by appending it to the option with the following syntax:
+applylearn+filename
When you recompile your design with the +applylearn compile-time option, it is important that you also re-enter all the compile-time options that you used for the previous compilation. For example, if in a previous compilation, you specified a PLI table file with the -P compile-time option, specify this PLI table file again, using the -P option, along with the +applylearn option. Note: If you change your design after VCS writes the pli_learn.tab file, and you want to make sure that you are using only the access capabilities you need, you will need to have VCS write another one, by including the +vcs+learn+pli runtime option and then compiling your design again with the +applylearn option.
Limitations VCS is not able maintain a history of all access capabilities. However, the capabilities it does maintain, and specify in the pli_learned.tab file, are as follows: r - read rw - read and write cbk - callbacks cbka - callback all including unnamed objects frc - forcing values on signals
The +applylearn compile-time option does not work if you also use either the +multisource_int_delays or +transport_int_delays compile-time option, because interconnect delays need global access capabilities. If you enter the +applylearn compile-time option more than once on the vcs command line, VCS ignores all instances, except for the first occurrence.
+nocelldefinepli+1+ports Removes the PLI caps from `celldefine modules and allows PLI access to port nodes and parameters. +nocelldefinepli+2+ports Removes the PLI caps from library and celldefine modules and allows PLI access to port nodes and parameters.
Example
Following is a sample Verilog code in which the dut is a cell define module. test.sv
`celldefine module ram (Addr, Data, CS, WE, OE); parameter AddrSize = 4; parameter WordSize = 1; input [AddrSize-1:0] Addr; inout [WordSize-1:0] Data; input CS, WE, OE; reg [WordSize-1:0] Mem [0:1<<AddrSize]; assign Data = (!CS && !OE) always @(CS or WE) if (!CS && !WE) Mem[Addr] = Data; endmodule `endcelldefine module ramTop; ? Mem[Addr] : {WordSize{1'bz}};
reg [7:0] addr; wire [7:0] data; reg cs, we, oe; reg [7:0] data_temp; ram #(8,8) dut (addr, data, cs, we, oe);
assign data = (!cs && !we) ? data_temp : data; initial begin $vcdpluson; $vcdplusmemon; repeat (10) begin #10; { cs, we, oe} = {$urandom%2, $urandom%2, $urandom%2}; addr = {$urandom%2, $urandom%2, $urandom%2, $urandom%2, $urandom%2, $urandom%2, $urandom%2, $urandom%2}; data_temp = {$urandom%2, $urandom%2, $urandom%2, $urandom%2, $urandom%2, $urandom%2, $urandom%2, $urandom%2}; end end endmodule
Visualization in DVE
In the following illustration, you can see that Mem which is an internal signal for the ram module is not shown in the Data pane anymore. However other signals, which are ports or parameters, are visible.
Ports
Parameters
Limitations Only Direct Kernel Interface (DKI) applications can access the ports, PLI applications cannot access.
The header file for the VPI routines is $VCS_HOME/include/ vpi_user.h. You can register your user-defined system tasks/function-related callbacks using the vpi_register_systf VPI routine, see Support for the vpi_register_systf Routine on page 33. You can also use a PLI .tab file to associate your user-defined system tasks with your VPI routines, see PLI Table File for VPI Routines on page 36.
VPI callbacks reasons cbForce and cbRelease are now supported with the following limitations: The force and release commands generates a callback only if cb_data_p > obj is a valid handle. If it is set to NULL, it doesnt generate a callback. For cbForce, cbRelease, cbAssign, and cbDeassign callbacks, the handle that you supplied while registering the callback is returned and not the corresponding statement handle [NULL handles are not allowed].
For more information about the VPI callbacks, see the section Simulation-event-related callbacks in the Verilog IEEE LRM 13642001.
In this example: The routine named register_me is externally declared. It is also included in the array named vlog_startup_routines. The last entry in the array is zero.
You specify this file with the -use_vpiobj compilation option. For example:
% vcs top.v -use_vpiobj vpi_user.c +vpi
You can also write a PLI table file for VPI routines. See PLI Table File for VPI Routines .
You do not have to specify the path name of the shared library, if that path is part of your LD_LIBRARY_PATH environment variable. The following are some examples of using this option: -load lib1.so:my_register
The my_register() routine is in lib1.so. The location of lib1.so is in the LD_LIBRARY_PATH environment variable. -load lib1.so:my_register,new_register The registration routines my_register() and new_register() are in lib1.so. The location of lib1.so is in the LD_LIBRARY_PATH environment variable. -load lib1.so:my_register -load lib2.so:new_register The registration routine my_register() is in lib1.so and the second registration routine new_register() is in lib2.so. The path to both of these libraries are in the LD_LIBRARY_PATH environment variable. You can enter more than one -load option to specify multiple shared libraries and their registration routines. -load lib1.so:my_register The registration routine my_register() is in lib1.so. The location of lib1.so is in the LD_LIBRARY_PATH environment variable. -load /usr/lib/mylib.so:my_register The registration routine my_register() is in lib1.so, which is in /usr/lib/mylib.so, and not in the LD_LIBRARY_PATH environment variable.
Note that this entry includes acc= even though the C functions in the PLI specification call VPI routines instead of PLI 1.0 routines. The syntax has not changed; you use the same syntax for enabling PLI 1.0 and PLI 2.0 routines. This PLI table file is used for an example file named set_mipd_delays_vpi.c, which is available with The Verilog PLI Handbook by Stuart Sutherland, Kluwer Academic Publishers, Boston, Dordrect, and London.
To debug the Virtual Interface objects, the VPI properties defined in the SystemVerilog LRM, such as vpiVirtual, vpiActual, and vpiInterfaceDecl, are supported. For more information about these properties, see the IEEE SystemVerilog LRM.
Example
The following example show the VPI routines usage for Virtual Interface Debug: virtual_interface.sv
interface ifc (input logic clk); event reset; int ifci; modport tracker (input clk); endinterface: ifc package p; class C; VI declared in Class scope
function new (virtual ifc inf); busIF = inf; endfunction // new function test(virtual ifc inf); busIF = inf; $display("hello"); endfunction: test endclass: C endpackage: p
module mod( input logic clk); import p::*; ifc trkIF(.clk(clk)); VI declared in Module scope virtual ifc modbusIF = trkIF; virtual ifc.tracker modportIF2; C c; initial begin `ifdef DUMP $vcdpluson; `endif c = new(trkIF); c.test(modbusIF); modbusIF.ifci <= 10; #1 $getVar; $display("end the first round\n"); #1 modbusIF.ifci <= 11; $getVar; $display("end the second round."); end endmodule: mod
pli.c
#include #include #include #include <stdio.h> <stdlib.h> "vcs_vpi_user.h" "sv_vpi_user.h"
void traverse(){ vpiHandle Han, iterHan, scanHan, cls, obj, intfHan, Href, Hactual; vpi_configure(vpiDisplayWarnings,"true"); intfHan = vpi_handle_by_name("mod.vbusIF",NULL); vpi_printf("\tVAR `%s'\n", vpi_get_str(vpiName,intfHan ));
vpi_printf("\t--- DefName `%s'\n\t--- FullName:%s\n\t-- vpiType:%s\n", vpi_get_str(vpiDefName,intfHan ), vpi_get_str(vpiFullName,intfHan ), vpi_get_str(vpiType,intfHan )); if(vpi_get(vpiVirtual, intfHan)){ vpi_printf("\t%s is Virtual Interface\n",vpi_get_str(vpiName,intfHan )); } Hactual = vpi_handle(vpiActual, intfHan); if ( Hactual ) { vpi_printf("\n\tActual `%s'\n", vpi_get_str(vpiName,Hactual)); vpi_printf("\t--- DefName `%s'\n\t--- FullName:%s\n\t-- vpiType:%s\n", vpi_get_str(vpiDefName,Hactual), vpi_get_str(vpiFullName,Hactual), vpi_get_str(vpiType,Hactual)); if(vpi_get(vpiVirtual, Hactual)){ vpi_printf("\tActual Handle is Virtual Interface\n"); } } }
pli.tab
$getVar call=traverse acc+=r:* acc+=cbk:*
To view how the virtual interface objects appear in DVE, see the DVE User Guide.
Limitations
Virtual Interface passed as a method port is not shown in DVE. Virtual Interface as an array is not supported. Virtual Interface debugging is not supported in UCLI. $vcdplustblog and $vcdplusmsglog do not dump Virtual Interface.
- Cannot retrieve the value of VPI operators (expressions) unless they are arguments to system tasks or system functions. - Cannot retrieve the value of UDP table entries (vpiVectorVal not implemented). vpi_put_value Cannot set the value of var select objects (diagram 26.6.8 Variables) and primitive objects (diagram 26.6.13 Primitive, prim term). vpi_get_delays Cannot retrieve the values of continuous assign objects (diagram 26.6.24 Continuous assignment) or procedurally assigned objects. vpi_put_delays Cannot put values on continuous assign objects (diagram 26.6.24 Continuous assignment) or procedurally assigned objects. vpi_register_cb Cannot register the following types of callbacks that are defined for this routine:
cbEndOfSimulation cbTchkViolation cbError cbSignal cbPliError
Also, the cbValueChange callback is not supported for the following objects: - A memory or a memory word (index or element) - VarArray or VarSelect
Using DirectC
DirectC is an extended interface between Verilog and C/C++. It is an alternative to the PLI that, unlike the PLI, enables you to do the following: More efficiently pass values between Verilog module instances and C/C++ functions by calling the functions directly, along with actual parameters, in your Verilog code. Pass more types of data between Verilog and C/C++. With the PLI, you can only pass Verilog information to and from a C/C++ application. With DirectC you do not have this limitation.
With DirectC, for example, you can model a simulation environment for your design in C/C++ in which you can pass pointers from the environment to your design and store them in Verilog signals, and at a later simulation time, pass these pointers to the simulation environment. Similarly, you can use DirectC to develop applications to run with VCS to which you can pass pointers to the location of simulation values for your design. DirectC is an alternative to, but not a replacement for, the PLI. You can do things with the PLI that you cannot do with DirectC. For example, there are PLI TF and ACC routines to implement a callback to start a C/C++ function when a Verilog signal changes value. You cannot do this with DirectC.
You can use Direct C/C++ function calls for existing and proven C code as well as C/C++ code that you write in the future. You can also use them without much rewriting of, or additions to, your Verilog code. You call them the same way you call (or enable) a Verilog function or Verilog task. This section describes the DirectC interface in the following sections: Using Direct C/C++ Function Calls Using Direct Access Using Abstract Access Enabling C/C++ Functions Extended BNF for External Function Declarations
DirectC allows the invocation of C++ functions that are declared in C++ using the extern "C" linkage directive. The extern "C" directive is necessary to protect the name of the C++ function from being mangled by the C++ compiler. Plain C functions do not undergo mangling, and therefore, do not need any special directive. The declaration of these functions involves specifying a direction for the parameters of the C function, because, in the Verilog environment, they become analogous to Verilog tasks as well as functions. Verilog tasks are similar to void C functions in that they do not return a value. However, Verilog tasks do have input, output, and inout arguments, whereas C function parameters do not have explicitly declared directions. See Declaring the C/C++ Function . There are two access modes for C/C++ function calls. These modes do not make much difference in your Verilog code; they only pertain to the development of the C/C++ function. They are as follows: The slightly more efficient direct access mode - this mode has rules for how values of different types and sizes are passed to and from Verilog and C/C++. This mode is explained in detail in the section, Using Direct Access . The slightly less efficient, but with better error handling abstract access mode - in this implementation, VCS creates a descriptor for each actual parameter of the C function. You access these descriptors using a specially defined pointer called a handle. All formal arguments are handles. DirectC comes with a library of accessory functions for using these handles. This mode is explained in detail in the section, Using Abstract Access .
The abstract access library of accessory functions contains operations for reading and writing values and for querying about argument types, sizes, etc. An alternative library, with perhaps different levels of security or efficiency, can be developed and used in abstract access without changing your Verilog or C/C++ code. If you have an existing C/C++ function that you want to use in a Verilog design, you consider using direct access and see if you really need to edit your C/C++ function or write a wrapper so that you can use direct access inside the wrapper. There is a small performance gain by using direct access compared to abstract access. If you are about to write a C/C++ function to use in a Verilog design, first decide how you wish to use it in your Verilog code and write the external declaration for it, then decide which access mode you want. You can change the mode later with perhaps a small change in your Verilog code. Using abstract access is safer because the library of accessory functions for abstract access has error messages to help you to debug the interface between C/C++ and Verilog. With direct access, errors simply result in segmentation faults, memory corruption, etc. Abstract access can be generalized more easily for your C/C++ function. For example, with open arrays you can call the function with 8-bit arguments at one point in your Verilog design and call it again some place else with 32-bit arguments. The accessory functions can manage the differences in size. With abstract access you can have the size of a parameter returned to you. With direct access you must know the size.
Note: In two-state simulation, a reg has a new name, bit. - The value of the C type int - A pointer - A short, 32 bits or less, vector bit
- The value of a Verilog real which is represented by the C type double So C/C++ functions cannot return the value of a four-state vector reg, long (longer than 32 bits) vector bit, or Verilog integer, realtime, or time data type. You can pass these type of values out of the C/C++ function using a parameter that you declare to be inout or output in the declaration of the function in your Verilog code.
extern_declaration ::= extern access_mode ? attribute ? return_type function_id (extern_func_args ? ) ; access_mode attribute return_type ::= ( "A" | "C" ) ::= pure ::= void | reg | bit | DirectC_primitive_type | small_bit_vector ::= bit [ (constant_expression : constant_expression ) ] ::= extern_func_arg ( , extern_func_arg ) * ::= arg_direction ? arg_type arg_id ? ::= input | output | inout ::= bit_or_reg_type | array_type | DirectC_primitive_type ::= ( bit | reg ) optional_vector_range ?
optional_vector_range ::= [ ( constant_expression : constant_expression ) ? ] array_type ::= bit_or_reg_type array [ (constant_expression : constant_expression ) ? ]
Here: extern Keyword that begins the declaration of the C/C++ function declaration. access_mode Specifies the mode of access in the declaration. Enter C for direct access, or A for abstract access. Using this entry enables some functions to use direct access and others to use abstract access. attribute An optional attribute for the function. The pure attribute enables some optimizations. Enter this attribute if the function has no side effects and is dependent only on the values of its input parameters. return_type The valid return types are int, bit, reg, string, pointer, and void. See Table 20-1 for a description of what these types specify. small_bit_vector Specifies a bit-width of a returned vector bit. A C/C++ function cannot return a four-state vector reg, but it can return a vector bit if its bit-width is 32 bits or less. function_id The name of the C/C++ function. direction
C Language Interface 20-48
One of the following keywords: input, output, inout. In a C/ C++ function, these keywords specify the same thing that they specify in a Verilog task; see Table 20-2. arg_type The valid argument types are real, reg, bit, int, pointer, string. [bit_width] Specifies the bit-width of a vector reg or bit that is an argument to the C/C++ function. You can leave the bit-width open by entering []. array Specifies that the argument is a Verilog memory. [index_range] Specifies a range of elements (words, addresses) in the memory. You can leave the range open by entering []. arg_id The Verilog register argument to the C/C++ function that becomes the actual parameter to the function.
Note: Argument direction (i.e., input, output, inout) applies to all arguments that follow it until the next direction occurs; the default direction is input. Table 20-1
int bit reg string pointer void
Return Type
Table 20-2
keyword input
output inout
Table 20-3
real reg bit int
keyword
pointer string
Example 1
extern "A" reg return_reg (input reg r1);
This example declares a C/C++ function named return_reg. This function returns the value of a scalar reg. When we call this function, the value of a scalar reg named r1 is passed to the function. This function uses abstract access. Example 2
extern "C" bit [7:0] return_vector_bit (bit [7:0] r3);
This example declares a C/C++ function named return_vector_bit. This function returns an 8-bit vector bit (a reg in two state simulation). When we call this function, the value of an 8-bit vector bit (a reg in two state simulation) named r3 is passed to the function. This function uses direct access.
The keyword input is omitted. This keyword can be omitted if the first argument specified is an input argument. Example 3
extern string return_string();
This example declares a C/C++ function named return_string. This function returns a character string and takes no arguments. Example 4
extern void receive_string( input string r5);
This example declares a C/C++ function named receive_string. It is a void function. At some time earlier in the simulation, another C/ C++ function passed the address of a character string to reg r5. When we call this function, it reads the address in reg r5. Example 5
extern pointer return_pointer();
This example declares a C/C++ function named return_pointer. When we call this function, it returns a pointer. Example 6
extern void receive_pointer (input pointer r6);
This example declares a C/C++ function named receive_pointer. When we call this function the address in reg r6 is passed to the function. Example 7
extern void memory_reorg (input bit [32:0] array [7:0] mem2, output bit [32:0] array [7:0] mem1);
This example declares a C/C++ function named memory_reorg. When we call this function, the values in memory mem2 are passed to the function. After the function executes, new values are passed to memory mem1. Example 8
extern void incr (inout bit [] r7);
This example declares a C/C++ function named incr. When we call this function, the value in bit r7 is passed to the function. When it finishes executing, it passes a new value to bit r7. We did not specify a bit width for vector bit r7. This allows us to use various sizes in the parameter declaration in the C/C++ function header. Example 9
extern void passbig (input bit [63:0] r8, output bit [63:0] r9);
This example declares a C/C++ function named passbig. When we call this function, the value in bit r8 is passed by reference to the function because it is more than 32 bits; see Using Direct Access on page 62. When it finishes executing, a new value is passed by reference to bit r9.
You call a non-void (returns a value) C/C++ function in the same manner as you call a Verilog function call, that is, by entering its name and arguments, either in an expression on the RHS of a procedural assignment statement in an always or initial block, or in a Verilog task or function declaration. Examples
r2=return_reg(r1);
The value of scalar reg r1 is passed to C/C++ function return_reg. It returns a value to reg r2.
r4=return_vector_bit(r3);
The value of vector bit r3 is passed to C/C++ function return_vector_bit. It returns a value to vector bit r4.
r5=return_string();
The address pointed to in a pointer in C/C++ function return_pointer is passed to reg r6.
get_pointer(r6);
memory_reorg(mem1,mem2);
In this example, all the values in memory mem2 are passed to C/C++ function memory_reorg, and when it finishes executing, it passes new values to memory mem1.
incr(r7);
In this example, the value of bit r7 is passed to C/C++ function incr, and when it finishes executing, it passes a new value to bit r7.
When a routine returns Verilog data to a C/C++ function, how that data is stored depends on whether it is from a two-state or four-state value, and whether it is from a scalar, a vector, or from an element in a Verilog memory.
For a four-state vector (denoted by the keyword reg), the Verilog data is stored in type vec32, which for abstract access is defined as follows:
typedef unsigned int U; typedef struct { U c; U d;} vec32;
So, type vec32* has two members of type U; member c is for control bits and member d is for data bits. For a two-state vector bit, the Verilog data is stored in type U*. Vector values are stored in arrays of chunks of 32 bits. For four-state vectors there are chunks of 32 bits for data values and 32 bits for control values. For two-state vectors, there are chunks of 32 bits for data values. Figure 20-1 Storing Vector Values
two-state data
Long vectors, more than 32 bits, have their value stored in more than one group of 32 bits and can be accessed by chunk. Short vectors, 32 bits or less, are stored in a single chunk.
For long vectors, the chunk for the least significant bits come first, followed by the chunks for the more significant bits. Figure 20-2 Storing Vector Values of More than 32 Bits four-state
control data control data
two-state
data data data data
In an element in a Verilog memory, for each eight bits in the element, there is a data byte and a control byte with an additional set of bytes for remainder bit. So, if a memory had 9 bits, it would need two data bytes and two control bytes. If it had 17 bits, it would need three data bytes and three control bytes. All the data bytes precede the control bytes. Two-state memories have both data and control bytes, but the bits in the control bytes always have a zero value. Figure 20-3 Storing Verilog Memory Elements in Machine Memory
data data data control control control
Converting Strings
There are no *true* strings in Verilog, and a string literal, like "some_text," is just a notation for vectors of bits, based on the same principle as binary, octal, decimal, and hexadecimal numbers. So there is a need for a conversion between the two representations of "strings": the C-style representation (which actually is a pointer to the sequence of bytes terminated with null byte) and the Verilog vector encoding a string.
C Language Interface 20-57
DirectC comes with the vc_ConvertToString() routine that you can use to convert a Verilog string to a C string. Its syntax is as follows:
void vc_ConvertTo String(vec32 *, int, char *)
There are scenarios in which a string is created on the Verilog side and is passed to C code, and therefore, has to be converted from Verilog representation to C representation. Consider the following example:
extern void WriteReport(string result_code, .... /* other stuff */);
This call causes a core dump because the function expects a pointer and gets some random bits instead. It may happen that a string, or different strings, are assigned to a signal in Verilog code and their values are passed to C. For example:
task DoStuff(...., result_code); ... output reg [100*8:1]
C Language Interface 20-58
result_code; begin . . . if (...) result_code = "Bus error"; . . . if (...) result_code = "Erroneous address"; . . . else result_code = "Completed"); end endtask
There are two solutions: Solution 1: Write a C wrapper function, pass "message" to this function and perform the conversion of vector-to-C string in C, calling vc_ConvertToString. Solution 2: Perform the conversion on the Verilog side. This requires some additional effort, as the memory space for a C string has to be allocated as follows:
extern "C" string malloc(int); extern "C" void vc_ConvertToString(reg [], int, string);
// this function comes from DirectC library reg [31:0] sptr; . . . // allocate memory for a C-string sptr = malloc(8*100+1); //100 is the width of 'message', +1 is for NULL terminator // perform conversion vc_ConvertToString(message, 800, sptr); WriteReport(sptr, ...);
pythag.c
#include <stdio.h> void pythag(double *p) { printf ("Passed real value from verilog p=%f \n",*p); }
You can try out this example with the following command-line:
vcs +vc main.v pythag.c -R -l somv.log
Some of these type identifiers are standard C/C++ types; those that are not, were defined with the following typedef statements:
typedef typedef typedef typedef unsigned int U; unsigned char UB; unsigned char scalar; struct {U c; U d;} vec32;
The type identifier you use depends on the corresponding argument direction, type, and bit-width that you specified in the declaration of the function in your Verilog code. The following rules apply: Direct access passes all output and inout arguments by reference, so their corresponding formal parameters in the C/C++ function must be pointers. Direct access passes a Verilog bit by value only if it is 32 bits or less. If it is larger than 32 bits, direct access passes the bit by reference so the corresponding formal parameters in the C/C++ function must be pointers if they are larger than 32 bits. Direct access passes a scalar reg by value. It passes a vector reg direct access by reference, so the corresponding formal parameter in the C/C++ function for a vector reg must be a pointer.
An open bit-width for a reg makes it possible for you to pass a vector reg, so the corresponding formal parameter for a reg argument, specified with an open bit-width, must be a pointer. Similarly, an open bit-width for a bit makes it possible for you to pass a bit larger than 32 bits, so the corresponding formal parameter for a bit argument specified with an open bit width must be a pointer. Direct access passes by value the following types of input arguments: int, string, and pointer. Direct access passes input arguments of type real by reference.
The following tables show the mapping between the data types you use in the C/C++ function and the arguments you specify in the function declaration in your Verilog code. Table 20-4 For Input Arguments
C/C++ formal parameter data type int double* void* char* scalar scalar U Passed by value reference value value value value value reference reference reference
argument type int real pointer string bit reg bit [] - 1-32 bit wide vector
bit [] - open vector, any vector wider than U* 32 bits reg [] - 1-32 bit wide vector array [] - open vector, any vector wider than 32 bits vec32* UB*
Table 20-5
argument type int real pointer string bit reg bit [] - any vector, including open vector reg[] - any vector, including open vector
In direct access, the return value of the function is always passed by value. The data type of the returned value is the same as the input argument. Example 1 Consider the following C/C++ function declared in the Verilog source code:
extern reg return_reg (input reg r1);
In this example, the function named return_reg returns the value of a scalar reg. The value of a scalar reg is passed to it. The header of the C/C++ function is as follows:
extern "C" scalar return_reg(scalar reti); scalar return_reg(scalar reti);
Note: The extern "C" directive has been omitted in subsequent examples, for brevity. A scalar reg is passed by value to the function so the parameter is not a pointer. The parameters type is scalar. Example 2 Consider the following C/C++ function declared in the Verilog source code:
extern "C" bit [7:0] return_vector_bit (bit [7:0] r3);
In this example, the function named return_vector_bit returns the value of a vector bit. The "C" entry specifies direct access. Typically, a declaration includes this when some other functions use abstract access. The value of an 8-bit vector bit is passed to it. The header of the C/C++ function is as follows:
U return_vector_bit(U returner);
A vector bit is passed by value to the function because the vector bit is less than 33 bits so the parameter is not a pointer. The parameters type is U.
Example 3 Consider the following C/C++ function declared in the Verilog source code:
extern void receive_pointer ( input pointer r6 );
In this example, the function named receive_pointer does not return a value. The argument passed to it is declared to be a pointer. The header of the C/C++ function is as follows:
void receive_pointer(*pointer_receiver);
A pointer is passed by value to the function so the parameter is a pointer of type void, a generic pointer. In this example, we dont need to know the type of data that it points to. Example 4 Consider the following C/C++ function declared in the Verilog source code:
extern void memory_rewriter (input bit [1:0] array [1:0] mem2, output bit [1:0] array [1:0] mem1);
In this example, the function named memory_rewriter has two arguments, one declared as an input, the other as an output. Both arguments are bit memories. The header of the C/C++ function is as follows:
void memory_rewriter(UB *out[2],*in[2]);
Memories are always passed by reference to a C/C++ function so the parameter named in is a pointer of type UB with the size that matched the memory range. The parameter named out is also a pointer, because its corresponding argument is declared to be output. Its type is also UB because it outputs to a Verilog memory. Example 5 Consider the following C/C++ function declared in the Verilog source code:
extern void incr (inout bit [] r7);
In this example, the function named incr, that does not return a value, has an argument declared as inout. No bit-width is specified, but the [] entry for the argument specifies that it is not a scalar bit. The header of the C/C++ function is as follows:
void incr (U *p);
Open bit-width parameters are always passed to by reference. A parameter whose corresponding argument is declared to be inout is passed to and from by reference. So there are two reasons for parameter p to be a pointer. It is a pointer to type U because its corresponding argument is a vector bit. Example 6 Consider the following C/C++ function declared in the Verilog source code:
extern void passbig1 (input bit [63:0] r8, output bit [63:0] r9);
In this example, the function named passbig1, that does not return a value, has input and output arguments declared as bit and larger than 32 bits. The header of the C/C++ function is as follows:
void passbig (U *in, U *out)
In this example, the parameters in and out are pointers to type U. They are pointers because their corresponding arguments are larger than 32 bits and type U because their corresponding arguments are type bit. Example 7 Consider the following C/C++ function declared in the Verilog source code:
extern void passbig2 (input reg [63:0] r10, output reg [63:0] r11);
In this example, the function named passbig2, that does not return a value, has input and output arguments declared as non-scalar reg. The header of the C/C++ function is as follows:
void passbig2(vec32 *in, vec32 *out)
In this example, the parameters in and out are pointers to type vec32. They are pointers because their corresponding arguments are non-scalar type reg. Example 8 Consider the following C/C++ function declared in the Verilog source code:
extern void reality (input real real1, output real real2);
In this example, the function named reality, that does not return a value, has input and output arguments of declared type real. The header of the C/C++ function is as follows:
void reality (double *in, double *out)
In this example, the parameters in and out are pointers to type double because their corresponding arguments are type real.
These declarations contain the /*OUT*/ comment in the parameter specification if its corresponding argument in your Verilog code is of type output in the declaration of the function.
These declarations contain the /*INOUT*/ comment in the parameter specification if its corresponding argument in your Verilog code is of type inout in the declaration of the function. You can copy from these extern declarations to the function headers in your C code. If you do, you will always use the right type of parameter in your function header and you do not have to learn the rules for direct access. Let VCS do this for you.
There are specialized versions of this routine for one-, two-, and three-dimensional arrays:
UB *vc_array1ElemRef(UB*, U) UB *vc_array2ElemRef(UB*, U, U) UB *vc_array3ElemRef(UB*, U, U, U)
U vc_getSize(UB*,U) This routine is similar to the vc_mdaSize() routine used in abstract access. It returns the following: If the U type parameter has a value of 0, it returns the number of indices in an array. If the U type parameter has a value greater than 0, it returns the number of values in the index specified by the parameter. There is an error condition if this parameter is out of the range of indices.
In abstract access, VCS creates a descriptor for every argument that you enter in the function call in your Verilog code. The vc_handle is a pointer to the descriptor for the argument. It is defined as follows:
typdef struct VeriC_Descriptor *vc_handle;
Using vc_handle
In the function header, the vc_handle for a Verilog reg, bit, or memory is based on the order that you declare the vc_handle and the order that you entered its corresponding reg, bit, or memory in the function call in your Verilog code. For example, you could have declared the function and called it in your Verilog code as follows:
extern "A" void my_function( input bit [31:0] r1, input bit [32:0] r2); module dev1; reg [31:0] bit1; reg [32:0] bit2; initial begin
. . .
my_function(bit1,bit2);
. . .
end endmodule
This is using abstract access so VCS created descriptors for bit1 and bit2. These descriptors contain information about their value, but also other information such as whether they are scalar or vector, and whether they are simulating in two- or four-state simulation.
my_function(vc_handle h1, vc_handle h2) { . h1 is the vc_handle for bit1 . h2 is the vc_handle for bit2 up1=vc_2stVectorRef(h1); up2=vc_2stVectorRef(h2); . A routine that accesses the data . structures for bit1 and bit2 using . } their vc_handles
After declaring the vc_handles, you can use them to pass data to and from these descriptors.
The access routines were named to help you to remember their function. Routine names beginning with vc_get are for retrieving data from the descriptor for the Verilog parameter. Routine names beginning with vc_put are for passing new values to these descriptors. These routines can convert Verilog representation of simulation values and strings to string representation in C/C++. Strings can also be created in a C/C++ function and passed to Verilog, but you should keep in mind that they can be overwritten in Verilog. Therefore, you should copy them to local buffers if you want them to persist. The following are the access routines, their parameters, and return values, and examples of how they are used. There is a summary of the access routines at the end of this chapter; see Summary of Access Routines . int vc_isScalar(vc_handle) Returns a 1 value if the vc_handle is for a one-bit reg or bit; returns a 0 value for a vector reg or bit or any memory including memories with scalar elements. For example:
extern "A" void scalarfinder(input input reg input reg input reg module top; reg r1; reg [1:0] r2; reg [1:0] r3 [1:0]; reg r4 [1:0]; initial scalarfinder(r1,r2,r3,r4); endmodule reg r1, [1:0] r2, [1:0] array [1:0] r3, array [1:0] r4);
In this example, we declare a routine named scalarfinder and input a scalar reg, a vector reg and two memories (one with scalar elements). The declaration contains the "A" specification for abstract access. You typically include it in the declaration when other functions will use direct access, that is, you have a mix of functions with direct and abstract access.
#include <stdio.h> #include "DirectC.h" scalarfinder(vc_handle h1, vc_handle h2, vc_handle h3, vc_handle h4) { int i1 = vc_isScalar(h1), i2 = vc_isScalar(h2), i3 = vc_isScalar(h3), i4 = vc_isScalar(h4); printf("\ni1=%d i2=%d i3=%d i4=%d\n\n",i1,i2,i3,i4); }
Parameters h1, h2, h3, and h4 are vc_handles to regs r1 and r2 and memories r3 and r4, respectively. The function prints the following:
i1=1 i2=0 i3=0 i4=0
int vc_isVector(vc_handle) This routine returns a 1 value if the vc_handle is to a vector reg or bit. It returns a 0 value for a vector bit or reg or any memory. For example, using the Verilog code from the previous example, and the following C/C++ function:
scalarfinder(vc_handle h1, vc_handle h2, vc_handle h3, vc_handle h4) {
C Language Interface 20-75
int vc_isMemory(vc_handle) This routine returns a 1 value if the vc_handle is to a memory. It returns a 0 value for a bit or reg that is not a memory. For example, using the Verilog code from the previous example and the following C/C++ function:
#include <stdio.h> #include "DirectC.h" scalarfinder(vc_handle h1, vc_handle h2, vc_handle h3, vc_handle h4) { int i1 = vc_isMemory(h1), i2 = vc_isMemory(h2), i3 = vc_isMemory(h3), i4 = vc_isMemory(h4); printf("\ni1=%d i2=%d i3=%d i4=%d\n\n",i1,i2,i3,i4); }
int vc_is4state(vc_handle) This routine returns a 1 value if the vc_handle is to a reg or memory that simulates with four states. It returns a 0 value for a bit or a memory that simulates with two states. For example, the following Verilog code uses metacomments to specify four- and twostate simulation:
extern void statefinder (input reg r1, input reg [1:0] input reg [1:0] input reg array input bit r5, input bit [1:0] input bit [1:0] input bit array module top; reg /*4value*/ r1; reg /*4value*/ [1:0] r2; reg /*4value*/ [1:0] r3 [1:0]; reg /*4value*/ r4 [1:0]; reg /*2value*/ r5; reg /*2value*/ [1:0] r6; reg /*2value*/ [1:0] r7 [1:0]; reg /*2value*/ r8 [1:0]; initial statefinder(r1,r2,r3,r4,r5,r6,r7,r8); endmodule r2, array [1:0] r3, [1:0] r4, r6, array [1:0] r7, [1:0] r8);
printf("\nh1=%d h2=%d h3=%d h4=%d\n\n", vc_is4state(h1),vc_is4state(h2), vc_is4state(h3),vc_is4state(h4)); printf("\nThe vc_handles to 2state are:"); printf("\nh5=%d h6=%d h7=%d h8=%d\n\n", vc_is4state(h5),vc_is4state(h6), vc_is4state(h7),vc_is4state(h8)); }
int vc_is2state(vc_handle) This routine does the opposite of the vc_is4state routine. For example, using the Verilog code from the previous example and the following C/C++ function:
#include <stdio.h> #include "DirectC.h" statefinder(vc_handle h1, vc_handle h2, vc_handle h3, vc_handle h4, vc_handle h5, vc_handle h6, vc_handle h7, vc_handle h8) { printf("\nThe vc_handles to 4state are:"); printf("\nh1=%d h2=%d h3=%d h4=%d\n\n", vc_is2state(h1),vc_is2state(h2), vc_is2state(h3),vc_is2state(h4)); printf("\nThe vc_handles to 2state are:"); printf("\nh5=%d h6=%d h7=%d h8=%d\n\n", vc_is2state(h5),vc_is2state(h6), vc_is2state(h7),vc_is2state(h8)); }
int vc_is4stVector(vc_handle) This routine returns a 1 value if the vc_handle is to a vector reg. It returns a 0 value if the vc_handle is to a scalar reg, scalar or vector bit, or memory. For example, using the Verilog code from the previous example, and the following C/C++ function:
#include <stdio.h> #include "DirectC.h" statefinder(vc_handle h1, vc_handle h2, vc_handle h3, vc_handle h4, vc_handle h5, vc_handle h6, vc_handle h7, vc_handle h8) { printf("\nThe vc_handle to a 4state Vector is:"); printf("\nh2=%d \n\n",vc_is4stVector(h2)); printf("\nThe vc_handles to 4state scalars or memories and 2state are:"); printf("\nh1=%d h3=%d h4=%d h5=%d h6=%d h7=%d h8=%d\n\n", vc_is4stVector(h1), vc_is4stVector(h3), vc_is4stVector(h4),vc_is4stVector(h5), vc_is4stVector(h6), vc_is4stVector(h7), vc_is4stVector(h8)); }
The vc_handles to 4state scalars or memories and 2state are: h1=0 h3=0 h4=0 h5=0 h6=0 h7=0 h8=0
int vc_is2stVector(vc_handle) This routine returns a 1 value if the vc_handle is to a vector bit. It returns a 0 value if the vc_handle is to a scalar bit, scalar or vector reg, or to a memory. For example, using the Verilog code from the previous example and the following C/C++ function:
#include <stdio.h> #include "DirectC.h" statefinder(vc_handle h1, vc_handle h2, vc_handle h3, vc_handle h4, vc_handle h5, vc_handle h6, vc_handle h7, vc_handle h8) { printf("\nThe vc_handle to a 2state Vector is:"); printf("\nh6=%d \n\n",vc_is2stVector(h6)); printf("\nThe vc_handles to 2state scalars or memories and 4state are:"); printf("\nh1=%d h2=%d h3=%d h4=%d h5=%d h7=%d h8=%d\n\n", vc_is2stVector(h1), vc_is2stVector(h2), vc_is2stVector(h3), vc_is2stVector(h4), vc_is2stVector(h5), vc_is2stVector(h7), vc_is2stVector(h8)); }
int vc_arraySize(vc_handle) Returns the number of elements in a memory or multi-dimensional array. The previous example also shows a usage of vc_arraySize(). scalar vc_getScalar(vc_handle) Returns the value of a scalar reg or bit. For example:
void rotate_scalars(vc_handle h1, vc_handle h2, vc_handle
h3) { scalar a; a = vc_getScalar(h1); vc_putScalar(h1, vc_getScalar(h2)); vc_putScalar(h2, vc_getScalar(h3)); vc_putScalar(h3, a); return; }
void vc_putScalar(vc_handle, scalar) Passes the value of a scalar reg or bit to a vc_handle by reference. The previous example also shows a usage of vc_putScalar(). char vc_toChar(vc_handle) Returns the 0, 1, x, or z character. For example:
void print_scalar(vc_handle h) { printf("%c", vc_toChar(h)); return; }
int vc_toInteger(vc_handle) Returns an int value for a vc_handle to a scalar bit or a vector bit of 32 bits or less. For a vector reg or a vector bit with more than 32 bits this routine returns a 0 value and displays the following warning message:
DirectC interface warning: 0 returned for 4-state value (vc_toInteger)
The following is an example of Verilog code that calls a C/C++ function that uses this routine:
extern void rout1 (input bit onebit, input bit [7:0] mobits); module top; reg /*2value*/ onebit; reg /*2value*/ [7:0] mobits; initial begin rout1(onebit,mobits); onebit=1; mobits=128; rout1(onebit,mobits); end endmodule
Notice that the function declaration specifies that the parameters are of type bit. It includes metacomments for two-state simulation in the declaration of reg onebit and mobits. There are two calls to the function rout1, before and after values are assigned in this Verilog code. The following C/C++ function uses this routine:
#include <stdio.h> #include "DirectC.h" void rout1 (vc_handle onebit, vc_handle mobits) { printf("\n\nonebit is %d mobits is %d\n\n", vc_toInteger(onebit), vc_toInteger(mobits)); }
char *vc_toString(vc_handle) Returns a string that contains the 1, 0, x, and z characters. For example:
extern void vector_printer (input reg [7:0] r1); module test; reg [7:0] r1,r2; initial begin #5 r1 = 8bzx01zx01; #5 vector_printer(r1); #5 $finish; end endmodule
void vector_printer (vc_handle h) { vec32 b,*c; c=vc_4stVectorRef(h); b=*c; printf("\n b is %x[control] %x[data]\n\n",b.c,b.d); printf("\n b is %s \n\n",vc_toString(h)); }
In this example, a vector reg is assigned a value that contains x and z values, as well as, 1 and 0 values. In the abstract access C/C++ function, there are two ways of displaying the value of the reg: Recognize that type vec32 is defined as follows in the DirectC.h file:
typdef struct {U c; U d;} vec32;
In machine memory, there are control, as well as, data bits for Verilog data to differentiate X from 1 and Z from 0 data, so there are c (control) and d (data) data variables in the structure and you must specify which variable when you access the vec32 type. Use the vc_toString routine to display the value of the reg that contains X and Z values.
b is zx01zx01
char *vc_toStringF(vc_handle, char) Returns a string that contains the 1, 0, x, and z characters and allows you to specify the format or radix for the display. The char parameter can be b, o, d, or x. So, if we modify the C/C++ function in the previous example, it is as follows:
void vector_printer (vc_handle h) { vec32 b,*c; c=vc_4stVectorRef(h); b=*c; printf("\n b is %s \n\n",vc_toStringF(h,b)); printf("\n b is %s \n\n",vc_toStringF(h,o)); printf("\n b is %s \n\n",vc_toStringF(h,d)); printf("\n b is %s \n\n",vc_toStringF(h,x)); }
b is XZX
b is X
b is XX
void vc_putReal(vc_handle, double) Passes by reference a real (double) value to a vc_handle. For example:
void get_PI(vc_handle h) { vc_putReal(h, 3.14159265); }
double vc_getReal(vc_handle) Returns a real (double) value from a vc_handle. For example:
void print_real(vc_handle h) { printf("[print_real] %f\n", vc_getReal(h)); }
void vc_putValue(vc_handle, char *) This function passes, by reference, through the vc_handle, a value represented as a string containing the 0, 1, x, and z characters. For example:
extern void check_vc_putvalue(output reg [] r1); module tester; reg [31:0] r1;
In this example, the C/C++ function is declared in the Verilog code specifying that the function passes a value to a four-state reg (and, therefore, can hold X and Z values).
#include <stdio.h> #include "DirectC.h" void check_vc_putvalue(vc_handle h) { vc_putValue(h,"10xz"); }
The vc_putValue routine passes the string "10xz" to the reg r1 through the vc_handle. The Verilog code displays:
r1=10xz
void vc_putValueF(vc_handle, char *, char ) This function passes by reference, through the vc_handle, a value for which you specify a radix with the third parameter. The valid radixes are b, o, d, and x. For example the following Verilog code declares a function named assigner that uses this routine:
extern void assigner (output output output output module test; reg reg reg reg [31:0] [31:0] [31:0] [31:0] r1, r2, r3, r4);
reg [31:0] r1,r2,r3,r4; initial begin assigner(r1,r2,r3,r4); $display("r1=%0b in binary r1=%0d in decimal\n",r1,r1); $display("r2=%0o in octal r2 =%0d in decimal\n",r2,r2); $display("r3=%0d in decimal r3=%0b in binary\n",r3,r3); $display("r4=%0h in hex r4= %0d in decimal\n\n",r4,r4); $finish; end endmodule
void vc_putPointer(vc_handle, void*) void *vc_getPointer(vc_handle) These functions pass a generic type of pointer or string to a vc_handle by reference. Do not use these functions for passing Verilog data (the values of Verilog signals). Use them for passing C/ C++ data instead. vc_putPointer passes this data by reference to Verilog and vc_getPointer receives this data in a pass by reference from Verilog. You can also use these functions for passing Verilog strings. For example:
extern void passback(output string, input string); extern void printer(input pointer); module top; reg [31:0] r2; initial begin passback(r2,"abc"); printer(r2); end endmodule
This Verilog code passes the string "abc" to the passback C/C++ function by reference, and that function passes it by reference to reg r2. The Verilog code then passes it by reference to the C/C++ function printer from reg r2.
passback(vc_handle h1, vc_handle h2) { vc_putPointer(h1, vc_getPointer(h2)); } printer(vc_handle h) { printf("Procedure printer prints the string value %s\n\n",
vc_getPointer (h)); }
void vc_StringToVector(char *, vc_handle) Converts a C string (a pointer to a sequence of ASCII characters terminated with a null character) into a Verilog string (a vector with 8-bit groups representing characters). For example:
extern "C" string FullPath(string filename); // find full path to the file // C string obtained from C domain extern "A" void s2v(string, output reg[]); // string-to-vector // wrapper for vc_StringToVector(). `define FILE_NAME_SIZE 512 module Test; reg [`FILE_NAME_SIZE*8:1] file_name; // this file_name will be passed to the Verilog code that expects // a Verilog-like string . . . initial begin s2v(FullPath("myStimulusFile"), file_name); // C-string to Verilog-string // bits of 'file_name' represent now 'Verilog string' end . . . endmodule
void vc_VectorToString(vc_handle, char *) Converts a vector value to a string value. int vc_getInteger(vc_handle) Same as vc_toInteger. void vc_putInteger(vc_handle, int) Passes an int value by reference through a vc_handle to a scalar reg or bit or a vector bit that is 32 bits or less. For example:
void putter (vc_handle h1, vc_handle h2, vc_handle h3, vc_handle h4) { int a,b,c,d; a=1; b=2; c=3; d=9999999; vc_putInteger(h1,a); vc_putInteger(h2,b); vc_putInteger(h3,c); vc_putInteger(h4,d); }
vec32 *vc_4stVectorRef(vc_handle) Returns a vec32 pointer to a four-state vector. Returns NULL if the specified vc_handle is not to a four-state vector reg. For example:
C Language Interface 20-91
typedef struct vector_descriptor { int width; /* number ofbits */ int is4stte; /* TRUE/FALSE */ } VD; void WriteVector(vc_handle file_handle, vc_handle a_vector) { FILE *fp; int n, size; vec32 *v; VD vd; fp = vc_getPointer(file_handle); /* write vectors size and type */ vd.is4state = vc_is4stVector(a_vector); vd.width = vc_width(a_vector); size = (vd.width + 31) >> 5; /* number of 32-bit chunks */ /* printf("writing: %d bits, is 4 state: %d, #chunks: %d\n", vd.width, vd.is4state, size); */ n = fwrite(&vd, sizeof(vd), 1, fp); if (n != 1) { printf("Error: write failed.\n"); } /* write the vector into a file; vc_*stVectorRef is a pointer to the actual Verilog vector */ if (vc_is4stVector(a_vector)) { n = fwrite(vc_4stVectorRef(a_vector), sizeof(vec32), size, fp); } else { n = fwrite(vc_2stVectorRef(a_vector), sizeof(U), size, fp); } if (n != size) { printf("Error: write failed for vector.\n"); } }
U *vc_2stVectorRef(vc_handle) Returns a U pointer to a bit vector that is larger than 32 bits. If you specify a short bit vector (32 bits or fewer) this routine returns a NULL value. For example:
extern void big_2state( input bit [31:0] r1, input bit [32:0] r2); module test; reg [31:0] r1; reg [32:0] r2; initial begin r1=4294967295; r2=33b100000000000000000000000000000010; big_2state(r1,r2); end endmodule
In this example, the Verilog code declares a 32-bit vector bit, r1, and a 33-bit vector bit, r2. The values of both are passed to the C/C++ function big_2state. When we pass the short bit vector r1 to vc_2stVectorRef, it returns a null value because it has fewer than 33 bits. This is not the case when we pass bit vector r2 because it has more than 32 bits. Notice that from right to left, the first 32 bits of r2 have a value of 2 and the MSB 33rd bit has a value of 1. This is significant in how the C/C++ stores this data.
#include <stdio.h> #include "DirectC.h" big_2state(vc_handle h1, vc_handle h2) { U u1,*up1,u2,*up2; int i;
int size; up1=vc_2stVectorRef(h1); up2=vc_2stVectorRef(h2); if (up1){ /* check for the null value returned to up1 */ u1=*up1;} else{ u1=0; printf("\nShort 2 state vector passed to up1\n"); } if (up2){ /* check for the null value returned to up2 */ size = vc_width (h2); /* to find out the number of bits */ /* in h2 */ printf("\n width of h2 is %d\n",size); size = (size + 31) >> 5; /* to get number of 32-bit chunks */ printf("\n the number of chunks needed for h2 is %d\n\n", size); printf("loading into u2"); for(i = size - 1; i >= 0; i--){ u2=up2[i]; /* load a chunk of the vector */ printf(" %x",up2[i]);} printf("\n");} else{ u2=0; printf("\nShort 2 state vector passed to up2\n");} }
In this example, the short bit vector is passed to the vc_2stVectorRef routine, so it returns a null value to pointer up1. Then the long bit vector is passed to the vc_2stVectorRef routine, so it returns a pointer to the Verilog data for vector bit r2 to pointer up2. It checks for the null value in up1. If it doesnt have a null value, whatever it points to is passed to u1. If it does have a null value, the function prints a message about the short bit vector. In this example, you can expect it to print this message.
Still later in the function, it checks for the null value in up2 and the size of the long bit vector that is passed to the second parameter. Then, because Verilog values are stored in 32-bit chucks in C/C++, the function finds out how many chunks are needed to store the long bit vector. It then loads one chunk at a time into u2 and prints the chunk starting with the most significant bits. This function displays the following:
Short 2 state vector passed to up1 width of h2 is 33 the number of chunks needed for h2 is 2 loading into u2 1 2
void vc_get4stVector(vc_handle, vec32 *) void vc_put4stVector(vc_handle, vec32 *) Passes a four-state vector by reference to a vc_handle to and from an array in C/C++ function. vc_get4stVector receives the vector from Verilog and passes it to the array and vc_put4stVector passes the array to Verilog. These routines work only if there are enough elements in the array for all the bits in the vector. The array must have an element for every 32 bit in the vector plus an additional element for any remaining bits. For example:
extern void copier (input reg [67:0] r1, output reg [67:0] r2); module top; reg [67:0] r1,r2; initial
begin r1 [67:65] = 3b111; r1 [64:33] = 32bzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz; r1 [32:0] = 32b00000000000000000000000000000000; copier(r1,r2); $display("r1=%0b\n",r1); $display("r2=%0b\n",r2); end endmodule
In this example, there are two 68-bit regs. Values are assigned to all the bits of one reg and both of these regs are parameters to the C/ C++ function named copier.
copier(vc_handle h1, vc_handle h2) { vec32 holder[3]; vc_get4stVector(h1,holder); vc_put4stVector(h2,holder); }
This function declares a vec32 array of three elements named holder. It uses three elements because its parameters are 68-bit regs so we need an element for every 32 bits and one more for the remaining four bits. The Verilog code displays the following:
r1=111zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz000000000000000000000000000000000 r2=111zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz000000000000000000000000000000000
void vc_get2stVector(vc_handle, U *) void vc_put2stVector(vc_handle, U *) Passes a two-state vector by reference to a vc_handle to and from an array in C/C++ function. vc_get2stVector receives the vector from Verilog and passes it to the array and vc_put4stVector passes the array to Verilog. There routines, just like the vc_get4stVector and vc_put4stVector routines, work only if there are enough elements in the array for all the bits in the vector. The array must have an element for every 32 bit in the vector plus an additional element for any remaining bits. The only differences between these routines and the vc_get4stVector and vc_put4stVector routines are the type of data they pass, two- or four-state simulation values, and the type you declare for the array in the C/C++ function. UB *vc_MemoryRef(vc_handle) Returns a pointer of type UB that points to a memory in Verilog. For example:
extern void mem_doer ( input reg [1:0] array [3:0] memory1, output reg [1:0] array [31:0] memory2); module top; reg [1:0] memory1 [3:0]; reg [1:0] memory2 [31:0]; initial begin memory1 [3] = 2b11; memory1 [2] = 2b10; memory1 [1] = 2b01; memory1 [0] = 2b00; mem_doer(memory1,memory2);
In this example, we declare two memories, one with 4 addresses, memory1, the other with 32 addresses, memory2. We assign values to the addresses of memory1, and then pass both memories to the C/C++ function mem_doer.
#include <stdio.h> #include "DirectC.h"
void mem_doer(vc_handle h1, vc_handle h2) { UB *p1, *p2; int i; p1 = vc_MemoryRef(h1); p2 = vc_MemoryRef(h2); for ( i = 0; i < 8; i++){ memcpy(p2,p1,8); p2 += 8; } }
The purpose of the C/C++ function mem_doer is to copy the four elements in Verilog memory memory1 into the 32 elements of memory2. The vc_MemoryRef routines return pointers to the Verilog memories and the machine memory locations they point to are also pointed to by pointers p1 and p2. Pointer p1 points to the location of Verilog memory memory1, and p2 points to the location of Verilog memory memory2.
The function uses a for loop to copy the data from Verilog memory memory1 to Verilog memory memory2. It uses the standard memcpy function to copy a total of 64 bytes by copying eight bytes eight times. This example copies a total of 64 bytes because each element of memory2 is only two bits wide, but for every eight bits in an element in machine memory there are two bytes, one for data and another for control. The bits in the control byte specify whether the data bit with a value of 0 is actually 0 or Z, or whether the data bit with a value of 1 is actually 1 or X. Figure 20-4 Storing Verilog Memory Elements in Machine Memory
data data data data control control control control
In an element in a Verilog memory, for each eight bits in the element there is a data byte and a control byte with an additional set of bytes for a remainder bit. So, if a memory had 9 bits it would need two data bytes and two control bytes. If it had 17 bits it would need three data bytes and three control bytes. All the data bytes precede the control bytes. Therefore, memory1 needs 8 bytes of machine memory (four for data and four for control) and memory2 needs 64 bytes of machine memory (32 for data and 32 for control). Therefore, the C/C++ function needs to copy 64 bytes. The Verilog code displays the following:
memory2[31]=3
UB *vc_MemoryElemRef(vc_handle, U indx) Returns a pointer to an element (word, address or index) of a Verilog memory. You specify the vc_handle of the memory and the element. For example:
extern void mem_elem_doer( inout reg [25:1] array [3:0] memory1); module top; reg [25:1] memory1 [3:0]; initial begin memory1 [0] = 25bz00000000xxxxxxxx11111111; $display("memory1 [0] = %0b\n", memory1[0]); mem_add_doer(memory1); $display("\nmemory1 [3] = %0b", memory1[3]); end endmodule
In this example, there is a Verilog memory with four addresses, each element has 25 bits. This means that the Verilog memory needs eight bytes of machine memory because there is a data byte and a control byte for every eight bits in an element, with an additional data and control byte for any remainder bits. In this example, in element 0 the 25 bits are assigned, from right to left, eight 1 bits, eight unknown x bits, eight 0 bits, and one high impedance z bit.
#include <stdio.h> #include "DirectC.h"
indx = 0; p1 = vc_MemoryElemRef(h, indx); indx = 3; p2 = vc_MemoryElemRef(h, indx); memcpy(p2,p1,8); memcpy(t,p2,8); printf(" %d from t[0], %d from (int)t[0], (int) t[1]); printf(" %d from t[2], %d from (int)t[2], (int) t[3]); printf(" %d from t[4], %d from (int)t[4], (int)t[5]); printf(" %d from t[6], %d from (int)t[6], (int)t[7]); }
C/C++ function mem_elem_doer uses the vc_MemoryElemRef routine to return pointers to addresses 0 and 3 in Verilog memory1 and pass them to UB pointers p1 and p2. The standard memcpy routine then copies the eight bytes for address 0 to address 3. The remainder of the function is additional code to show you data and control bytes. The eight bytes pointed to by p2 are copied to array t and then the elements of the array are printed. The combined Verilog and C/C++ code displays the following:
memory1 [0] = z00000000xxxxxxxx11111111 255 from t[0], 255 from t[1] 0 from t[2], 0 from t[3] 0 from t[4], 255 from t[5] 0 from t[6], 1 from t[7] memory1 [3] = z00000000xxxxxxxx11111111
As you can see, function mem_elem_doer passes the contents of the Verilog memory memory1 element 0 to element 3. In array t, the elements contain the following:
[0] [1] [2] [3] [4] [5] [6] [7] The data bits for the eight 1 values assigned to the element. The data bits for the eight X values assigned to the element The data bits for the eight 0 values assigned to the element The data bit for the Z value assigned to the element The control bits for the eight 1 values assigned to the element The control bits for the eight X values assigned to the element The control bits for the eight 0 values assigned to the element The control bit for the Z value assigned to the element
scalar vc_getMemoryScalar(vc_handle, U indx) Returns the value of a one-bit memory element. For example:
extern void bitflipper (inout reg array [127:0] mem1); module test; reg mem1 [127:0]; initial begin mem1 [0] = 1; $display("mem1[0]=%0d",mem1[0]); bitflipper(mem1); $display("mem1[0]=%0d",mem1[0]); $finish; end endmodule
In this example of Verilog code, we declare a memory with 128 onebit elements, assign a value to element 0, and display its value before and after we call a C/C++ function named bitflipper.
#include <stdio.h>
#include "DirectC.h" void bitflipper(vc_handle h) { scalar holder=vc_getMemoryScalar(h, 0); holder = ! holder; vc_putMemoryScalar(h, 0, holder); }
In this example, we declare a variable of type scalar, named holder, to hold the value of the one-bit Verilog memory element. The routine vc_getMemoryScalar returns the value of the element to the variable. The value of holder is inverted and then the variable is included as a parameter in the vc_putMemoryScalar routine to pass the value to that element in the Verilog memory. The Verilog code displays the following:
mem[0]=1 mem[0]=0
void vc_putMemoryScalar(vc_handle, U indx, scalar) Passes a value of type scalar to a Verilog memory element. You specify the memory by vc_handle and the element by the indx parameter. This routine is used in the previous example. int vc_getMemoryInteger(vc_handle, U indx) Returns the integer equivalent of the data bits in a memory element whose bit-width is 32 bits or less. For example:
extern void mem_elem_halver (inout reg [] array [] memX); module test; reg [31:0] mem1 [127:0];
reg [7:0] mem2 [1:0]; initial begin mem1 [0] = 999; mem2 [0] = 8b1111xxxx; $display("mem1[0]=%0d",mem1[0]); $display("mem2[0]=%0d",mem2[0]); mem_elem_halver(mem1); mem_elem_halver(mem2); $display("mem1[0]=%0d",mem1[0]); $display("mem2[0]=%0d",mem2[0]); $finish; end endmodule
In this example, when the C/C++ function is declared on our Verilog code it does not specify a bit-width or element range for the inout argument to the mem_elem_halver C/C++ function, because in the Verilog code we call the C/C++ function twice, with a different memory each time and these memories have different bit widths and different element ranges. Notice that we assign a value that included X values to the 0 element in memory mem2.
#include <stdio.h> #include "DirectC.h"
This C/C++ function inputs the value of an element and then outputs half that value. The vc_getMemoryInteger routine returns the integer equivalent of the element you specify by vc_handle and
index number, to an int variable i. The function halves the value in i. Then the vc_putMemoryInteger routine passes the new value by value to the specified memory element. The Verilog code displays the following before the C/C++ function is called twice with the different memories as the arguments:
mem1[0]=999 mem2[0]=X
Element mem2[0] has an X value because half of its binary value is x and the value is displayed with the %d format specification and, in this example, a partially unknown value is just an unknown value. After the second call of the function, the Verilog code displays:
mem1[1]=499 mem2[0]=127
This occurs because before calling the function, mem1[0] had a value of 999, and after the call it has a value of 499 which is as close as it can get to half the value with integer values. Before calling the function, mem2[0] had a value of 8b1111xxxx, but the data bits for the element would all be 1s (11111111). Its the control bits that specify 1 from x and this routine only deals with the data bits. So, the vc_getMemoryInteger routine returned an integer value of 255 (the integer equivalent of the binary 11111111) to the C/C++ function, which is why the function outputs the integer value 127 to mem2[0]. void vc_putMemoryInteger(vc_handle, U indx, int) Passes an integer value to a memory element that is 32 bits or fewer. You specify the memory by vc_handle and the element by the indx argument. This routine is used in the previous example.
C Language Interface 20-105
void vc_get4stMemoryVector(vc_handle, U indx, vec32 *) Copies the value in an Verilog memory element to an element in an array. This routine copies both the data and control bytes. It copies them into an array of type vec32 which is defined as follows:
typedef struct { U c; U d;} vec32;
Therefore, type vec32 has two members, c and d, for control and data information. This routine always copies to the 0 element of the array. For example:
extern void mem_elem_copier (inout reg [] array [] memX); module test; reg [127:0] mem1 [127:0]; reg [7:0] mem2 [64:0]; initial begin mem1 [0] = 999; mem2 [0] = 8b0000000z; $display("mem1[0]=%0d",mem1[0]); $display("mem2[0]=%0d",mem2[0]); mem_elem_copier(mem1); mem_elem_copier(mem2); $display("mem1[32]=%0d",mem1[32]); $display("mem2[32]=%0d",mem2[32]); $finish; end endmodule
In the Verilog code, a C/C++ function is declared that is called twice. Notice the value assigned to mem2[0]. The C/C++ function copies the values to another element in the memory.
#include <stdio.h> #include "DirectC.h" void mem_elem_copier(vc_handle h)
This C/C++ function declares an array of type vec32. We must declare an array for this type, but as shown here, we specify that it have only one element. The vc_get4stMemoryVector routine copies the data from the Verilog memory element (in this example, specified as the 0 element) to the 0 element of the vec32 array. It always copies to the 0 element. The vc_put4stMemoryVector routine copies the data from the vec32 array to the Verilog memory element (in this case, element 32). The call to printf is to show you how the Verilog data is stored in element 0 of the vec32 array. The Verilog and C/C++ code display the following:
mem1[0]=999 mem2[0]=Z holder[0].d is 999 holder[0].c is 0 holder[0].d is 768 holder[0].c is 1 mem1[32]=999 mem2[32]=Z
As you can see, the function does copy the Verilog data from one element to another in both memories. When the function is copying the 999 value, the c (control) member has a value of 0; when it is copying the 8b0000000z value, the c (control) member has a value of 1 because one of the control bits is 1, the rest are 0.
void vc_put4stMemoryVector(vc_handle, U indx, vec32 *) Copies Verilog data from a vec32 array to a Verilog memory element. This routine is used in the previous example. void vc_get2stMemoryVector(vc_handle, U indx, U *) Copies the data bytes, but not the control bytes, from a Verilog memory element to an array in your C/C++ function. For example, if you use the Verilog code from the previous example, but simulate in two-state and use the following C/C++ code:
#include <stdio.h> #include "DirectC.h"
The only difference here is that we declare the array to be of type U instead and we do not copy the control bytes, because there are none in two-state simulation. void vc_put2stMemoryVector(vc_handle, U indx, U *) Copies Verilog data from a U array to a Verilog memory element. This routine is used in the previous example.
void vc_putMemoryValue(vc_handle, U indx, char *) This routine works like the vc_putValue routine except that is for passing values to a memory element instead of to a reg or bit. You enter an argument to specify the element (index) to which you want the routine to pass the value. For example:
#include <stdio.h> #include "DirectC.h" void check_vc_putvalue(vc_handle h) { vc_putMemoryValue(h,0,"10xz"); }
void vc_putMemoryValueF(vc_handle, U indx, char, char *) This routine works like the vc_putValueF routine except that it is for passing values to a memory element instead of to a reg or bit. You enter an argument to specify the element (index) to which you want the routine to pass the value. For example:
#include <stdio.h> #include "DirectC.h" void assigner (vc_handle h1, vc_handle h2, vc_handle h3, vc_handle h4) { vc_putMemoryValueF(h1, 0, "10", b); vc_putMemoryValueF(h2, 0, "11", o); vc_putMemoryValueF(h3, 0, "10", d); vc_putMemoryValueF(h4, 0, "aff", x); }
char *vc_MemoryString(vc_handle, U indx) This routine works like the vc_toString routine except that it used is for passing values to/from memory elements instead of to a reg or bit. You enter an argument to specify the element (index) whose value you want the routine to pass. For example:
extern void memcheck_vec(inout reg[] array[]);
module top; reg [0:7] mem[0:7]; integer i; initial begin for(i=0;i<8;i=i+1) begin mem[i] = 8b00000111; $display("Verilog code says \"mem [%0d] i,mem[i]); end memcheck_vec(mem); end endmodule
%0b\"",
void memcheck_vec(vc_handle h) { int i; for(i= 0; i<8;i++) { printf("C/C++ code says \"mem [%d] is %s \"\n",i,vc_MemoryString(h,i));
} }
char *vc_MemoryStringF(vc_handle, U indx, char) This routine works like the vc_MemoryString function except that you specify a radix with the third parameter. The valid radixes are b, o, d, and x. For example:
extern void memcheck_vec(inout reg[] array[]);
module top; reg [0:7] mem[0:7]; initial begin mem[0] = 8b00000111; $display("Verilog code $display("Verilog code $display("Verilog code $display("Verilog code memcheck_vec(mem);
end endmodule
void vc_FillWithScalar(vc_handle, scalar) This routine fills all the bits or a reg, bit, or memory with all 1, 0, x, or z values (you can choose only one of these four values).
You specify the value with the scalar argument, which can be a variable of the scalar type. The scalar type is defined in the DirectC.h file as:
typedef unsigned char scalar;
You can also specify the value with integer arguments as follows: 0 1 2 3 Specifies 0 values Specifies 1 values Specifies z values Specifies x values
If you declare a scalar type variable, enter it as the argument, and assign only the 0, 1, 2, or 3 integer values to it, they specify filling the Verilog reg, bit, or memory with the 0, 1, z, or x values. You can use the following definitions from the DirectC.h file to specify these values:
#define #define #define #define scalar_0 scalar_1 scalar_z scalar_x 0 1 2 3
The following Verilog and C/C++ code shows you how to use this routine to fill a reg and a memory using the following values:
extern void filler (inout reg [7:0] r1, inout reg [7:0] array [1:0] r2, inout reg [7:0] array [1:0] r3); module top; reg [7:0] r1; reg [7:0] r2 [1:0]; reg [7:0] r3 [1:0]; initial
begin $display("r1 is %0b",r1); $display("r2[0] is %0b",r2[0]); $display("r2[1] is %0b",r2[1]); $display("r3[0] is %0b",r3[0]); $display("r3[1] is %0b",r3[1]); filler(r1,r2,r3); $display("r1 is %0b",r1); $display("r2[0] is %0b",r2[0]); $display("r2[1] is %0b",r2[1]); $display("r3[0] is %0b",r3[0]); $display("r3[1] is %0b",r3[1]); end endmodule
char *vc_argInfo(vc_handle) Returns a string containing the information about the argument in the function call in your Verilog source code. For example, if you have the following Verilog source code:
extern void show(reg [] array []); module tester; reg [31:0] mem [7:0]; reg [31:0] mem2 [16:1]; reg [64:1] mem3 [32:1]; initial begin show(mem); show(mem2); show(mem3); end endmodule
Verilog memories mem, mem2, and mem3 are all arguments to the function named show. If that function is defined as follows:
#include <stdio.h> #include "DirectC.h" void show(vc_handle h) { printf("%s\n", vc_argInfo(h)); /* notice \n after the string */ }
int vc_Index(vc_handle, U, ...) Internally, a multi-dimensional array is always stored as a onedimensional array and this makes a difference in how it can be accessed. In order to avoid duplicating many of the previous access routines for multi-dimensional arrays, the access process is split into two steps. The first step, which this routine performs, is to translate the multiple indices into a single index of a linearized array. The second step is for another access routine to perform an access operation on the linearized array. This routine returns the index of a linearized array or returns -1 if the U-type parameter is not an index of a multi-dimensional array or the vc_handle parameter is not a handle to a multi-dimensional array of the reg data type.
/* get the sum of all elements from a 2-dimensional slice of a 4-dimensional array */ int getSlice(vc_handle vh_array, vc_handle vh_indx1, vc_handle vh_indx2) { int sum = 0; int i1, i2, i3, i4, indx; i1 = vc_getInteger(vh_indx1); i2 = vc_getInteger(vh_indx2); /* loop over all possible indices for that slice */ for (i3 = 0; i3 < vc_mdaSize(vh_array, 3); i3++) { for (i4 = 0; i4 < vc_mdaSize(vh_array, 4); i4++) { indx = vc_Index(vh_array, i1, i2, i3, i4); sum += vc_getMemoryInteger(vh_array, indx); } } return sum; }
There are specialized, more efficient versions for two- and threedimensional arrays. They are as follows: int vc_Index2(vc_handle, U, U) Specialized version of vc_Index() where the two U parameters are the indices in a two-dimensional array. int vc_Index3(vc_handle, U, U, U) Specialized version of vc_Index() where the two U parameters are the indices in a three-dimensional array. U vc_mdaSize(vc_handle, U) Returns the following: If the U-type parameter has a value of 0, it returns the number of indices in the multi-dimensional array. If the U-type parameter has a value greater than 0, it returns the number of values in the index specified by the parameter. There is an error condition if this parameter is out of the range of indices. If the vc_handle parameter is not an array, it returns 0.
Table 20-6
Access Routine
int vc_isScalar(vc_handle) Returns a 1 value if the vc_handle is for a one-bit reg or bit. It returns a 0 value for a vector reg or bit or any memory including memories with scalar elements. int vc_isVector(vc_handle) This routine returns a 1 value if the vc_handle is to a vector reg or bit. It returns a 0 value for a vector bit or reg or any memory. int vc_isMemory(vc_handle) This routine returns a 1 value if the vc_handle is to a memory. It returns a 0 value for a bit or reg that is not a memory. int vc_is4state(vc_handle) This routine returns a 1 value if the vc_handle is to a reg or memory that simulates with four states. It returns a 0 value for a bit or a memory that simulates with two states. int vc_is2state(vc_handle) This routine does the opposite of the vc_is4state routine. int vc_is4stVector(vc_handle) int vc_is2stVector(vc_handle) int vc_width(vc_handle) int vc_arraySize(vc_handle) scalar vc_getScalar(vc_handle) void vc_putScalar(vc_handle, scalar) char This routine returns a 1 value if the vc_handle is to a vector reg. It returns a 0 value if the vc_handle is to a scalar reg, scalar or vector bit, or to a memory. This routine returns a 1 value if the vc_handle is to a vector bit. It returns a 0 value if the vc_handle is to a scalar bit, scalar or vector reg, or to a memory. Returns the width of a vc_handle. Returns the number of elements in a memory. Returns the value of a scalar reg or bit. Passes the value of a scalar reg or bit to a vc_handle by reference.
vc_toChar(vc_handle) Returns the 0, 1, x, or z character. Returns an int value for a vc_handle to a scalar bit or a vector bit of 32 bits or less. Returns a string that contains the 1, 0, x, and z characters.
Access Routine char *vc_toStringF(vc_handle, char) void vc_putReal(vc_handle, double) double vc_getReal(vc_handle) void vc_putValue(vc_handle, char *) void vc_putValueF(vc_handle, char, char *) void vc_putPointer(vc_handle, void*) void *vc_getPointer(vc_handle)
Description Returns a string that contains the 1, 0, x, and z characters and allows you to specify the format or radix for the display. The char parameter can be b, o, d, or x. Passes by reference a real (double) value to a vc_handle. Returns a real (double) value from a vc_handle. This function passes, by reference through the vc_handle, a value represented as a string containing the 0, 1, x, and z characters. This function passes by reference through the vc_handle a value for which you specify a radix with the third parameter. The valid radixes are b, o, d, and x. These functions pass, by reference to a vc_handle, a generic type of pointer or string. Do not use these functions for passing Verilog data (the values of Verilog signals). Use it for passing C/C++ data. vc_putPointer passes this data by reference to Verilog and vc_getPointer receives this data in a pass by reference from Verilog. You can also use these functions for passing Verilog strings. Converts a C string (a pointer to a sequence of ASCII characters terminated with a null character) into a Verilog string (a vector with 8-bit groups representing characters).
void Converts a vector value to a string value. vc_VectorToString(vc_handl e, char *) int vc_getInteger(vc_handle) void vc_putInteger(vc_handle, int) Same as vc_toInteger. Passes an int value by reference through a vc_handle to a scalar reg or bit or a vector bit that is 32 bits or less.
Access Routine
Description
vec32 Returns a vec32 pointer to a four state vector. *vc_4stVectorRef(vc_handle Returns NULL if the specified vc_handle is not to a ) four-state vector reg. U This routine returns a U pointer to a bit vector that *vc_2stVectorRef(vc_handle is larger than 32 bits. If you specify a short bit vector ) (32 bits or fewer), this routine returns a NULL value. void vc_get4stVector(vc_handle, vec32 *) void vc_put4stVector(vc_handle, vec32 *) void vc_get2stVector(vc_handle, U *) void vc_put2stVector(vc_handle, U *) UB *vc_MemoryRef(vc_handle) Passes a four-state vector by reference to a vc_handle to and from an array in C/C++ function. vc_get4stVector receives the vector from Verilog and passes it to the array. vc_put4stVector passes the array to Verilog. Passes a two state vector by reference to a vc_handle to and from an array in C/C++ function. vc_get2stVector receives the vector from Verilog and passes it to the array. vc_put4stVector passes the array to Verilog. Returns a pointer of type UB that points to a memory in Verilog.
UB Returns a pointer to an element (word, address or *vc_MemoryElemRef(vc_handl index) of a Verilog memory. You specify the e, U indx) vc_handle of the memory and the element. scalar Returns the value of a one-bit memory element. vc_getMemoryScalar(vc_hand le, U indx) void Passes a value, of type scalar, to a Verilog memory vc_putMemoryScalar(vc_hand element. You specify the memory by vc_handle and le, U indx, scalar) the element by the indx parameter. int Returns the integer equivalent of the data bits in a vc_getMemoryInteger(vc_han memory element whose bit-width is 32 bits or less. dle, U indx) void Passes an integer value to a memory element that vc_putMemoryInteger(vc_han is 32 bits or fewer. You specify the memory by dle, U indx, int) vc_handle and the element by the indx parameter.
Access Routine
Description
void Copies the value in an Verilog memory element to vc_get4stMemoryVector(vc_h an element in an array. This routine copies both the andle, U indx, vec32 *) data and control bytes. It copies them into an array of type vec32. void Copies Verilog data from a vec32 array to a Verilog vc_put4stMemoryVector(vc_h memory element. andle, U indx, vec32 *) void Copies the data bytes, but not the control bytes, from vc_get2stMemoryVector(vc_h a Verilog memory element to an array in your C/C++ andle, U indx, U *) function. void Copies Verilog data from a U array to a Verilog vc_put2stMemoryVector(vc_h memory element. andle, U indx, U *) void This routine works like the vc_putValue routine vc_putMemoryValue(vc_handl except that it is for passing values to a memory e, U indx, char *) element instead of to a reg or bit. You enter an parameter to specify the element (index) you want the routine to pass the value to. void This routine works like the vc_putValueF routine vc_putMemoryValueF(vc_hand except that it is for passing values to a memory le, U indx, char, char *) element instead of to a reg or bit. You enter an parameter to specify the element (index) you want the routine to pass the value to. char This routine works like the vc_toString routine *vc_MemoryString(vc_handle except that it is for passing values to from memory , U indx) element instead of to a reg or bit. You enter an parameter to specify the element (index) you want the routine to pass the value of. char This routine works like the vc_MemoryString *vc_MemoryStringF(vc_handl function except that you specify a radix with the third e, U indx, char) parameter. The valid radixes are b, o, d, and x. void This routine fills all the bits or a reg, bit, or memory vc_FillWithScalar(vc_handl with all 1, 0, x, or z values (you can choose only one e, scalar) of these four values).
Description Returns a string containing the information about the parameter in the function call in your Verilog source code. Returns the index of a linearized array, or returns 1 if the U-type parameter is not an index of a multidimensional array, or the vc_handle parameter is not a handle to a multi-dimensional array of the reg data type.
int vc_Index2(vc_handle, U, Specialized version of vc_Index() where the two U U) parameters are the indices in a two-dimensional array. int vc_Index3(vc_handle, U, Specialized version of vc_Index() where the two U U, U) parameters are the indexes in a three-dimensional array. U vc_mdaSize(vc_handle, U) If the U type parameter has a value of 0, it returns the number of indices in multi-dimensional array. If the U type parameter has a value greater than 0, it returns the number of values in the index specified by the parameter. There is an error condition if this parameter is out of the range of indices. If the vc_handle parameter is not a multi-dimensional array, it returns 0.
These suffixes specify the following: +abstract Specifies that you are using abstract access through vc_handles to the data structures for the Verilog arguments. When you include this suffix, all functions use abstract access except those with "C" in their declaration; these exceptions use direct access. If you omit this suffix, all functions use direct access except those wit the "A" in their declaration; these exceptions use abstract access. +allhdrs Writes the vc_hdrs.h file that contains external function declarations that you can use in your Verilog code. +list Displays on the screen all the functions that you called in your Verilog source code. In this display, void functions are called procedures. The following is an example of this display:
______________________________________________________ The following external functions have been actually called: procedure receive_string procedure passbig2 function return_string procedure passbig1 procedure memory_rewriter function return_vector_bit procedure receive_pointer procedure incr function return_pointer
Note: If access mode is not specified, then the command-line option +abstract rules; default mode is "C".]
extern_func_type ::= void | reg | bit | DirectC_primitive_type | bit_vector_type bit_vector_type ::= bit [ constant_expression : constant_expression ] list_of_extern_func_args ::= extern_func_arg ( , extern_func_arg ) * extern_func_arg ::= arg_direction ? arg_type optional_arg_name ?
Note: Argument direction (i.e., input, output, inout) applies to all arguments that follow it until the next direction occurs; the default direction is input.
arg_direction ::= input | output | inout arg_type ::= bit_or_reg_type | array_type | DirectC_primitive_type bit_or_reg_type ::= ( bit | reg ) optional_vector_range ? optional_vector_range ::= [ ( constant_expression : constant_expression ) ? ] array_type ::= bit_or_reg_type array [ ( constant_expression : constant_expression ) ? ] DirectC_primitive_type ::= int | real | pointer | string
21
SAIF Support 3
The Synopsys Power Compiler enables you to perform power analysis and power optimization for your designs by entering the power command at the vcs prompt. This command outputs Switching Activity Interchange Format (SAIF) files for your design. SAIF files support signals and ports for monitoring as well as constructs such as generates, enumerated types, records, array of arrays, and integers. This chapter covers the following topics: Using SAIF Files SAIF System Tasks Flow to Dump the Backward SAIF File SAIF Support for Two-Dimensional Memories in v2k Designs
UCLI SAIF Dumping Criteria for Choosing Signals for SAIF Dumping
$toggle_reset Sets the toggle counter to 0 for all the nets in the current toggle region. Syntax:
$toggle_reset();
This task has a slight change in native SAIF implementation compared to PLI-based implementation. VCS considers only the arguments specified here for processing. Other arguments have no meaning. VCS does not report signals in modules defined under the celldefine compiler directive.
$read_lib_saif Allows you to read in a state dependent and path dependent (SDPD) library forward SAIF file. It registers the state and path dependent information on the scope. It also monitors the internal nets of the design. Syntax:
$read_lib_saif("inputFile");
$set_gate_level_monitoring Allows you to turn on/off the monitoring of nets in the design if $read_lib_saif is present in the design. Syntax:
$set_gate_level_monitoring("on" | "off" | "rtl_on");
"rtl_on"
All reg type of objects are monitored for toggles. Net type of objects are monitored only if it is a cell highconn. This is the default monitoring policy.
"off"
reg type of objects are monitored only if it is a cell highconn. For more details on these task calls, refer to the Power Compiler User Guide. Note: The $read_mpm_saif, $toggle_set, and $toggle_count tasks in the PLI-based vpower.tab file are obsolete and no longer supported.
To generate a non-SDPD backward SAIF file without using SAIF files, do the following:
initial begin $set_gate_level_monitoring("on"); $set_toggle_region(Scope); // initialization of Verilog signals, and then: $toggle_start; // testbench $toggle_stop; $toggle_report("outputFile", timeUnit, Scope); end
You must pass the mda keyword to the $set_gate_level_monitoring system task to monitor twodimensional memories in v2k designs. Note: You must pass the +memcbk compile-time option at vcs command-line, to dump two-dimensional wire or register. If you want to dump through the UCLI command, you must pass the mda string to the power -gate_level command, as shown in the below section.
support bit selects and part selects as arguments to $set_toggle_region or $toggle_report. In addition, it monitors cell highconns based on the policy.
22
Encrypting Source Files 1
You can use VCS to encrypt your HDL source files in such a way that they can be used only with VCS. This chapter describes how to use VCS to encrypt the source files for this purpose. VCS uses the 128-bit Advanced Encryption Standard (AES) to encrypt the Verilog and VHDL files. The 128-bit key is generated internally by VCS. This 128-bit encryption methodology is exclusive to VCS, and can be decrypted only by VCS. You can choose to encrypt only certain parts of your source files or entire files using either of the following methods: Using Compiler Directives or Pragmas on page 2 Using Automatic Protection Options on page 5
Note: By default, the encrypted .vp or .vhdp files are saved in the same directory as the source files. You can change this location by using the -putprotect128 analysis option. For example, the following command saves the foo.vp encrypted file in the ./out directory: % vlogan -putprotect128 ./out -protect128 foo.v Note: - If you specify the protect and protect128 analysis options on the same vcs command line, VCS ignores the protect128 option and uses the protect option. It also reports a warning message. - The Protect128 and genip options are mutually exclusive, you cannot specify both of these options on the same vcs command line.
Example
The following Verilog file illustrates the use of protect128 and endprotect128 to mark the code that needs to be encrypted:
module top( inp, outp); input [7:0] inp; output [7:0] outp; reg [7:0] count; assign outp = count; always begin:counter `protect128 //begin protected region reg [7:0] int; count = 0; int = inp; while (int) begin if (int [0]) count = count + 1;
int = int >> 1; end `endprotect128 //end protected region end endmodule
The contents of the.vp file that is generated using the -protect128 analysis option is shown below:
module top( inp, outp); input [7:0] inp; output [7:0] outp; reg [7:0] count; assign outp = count; always begin:counter `protected128 P$<-:U="& Y0_+\[?7SYR'AYPDX_H5!KR%>.,^%':>9A_+^UF,6X]=F0S&\-5<;IQ P:F]/8/)U-%R2 MKD.FB#6?UC"0>XE?R>]^ 3)4@K<.5;*[DX>,+7P@1!S%QA\MME P>E#R7!*4#IQNK LU):.T[LT=4Y6DP5VWKXN^)F[@L34;C>,=1D'8!9ILX<,AE[6H P^<P2#1%RY0X??,5)!,84>FHD @RVX1K=E9UK5,[7Q$^; U\,<JLM#>2@OZ! "'"7 P&ZV60$"CTNE)N+A%]UN19](H;D,L#V&?&=X)(U!CGVRF3],F!+IC2/ KRLG:(-(60 P'>K\BRT_2_/(5^%FBS#*O$IB[R.;V"1SMJBB:"P4#J="EH".5^?!MYZ#>84>:Q. `endprotected128 //end protected region end endmodule
For VHDL files, VCS encrypts everything other than the ports in the entity declarations. Though the generated file is syntactically correct file, it may not be semantically correct as the VHDL port declarations can refer to generics in the encrypted portion. -auto3protect128 This option is similar to the -auto2protect128 option except for the following differences. For Verilog files, VCS does not encrypt parameters preceding the ports declaration in a Verilog module. For VHDL files, VCS does not encrypt the generic clause of entity declarations.
23
Integrating VCS with Vera 1
Vera is a comprehensive testbench automation solution for module, block and full system verification. The Vera testbench automation system is based on the OpenVera language. This is an intuitive, high-level, object-oriented programming language developed specifically to meet the unique requirements of functional verification. You can use Vera with VCS to simulate your testbench and design. This chapter describes the required environment settings and usage model to integrate Vera with VCS.
Note: If you set the SNPSLMD_LICENSE_FILE environment variable, then VCS ignores the LM_LICENSE_FILE environment variable. Set the VCS environment as shown below:
% setenv VCS_HOME VCS_Installation % setenv PATH $VCS_HOME/bin:$PATH % setenv LM_LICENSE_FILE license_path:$LM_LICENSE_FILE or
% setenv SNPSLMD_LICENSE_FILE license_path:$SNPSLMD_LICENSE_FILE
Note: If you set the SNPSLMD_LICENSE_FILE environment variable, then VCS ignores the LM_LICENSE_FILE environment variable. For more information on VCS installation, see Setting Up the Simulator .
Compile your design and the filename_vshell.v file using the -vera option. This option is required to use Vera with VCS. Simulate the design by specifying the .vro file created in the first step using the +vera_load runtime option. You can also specify this .vro file in the vera.ini file in your working directory as shown in the following example:
vera_load = tb_top.vro
Usage Model
Use the following usage model to compile OpenVera code using Vera:
% vera -cmp [Vera_options] OpenVera_files
See the Vera User Guide for a list of Vera compilation options. Compilation
% vcs [compile_options] -vera verilog_filelist filename_vshell.v
Simulation
% simv [simv_options] +vera_load=file.vro
24
Integrating VCS with HSIM 1
HSIM-VCS DKI is a new mixed-signal simulation implementation using the Synopsys HSIM and VCS simulators. Unlike the VPI/PLI implementation of mixed-signal simulation previously used by HSIM with VPI/PLI standard compliant digital simulators, HSIM-VCS DKI uses a Direct Kernel Interface to exchange information between the HSIM analog simulator and the VCS digital simulator. This approach is similar to the NanoSim-VCS mixed-signal simulation flow and provides more flexibility and better performance over VPI/PLI-based mixedsignal simulation. HISM-VCS DKI mixed-signal simulation supports: The use of both Verilog top-level netlists and SPICE top-level netlists. Donut partitioning, which is the arbitrary instantiation of Spice subcircuits and Verilog modules under either Spice or Verilog throughout the design hierarchy. The use of either instance-based or cell-based partitioning.
Environment Setup
A working installation of VCS and a matching version of HSIM are required to run DKI mixed-signal simulation. The compatibility table for versions of HSIM and VCS that work together is available at: https:// solvnet.synopsys.com/retrieve/020828.html. The following environment variables must be set:
% setenv LM_LICENSE_FILE Location_of_License_File or % setenv SNPSLMD_LICENSE_FILE license_file_path % setenv VCS_HOME VCS_install_directory % setenv HSIM_HOME HSIM_install_directory % set path = ($VCS_HOME/bin $HSIM_HOME/bin $path) % setenv HSIM_64 1
Unset the variable HSIM_64 if you are using in 32-bit mode. Note: If you set the SNPSLMD_LICENSE_FILE environment variable, then VCS ignores the LM_LICENSE_FILE environment variable.
Usage Model
To Compile The syntax to start the compile process is:
% vcs -ad=init_file Verilog_source_files [other_VCS_options]
This links the libvcsdkihsim.so file and generates an executable called simv. A directory called simv.daidir is created that contains all of the generated files for VCS and HSIM to run.
-ad=init_file Enables mixed-signal simulation. In the absence of the init_file, VCS looks for the default initialization file vcsAD.init. To Run Simulation The syntax to run the mixed-signal simulation is:
% simv [runtime_options]
This dynamically loads the libvcsdkihsim.so file and runs the simulation. For more information about VCS-HSIM mixed-signal simulation, see the HSIM documentation.
25
Integrating VCS with NanoSim 1
VCS-NanoSim (VCS-NS) allows a mixed-signal simulation solution, which enables simulating a design that is partly modeled in both analog and digital. It is recommended that before starting a mixed-signal simulation, both SPICE subcircuits and Verilog modules should be error-free (individually tested). This chapter briefly describes the environment setup and usage model of VCS-NanoSim mixed-signal simulations. For more information, see the co_sim.pdf file in the NanoSim documentation (/NanoSim_installation/doc/ns/manuals/co_sim.pdf). VCS-NanoSim mixed-signal simulation supports: The use of both Verilog top-level netlists and SPICE top-level netlists. Donut partitioning, which is the arbitrary instantiation of Spice subcircuits and Verilog modules under either Spice or Verilog throughout the design hierarchy.
Environment Setup
A working installation of VCS and a matching version of NanoSim are required to run mixed-signal simulation. The compatibility table for versions of VCS and NanoSim that work together can be found at: https://solvnet.synopsys.com/retrieve/020828.html. The following environment variables must be set: Licenses
setenv LM_LICENSE_FILE license_file_path
or
setenv SNPSLMD_LICENSE_FILE license_file_path
Note: If you set the SNPSLMD_LICENSE_FILE environment variable, then VCS ignores the LM_LICENSE_FILE environment variable. For NanoSim
source NanoSim_install_directory/CSHRC_platform
For VCS
setenv VCS_HOME vcs_install_directory set path = ($VCS_HOME/bin $path)
Usage Model
To Compile The syntax to start the compile process is:
% vcs -ad=init_file verilog_source_files [other_vcs_options]
-ad=init_file Enables mixed-signal simulation. In the absence of the init_file, VCS looks for the default initialization file, vcsAD.init. To Run Simulation The syntax to run the mixed-signal simulation is:
% simv [runtime_options]
26
Integrating VCS with Specman 1
The VCS ESI Adapter integrates VCS with the Specman Elite. This chapter describes how to prepare a stand-alone Verilog design for use with the ESI interface. See the Specman Elite User Guide for further information. The VCS ESI adapter is implemented as a Verilog PLI application, and is called specman.v. This file is generated using the specman command, as explained later in the chapter. This chapter includes the following topics: Type Support Usage Flow Using specrun and specview Adding Specman Objects To DVE
Type Support
The VCS ESI adapter supports the following Verilog Types: nets wires registers integers array of registers (verilog memory)
Other Verilog support: Verilog macros Verilog tasks Verilog functions Verilog events in/out/inout ports
Usage Flow
This section explains how to integrate Specman with VCS.
Commands "% sn_compile.sh -sim vcs \ -sim_flags [compiletime_options] \ -debug top_cfg/entity/module -o <exe_name> <top_e_file>.e " "% sn_compile.sh -sim vcs \ -sim_flags [compiletime_options] \ -debug top_cfg/entity/module <top_e_file>.e " "% sn_compile.sh -sim vcs \ -sim_flags [compiletime_options] \ -debug top_cfg/entity/module -o <exe_name> " "% sn_compile.sh -sim vcs \ -sim_flags [compiletime_options] \ -debug top_cfg/entity/module "
Execution with -o
<exe_name>
ucli> quit
Note: Notice the use of the -o option with this script in compile mode to change the name of the executable generated to vcs_simv from the default name given by the script which is vcs_<top_e_file>.
In Loaded mode:
% simv -ucli [simv_options] ucli% sn load <top_e_file>; test ucli% run ucli% quit
Note: Notice the use of the -o option with this script in loaded mode to change the name of the executable generated to simv from the default name given by the script which is vcs_specman.
specrun invokes Specman in batch mode, while specview invokes the Specman GUI. The usage model is shown below: Using specrun In Compiled mode:
% specrun -p "test -seed=1;" simv [simv_options]
In Loaded mode:
% specrun -p "load [top_e_file]; test -seed=1;" \ simv [simv_options]
In Compiled mode:
% specview -p "test -seed=1;" -sio simv -gui
In Loaded mode:
% specview -p "load [top_e_file]; test -seed=1;" \ -sio simv -gui
You can also specify VCS runtime options with specview or specrun as shown in the following examples: Example 26-1 To Invoke DVE Using specview
The following command invokes the Specman GUI, as well as, DVE.
% specview -p "test -seed=1;" -sio simv -gui
Similarly, you can also use -ucli with specview to invoke simulation in UCLI mode.
Integrating VCS with Specman 26-6
Example 26-2
Similarly, you can also use -gui with specrun to invoke DVE.
- In Loaded mode:
% simv -gui -do run.do
The simv -gui -do run.do command starts DVE, executes the UCLI commands specified in run.do and creates the sn_wave_sys.tcl session file. Now, load sn_wave_sys.tcl using File > Load Session and the dumped e-objects will be added to the Wave window automatically. Go to the Wave window and click on the groups icon to the side of the filter pane and select the e-objects to be added. See the figure shown below:
Select Groups Select the e-objects to be added
Use Model
Through Command-line Options % vcs +warn=V2V_CHECK_SPECMAN To convert warning to error: % vcs +vcs+error=V2V_CHECK_SPECMAN Enabling at Runtime: %simv +warn=V2V_CHECK_SPECMAN You can use the +warn=noV2V_CHECK_SPECMAN option to turn off the warning message. In this option, no specifies disabling warning messages.
27
Integrating VCS with Denali 1
Denali, a third-party Memory Modeler - Advanced Verification (MMAV) product, can be integrated with VCS through a set of APIs. Denali provides a complete solution for memory modeling and system verification. It automatically monitors all the timing and protocol requirements specified by the memory vendor.
Usage Model
This section describes the following: Usage Model for Verilog Memory Models Execute Denali Commands at UCLI Prompt
Note: To compile the design in 64-bit mode, you must use the -lpthread option. Simulation
% simv [simv_options]
The above UCLI command loads the Denali memory in the instance I_denali_model with the data specified in the data_file. For more information on invoking UCLI, see Using UCLI .
28
Integrating VCS with Debussy
In this release, VCS supports Novas 2010.07 version under the fsdb option. This chapter contains the following section: Using the Current Version of VCS with Novas 2010.07 Version on page 1
Setting Up Debussy
To dump an fsdb file, you need to set the following environment variables:
% setenv DEBUSSY_HOME Debussy_installation % setenv DEBUSSY_LIB $DEBUSSY_HOME/share/PLI/VCS/LINUX % setenv LD_LIBRARY_PATH ${DEBUSSY_HOME}/share/PLI/lib/ LINUX:$DEBUSSY_LIB % setenv LM_LICENSE_FILE[Debussy_license]:$LM_LICENSE_FILE
Using UCLI
Compilation This can be done in following two ways: % vcs -fsdb [compile_options] verilog_filelist For P tab flow, include load libnovas.so:FSDBDumpCmd in the compilation step.
The following is the use model change: % vcs -debug_pp -P $DEBUSSY_LIB/novas.tab $DEBUSSY_LIB/pli.a -load libnovas.so:FSDBDumpCmd Simulation
% simv [run_options] -ucli ucli> fsdbDumpfile your_fsdb_dumpfile ucli> fsdbDumpvars level module/entity
Examples
Example 28-1 Using Verilog System Tasks
This example demonstrates the use of Verilog system tasks, $fsdbDumpfile and $fsdbDumpvars.
`timescale 1ns\1ns module test; initial begin $fsdbDumpfile("test.fsdb"); $fsdbDumpvars(0,test); end ... endmodule
Now the usage model to compile and simulate the above design is as shown below: Compilation
% vcs -fsdb test.v
Simulation
% simv
The above set of commands dumps all the instances in test into the test.fsdb file. Example 28-2 Using UCLI
This example demonstrates the use of UCLI commands fsdbDumpfile and fsdbDumpvars at the UCLI prompt to dump an fsdb file: Consider the following Verilog file:
timescale 1ns/1ns module test(); .... endmodule
The usage model to compile the design to use UCLI commands is as shown below: Compilation
% vcs -fsdb -debug_pp test.v
Simulation
% simv -ucli ucli> fsdbDumpfile test.fsdb ucli> fsdbDumpvars 0 test ucli> run ucli> quit
The above command dumps the whole design test into the test.fsdb file.
29
Integrating VCS with XA
XA-VCS allows a mixed-signal simulation solution, which enables simulating a design that is partly modeled in both analog and digital. It is recommended that before starting a mixed-signal simulation, both SPICE subcircuits and Verilog modules should be error-free (individually tested). This chapter briefly describes the environment setup and usage model of XA-VCS mixed-signal simulations. For more information, please refer Discovery AMS: Mixed-Signal Simulation User Guide in the XA documentation. XA-VCS mixed-signal simulation supports: The use of both Verilog top-level netlists and SPICE top-level netlists. Donut partitioning, which is the arbitrary instantiation of SPICE subcircuits and Verilog modules under either SPICE or Verilog throughout the design hierarchy. The use of either instance-based or cell-based partitioning.
Integrating VCS with XA 29-1
Environment Setup
A working installation of VCS and a matching version of XA are required to run mixed-signal simulation. The compatibility table for versions of VCS and XA that work together can be found at: https://solvnet.synopsys.com/retrieve/020828.html. The following environment variables must be set: Licenses
% setenv LM_LICENSE_FILE license_file_path
or
% setenv SNPSLMD_LICENSE_FILE license_file_path
Note: If you set the SNPSLMD_LICENSE_FILE environment variable, then VCS ignores the LM_LICENSE_FILE environment variable. For XA
source XA_install_directory/CSHRC_platform
For VCS
setenv VCS_HOME vcs_install_directory set path = ($VCS_HOME/bin $path)
Usage Model
To Compile The syntax to start the compile process is:
% vcs -ad=init_file verilog_source_files [other_vcs_options]
-ad=init_file Enables mixed-signal simulation. In the absence of the init_file, VCS looks for the default initialization file, vcsAD.init. To Run Simulation The syntax to run the mixed-signal simulation is:
% simv [runtime_options]
30
Integrating VCS with MVSIM Native Mode 1
This chapter provides brief description on the MVSIM tool and how VCS works with MVSIM native mode.
Introduction to MVSIM
MVSIM is a multivoltage simulation tool that enables voltage-level aware simulation and verification of power-managed designs. The tool enables you to simulate the impact of voltage variation on digital logic. You can use MVSIM for both RTL and Netlist simulations. MVSIM uses IEEE-1801 (also known as UPF) as the format to capture power-intent of a design.
References
For more details about getting the license for MVSIM and installing it, refer to the Multi-Voltage Low Power Verification Tools Suite Installation Guide. For more details about MVSIM Native mode in VCS, refer to the MVSIM Native Mode User Guide.
A
VCS Environment Variables
This appendix covers the following topics: Simulation Environment Variables Optional Environment Variables
PATH On UNIX, set this environment variable to $VCS_HOME/bin. Add the following directories to your PATH environment variable:
set path=($VCS_HOME/bin\ $VCS_HOME/$VCS_HOME/bin/vcs -platform/bin\ $path)
Also, make sure the path environment variable is set to a bin directory containing a make or gmake program. LM_LICENSE_FILE or SNPSLMD_LICENSE_FILE The definition can either be an absolute path name to a license file or to a port on the license server. Separate the arguments in this definition with colons. For example:
setenv LM_LICENSE_FILE 7182@serveroh:/u/net/server/ eda_tools/license.dat
or setenv SNPSLMD_LICENSE_FILE 7182@serveroh:/u/net/ server/eda_tools/license.dat Note: - You can use SNPSLMD_LICENSE_FILE environment variable to set licenses explicitly for Synopsys tools. -If you set the SNPSLMD_LICENSE_FILE environment variable, then VCS ignores the LM_LICENSE_FILE environment variable. -
- .
PERSISTENT_FLAG When set to 1, VCS disables the checks enabled by the persistent specification in the tab file. It also disables similar checks that are enabled by the -debug, -debug_all, or -debug_pp options. See the section PLI Table File on page 6.
SYSTEMC_OVERRIDE Specifies the location of the SystemC simulator used with the VCS/SystemC co-simulation interface. See Using SystemC. TMPDIR Specifies the directory used by VCS and the C compiler to store temporary files during compilation.
VCS_CC Indicates the C compiler to be used. To use the gcc compiler specify the following:
setenv VCS_CC gcc
VCS_COM Specifies the path to the VCS compiler executable named vcs1, not the compile script. If you receive a patch for VCS, you might need to set this environment variable to specify the patch. This variable is used for solving problems that require patches from VCS and should not be set by default. VCS_LIC_EXPIRE_WARNING By default, VCS displays a warning message 30 days before a license expires. You can specify that this warning message begin fewer days before the license expires with this environment variable, for example:
VCS_LIC_EXPIRE_WARNING 5
VCS_LOG Specifies the runtime log file name and location. VCS_NO_RT_STACK_TRACE Tells VCS not to return a stack trace when there is a fatal error and instead dump a core file for debugging purposes. VCS_SWIFT_NOTES
Enables the printf PCL command. PCL is the Processor Control Language that works with SWIFT microprocessor models. To enable it, set the value of this environment variable to 1. VCS_DIAGTOOL Generates valgrind data for vcs1, if you set this environment variable as shown below:
% setenv VCS_DIAGTOOL "valgrind --tool=memcheck"
Once you set this environment variable, any subsequent invocation of vcs1 generates valgrind data.
B
Compile-time Options A
The vcs command performs compilation of your design and creates a simulation executable. Compiled event code is generated and used by default. The generated simulation executable, simv, can then be used to run multiple simulations. This section describes the vcs command and related options. Syntax:
vcs source_files [source_or_object_files] [options]
Here: source_files The Verilog or OVA source files for your design separated by spaces.
source_or_object_files Optional C files (.c), object files (.o), or archived libraries (.a). These are DirectC or PLI applications that you want VCS to link into the binary executable file along with the object files from your Verilog source files. When including object files include the -cc and -ld options to specify the compiler and linker that generated them. options Compile-time options that control how VCS compiles your design. This appendix lists the following: Options for Accessing Verilog Libraries Options for Incremental Compilation Options for Help and Documentation Options for SystemVerilog Assertions Options to Enable Compilation of OVA Case Pragmas Options for Native Testbench Options for Different Versions of Verilog Options for Initializing Memories and Registers with Random Values Options for Using Radiant Technology Options for 64-bit Compilation Options for Starting Simulation Right After Compilation Options for Specifying Delays and SDF Files
Options for Compiling an SDF File Options for Specify Blocks and Timing Checks Options for Pulse Filtering Options for Negative Timing Checks Options for Profiling Your Design Options to Specify Source Files and Compile-time Options in a File Options for Compiling Runtime Options into the Executable Options for PLI Applications Options to Enable the VCS DirectC Interface Options for Flushing Certain Output Text File Buffers Options for Simulating SWIFT VMC Models and SmartModels Options for Controlling Messages Options for Cell Definition Options for Licensing Options for Controlling the Linker Options for Controlling the C Compiler Options for Source Protection Options for Mixed Analog/Digital Simulation Options for Changing Parameter Values Checking for X and Z Values in Conditional Expressions
Options for Detecting Race Conditions Options to Specify the Time Scale "Options for Overriding Parameters" General Options
If rev1/cell.v, rev2/cell.v and rev3/cell.v all exist and define the module cell(), and you issue the following command:
% vcs -y rev1 -y rev2 -y rev3 +libext+.v top.v
VCS picks cell.v from rev1. However, if the top.v file has a `uselib compiler directive as shown below, then `uselib takes priority:
//top.v `uselib directory = /proj/libraries/rev3 //rest of top module code //end top.v
In this case, VCS will use rev3/cell.v when you issue the following command:
% vcs -y rev1 -y rev2 +libext+.v top.v
Include the +libext compile-time option to specify the file name extension of the files you want VCS to look for in these directories. +libext+extension+ Specifies that VCS searches only for files with the specified file name extensions in a library directory. You can specify more than one extension, separating the extensions with the plus (+) character. For example, +libext+.v+.V+ specifies searching for files with either the .v or .V extension in a library. The order in which you add file name extensions to this option does not specify an order in which VCS searches files in the library with these file name extensions. +liborder
Specifies searching for module definitions for unresolved module instances through the remainder of the library where VCS finds the instance, then searching the next and then the next library on the vcs command line before searching in the first library on the command line. +librescan Specifies always searching libraries for module definitions for unresolved module instances beginning with the first library on the vcs command line. +libverbose Tells VCS to display a message when it finds a module definition in a source file in a Verilog library directory that resolves a module instantiation statement that VCS read in your source files, a library file, or in another file in a library directory. The message is as follows:
Resolving module "module_identifier"
By default, VCS does not display this message when it finds a module definition in a Verilog library file that resolves a module instantiation statement.
-Mlib=dir This option provides VCS with a central place to look for the descriptor information before it compiles a module and a central place to get the object files when it links together the executable. This option allows you to use the parts of a design that have been already tested and debugged by other members of your team without recompiling the modules for these parts of the design. You can specify more than one place for VCS to look for descriptor information and object files by providing multiple arguments with this option. Example: vcs design.v -Mlib=/design/dir1 -Mlib=/design/ dir2 Or, you can specify more than one directory with this option, using a colon (:) as a delimiter between them, as shown below: vcs design.v -Mlib=/design/dir1:/design/dir2 -noIncrComp Disables incremental compilation. -parallel_compile_off Turns off parallel compilation and uses serial compilation.
Lists descriptions of the most commonly used VCS compile and runtime options. -doc Displays the VCS documentation in your systems default web browser.
all Suppresses warning messages about unique if, unique case, priority if and priority case statements. You can tell VCS to report errors for both unique and priority violations with the +vcs+error compile-time option as shown below: +vcs+error=UNIQUE VCS reports unique violations as error conditions. +vcs+error=PRIORITY VCS reports priority violations as error conditions. +vcs+error=UNIQUE,PRIORITY VCS reports unique and priority violations as error conditions. -assert keyword_argument The keyword arguments are as follows: enable_diag Enables further control of results reporting with runtime options. The runtime assert options are enabled only if you compile the design with this option. funchier Enables enhanced reporting for assertions in functions. hier=file_name
You can use the -assert hier=file_name option to specify the configuration file for enabling and disabling SystemVerilog assertions. You can either enable or disable: - Assertions in a module or in a hierarchy. - An individual assertion. The types of entries that you can specify in the file are as follows:
-assert <assertion_name> or <assertion_hierarchical_name>
If assertion_name is provided, VCS disables the assertions based on wildcard matching of the name in the full design. If assertion_hierarchical_name is provided, VCS disables the assertions based on wildcard matching of the name in the particular hierarchy given. Examples -assert my_assert Disables all assertions with name my_assert in the full design. -assert A* Disables all assertions whose name starts with A in the full design. -assert * Disables all assertions in the full design. -assert top.INST2.A
Disables all assertions whose names start with A in the hierarchy top.INST2. If assertions whose name starts with A exists in inner scopes under top.INST2, they are not disabled. This command has affect on assertions only in scope top.INST2.
+tree <module_instance_name> or <assertion_hierarchical_name>
If module_instance_name is provided, VCS enables assertions in the specified module instance and all module instances hierarchically under that instance. If assertion_hierarchical_name is provided, VCS enables the specified SystemVerilog assertion. Wildcard characters can also be used for specifying the hierarchy. Examples +tree top.inst1 Enables the assertions in module instance top.inst1 and all the assertions in the module instances under this instance. +tree top.inst1.a1 Enables the SystemVerilog assertion with the hierarchical name top.inst1.a1. +tree top.INST*.A1 Enables assertion A1 from all the instances whose names start with INST under module top.
-tree <module_instance_name> or <assertion_hierarchical_name>
If module_instance_name is provided, VCS disables the assertions in the specified module instance and all module instances hierarchically under that instance. If assertion_hierarchical_name is provided, VCS disables the specified SystemVerilog assertion. Wildcard characters can also be used for specifying the hierarchy. Examples -tree top.inst1 Disables the assertions in module instance top.inst1 and all the assertions in the module instances under this instance. -tree top.inst1.a1 Disables SystemVerilog assertion with the hierarchical name top.inst1.a1. -tree top.INST*.A1 Disables assertion A1 from all the instances whose names start with INST under module top. +module module_identifier VCS enables all the assertions in all instances of the specified module, for example: +module dev VCS enables the assertions in all instances of module dev. -module module_identifier
VCS disables all the assertions in all instances of the specified module, for example: -module dev VCS disables the assertions in all instances of module dev. The specifications are applied serially as they appear in file file_name. The result of applying the specifications in this file is that a group of assertions get excluded. The remaining assertions are available for further exclusion by other means, such as the $assertoff system task in the source code. However, the following should be noted: - The first specification denotes the default exclusion for interpreting the file. If the first specification is a minus(-), then all assertions are included before applying the first and the following specifications. Conversely, if the first specification is a plus(+), then all assertions are excluded prior to applying the first and the following specifications. - Unlike -/+module and -/+tree specifications, any assertion excluded by applying assert specification cannot be included by the later specifications in the file. enable_hier Enables the use of the runtime option -assert hier=file.txt, which allows turning assertions on or off. filter_past
For assertions that are defined with the $past system task, ignore these assertions when the past history buffer is empty. For instance, at the very beginning of the simulation, the past history buffer is empty. Therefore, the first sampling point and subsequent sampling points should be ignored until the past buffer has been filled with respect to the sampling point. disable Disables all SystemVerilog assertions in the design. disable_cover When you include the -cm assert compile-time and runtime option, VCS includes information about cover statements in the assertion coverage reports. This keyword prevents cover statements from appearing in these reports. disable_file=filename Disables the SystemVerilog assertions specified in the file. This file should contain the hierarchical path to your SVA, as shown in the following example:
% vcs -assert disable_file=dsbl.txt top % cat dsbl.txt top.U.SVA1 top.U.COV1
In this example, dsbl.txt is disabling the assertions SVA1 and COV1. disable_rep_opt
Specifying a delay or a repetition value greater than 5000 in the assertion expression will affect both compile-time and runtime performance. Therefore, VCS optimizes expression and issues a warning message as shown below:
Warning-[LDRF] Large delay or repetition found. VCS will optimize compile time. However it may affect runtime. Use '-assert disable_rep_opt' to disable this optimization. "design.v", 156: (b_ce_idle [* 1:50000])
Use -assert disable_rep_opt to switch off the optimization and disable this message. dumpoff Disables the dumping of SVA information in the VPD file during simulation. vpiSeqBeginTime Enables you to see the simulation time that a SystemVerilog assertion sequence starts when using Debussy. vpiSeqFail Enables you to see the simulation time that a SystemVerilog assertion sequence doesnt match when using Debussy.
-ntb_filext .ext
Specifies an OpenVera file name extension. You can specify multiple file name extensions using the plus (+) character. -ntb_incdir directory_path Specifies the include directory path for OpenVera files. You can specify multiple include directories using the plus (+) character. -ntb_cmp Compiles and generates the testbench shell (file.vshell) and shared object files. -ntb_noshell Tells VCS not to generate the shell file. Use this option when you recompile a testbench. -ntb_opts keyword_argument The keyword arguments are as follows: ansi Preprocesses the OpenVera files in the ANSI mode. The default preprocessing mode is the Kernighan and Ritchie mode of the C language. check Does a bounds check on dynamic type arrays (dynamic, associative, queues) and issues an error at runtime. check=dynamic Same as check. Does a bounds check on dynamic type arrays (dynamic, associative, queues) and issues an error at runtime.
check=fixed Does a bounds check only on fixed size arrays and issues an error at runtime. check=all Does a bounds check on both fixed size and dynamic type arrays and issues an errors at runtime. dep_check Enables dependency analysis and incremental compilation. Detects files with circular dependencies and issues an error message when VCS cannot determine which file to compile first. no_file_by_file_pp By default, VCS does file-by-file preprocessing on each input file, feeding the concatenated result to the parser. This argument disables this behavior. print_deps Tells VCS to display the dependencies for the source files on the screen. Enter this argument with the dep_check argument. rvm Use rvm when RVM or VMM is used in the testbench. For more information, refer to the Using VMM with SV section. sv_fmt The default padding used in displayed or printed strings is right padding. The sv_fmt option specifies left padding. For example, when -ntb_opts sv_fmt is used, the result of
$display("%10s", "my_string");
is to put 10 spaces to the left of my_string. To specify right padding when -ntb_opts sv_fmt is used, put a dash before the number of spaces. For example, the result of
$display("%-10s", "my_string");
is to put 10 spaces to the right of my_string. tb_timescale=value Specifies an overriding timescale for the testbench, whenever the required testbench timescale is different from that of the design. It must be used in conjunction with the -timescale option that specifies the timescale for the design. If the required testbench timescale is different from the design or DUT timescale, then both the testbench timescale and the DUT timescale must be passed during VCS compilation. Example: The following command specifies a required testbench timescale of 10ns/10ps and a design timescale of 1ns/1ps: %> vcs -ntb_opts tb_timescale=1ns/1ps -timescale=10/10ns file.sv tokens
Preprocesses the OpenVera files to generate two files, tokens.vr and tokens.vrp. The tokens.vr contains the preprocessed result of the non-encrypted OpenVera files, while the tokens.vrp contains the preprocessed result of the encrypted OpenVera files. If there is no encrypted OpenVera file, VCS sends all the OpenVera preprocessed results to the tokens.vr file. use_sigprop Enables the signal property access functions. For example, vera_get_ifc_name(). vera_portname Specifies the following: -The Vera shell module name is named vera_shell. -The interface ports are named ifc_signal. -Bind signals are named, for example, as: \if_signal[3:0]. -ntb_shell_only Generates only a .vshell file. Use this option when compiling a testbench separately from the design file. -ntb_sfname filename Specifies the file name of the testbench shell. -ntb_sname module_name Specifies the name and directory where VCS writes the testbench shell module. -ntb_spath
Specifies the directory where VCS writes the testbench shell and shared object files. The default is the compilation directory. -ntb_vipext .ext Specifies an OpenVera encrypted-mode file extension to mark files for processing in OpenVera encrypted IP mode. Unlike the -ntb_filext option, the default encrypted-mode extensions .vrp and .vrhp are not overridden and will always be in effect. You can pass multiple file extensions at the same time using the plus (+) character. -ntb_vl Specifies the compilation of all Verilog files, including the design, the testbench shell file, and the top-level Verilog module.
Specifies a file name extension for Verilog 2001 source files. If you use a different file name extension for the Verilog 2001 part of your source code and you use this option, you can omit the +v2k option. Note: If you specify this option in a command to run a design, then this option behaves as the +v2k option, which does the semantic check on the entire design with V2K LRM syntax. +verilog1995ext+ext Specifies a file name extension for Verilog 1995 files. Using this option allows you to write Verilog 1995 code that would be invalid in Verilog 2001 or SystemVerilog code, such as using Verilog 2001 or SystemVerilog keywords, like localparam and logic, as names. Note: Do not enter all three of these options on the same command line. -extinclude If a source file for one version of Verilog contains the include compiler directive, VCS by default compiles the included file for the same version of Verilog, even if the included file has a different filename extension. If you want VCS to compile the included file with the version specified by its extension, enter this compile-time option. The following code examples show using this option. If source file a.v contains the following:
`include b.sv module a(); reg ar;
endmodule
VCS compiles b.sv for SystemVerilog with the following command line:
vcs a.v +systemverilogext+.sv -extinclude
-comp64 Enables 64-bit compilation that generates a 32-bit simv executable. Note: The following are the limitations of -comp64 option: - OpenVera Native Testbench (OV-NTB) and SystemVerilog Native Testbench (SV-NTB) are not supported. - Cross-compilation is not supported in pure SystemC simulation. - Interactive debugging with CBug is not supported on -comp64 flow of VCS.
Specifies compiling separate files for minimum, typical, and maximum delays when there are min:typ:max delay triplets in SDF files. If you use this option, you can use the +mindelays, +typdelays, or +maxdelays options at runtime to specify which compiled SDF file VCS uses. Do not use this option with the +maxdelays, +mindelays, or +typdelays compile-time options. +charge_decay Enables charge decay in trireg nets. Charge decay will not work if you connect the trireg to a transistor (bidirectional pass) switch such as tran, rtran, tranif1, or rtranif0. +delay_mode_path For modules that contain specify blocks, ignores the delay specifications on all gates and switches and uses only the module path delays and the delay specifications on continuous assignments. +delay_mode_zero Changes all the delay specifications on all gates, switches, and continuous assignments to zero and changes all module path delays in specify blocks to zero. +delay_mode_unit Ignores the module path delays in specify blocks and changes all the delay specifications on all gates, switches, and continuous assignments to the shortest time precision argument of all the timescale compiler directives in the source code. The default time unit and time precision argument of the timescale compiler directive is 1s.
+delay_mode_distributed Ignores the module path delays in specify blocks and uses only the delay specifications on all gates, switches, and continuous assignments. +maxdelays Specifies using the maximum timing delays in min:typ:max delay triplets when compiling the SDF file. The mtm_spec argument to the $sdf_annotate system task overrides this option. +mindelays Specifies using the minimum timing delays in min:typ:max delay triplets when compiling the SDF file. The mtm_spec argument to the $sdf_annotate system task overrides this option. +typdelays Specifies using the typical timing delays in min:typ:max delay triplets when compiling the SDF file. The mtm_spec argument to the $sdf_annotate system task overrides this option. +multisource_int_delays Enables the multisource INTERCONNECT feature, including transport delays with full pulse control. +nbaopt Removes all intra-assignment delays in all the nonblocking assignment statements in the design. Many users enter a #1 intraassignment delay in nonblocking procedural assignment statements to make debugging in the Wave window easier. For example:
These delays impede the simulation performance of the design, so after debugging, you can remove these delays with this option. Note: The +nbaopt option removes all intra-assignment delays in all the nonblocking assignment statements in the design, not just the #1 delays. +sdf_nocheck_celltype For a module instance to which an SDF file back-annotates delay data, disables comparing the module identifier in the source code with the CELLTYPE entry in the SDF file. +transport_int_delays Enables transport delays for delays on nets with a delay backannotated from an INTERCONNECT entry in an SDF file. The default is inertial delays. +transport_path_delays Enables transport delays for module path delays. -sdfretain Enables timing annotation as specified by a RETAIN entry on IOPATH delays. By default, VCS ignores RETAIN entries with the following warning message:
Warning-[SDFCOM_RCI] RETAIN clause ignored SDF_filename, line_number module: module_name, "instance: hierarchical_name" SDF Warning: RETAIN clause ignored, but IOPATH annotated, Please use -sdfretain switch to consider RETAIN
Compile-time Options B-28
The syntax for RETAIN entries are as follows: (IOPATH port_spec port_instance (RETAIN delval_list) delval_list)* For example: (IOPATH RCLK DOUT[0] (RETAIN (40)) (100.1) (100.2)) -sdfretain=warning If the RETAIN entry values are larger than the delay values, VCS displays the following warning message at runtime:
Warning-[SDFRT_IRV] RETAIN value ignored RETAIN value is ignored as it is greater than IOPATH delay
If you want to see a warning message at compile-time, enter this option along with the -sdfretain option. The following is an example of this warning message:
Warning-[SDFCOM_RLTPD] RETAIN value larger than IOPATH delay SDF_filename, line_number module: module_name, "instance: hierarchical_name" SDF Warning: RETAIN value (value) is larger than IOPATH delay, RETAIN will be ignored at runtime
+iopath+edge+sub-option This option is used when edge sensitivity is used in IOPATH SDF file entries. The different sub-options used with +iopath+edge+option and their descriptions are as follows: +iopath+edge+strict
Compile-time Options B-29
This option is used for LRM compliance. When edge sensitivity is specified for the input port in the SDF file and corresponding arc is not found in Verilog model, VCS by default does not give the warning message, you should use the switch +iopath+edge+strict to display the warning message. After the warning message is displayed, the data from SDF will not be back-annotated to the Verilog model. +iopath+edge+match This option can be used to make the annotation work by ignoring the edge in SDF. +iopath+edge+max This option is used for annotating higher delays. +iopath+edge+min This option is used for annotating smaller delays.
+nospecify Suppresses module path delays and timing checks in specify blocks. This option can significantly improve simulation performance. +notimingcheck Tells VCS to ignore timing check system tasks when it compiles your design. This option can moderately improve simulation performance. The extent of this improvement depends on the number of timing checks that VCS ignores. You can also use this option at runtime to disable these timing checks after VCS has compiled them into the executable. However, the executable simulates faster if you include this option at compile-time so that the timing checks are not in the executable. If you need the delayed versions of the signals in negative timing checks but want faster performance, include this option at runtime. The delayed versions are not available if you use this option at compile-time. Note: - VCS recognizes +notimingchecks to be the same as +notimingcheck when you enter it on the vcs or simv command line. - The +notimingcheck option has higher precedence than any tcheck command in UCLI. +no_notifier Disables toggling of the notifier register that you specify in some timing check system tasks. This option does not disable the display of warning messages when VCS finds a timing violation that you specified in a timing check. +no_tchk_msg
Disables display of timing violations, but does not disable the toggling of notifier registers in timing checks. This is also a runtime option.
Specifies that when VCS encounters a pulse shorter than the module path delay, VCS waits until the module path delay elapses and then drives an X value on the module output port and displays an error message. It drives that X value for a simulation time equal to the length of the short pulse or until another simulation event drives a value on the output port. +pulse_on_detect Specifies that when VCS encounters a pulse shorter than the module path delay, VCS immediately drives an X value on the module output port, and displays an error message. It does not wait until the module path delay elapses. It drives that X value until the short pulse propagates through the module or until another simulation event drives a value on the output port.
Otherwise, the negative INTERCONNECT delay will be ignored, and a warning message is generated for the same. Similarly, to consider a negative IOPATH delay, the sum of IOPATH and DEVICE delays should be greater than zero. Otherwise, the negative IOPATH delay will be ignored, and a warning message is generated for the same. Limitations This option is not supported in the following scenarios: - Precompiled SDF - RETAIN on negative IOPATH - INCREMENT delay +neg_tchk Enables negative values in timing checks. +old_ntc Prevents the other timing checks from using delayed versions of the signals in the $setuphold and $recrem timing checks. +NTC2 In $setuphold and $recrem timing checks, specifies checking the timestamp and timecheck conditions when the original data and reference signals change value instead of when their delayed versions change value. +overlap
Enables accurate simulation of multiple non-overlapping violation windows for the same signals specified with negative delay values back-annotated from an SDF file to timing checks.
- You can specify all compile-time options that begin with a plus (+) character. There is a limitation you can only specify the following compile-time options that begin with a minus (-) character:
-f -y -gen_asm -l -u -gen_obj -v
-file filename Specify a file that contains a list of source files and VCS compiletime options, including C source files and object files. You can use this option to overcome the limitation of the -f compile-time option. Limitations of -f and -file options These options do not support the -full64 and -comp64 options in the file. You must enter these options on the vcs command-line. You cannot specify escape characters in the file. You cannot use meta characters in the file, except * and $.
Tells VCS not to compile the following runtime options into the simv executable. This option is used to counter the +plusarg_save option on a previous line.
Specifies the name of your main() routine. You write your own main() routine when you are writing a C++ application or when your application does some processing before starting the simv executable. Note: Do not use the -e option with the VCS/SystemC Cosimulation Interface. -slave Specifies VCS should build a shared executable library instead of simv executable. This option enables the slave mode operation of VCS . Note: - In this case, your C program hosts the main() routine. Hence, you must rename vcs main() routine using the -e option. - Some of the VCS features like UCLI, DVE, $save, and $restart are not supported in slave mode. For more information on features that are supported with VCS slave mode, contact [email protected].
-P pli.tab
Compiles a user-defined PLI definition table file. +vpi Enables the use of VPI PLI access routines. +vpi+1
Allows you to reduce the runtime memory by reducing the information storage for VPI interface at runtime. This option limits the behavioral information at compile-time, but preserves the structural information. This option allows you to: - Browse the design hierarchy and read the values of variables. This facilitates debugging. - Write over or force values on variables using vpi_put_value(). This allows a foreign language testbench to drive a stimulus to a Verilog design. - Register VPI callbacks. This facilitates the waveform dumping features. However, certain advance debugging features (such as Line stepping, Driver/Loads information, and so on) will not be available. Limitations: - You cannot use this option to browse, enable, or disable SV and RT assertions. Note: The +vpi+1+assertion option allows you to browse, enable, and disable SV and RT assertions to the base features of +vpi+1. - If you use +vpi+1 with any debug option (-debug_all, debug_pp, or -debug), and try to use UCLI commands, then some of the commands may fail. No diagnostics or error messages will be generated to suggest that those commands are failing due to existence of +vpi+1 option. +vpi+1+assertion
Compile-time Options B-39
Allows you to browse, enable, and disable SV and RT assertions to the base features of +vpi+1. -load shared_library:registration_routine Specifies the registration routine in a shared library for a VPI application. -use_vpiobj Specifies the vpi_user.c file that enables you to use the vpi_register_systf VPI access routine.
These options can also be entered at runtime. Entering them at compile-time modifies the simv executable so that it runs as if these options were always entered at runtime.
VCS does not display this message when it finds a module definition in a Verilog library file that resolves a module instantiation statement. +lint=[no]ID|none|all Enables messages that tell you when your Verilog code contains something that is bad style, but is often used in designs.
-no_error ID+ID Changes the error messages with the UPIMI and IOPCWM IDs to warning messages with the -no_error compile-time option. You include one or both IDs as arguments, for example:
-noerror UPIMI+IOPCWM
This option does not work with the ID for any other error message.
-notice
Enables verbose diagnostic messages. -q Quiet mode; suppresses messages such as those about the C compiler VCS is using, the source files VCS is parsing, the top-level modules, or the specified timescale. -V Verbose mode; compiles verbosely. The compiler driver program prints the commands it executes as it runs the C compiler, assembler, and linker. If you include the -R option with the -V option, the -V option is also passed to runtime executable, just as if you had entered simv -V. -Vt Verbose mode; provides CPU time information. Like -V, but also prints the amount of time used by each command. Use of the -Vt option can cause the simulation to slow down. +warn=[no]ID|none|all Uses warning message IDs to enable or disable display of warning messages. In the following warning message:
Compile-time Options B-43
The text string TFIPC is the message ID. The syntax of this option is as follows:
+warn=[no]ID|none|all,...
Where:
no none all Specifies disabling warning messages with the ID that follows. There is no space between the keyword no and the ID. Specifies disabling all warning messages. IDs that follow, in a comma-separated list, specify exceptions. Specifies enabling all warning messages, IDs that follow preceded by the keyword no, in a comma separated list, specify exceptions.
The following are examples that show how to use this option:
+warn=noIPDW +warn=none,TFIPC +warn=noIPDW,noTFIPC +warn=all Enables all warning messages except the warning with the IPDW ID. Disables all warning messages except the warning with the TFIPC ID. Disables the warning messages with the IPDW and TFIPC IDs. Enables all warning messages. This is the default.
Enables recording in VPD files, the transition times and values of nets and registers in all modules defined under the celldefine compiler directive or defined in a library that you specify with the -v or -y options. This option also enables full PLI access to these modules. +nocelldefinepli+1 Disables recording in VPD files, the transition times and values of nets and registers in all modules defined under the celldefine compiler directive. This option also disables full PLI access to these modules. Modules in a library file or directory are not affected by this option unless they are defined under the celldefine compiler directive. +nocelldefinepli+2 In VPD files, disables recording the transition times and values of nets and registers in all modules defined under the celldefine compiler directive or defined in a library that you specify with the -v or -y options, whether the modules in these libraries are defined under the celldefine compiler directive or not. This option also disables PLI access to these modules. Disabling recording of transition times and values of the nets and registers in library cells can significantly increase simulation performance. Note: Disabling recording transitions in library cells is intended for batch simulation only and not for interactive debugging with DVE. Any attempt in DVE to access a part of your design for which VPD has been disabled may have unexpected results. +nocelldefinepli+1+ports
Removes the PLI capabilities from `celldefine modules but allows PLI access to port nodes and parameters. +nocelldefinepli+2+ports Removes the PLI capabilities from library and celldefine modules and allows PLI access to port nodes and parameters.
Returns useful information about a number of things: the version of VCS that you have set the VCS_HOME environment variable to, the name of your work station, your workstations platform, the host ID of your workstation (used in licensing), the version of the VCS compiler (same as VCS) and the VCS build date.
By default, VCS compiles module definitions into individual object files and sends all the object files in a command line to the linker. Some platforms use a fixed-length buffer for the command line, and if VCS sends too long a list of object files, this buffer overflows and the link fails. A solution to this problem is to have the linker create temporary object files containing more than one module definition so there are fewer object files on the linker command line. With this option, you enable creating these temporary object files and specify how many module definitions are in these files. Using this option briefly doubles the amount of disk space used by the linker because the object files containing more than one module definition are copies of the object files for each module definition. After the linker creates the simv executable, it deletes the temporary object files. -picarchive VCS can fail during linking due to the following two reasons: - Huge size of object files: VCS compiles the units of your design into object files, then calls the linker to combine them together. Sometimes the size of a design is large enough that the size of text section of these object files exceeds the limit allowed by the linker. If so, the linker fails and generates the following error: relocation truncated to fit:.... - Large number of object files: By default, VCS compiles module or entity definitions into individual object files and sends this list of object files in a single command line to the linker. Some platforms use a fixed-length buffer for the command line. If VCS sends a long list of object files, this buffer overflows and the link fails, generating errors such as:
make: execvp: gcc: Argument list too long make: execvp: g++: Argument list too long You can use the -picarchive option to deal with the above linker errors. The picarchive option does the following: 1. Enables Position Independent Code (PIC) object file generation along with linking the shared object version of VCS libraries. 2. Archives generated PIC code into multiple shared objects inside simv.daidir or simv.db.dir directory. 3. Links the Shared objects at runtime to the final executable, instead of linking all the objects statically into final executable in a single step at compile-time.
Passes options to the C compiler or assembler. -CFLAGS options Passes options to C compiler. Multiple -CFLAGS are allowed. Allows passing of C compiler optimization levels. For example, if your C code, test.c, calls a library file in your VCS installation under $VCS_HOME/include, use any of the following CFLAGS option arguments:
or
%setenv CWD pwd %vcs top.v test.c -CFLAGS "-I$CWD/include"
or
%vcs top.v test.c -CFLAGS "-I../include"
Note: The reason to enter "../include" is because VCS creates a default csrc directory where it runs gcc commands. The csrc directory is under your current working directory. Therefore, you need to specify the relative path of the include directory to the csrc directory for gcc C compiler. Further, you cannot edit files in the csrc because VCS automatically creates this directory. -cpp Specifies the C++ compiler. Note: If you are entering a C++ file or an object file compiled from a C++ file on the vcs command line, you must tell VCS to use the standard C++ library for linking. To do this, enter the -lstdc++ linker flag with the -LDFLAGS elaboration option. For example:
vcs top.v source.cpp -P my.tab \ -cpp /net/local/bin/c++ -LDFLAGS -lstdc++
-jnumber_of_processes
Compile-time Options B-50
Specifies the number of processes that VCS forks for parallel compilation. There is no space between the "j" character and the number. You can use this option in any compilation mode: directly generating object files from the parallel compilation of your Verilog source files (-gen_obj, default on the Solaris and Linux platforms), generating intermediate assembly files (-gen_asm) and then their parallel assembly, or generating intermediate C files (-gen_c) and their parallel compilation. -C Stops after generating the C code intermediate files. -O0 Suppresses optimization for faster compilation (but slower simulation). Suppresses optimization for how VCS both writes intermediate C code files and compiles these files. This option is the uppercase letter "O" followed by a zero with no space between them. -Onumber Specifies an optimization level for how VCS both writes and compiles intermediate C code files. The number can be in the 0-4 range; 2 is the default, 0 and 1 decrease optimization, 3 and 4 increase optimization. This option is the uppercase letter "O" followed by 0, 1, 2, 3 or 4 with no space between them. See above, for additional information regarding the -O0 variant. -override-cflags
Tells VCS not to pass its default options to the C compiler. By default, VCS has a number of C compiler options that it passes to the C compiler. The options it passes depends on the platform, whether it is a 64-bit compilation and other factors. VCS passes these options and then passes the options you specify with the -CFLAGS compile-time option.
Creates a protected source file, only encrypting `protect/ `endprotect regions. +object_protect <sourcefile> Debugs the partially encrypted source code.
vcs +protect +object_protect <sourcefile.v>
+putprotect+target_dir Specifies the target directory for protected files. +sdfprotect[file_suffix] Creates a protected SDF file. -Xmangle=number Produces a mangled version of input, changing variable names to words from list. Useful to get an entire Verilog design into a single file. Output is saved in the tokens.v file. You can substitute -Xman for -Xmangle. The argument number can be 1, 4, 12, or 28: -Xman=1 Randomly changes names and identifiers, and removes comments, to provide more secure code. -Xman=4 Preserves variable names, but removes comments. -Xman=12
Does the same thing as -Xman=4, but also enters, in comments, the original source file name and the line number of each module header. -Xman=28 Does the same thing as -Xman=12, but also writes at the bottom of the file comprehensive statistics about the contents of the original source file. -Xnomangle=.first|module_identifier,... Specifies module definitions whose module and port identifiers VCS does not change. You use this option with the -Xman option. The .first argument specifies the module by location (first in file) rather than by identifier. You can substitute -Xnoman for -Xnomangle.
+bidir+1 Tells VCS to finish compilation when it finds a bidirectional registered mixed-signal net. +print+bidir+warn Tells VCS to display a list of bidirectional, registered, mixed signal nets.
The path to the parameter is similar to a hierarchical name, except that you use the forward slash character (/) instead of a period as the delimiter.
Suppress the warning message when the value of a conditional expression transitions to an X or Z value and then to 0 or 1 in the same simulation time step.
The default_timecale value should be in the same format as the `timescale directive. If the default timescale is not specified, then 1s/1s is taken as the default timescale of the compilation-unit. -override_timescale=time_unit/time_precision Overrides the time unit and precision unit for all the timescale compiler directives in the source code, and, similar to the -timescale option, provides a timescale for all module definitions that precede the first timescale compiler directive. Do not include spaces when specifying the arguments to this option.
val: The value that overrides the Specified parameter. path: Specifies the absolute hierarchical path to the parameter value which is to be overridden. Note: The gfile supports only VHDL syntax for hierarchical path representation. All escaped identifiers in the Verilog path must be converted into VHDL extended identifiers. If the escaped identifier contains \ characters, they must be escaped with another \ character. For example, consider the following Verilog hierarchical path for the parameter P1. top.dut.\inst1_\cpu .inst2.P1 The corresponding generics_file entry is as follows: assign hffffffff /top/dut/\inst1_\\cpu\/ inst2/P1 All for-generate and instance-array parentheses must be round parentheses, and the path delimiter must be /. All instance paths must start with /. Example: You can override the parameter and generic values using the -gfile option as follows: vcs test.v gfile overrides.txt
where, overrides.txt contains the following entries: assign hffffffff /top/dut/\inst1_\\cpu\/ inst2/P1 assign P2 assign DUMMY /top/dut/\inst1_\\cpu\/inst2/
10.34 /top/dut/\inst1_\\cpu\/inst2/P3
Supported Data Types: The following data types are supported in -gfile option: - Integer - Real - String The -gfile option ignores other data types with a suitable warning message. -pvalue You can use the -pvalue compile-time option for changing the parameter values from the vcs command line. You specify a parameter with the -pvalue option. It has the following syntax: vcs -pvalue+hierarchical_name_of_parameter= value Example:
vcs source.v -pvalue+test.d1.param1=33 Note: The -pvalue option does not work with a localparam or a specparam.
Determines the finer time resolution of SystemC and HDL in case of a mismatch, and sets it as the simulators timescale. VCS may be unable to adjust the time resolution if you elaborate your HDL with the -timescale option or use the sc_set_time_resolution() function call in your SystemC code. In such cases, VCS reports an error and does not create simv. Note: You must use this option along with the -sysc option.
TetraMAX
+tetramax Enables simulation of TetraMAXs testbench in zero delay mode.
VCS errors out if you use "0" or a negative number as a multiconcat multiplier. You can change that error to a warning message using this option.
Enabling Dumping
+vcs+vcdpluson A compile-time substitute for $vcdpluson option. The +vcs+vcdpluson switch enables dumping for the entire design. You would however need to use a debug switch (example -debug_pp) to dump the data.
Specifies a file where VCS records compilation messages. If you also enter the -R option, VCS records messages from both compilation and simulation in the same file. -a logFilename Captures simulation output and appends the log information in the existing log file. If the log file doesnt exist, then this option would create a log file.
Displays a runtime error message and terminates the simulation when a zero delay loop is detected. By default, VCS checks if a simulation event loops for more than 2,000,000 times during the same simulation time. You can change this default value by specifying any number along with this option.
Gate-Level Performance
-hsopt=gates Improves runtime performance on gate-level designs (both functional and timing simulations with SDF).You may see some compile-time degradation when you use this switch.
C
Simulation Options A
This appendix describes the options and syntax associated with the simv executable. These runtime options are typically entered on the simv command line but some of them can be compiled into the simv executable at compile-time. This appendix describes the following runtime options: Options for Simulating Native Testbenches Options for SystemVerilog Assertions Options to Control Termination of Simulation Options for Enabling and Disabling Specify Blocks Options for Specifying When Simulation Stops Options for Recording Output Options for Controlling Messages
Simulation Options C-1
Options for VPD Files Options for VCD Files Options for Specifying Delays Options for Flushing Certain Output Text File Buffers Options for Licensing Options to Specify User-Defined Runtime Options in a File Options for Initializing Memories and Registers with Random Values at Runtime General Options
Note: You can also use this runtime option with the coverage_control() system task. The coverage_control() system task enables/disables data collection for one or more coverage groups at the program level. The runtime option takes precedence over the system task. For more information on this system task, refer to the OpenVera Language Reference Manual: Native Testbench. +ntb_cache_dir Specifies the directory location of the cache that VCS maintains as an internal disk cache for randomization. +ntb_delete_disk_cache=value Specifies whether VCS deletes the disk cache for randomization before simulation. The valid values are: 0 - do not delete (the default condition) 1 - delete the disk cache +ntb_disable_cnst_null_object_warning[=value] VCS produces the following warning when a null object handle is encountered in an object being randomized. Allowed values are 0 and 1. 0 - Do not disable null object warning (this is the default) 1 - Disable null object warning Here is an example of the null object warning:
Warning-[CNST-PPRW] Constraint randomize NULL object warning test.sv, <line number>. Null object found during randomization. Please make sure all random variables/arrays/function calls being randomized are allocated fully and properly. The null handle may be intentional or the result of an oversight. If you want to randomize objects which contain null handles, you can use this switch to disable the runtime warning. +ntb_enable_checker_trace=0|1 In-line constraint checker using randomize(null) returns 1 if all constraints are satisfied and 0 otherwise. This option controls whether the constraint checker trace is enabled or not. The valid arguments are as follows: 0 - do not display the constraint checker trace (default) 1 - displays the constraint checker trace If +ntb_enable_solver_trace is specified without an argument, the default value is 1. If it is not specified, the default value is 0. +ntb_enable_checker_trace_on_failure[=value] Enables a mode that prints trace information only when the randomize returns 0. Allowed values are 0, 1, and 2. 0 1 2 Disables tracing Enables tracing Enables more verbose message in trace
In addition to the message in trace with option 2, the checker reports all the earlier solved constraints, which could have lead to the current failing constraint.
If ntb_enable_checker_trace_on_failure is specified without an argument, the default value is 1. If the ntb_enable_checker_trace_on_failure is not specified, the default value is 2. +ntb_enable_solver_trace_on_failure[=0|1|2|3] Displays trace information when the VCS constraint solver fails to compute a solution. The valid argument values are as follows: 0 1 2 3 Disables displaying trace information Enables displaying trace information Enables more verbose trace information In addition to the more verbose trace information specified with 2, the solver reports all the earlier solved constraints, which could have lead to the current failing constraint.
+ntb_exit_on_error[=value] Causes VCS to exit when the value is less than 0. The value can be: 0 - continue 1 - exit on first error (default value) N - exit on nth error
When the value is 0, the simulation finishes regardless of the number of errors. +ntb_load=path_name_to_libtb.so Specifies loading the testbench shared object file, libtb.so. +ntb_random_seed=value Sets the seed value to be used by the top-level random number generator at the start of simulation. The srandom(seed) system function call overrides this setting. The value can be any integer. +ntb_random_seed_automatic Picks a unique value to supply as the first seed used by a testbench. The value is determined by combining the time of day, host name and process id. This ensures that no two simulations have the same starting seed. The +ntb_random_seed_automatic seed appears in both the simulation log and the coverage report. When you enter both +ntb_random_seed_automatic and +ntb_random_seed VCS MX displays a warning message and uses the +ntb_random_seed value. +ntb_random_reseed Enables the re-seeding of the value the top-level random number generator uses after a save and restore of the simulation. You enter this option with the +ntb_random_seed_automatic or +ntb_random_seed=value options. The seed value after the restore is the same as the one specified or generated by these other options.
if you omit these other options VCS ignores the +ntb_random_reseed option and displays the following informational message:
Info-[RNG-SEED-MISSING] New seed was not specified for reseeding. Please use runtime option +ntb_random_seed= or +ntb_random_automatic to specify new seed.
The srandom(seed) system function overrides this re-seeding. +ntb_solver_array_size_warn=value Specifies the array size warning limit (default is 10000) for constrained array sizes. +ntb_solver_debug=keyword_argument Tells VCS to give you more information so you can debug the constraints for the randomize() calls in batch mode. The keyword arguments are as follows: extract Tells VCS to extract a standalone test case in SystemVerilog for the specified randomize() call(s). To use this keyword argument also enter the +ntb_solver_debug_filter runtime option. profile Enables constraint profiling in VCS . You can view the constraint profile report in simv.cst/html/profile.xml using a web browser (simv is the default name of the VCS simv executable).
This keyword argument also writes a file with a listing of the top randomize calls in simv.cst/serial2trace.txt (simv is the default name of the VCS simv executable). serial Displays the randomize serial number at the end of each randomize() completion. trace Displays the solver trace to show how VCS solved the constraints for the random variables in specified randomize() call(s). To use this argument also enter the +ntb_solver_debug_filter runtime option. trace_all Displays the solver trace for all randomize() calls. +ntb_solver_debug=trace_all is the equivalent of entering the following options and arguments together: +ntb_solver_debug=trace +ntb_solver_debug_filter=all You can enter multiple the keyword arguments using a plus (+) as a delimiter, for example:
vcs source.sv +ntb_solver_debug=serial+extract+profile \ +ntb_solver_debug_filter=12
You cannot enter multiple +ntb_solver_debug options. +ntb_solver_debug_filter= serial_num [.partition_num] | file[:filename] | all
Specifies a list of randomize() calls that VCS displays debug information about. You can specify this list in the following ways: - a comma separated list, for example: +ntb_solver_debug_filter=1.5,4,20 This example specifies: the 5th partition of 1st call, and all partitions of the 4th and 20th call. - in a file. The default filename is: simv.cst/serial2trace.txt. You just need to enter the keyword argument file if the file is the default file name and location. - the keyword all as in: +ntb_solver_debug_filter=all Specifying all means you want debug information about all randomize() calls. Note: The all argument can result in a large amount of solver trace information or extracted test cases. +ntb_solver_mode=value Allows you to choose between one of two constraint solver modes. When set to 1, the solver spends more preprocessing time in analyzing the constraints during the first call to randomize() on each class. Therefore, subsequent calls to randomize() on that class are very fast. When set to 2, the solver does minimal preprocessing, and analyzes the constraint in each call to randomize(). The default is 2. +ntb_stop_on_constraint_solver_error=0|1
Specifies whether VCS continues or exits after a constraint solver failure due to constraint inconsistency. 0 1 VCS to continues to run after a constraint solver failure (default). VCS exits on the first constraint solver error
Disables the collection of coverage information for cover statements after the cover statements are covered N number of times. N must be a positive integer; it cannot be 0. maxfail=N Limits the number of failures for each assertion to N. When the limit is reached, VCS disables the assertion. You must supply N, otherwise no limit is set. maxsuccess=N Limits the total number of reported successes to N. You must supply N, otherwise no limit is set. VCS continues to monitor assertions even after the limit is reached. nocovdb Tells VCS not to write the program_name.db database file for assertion coverage. nopostproc Disables the display of the SystemVerilog assert and cover statement summary at the end of simulation. This begins with the assert and cover statements that started but did not finish, in the following format: "source_filename.v", line_number: assert_or_cover_statement_hierarchical_name: started at simulation_time not finished If the assert or cover statement doesnt start, this summary also reports this in the following format::
**** Following assertions did not fire at all during simulation. ***** "source_filename.v", line_number: assert_or_cover_statement_hierarchical_name: No attempt started This is followed by a cover statement summary in the following format: "source_filename.v", line_number: cover_statement_hierarchical_name, number attempts, number match no_fatal_action Excludes failures on SVA assertions with fail action blocks for computation of failure count in the assert [global_]finish_maxfail=N runtime option. no_default_msg[=SVA|OVA|PSL] Disables the display of default failure messages for SVA assertions that contain a fail action block, and OVA and PSL assertions that contain user messages. quiet Disables the display of messages when assertions fail. quiet1 Disables the display of messages when assertions fail, but enables the display of summary information at the end of simulation. For example:
Summary: 2 assertions, 2 with attempts, 2 with failures report[=path/filename] Generates a report file in addition to printing results on your screen. By default, the report file name and location is ./assert.report, but you can change it by entering the path/filename argument. The report file name can start with a number or letter. The following special characters are acceptable in the file name: %, ^, and @. Using the following unacceptable special characters: #, &, *, [], $, (), or ! has the following consequences: - A file name containing # or & results in a file name truncation to the character before the # or &. - A file name containing * or [] results in a No match message. - A file name containing $ results in an Undefined variable message. - A file name containing () results in a Badly placed ()s message. - A file name containing ! results in an Event not found message. success Enables reporting of successful matches, and successes on cover and assert statements respectively, in addition to failures. The default is to report only failures.
vacuous Enables reporting of vacuous successes on assert statements in addition to the failures. By default, VCS reports only failures. verbose Adds more information to the end of the report specified by the report keyword argument, and a summary with the number of assertions present, attempted, and failed. hier=file_name Specifies a file to enable and disable SystemVerilog assertions when you simulate your design. This feature enables you to control which assertions are active and VCS records in the coverage database, without having to recompile your design. The types of entries you can make in the file are as follows:
-assert <assertion_name> or <assertion_hierarchical_name>
If assertion_name is provided, VCS disables the assertions based on wildcard matching of the name in the full design. If assertion_hierarchical_name is provided, VCS disables the assertions based on wildcard matching of the name in the particular hierarchy given. Examples -assert my_assert Disables all assertions with name my_assert in the full design. -assert A*
Simulation Options C-14
Disables all assertions whose name starts with A in the full design. -assert * Disables all assertions in the full design. -assert top.INST2.A Disables all assertions whose names start with A in the hierarchy top.INST2. If assertions whose name starts with A exists in inner scopes under top.INST2, they are not disabled. This command has affect on assertions only in scope top.INST2.
+tree <module_instance_name> or <assertion_hierarchical_name>
If module_instance_name is provided, VCS enables assertions in the specified module instance and all module instances hierarchically under that instance. If assertion_hierarchical_name is provided, VCS enables the specified SystemVerilog assertion. Wildcard characters can also be used for specifying the hierarchy. Examples +tree top.inst1 Enables the assertions in module instance top.inst1 and all the assertions in the module instances under this instance. +tree top.inst1.a1
Enables SystemVerilog assertion with the hierarchical name top.inst1.a1. +tree top.INST*.A1 Enables assertion A1 from all the instances whose names start with INST under module top.
-tree <module_instance_name> or <assertion_hierarchical_name>
If module_instance_name is provided, VCS disables the assertions in the specified module instance and all module instances hierarchically under that instance. If assertion_hierarchical_name is provided, VCS disables the specified SystemVerilog assertion. Wildcard characters can also be used for specifying the hierarchy. Examples -tree top.inst1 Disables the assertions in module instance top.inst1 and all the assertions in the module instances under this instance. -tree top.inst1.a1 Disables the SystemVerilog assertion with the hierarchical name top.inst1.a1. -tree top.INST*.A1 Disables assertion A1 from all the instances whose names start with INST under module top.
+module module_identifier VCS enables all the assertions in all instances of the specified module. For example, +module dev. VCS enables the assertions in all instances of module dev. -module module_identifier VCS disables all the assertions in all instances of the specified module. For example, -module dev. VCS disables the assertions in all instances of module dev. -assert assertion_block_identifier VCS disables the assertion with the specified block identifier. You can use wildcard characters in specifying the block identifier to specify more than one assertion. You can enter more than one keyword using the plus (+) separator. For example: -assert maxfail=10+maxsucess=20+success+filter. -cm assert Specifies monitoring for SystemVerilog assertions coverage. When enabled, the option -cm assert does the following: - Generates the number of attempts, pass, fail, and incomplete data. - Generates vacuous and non-vacuous coverage. - Irrespective of type of assert statement, reports coverage.
- Covers immediate and deferred assertions. - Does not cover Expect statement. - Affects SVA and OVA as well.
You can also use this option at compile time. Using this option at compile time tells VCS to ignore timing checks when it compiles your design so that the timing checks are not compiled into the executable. This results in a faster simulating executable than one that includes timing checks, which are disabled by this option at runtime. If you need the delayed versions of the signals in negative timing checks, but want faster performance, include this option at runtime. Note: The +notimingcheck option has higher precedence than any tcheck command in UCLI.
By default, VCS displays no more than ten warning and ten error messages about back-annotating delay information from SDF files. This option enables the display of all back-annotation warning and error messages. This default limitation on back-annotation messages applies only to messages displayed on the screen and written in the simulation log file. If you specify an SDF log file in the $sdf_annotate system task, this log file receives all messages. +vcs+nostdout Disables all text output from VCS including messages and text from $monitor and $display and other system tasks. VCS still writes this output to the log file if you include the -l option.
Specifies the name of the output VPD file (default is vcdplus.vpd). You must include the full file name with the .vpd extension. +vpdfilesize+number_of_megabytes Creates a VPD file that has a moving window in time while never exceeding the file size specified by number_of_megabytes. When the VPD file size limit is reached, VPD continues saving simulation history by overwriting older history. File size is a direct result of circuit size, circuit activity, and the data being saved. Test cases show that VPD file sizes will likely run from a few megabytes to a few hundred megabytes. Many users can share the same VPD history file, which may be a reason for saving all time value changes when you do simulation. You can save one history file for a design and overwrite it on each subsequent run. +vpdfileswitchsize+number_in_MB Specifies a size for the vpd file. When the vpd file reaches this size, VCS closes this file and opens a new one with the same hierarchy as the previous vpd file. There is a number suffix added to all new vpd file names to differentiate them. For example: simv +vpdfile+test.vpd +vpdfileswitchsize+10. The first vpd file is named test.vpd. When its size reaches 10MB, VCS starts a new file test_01.vpd, the third vpd file is test_02.vpd, and so on. +vpdignore
Tells VCS to ignore any $vcdplusxx system tasks and license checking. By default, VCS checks out a VPD PLI license if there is a $vcdplusxx system task in the Verilog source. In some cases, this statement is never executed and VPD PLI license checkout should be suppressed. The +vpdignore option performs the license suppression. +vpdports Causes VPD to store port information, which is then used by the Hierarchy Browser to show whether a signal is a port, and if so, its direction. This option to some extent affects simulation initialization time and memory usage for larger designs. +vpdportsonly Dumps only the port type information. +vpdnoports Dumps only the signal not the ports (input/output). +vpddrivers Stores data for changes on drivers of resolved nets. +vpdupdate Enables VPD file locking. +vpdnocompress Disables the default compression of data as it is written to the VPD file.
+vpdnostrengths Disables the default storage of strength information on value changes to the VPD file. Use of this option may lead to slight improvements in VCS performance.
Specifies using the maximum delays in min:typ:max delay triplets in module path delays and timing checks, if you compiled your design with the +allmtm compile-time option. Also specifies using the maximum timing delays in min:typ:max delay triplets in an uncompiled SDF file. If you compiled the SDF file with the +allmtm compile-time option, the +maxdelays option specifies using the compiled SDF file with the maximum delays. Another use for this runtime option is to specify timing for SWIFT VMC and SmartModels when you also include the +override_model_delays runtime option. +mindelays Specifies using the minimum delays in min:typ:max delay triplets in module path delays and timing checks, if you compiled your design with the +allmtm compile-time option. Also specifies using the minimum timing delays in min:typ:max delay triplets in an uncompiled SDF file. If you compiled the SDF file with the +allmtm compile-time option, the +mindelays option specifies using the compiled SDF file with the minimum delays. Another use for this runtime option is to specify timing for SWIFT VMC and SmartModels when you also include the +override_model_delays runtime option.
+typdelays Specifies using the typical delays in min:typ:max delay triplets in module path delays and timing checks, if you compiled your design with the +allmtm compile-time option. Also specifies using the typical timing delays in min:typ:max delay triplets in an uncompiled SDF file. If you compiled the SDF file with the +allmtm compile-time option, the +typdelays option specifies using the compiled SDF file with the typical delays. This is a default option. By default, VCS uses the typical delay in min:typ:max delay triplets in your source code and in uncompiled SDF files unless you specify otherwise with the mtm_spec argument to the $sdf_annotate system task. Also, by default, VCS uses the compiled SDF file with typical values. Another use for this runtime option is to specify timing for SWIFT VMC and SmartModels when you also include the +override_model_delays runtime option.
+vcs+flush+log Increases the frequency of dumping both the compilation and simulation log files. +vcs+flush+dump Increases the frequency of dumping all VCD files. +vcs+flush+fopen Increases the frequency of dumping all files opened by the $fopen system function. +vcs+flush+all Increases the frequency of dumping all log files, VCD files, and all files opened by the $fopen system function. These options do not increase the frequency of dumping other text files including the VCDE files specified by the $dumpports system task or the simulation history file for LSI certification specified by the $lsi_dumpports system task. You can also enter these options at compile time. There is no performance gain to entering them at compile time.
+vcs+lic+wait Waits for a network license if none is available when the job starts. -licwait timeout Enables license queuing, where timeout is the time in minutes that VCS waits for a license before finally exiting. -licqueue Tells VCS to wait for a network license if none is available.
Options for Initializing Memories and Registers with Random Values at Runtime
+vcs+initreg+0|1|random|<seed>
Initializes all state variables (reg data type) and memories (reg data type) in the design, to random logic 0 or 1, at time zero. It gives you the flexibility to override the initialization of random values requested at compile-time. The following table describes all combinations of this option:
Syntax +vcs+initreg+0 Description Initializes all state variables (reg data type) and memories (reg data type) in the design, to random logic 0. Initializes all state variables (reg data type) and memories (reg data type) in the design, to random logic 1. Initializes all state variables (reg data type) and memories (reg data type) in the design, to random logic 0 or 1 (with default seed). Initializes all state variables (reg data type) and memories (reg data type) in the design, to random logic 0 or 1, with user-defined seed 100. Note: seed cannot be 1 or 0 and 1 or 0 has special meaning.
+vcs+initreg+1
+vcs+initreg+random
+vcs+initreg+100
Note: - This option works only if the +vcs+initreg+random option is used at compile-time. - This option works only for the Verilog portion of the design. -This option does not initialize registers (variables) and memories other than the reg data type. To prevent race conditions, avoid the following when you use this option:
- Assigning initial values to a reg in their declaration, when the value you assign is not the same as the value specified with the +vcs+initreg+0|1|random|<seed> option. - Initializing state variables to state "X". - Inconsistent states in the design due to the randomization. Use Model For information on use model of this option, see Use Model section documented under Initializing Verilog Memories and Registers .
D
Compiler Directives and System Tasks
This appendix describes: Compiler Directives System Tasks and Functions
Compiler Directives
Compiler directives are commands in the source code that specify how VCS compiles the source code that follows them, both in the source files that contain these compiler directives and in the remaining source files that VCS subsequently compiles. Compiler directives are not effective down the design hierarchy. A compiler directive written above a module definition affects how VCS compiles that module definition, but does not necessarily affect how
VCS compiles module definitions instantiated in that module definition. If VCS has already compiled these lower-level module definitions, it does not recompile them. If VCS has not yet compiled these module definitions, the compiler directive does affect how VCS compiles them. Note: Compile-time options override compiler directives.
`resetall Resets all compiler directives. See IEEE 1364-2001 page 357. Syntax: `resetall
`ifdef Specifies compiling the source lines that follow if the specified text macro is defined by either the `define compiler directive or the +define compile-time option. See IEEE Std 1364-2001 page 353. Syntax: `ifdef text_macro_name group_of_lines The exception is the character string VCS, which is a predefined text macro in VCS. Therefore, in the following source code, VCS compiles and executes the first block of code and ignores the second block even when you do not include `define VCS or +define+VCS: `ifdef VCS
begin // Block of code for VCS . . . end `else begin // Alternative block of code . . . end `endif
When you encrypt source code, VCS inserts ifdef VCS before all encrypted parts of the code. `ifndef Specifies compiling the source code that follows if the specified text macro is not defined. See IEEE Std 1364-2001 page 353. Syntax: `ifndef text_macro_name group_of_lines
`undef Undefines a macro definition. See IEEE Std 1364-2001 page 351. Syntax: `undef text_macro_name
`endprotected Defines the end of protected code. Syntax: `endprotected `protect Defines the start of code to be protected. Syntax: `protect `protected Defines the start of protected code. Syntax: `protected
You can enable partial debug capability by adding the +object_protect switch to the VCS encryption command line, so that partial encryption is applied and the encrypted file is also enabled with debug capability (-debug_all) for the unencrypted objects.
In VCS, the default time unit is 1 s (a full second) and the default time precision is also 1 s.
$assertkill Tells VCS to stop monitoring any of the specified assertions that start at a subsequent simulation time, and stop the execution of any of these assertions that are now occurring. $asserton Tells VCS to resume the monitoring of assertions that it stopped monitoring due to a previous $assertoff or $assertkill system task.
$dumpall Creates a checkpoint in the VCD file. When VCS executes this system task, VCS writes the current values of all specified nets and registers into the VCD file, whether there is a value change at this time or not. $dumpoff Stops recording value change information in the VCD file. $dumpon Starts recording value change information in the VCD file. $dumpfile Specifies the name of the VCD file you want VCS to record. Syntax: $dumpfile("filename"); $dumpflush Empties the VCD file buffer and writes all this data to the VCD file. $dumplimit Limits the size of a VCD file. $dumpvars Specifies the nets and registers whose transition times and values you want VCS to record in the VCD file. Syntax: $dumpvars(level_number,module_instance | net_or_reg); You can specify individual nets or registers, or specify all the nets and registers, in an instance.
$dumpchange Tells VCS to stop recording transition times and values in the current dump file and to start recording in the specified new file. Syntax: $dumpchange("filename"); Code example: $dumpchange("vcd16a.dmp"); $fflush VCS stores VCD data in the operating systems dump file buffer and as simulation progresses, reads from this buffer to write to the VCD file on disk. If you need the latest information written to the VCD file at a specific time, use the $fflush system task. Syntax: $fflush("filename"); Code example: $fflush("vcdfile1.vcd"); $fflushall If you are writing more than one VCD file and need VCS to write the latest information to all these files at a particular time, use the $fflushall system task. Syntax: $fflushall; $gr_waves Produces a VCD file with the name grw.dump. In this system task, you can specify a display label for a net or register whose transition times and values VCS records in the VCD file. Syntax: $gr_waves(["label",]net_or_reg,...); Code example: $gr_waves("wire w1",w1, "reg r1",r1);
In the past, the $dumpports and $lsi_dumpports system tasks both generated simulation history files for LSI certification and had identical syntax except for the name of the system task. Syntax of the $dumpports system task is now: $dumpports(module_instance,[module_instance,] "filename"); You can specify more than one module instance. Code example: $dumpports(top.middle1,top.middle2, "dumpports.evcd"); If your source code contains a $dumpports system task, and you want it to generate simulation history files for LSI certification, include the +dumpports+lsi runtime option. $dumpportsoff Suspends writing to files specified in $lsi_dumpports or $dumpports system tasks. You can specify a file to which VCS suspends writing or specify no particular file, in which case VCS suspends writing to all files specified by $lsi_dumpports or $dumpports system tasks. See IEEE Std 1364-2001 page 340341. Syntax: $dumpportsoff("filename"); $dumpportson Resumes writing to the file after writing was suspended by a $dumpportsoff system task. You can specify the file to which you want VCS to resume writing or specify no particular file, in which case VCS resumes writing to all files to which writing was halted by any $dumpportsoff or $dumpports system tasks. See IEEE Std 1364-2001 page 340-341. Syntax: $dumpportson("filename");
$dumpportsall By default, VCS writes to files only when a signal changes value. The $dumpportsall system task records the values of the ports in the module instances, which are specified by the $lsi_dumpports or $dumpports system task, whether there is a value change on these ports or not. You can specify the file to which you want VCS to record the port values for the corresponding module instance or specify no particular file, in which case VCS writes port values in all files opened by the $lsi_dumpports or $dumpports system task. See IEEE Std 1364-2001 page 341. Syntax: $dumpportsall("filename"); $dumpportsflush VCS stores simulation data in a buffer during simulation from which it writes data to the file. If you want VCS to write all simulation data from the buffer to the file or files at a particular time, execute this $dumpportsflush system task. You can specify the file to which you want VCS to write from the buffer or specify no particular file, in which case VCS writes all data from the buffer to all files opened by the $lsi_dumpports or $dumpports system task. See IEEE Std 1364-2001 page 342. Syntax: $dumpportsfush("filename"); $dumpportslimit Specifies the maximum file size of the file specified by the $lsi_dumpports or $dumpports system task. You specify the file size in bytes. When the file reaches this limit, VCS no longer writes to the file. You can specify the file whose size you want to limit or specify no particular file, in which case your specified size limit applies to all files opened by the $lsi_dumpports or $dumpports system task. See IEEE Std 1364-2001 page 341342.
Compiler Directives and System Tasks D-17
Syntax: $dumpportslimit(filesize,"filename");
VPD files are commonly used in post-processing, where VCS writes the VPD file during batch simulation, and then you review the simulation results using DVE. There are system tasks that specify the information that VCS writes in the VPD file. Note: To use the system tasks for VPD files, you must compile your source code with the -debug_pp option. $vcdplusautoflushoff Turns off the automatic flushing of simulation results to the VPD file whenever there is an interrupt, such as when VCS executes the $stop system task. Syntax: $vcdplusautoflushoff;
$vcdplusautoflushon Tells VCS to flush or write all the simulation results in memory to the VPD file whenever there is an interrupt, such as when VCS executes a $stop system task or when you halt VCS using the UCLI stop command, or the Stop button on the DVE Interactive window. Syntax: $vcdplusautoflushon; $vcdplusclose Tells VCS to mark the current VPD file as completed, and close the file. Syntax: $vcdplusclose; $vcdplusdeltacycleon The $vcdplusdeltacycleon task enables reporting of delta cycle information from the Verilog source code. It must be followed by the appropriate $vcdpluson/$vcdplusoff tasks. Glitch detection is automatically turned on when VCS executes $vcdplusdeltacycleon unless you have previously used $vcdplusglitchon/off. Once you use $vcdplusglitchon/off, DVE allows you explicit control of glitch detection. Syntax
$vcdplusdeltacycleon;
Note: Delta cycle collection can start only at the beginning of a time sample. The $vcdplusdeltacycleon task must precede the $vcdpluson command to ensure that delta cycle collection will start at the beginning of the time sample.
$vcdplusevent The $vcdplusevent task allows you to record a unique event for a signal at the current simulation time unit. Syntax
$vcdplusevent(net_or_reg,"event_name", "<E|W|I><S|T|D>");
A symbol is displayed in DVE on the signals waveform and in the Logic Browser. The event_name argument appears in the status bar when you click on the symbol. E|W|I Specifies severity. - E for error, displays a red symbol. - W for warning, displays a yellow symbol. - I for information, displays a green symbol. S|T|D Specifies the symbol shape. - S for square. - T for triangle. - D for diamond. Do not enter space between the arguments E|W|I and S|T|D. Do not include angle brackets < >. There is a limit of 244 unique events. $vcdplusdumpportsoff
Tells VCS to suspend writing to VPD file the transition times and values of the module instance specified by $vcdplusdumpportson system task. You can use $vcdplusdumpportsoff system task with arguments, but it is not required. Syntax: $vcdplusdumpportsoff(level_number, module_instance); $vcdplusdumpportson Records transition times and values of ports in a module instance. A level value of 0 tells VCS to dump all levels below the specified instance. If you do not specify a level, the default level is 1. If you use the system task without arguments, VCS dumps all the ports from the entire design to the VPD file. Syntax: $vcdplusdumpportson(level_number, module_instance); Use $vcdplusdumpportson and $vcdplusdumpportsoff system tasks to create a VPD file with port drive information for bidirectional ports if you want to use dumpports and dumpvcdports options in vpd2vcd filtering. Note: This system task records additional drive information for inout ports of type wire. It does not dump ports with unpacked dimensions. Furthermore, it is unable to determine if a wire is being forced. $vcdplusfile Specifies the next VPD file that DVE opens during simulation, after it executes the $vcdplusclose system task and when it executes the next $vcdpluson system task. Syntax: $vcdplusfile("filename");
$vcdplusglitchon Turns on checking for zero delay glitches and other cases of multiple transitions for a signal at the same simulation time. Syntax: $vcdplusglitchon; $vcdplusflush Tells VCS to flush or write all the simulation results in memory to the VPD file at the time VCS executes this system task. Use $vcdplusautoflushon to enable automatic flushing of simulation results to the file when simulation stops. Syntax: $vcdplusflush; $vcdplusmemon Records value changes and times for memories and multidimensional arrays. Syntax: system_task( Mda [, dim1Lsb [, dim1Rsb [, dim2Lsb [, dim2Rsb [, ... dimNLsb [, dimNRsb]]]]]] ); Mda This argument specifies the name of the multi-dimensional array (MDA) to be recorded. It must not be a part select. If no other arguments are given, then all elements of the MDA are recorded to the VPD file. dim1Lsb This is an optional argument that specifies the name of the variable that contains the left bound of the first dimension. If no other arguments are given, then all elements under this single index of this dimension are recorded.
dim1Rsb This is an optional argument that specifies the name of variable that contains the right bound of the first dimension. Note: The dim1Lsb and dim1Rsb arguments specify the range of the first dimension to be recorded. If no other arguments are given, then all elements under this range of addresses within the first dimension are recorded. dim2Lsb This is an optional argument with the same functionality as dim1Lsb, but refers to the second dimension. dim2Rsb This is an optional argument with the same functionality as dim1Rsb, but refers to the second dimension. dimNLsb This is an optional argument that specifies the left bound of the Nth dimension. dimNRsb This is an optional argument that specifies the right bound of the Nth dimension. Note that MDA system tasks can take 0 or more arguments, with the following caveats: - No arguments: The whole design will be traversed and all memories and MDAs will be recorded. Note that this process may cause significant memory usage and simulator drag.
Compiler Directives and System Tasks D-23
- One argument: If the object is a scope instance, all memories/ MDAs contained in that scope instance and its children will be recorded. If the object is a memory/MDA, that object will be recorded. $vcdplusmemoff Stops recording value changes and times for memories and multidimensional arrays. Syntax is the same as the $vcdplusmenon system task. $vcdplusmemorydump Records (dumps) a snapshot of the values in a memory or multi-dimensional array into the VPD file. Syntax is the same as the $vcdplusmenon system task. $vcdplusoff Stops recording, in the VPD file, the transition times and values for the nets and registers in the specified module instance or individual nets or registers. Syntax: $vcdplusoff[(level_number,module_instance | net_or_reg)]; Where: level_number Specifies the number of hierarchy scope levels for which to stop recording signal value changes (a zero value records all scope instances to the end of the hierarchy; default is all). module_instance Specifies the name of the scope for which to stop recording signal value changes (default is all).
net_or_reg Specifies the name of the signal for which to stop recording signal value changes (default is all). $vcdpluson Starts recording, in the VPD file, the transition times and values for the nets and registers in the specified module instance or individual nets or registers. Syntax: $vcdpluson[(level_number,module_instance | net_or_variable)]; where: level_number Specifies the number of hierarchy scope levels for which to record signal value changes (a zero value records all scope instances to the end of the hierarchy; default is all). module_instance Specifies the name of the scope for which to record signal value changes (default is all). net_or_variable Specifies the name of the signal for which to record signal value changes (default is all). $vcdplustraceoff Stops recording, in the VPD file, the order of statement execution in the specified module instance. Syntax: $vcdplustraceoff(module_instance);
$vcdplustraceon Starts recording, in the VPD file, the order of statement execution in the specified module instance and the module instances hierarchically under it. Syntax: $vcdplustraceon[(module_instance)];
Where: 0 Specifies reporting on the assertion if it is active (VCS checks for its properties) and if not, reporting on the assertion or assertions, whenever they start. 1 Specifies reporting on the assertion or assertions only once, the next time they start. If you specify neither 0 or 1, the default is 0.
Compiler Directives and System Tasks D-26
assertion_identifier... A comma separated list of assertions. If one of these assertions is not declared in the module definition containing this system task, specify it by its hierarchical name. $assert_monitor_off Disables the display from the $assert_monitor system task. $assert_monitor_on Re-enables the display from the $assert_monitor system task.
$rtoi Converts real numbers to integers. See IEEE std 1364-2001 page 310.
$fread Reads binary data from a file. See IEEE Std 1364-2001 page 293. $fscanf Reads characters in a file. See IEEE Std 1364-2001 pages 290293. $fseek Sets the position of the next read or write operation in a file. See IEEE Std 1364-2001 page 294. $fstrobe[b|h|0] Writes arguments to a file. See IEEE std 1364-2001 pages 288289. $ftell Returns the offset of a file. See IEEE Std 1364-2001 page 294. $fwrite[b|h|0] Writes to a file. See IEEE Std 1364-2001 pages 88-289. $rewind Sets the next read or write operation to the beginning of a file. See IEEE Std 1364-2001 page 294. $sformat Assigns a string value to a specified signal. See IEEE Std 1364-2001 pages 289-290. $sscanf
Reads characters from an input stream. See IEEE Std 1364-2001 pages 290-293. $swrite Assigns a string value to a specified signal, similar to the $sformat system function. See IEEE Std 1364-2001 pages 289-290. $ungetc Returns a character to the input stream. See IEEE Std 1364-2001 page 290.
$writememb Writes binary data in a memory to a file. Syntax: $writememb ("filename",memory [,start_address] [,end_address]); Code example: $writememb ("testfile.txt",mem,0,255); $writememh Writes hexadecimal data in a memory to a file. Syntax: $writememh ("filename",memory [,start_address] [,end_address]);
If you specify a module instance, this system task disables timing violations for the specified instance and all instances hierarchically under this instance. If you omit module instances, this system task disables timing violations throughout the design. Code example: $disable_warnings(seqdev1); $enable_warnings Re-enables the display of timing violations after the execution of the $disable_warnings system task. This system task does not enable timing violations during simulation when you used the +no_tchk_msg compile-time option to disable them. Syntax: $enable_warnings[(module_instance,...)]; An alternative syntax is:
$enable_warnings("timing"[,module_instance,...]);
If you specify a module instance, this system task enables timing violations for the specified instance and all instances hierarchically under this instance. If you omit module instances, this system task enables timing violations throughout the design.
$recrem Reports a timing violation if a data event occurs less than a specified time limit before or after a reference event. This timing check is identical to the $setuphold timing check except that typically the reference event is on a control signal and the data event is on a clock signal. You can specify negative values for the recovery and removal limits. The syntax is as follows: $recrem(reference_event, data_event, recovery_limit, removal_limit, notifier, timestamp_cond, timecheck_cond, delay_reference, delay_data); See IEEE Std 1364-2001 pages 246-248. $removal Reports a timing violation if the reference event, typically an asynchronous control signal, happens too soon after the data event, the clock signal. See IEEE Std 1364-2001 pages 244-245. $setup Reports a timing violation when the data event happens before and too close to the reference event. See IEEE Std 1364-2001 page 241. This timing check also has an extended syntax like the $recrem timing check. This extended syntax is not described in IEEE Std 1364-2001. $setuphold
Combines the $setup and $hold system tasks. See IEEE Std 1364-1995 page 189 for the official description. There is also an extended syntax that is in IEEE Std 1364-2001 pages 242-244. This extended syntax is as follows: $setuphold(reference_event, data_event, setup_limit, hold_limit, notifier, timestamp_cond, timecheck_cond, delay_reference, delay_data); $skew Reports a timing violation when a reference event happens too long after a data event. See IEEE std 1364-2001 pages 249-250. $width Reports a timing violation when a pulse is narrower than the specified limit. See IEEE std 1364-2001 pages 254-255. VCS ignores the threshold argument.
$q_exam Provides statistical information about activity at the queue. See IEEE Std 1364-2001 page 307. $q_full Returns 0 if the queue is not full, returns a 1 if the queue is full. See IEEE Std 1364-2001 page 307. $q_initialize Creates a new queue. See IEEE Std 1364-2001 page 306-307. $q_remove Receives an entry from a queue. See IEEE Std 1364-2001 page 307.
SDF Files
$sdf_annotate Tells VCS to back-annotate delay values from an SDF file to your Verilog design.
Depositing Values
$deposit Deposits a value on a net or variable. This deposited value overrides the value from any other driver of the net or variable. The value propagates to all loads of the net or variable. A subsequent simulation event can override the deposited value. You cannot use this system task to deposit values to bit-selects or part-selects. Syntax: $deposit(net_or_variable, value); The deposited value can be the value of another net or variable. You can deposit the value of a bit-select or part-select.
Suppress the warning message every time VCS evaluates a conditional expression to have an X or Z value. Syntax: $xzcheckoff(level_number,hierarchical_name) level_number (Optional) Specifies the number of hierarchy scope levels from the specified module instance, for which X and Z value check is disabled. If the number is 0 or not specified, implies to disable the check on all scope instances to the end of the hierarchy. hierarchical_name (Optional) Hierarchical name of the module instance, that is, the top-level instance of the subhierarchy for which you want to disable checking.
Note: If the argument has x or z values then that bit will be considered as 1or 0 respectively by VCS. The argument could be a vector with a few bits having x or z values. For more information on this system function, see section named Integer math functions in the IEEE Std-1800-2009 SystemVerilog LRM.
task t1(); t(); // line 22 endtask initial begin :B0 t1(); // line 26 end endprogram module top; test p(); endmodule
In this method stack: #0 is always the line containing the $stack system task. In this example it is in class C, user defined function named f3, at line number 5 is test.sv. #1 is a call of function f3 in user defined function f2 at line number 14. VCSexecuting f2 causes VCSto execute f3. #2 is a call of function f2 in user defined function f1 at line number 10. VCSexecuting f1 causes VCSto execute f2.
#3 is a call of function f1 in user defined task t at line number 18. VCSexecuting t causes VCSto execute f1. #4 is a task enabling statement for task t in user defined task t1 at line number 22. VCSexecuting t1 causes VCSto execute t. #5 is a task enabling statement for t1 in the begin-end block named B0. VCSexecuting B0 causes VCSto execute t1. #6 is the instance of program test. VCSdoes not include the line number because this instantiation is in the top level module.
$dist_erlang $dist_t
E
PLI Access Routines B
VCS includes a number of access routines. This appendix describes these access routines in the following sections: Access Routines for Reading and Writing to Memories Access Routines for Multidimensional Arrays Access Routines for Probabilistic Distribution Access Routines for Returning a Pointer to a Parameter Value Access Routines for Extended VCD Files Access Routines for Line Callbacks Access Routines for Source Protection Access Routine for Signal in a Generate Block VCS API Routines
acc_getmem_bitstr Reads a bit string from specific bits in a Verilog memory word. See acc_getmem_bitstr on page 17 for details. acc_handle_mem_by_fullname Returns the handle used by acc_readmem. See acc_handle_mem_by_fullname on page 18 for details. acc_readmem Reads a data file and writes the contents to a memory. See acc_readmem on page 18 for details. acc_getmem_range Returns the upper and lower limits of a memory. See acc_getmem_range on page 21 for details. acc_getmem_size Returns the number of elements (or words or addresses) in a memory. See acc_getmem_size on page 22 for details. acc_getmem_word_int Returns the integer of a memory element. See acc_getmem_word_int on page 23 for details. acc_getmem_word_range Returns the least significant bit of a memory element and the length of the element. See acc_getmem_word_range on page 24 for details.
acc_setmem_int
You use the acc_setmem_int access routine to write an integer value to specific bits in a Verilog memory word.
Table 0-1.
acc_setmem_int
Synopsis: Syntax: Writes an integer value to specific bits in a memory word. acc_setmem_int (memhand, value, row, start, length) Type Returns: void Type Arguments: handle int int int Name memhand value row start Description Handle to memory The integer value written in binary format to the bits in the word. The memory array index. Bit number of the leftmost bit in the memory word where this routine starts writing the value. Starting with the start bit, specifies the total number of bits this routine writes to. Description
length
acc_getmem_int acc_setmem_hexstr acc_getmem_hexstr acc_setmem_bitstr acc_getmem_bitstr acc_clearmem_int acc_handle_mem_by_fullname acc_readmem acc_getmem_range acc_getmem_size acc_getmem_word_int acc_getmem_word_range
acc_getmem_int
You use the acc_getmem_int access routine to return an integer value for certain bits in a Verilog memory word.
Table 0-1.
acc_getmem_int
Synopsis: Syntax: Returns an integer value for specific bits in a memory word. acc_getmem_int (memhand, row, start, length) Type Returns: int Type Arguments: handle int int Description Integer value of the bits in the memory word. Name memhand row start Description Handle to memory The memory array index Bit number of the leftmost bit in the memory word where this routine starts reading the value. Specifies the total number of bits this routine reads starting with the start bit.
length
acc_setmem_int acc_setmem_hexstr acc_getmem_hexstr acc_setmem_bitstr acc_getmem_bitstr acc_clearmem_int acc_handle_mem_by_fullname acc_readmem acc_getmem_range acc_getmem_size acc_getmem_word_int acc_getmem_word_range
acc_clearmem_int
You use the acc_clearmem_int access routine to write zeros to all bits in a memory.
Table 0-1.
acc_clearmem_int
Synopsis: Syntax: Clears a memory word. acc_clearmem_int (memhand) Type Returns: void Type Arguments: Related routines: handle Name memhand Description Handle to memory Description
acc_setmem_int acc_getmem_int acc_setmem_hexstr acc_getmem_hexstr acc_setmem_bitstr acc_getmem_bitstr acc_handle_mem_by_fullname acc_readmem acc_getmem_range acc_getmem_size acc_getmem_word_int acc_getmem_word_range
Examples
The following code examples illustrate how to use acc_getmem_int, acc_setmem_int, and acc_clearmem_int: Example E-1 shows C code that includes a number of functions to be associated with user-defined system tasks.
Example E-2 shows the PLI table for associating these functions with these system tasks. Example E-3 shows the Verilog source code containing these system tasks. C Source Code for Functions Calling acc_getmem_int, acc_setmem_int, and acc_clearmem_int
Example E-1
#include <stdio.h> #include "acc_user.h" #include "vcs_acc_user.h" void error_handle(char *msg) { printf("%s",msg); fflush(stdout); exit(1); } void set_mem() { handle memhand = NULL; int value = -1; int row = -1; int start_bit = -1; int len = -1; memhand = acc_handle_tfarg(1); if(!memhand) error_handle("NULL MEM HANDLE\n"); value = acc_fetch_tfarg_int(2); row = acc_fetch_tfarg_int(3); start_bit = acc_fetch_tfarg_int(4); len = acc_fetch_tfarg_int(5); acc_setmem_int(memhand, value, row, start_bit, len); } void get_mem() { handle memhand = NULL;
memhand = acc_handle_tfarg(1); if(!memhand) error_handle("NULL MEM HANDLE\n"); row = acc_fetch_tfarg_int(2); start_bit = acc_fetch_tfarg_int(3); len = acc_fetch_tfarg_int(4); value = acc_getmem_int(memhand, row, start_bit, len); printf("getmem: value of word %d is : %d\n",row,value); fflush(stdout); } void clear_mem() { handle memhand = NULL; memhand = acc_handle_tfarg(1); if(!memhand) error_handle("NULL MEM HANDLE\n"); acc_clearmem_int(memhand); }
The function with the set_mem identifier calls the IEEE standard acc_fetch_tfarg_int routine to get the handles for arguments to the user-defined system task that you associate with this function in the PLI table file. It then assigns the handles to local variables and calls acc_setmem_int to write to the specified memory in the specified word, start bit, for the specified length. Similarly, the function with the get_mem identifier calls the acc_fetch_tfarg_int routine to get the handles for arguments to a user-defined system task and assign them to local variables. It then calls acc_gtetmem_int to read from the specified memory in
the specified word, starting with the specified start bit for the specified length. It then displays the word index of the memory and its value. The function with the clear_mem identifier likewise calls the acc_fetch_tfarg_int routine to get a handle and then calls acc_clear_mem_int with that handle. Example E-2 PLI Table File
Here the $set_mem user-defined system task is associated with the set_mem function in the C code, as are the $get_mem and $clear_mem with their corresponding get_mem and clear_mem function identifiers. Example E-3 Verilog Source Code Using These System Tasks
module top; // read and print out data of memory parameter start = 0; parameter finish =9 ; parameter bstart =1 ; parameter bfinish =8 ; parameter size = finish - start + 1; reg [bfinish:bstart] mymem[start:finish]; integer i; integer len; integer value; initial begin // $set_mem(mem_name, value, row, start_bit, len) $clear_mem(mymem); // set values
#1 #1 #1 #1
// print values through acc_getmem_int #1 len = bfinish - bstart + 1; $display(); $display("Begin Memory Values"); for (i=start;i<=finish;i=i+1) begin $get_mem(mymem,i,bstart,len); end $display("End Memory Values"); $display(); // display values #1 $display(); $display("Begin Memory Display"); for (i=start;i<=finish;i=i+1) begin $display("mymem word %d is %b",i,mymem[i]); end $display("End Memory Display"); $display(); end endmodule
In this Verilog code, in the initial block, the following events occur: 1. The $clear_mem system task clears the memory. 2. Then the $set_mem system task deposits values in specified words, and in specified bits in the memory named mymem. 3. In a for loop, the $get_mem system task reads values from the memory and displays those values.
acc_setmem_hexstr
You use the acc_setmem_hexstr access routine for writing the corresponding binary representation of a hexadecimal string to a Verilog memory.
Table 0-1.
acc_setmem_hexstr
Synopsis: Syntax: Writes a hexadecimal string to a word in a Verilog memory. acc_setmem_hexstr (memhand, hexStrValue, row, start) Type Returns: void Type Arguments: handle char * int int Name memhand hexStrValue row start Description Handle to memory Hexadecimal string The memory array index Bit number of the leftmost bit in the memory word where this routine starts writing the string. Description
Related routines:
acc_setmem_int acc_getmem_int acc_getmem_hexstr acc_setmem_bitstr acc_getmem_bitstr acc_clearmem_int acc_handle_mem_by_fullname acc_readmem acc_getmem_range acc_getmem_size acc_getmem_word_int acc_getmem_word_range
This routine takes a value argument which is a hexadecimal string of any size and puts its corresponding binary representation into the memory word indexed by row, starting at the bit number start.
Examples
The following code examples illustrates the use of acc_setmem_hexstr: Example E-4 shows the C source code for an application that calls acc_setmem_hexstr. Example E-5 shows the contents of a data file read by the application. Example E-6 shows the PLI table file that associates the user-defined system task in the Verilog code with the application. Example E-7 shows the Verilog source that calls the application. C Source Code For an Application Calling acc_setmem_hexstr
Example E-4
#include <stdio.h> #include "acc_user.h" #include "vcsuser.h" #define NAME_SIZE 256 #define len 100 pli() { FILE *infile; char memory_name[NAME_SIZE] ; char value[len]; handle memory_handle; int row,start; infile = fopen("initfile","r"); while ( fscanf(infile,"%s %s %d %d ", memory_name,value,&row,&start) != EOF ) { printf("The mem= %s \n value= %s \n row= %d \n start= %d \n ", memory_name,value,row,start); memory_handle=acc_handle_object(memory_name); acc_setmem_hexstr(memory_handle,value,row,start);
} }
Example E-4 shows the source code for a PLI application that: 1. Reads a data file named initfile to find the memory identifiers of the memories it writes to, the hexadecimal string to be converted to its bit representation when written to the memory, the index of the memory where it writes this value, and the starting bit for writing the binary value. 2. Displays where in the memory it is writing these values 3. Calls the access routine to write the values in the initfile. Example E-5 The Data File Read by the Application
testbench.U2.cmd_array 5 0 0 testbench.U2.cmd_array a5 1 4 testbench.U2.cmd_array a5a5 2 8 testbench.U1.slave_addr a073741824 0 4 testbench.U1.slave_addr 16f0612735 1 8 testbench.U1.slave_addr 2b52a90e15 2 12
Each line lists a Verilog memory, followed by a hex string, a memory index, and a start bit. Example E-6 PLI Table File
acc=rw:*
$pli call=pli
Here the $pli system task is associated with the function with the pli identifier in the C source code. Example E-7 Verilog Source Calling the PLI Application
$monitor($stime,,, "sladd[0]=%h sladd[1]=%h sladd[2]=%h load=%h cmd[0]=%h cmd[1]=%h cmd[2]=%h", testbench.U1.slave_addr[0], testbench.U1.slave_addr[1], testbench.U1.slave_addr[2], testbench.U1.load, testbench.U2.cmd_array[0], testbench.U2.cmd_array[1], testbench.U2.cmd_array[2] ); #10; $pli(); end endmodule module master; reg[31:0] cmd_array [0:2]; integer i; initial begin //setup some default values for (i=0; i<3; i=i+1) cmd_array[i] = 32h0000_0000; end endmodule module monitor; reg load; reg[63:0] slave_addr [0:2]; integer i; initial begin //setup some default values for (i=0; i<3; i=i+1) slave_addr[i] = 64h0000_0000_0000_0000; load = 1b0; end endmodule
In Example E-7 module testbench calls the application using the $pli user-defined system task for the application. The display string in the $monitor system task is on two lines to enhance readability.
acc_getmem_hexstr
You use the acc_getmem_hexstr access routine to get a hexadecimal string from a Verilog memory.
Table 0-1.
acc_getmem_hexstr
Synopsis: Syntax: Returns a hexadecimal string from a Verilog memory. acc_getmem_hexstr (memhand,hexStrValue,row,start,len) Type Returns: void Type Arguments: handle char * int int Name memhand hexStrValue row start Description Handle to memory Pointer to a character array into which the string is written The memory array index Bit number of the leftmost bit in the memory word where this routine starts reading the string. Specifies the total number of bits this routine reads starting with the start bit. Description
length
acc_setmem_int acc_getmem_int acc_setmem_hexstr acc_setmem_bitstr acc_getmem_bitstr acc_clearmem_int acc_handle_mem_by_fullname acc_readmem acc_getmem_range acc_getmem_size acc_getmem_word_int acc_getmem_word_range
acc_setmem_bitstr
You use the acc_setmem_bitstr access routine for writing a string of binary bits (including x and z) to a Verilog memory.
Table 0-1.
acc_setmem_bitstr
Synopsis: Syntax: Writes a string of binary bits to a word in a Verilog memory. acc_setmem_bitstr (memhand, bitStrValue, row, start) Type Returns: void Type Arguments: handle char * int int Name memhand bitStrValue row start Description Handle to memory Bit string The memory array index Bit number of the leftmost bit in the memory word where this routine starts writing the string. Description
Related routines:
acc_setmem_int acc_getmem_int acc_setmem_hexstr acc_getmem_hexstr acc_getmem_bitstr acc_clearmem_int acc_handle_mem_by_fullname acc_readmem acc_getmem_range acc_getmem_size acc_getmem_word_int acc_getmem_word_range
This routine takes a value argument that is a bit string of any size, which can include the x and z values, and puts its corresponding binary representation into the memory word indexed by row, starting at the bit number start.
acc_getmem_bitstr
You use the acc_getmem_bitstr access routine to get a bit string, including x and z values, from a Verilog memory.
Table 0-1.
acc_getmem_bitstr
Synopsis: Syntax: Returns a hexadecimal string from a Verilog memory. acc_getmem_bitstr (memhand,bitStrValue,row,start,len) Type Returns: void Type Arguments: handle char * int int Name memhand hexStrValue row start Description Handle to memory Pointer to a character array into which the string is written The memory array index Bit number of the leftmost bit in the memory word where this routine starts reading the string. Specifies the total number of bits this routine reads starting with the start bit. Description
length
acc_setmem_int acc_getmem_int acc_setmem_hexstr acc_getmem_hexstr acc_setmem_bitstr acc_clearmem_int acc_handle_mem_by_fullname acc_readmem acc_getmem_range acc_getmem_size acc_getmem_word_int acc_getmem_word_range
acc_handle_mem_by_fullname
Returns a handle to a memory that can only be used as a parameter to acc_readmem.
Table 0-1.
acc_handle_mem_by_fullaname
Synopsis: Syntax: Returns a handle to be used as a parameter to acc_readmem only acc_handle_mem_by_fullname (fullMemInstName) Type Returns: handle Type Arguments: Related routines: char* Description Handle to the instance Name fullMemInstName Description Hierarchical name for a memory
acc_setmem_int acc_getmem_int acc_setmem_hexstr acc_getmem_hexstr acc_setmem_bitstr acc_getmem_bitstr acc_handle_mem_by_fullname acc_readmem acc_getmem_range acc_getmem_size acc_getmem_word_int acc_getmem_word_range
acc_readmem
You use the acc_readmem access routine to read a data file into a memory. It is similar to the $readmemb or $readmemh system tasks.
acc_readmem
Synopsis: Syntax: Reads a data file into a memory acc_readmem (memhandle, data_file, format) Type Returns: void Type Arguments: handle const char* int Name memhandle data_file format Description Handle returned by acc_handle_mem_fullname Data file this routine reads Specify a character that is promoted to int. h for hexadecimal data, b for binary data. Description
Related routines:
acc_setmem_int acc_getmem_int acc_setmem_hexstr acc_getmem_hexstr acc_setmem_bitstr acc_getmem_bitstr acc_handle_mem_by_fullname acc_readmem acc_getmem_range acc_getmem_size acc_getmem_word_int acc_getmem_word_range
Examples
The following code examples illustrate the use of acc_readmem and acc_handle_mem_by_fullname.
Example E-8
#include "acc_user.h" #include "vcs_acc_user.h" #include "vcsuser.h" int test_acc_readmem(void) { const char *memName = tf_getcstringp(1); const char *memFile = tf_getcstringp(2); handle mem = acc_handle_mem_by_fullname(memName); if (mem) { io_printf("test_acc_readmem: %s handle found\n", memName); acc_readmem(mem, memFile, 'h'); } else { io_printf("test_acc_readmem: %s handle NOT found\n", memName); } }
$test_acc_readmem call=test_acc_readmem
module top; reg [7:0] CORE[7:0]; initial $acc_readmem(CORE, "CORE"); initial $test_acc_readmem("top.CORE", "test_mem_file"); endmodule
acc_getmem_range
You use the acc_getmem_range access routine to access the upper and lower limits of a memory.
Table 0-1.
acc_getmem_range
Synopsis: Syntax: Returns the upper and lower limits of a memory acc_getmem_range (memhandle, p_left_index,p_right_index) Type Returns: void Type Arguments: handle int* int Related routines: Name memhandle p_left_index p_right_index Description Handle to a memory Pointer to int Pointer to int Description
acc_setmem_int acc_getmem_int acc_setmem_hexstr acc_getmem_hexstr acc_setmem_bitstr acc_getmem_bitstr acc_handle_mem_by_fullname acc_readmem acc_getmem_size acc_getmem_word_int acc_getmem_word_range
acc_getmem_size
You use the acc_getmem_size access routine to access the number of elements in a memory.
Table 0-1.
acc_getmem_size
Synopsis: Syntax: Returns the number of elements in a memory acc_getmem_size (memhandle) Type Returns: int Type Arguments: Related routines: handle Description The number of elements in a memory Name memhandle Description Handle to a memory
acc_setmem_int acc_getmem_int acc_setmem_hexstr acc_getmem_hexstr acc_setmem_bitstr acc_getmem_bitstr acc_handle_mem_by_fullname acc_readmem acc_getmem_range acc_getmem_word_int acc_getmem_word_range
acc_getmem_word_int
You use the acc_getmem_word_int access routine to access the integer value of an element (or word, address, or row).
Table 0-1.
acc_getmem_word_int
Synopsis: Syntax: Returns the integer value of an element acc_getmem_word_int (memhandle,row) Type Returns: int Type Arguments: handle int Related routines: Description The integer value of a row Name memhandle row Description Handle to a memory The element (word address, or row) in the memory
acc_setmem_int acc_getmem_int acc_setmem_hexstr acc_getmem_hexstr acc_setmem_bitstr acc_getmem_bitstr acc_handle_mem_by_fullname acc_readmem acc_getmem_range acc_getmem_size acc_getmem_word_range
acc_getmem_word_range
You use the acc_getmem_word_range access routine to access the least significant bit of an element (or word, address, or row) and the length of the element.
Table 0-1.
acc_getmem_word_range
Synopsis: Syntax: Returns the least significant bit of an element and the length of the element acc_getmem_word_range (memhandle,lsb,len) Type Returns: void Type Arguments: handle int* int* Related routines: Name memhandle lsb len Description Handle to a memory Pointer to the least significant bit Pointer to the length of the element Description
acc_setmem_int acc_getmem_int acc_setmem_hexstr acc_getmem_hexstr acc_setmem_bitstr acc_getmem_bitstr acc_handle_mem_by_fullname acc_readmem acc_getmem_range acc_getmem_size acc_getmem_word_int
We also have the following tf and access routines for accessing data in a multi-dimensional array: tf_mdanodeinfo and tf_imdanodeinfo Returns access parameter node information from a multidimensional array. See tf_mdanodeinfo and tf_imdanodeinfo on page 26 for details. acc_get_mda_range Returns all the ranges of the multi-dimensional array. See acc_get_mda_range on page 27 for details. acc_get_mda_word_range Returns the range of an element in a multi-dimensional array. See acc_get_mda_word_range() on page 29 for details. acc_getmda_bitstr Reads a bit string, including X and Z values, from an element in a multi-dimensional array. See acc_getmda_bitstr() on page 30 for details. acc_setmda_bitstr Writes a bit string, including X and Z values, from an element in a multi-dimensional array. See acc_setmda_bitstr() on page 31 for details.
tf_mdanodeinfo(), tf_imdanodeinfo()
Synopsis: Syntax: Returns access parameter node information from a multi-dimensional array. tf_mdanodeinfo(nparam, mdanodeinfo_p) tf_imdanodeinfo(nparam, mdanodeinfo_p, instance_p) Type Returns: mdanodeinfo_p * Type Arguments: int struct t_tfmdanodeinfo * char * Related routines: Description The value of the second argument if successful; 0 if an error occurs Name nparam mdanodeinfo_p Description Index number of the multidimensional array parameter Pointer to a variable declared as the t_tfmdanodeinfo structure type Pointer to a specific instance of a multi-dimensional array
instance_p
int node_vec_size; int node_sign; int node_ms_index; int node_ls_index; int node_mem_size; int *node_lhs_element; int *node_rhs_element; int node_dimension; int *node_handle; int node_vec_type; } s_tfmdanodeinfo, *p_tfmdanodeinfo;
acc_get_mda_range
The acc_get_mda_range routine returns the ranges of a multidimensional array.
Table 0-1.
acc_get_mda_range()
Synopsis: Syntax: Gets all the ranges of the multi-dimensional array. acc_get_mda_range(mdaHandle, size, msb, lsb, dim, plndx, prindex) Type Returns: void Type Arguments: handle int * int * Name mdaHandle size msb Description Handle to the multi-dimensional array Pointer to the size of the multidimensional array Pointer to the most significant bit of a range Description
Table 0-1.
int * int * lsb dim Pointer to the least significant bit of a range Pointer to the number of dimensions in the multidimensional array Pointer to the left index of a range Pointer to the right index of a range
plndx prndx
acc_get_mda_word_range()
The acc_get_mda_word_range routine returns the range of an element in a multi-dimensional array.
Table 0-1.
acc_get_mda_word_range()
Synopsis: Syntax: Gets the range of an element in a multi-dimensional array. acc_get_mda_range(mdaHandle, msb, lsb) Type Returns: void Type Arguments: handle int * int * Related routines: Name mdaHandle msb lsb Description Handle to the multi-dimensional array Pointer to the most significant bit of a range Pointer to the least significant bit of a range Description
left = 7; right = 0;
acc_getmda_bitstr()
You use the acc_getmda_bitstr access routine to read a bit string, including x and z values, from a multi-dimensional array.
Table 0-1.
acc_getmda_bitstr()
Synopsis: Syntax: Gets a bit string from a multi-dimensional array. acc_getmda_bitstr(mdaHandle, bitStr, dim, start, len) Type Returns: void Type Arguments: handle char * int * int * int * Related routines: Name mdaHandle bitStr dim start len Description Handle to the multi-dimensional array Pointer to the bit string Pointer to the dimension in the multi-dimensional array Pointer to the start element in the dimension Pointer to the length of the string Description
acc_setmda_bitstr()
You use the acc_setmda_bitstr access routine to write a bit string, including x and z values, into a multi-dimensional array.
Table 0-1.
acc_setmda_bitstr()
Synopsis: Syntax: Sets a bit string in a multi-dimensional array. acc_setmda_bitstr(mdaHandle, bitStr, dim, start, len) Type Returns: void Type Arguments: handle char * int * int * int * Related routines: Name mdaHandle bitStr dim start len Description Handle to the multi-dimensional array Pointer to the bit string Pointer to the dimension in the multi-dimensional array Pointer to the start element in the dimension Pointer to the length of the string Description
vcs_dist_normal Returns random numbers with a specified mean and standard deviation. See vcs_dist_normal on page 35 for details. vcs_dist_exponential Returns random numbers where the distribution function is exponential. See vcs_dist_exponential on page 36 for details. vcs_dist_poisson Returns random numbers with a specified mean. See vcs_random on page 33 for details. These routines are declared in the vcs_acc_user.h file in the $VCS_HOME/lib directory.
vcs_random
You use this routine to obtain a random number.
Table 0-1.
vcs_random()
Synopsis: Syntax: Returns a random number. vcs_random() Type Returns: int Type Arguments: Related routines: None vcs_random_const_seed vcs_random_seed vcs_dist_uniform vcs_dist_normal vcs_dist_exponential vcs_dist_poisson Description Random number Name Description
vcs_random_const_seed
You use this routine to return a random number and you supply an integer constant argument as the seed for the random number.
Table 0-1.
vcs_randon_const_seed
Synopsis: Syntax: Returns a random number. vcs_random_const_seed(integer) Type Returns: int Type Arguments: Related routines: int Description Random number Name integer Description An integer constant.
vcs_random_seed
You use this routine to return a random number and you supply a pointer argument.
Table 0-1.
vcs_random_seed()
Synopsis: Syntax: Returns a random number. vcs_random_seed(seed) Type Returns: int Type Arguments: Related routines: int * Description Random number Name seed Description Pointer to an int type.
vcs_dist_uniform
You use this routine to return a random number uniformly distributed between parameters.
Table 0-1.
vcs_dist_uniform
Synopsis: Syntax: Returns random numbers uniformly distributed between parameters. vcs_dist_uniform(seed, start, end) Type Returns: int Type Arguments: int * int int Related routines: Description Random number Name seed start end Description Pointer to a seed integer value. Starting parameter for distribution range. Ending parameter for distribution range.
vcs_dist_normal
You use this routine to return a random number with a specified mean and standard deviation.
Table 0-1.
vcs_dist_normal
Synopsis: Syntax: Returns random numbers with a specified mean and standard deviation. vcs_dist_normal(seed, mean, standard_deviation) Type Returns: int Description Random number
Table 0-1.
Type Arguments: int * int int Related routines: Name seed mean standard_ deviation Description Pointer to a seed integer value. An integer that is the average value of the possible returned random numbers. An integer that is the standard deviation from the mean for the normal distribution.
vcs_dist_exponential
You use this routine to return a random number where the distribution function is exponential.
Table 0-1.
vcs_dist_exponential
Synopsis: Syntax: Returns random numbers where the distribution function is exponential. vcs_dist_exponential(seed, mean) Type Returns: int Type Arguments: int * int Related routines: Description Random number Name seed mean Description Pointer to a seed integer value. An integer that is the average value of the possible returned random numbers.
vcs_dist_poisson
You use this routine to return a random number with a specified mean.
Table 0-1.
vcs_dist_poisson
Synopsis: Syntax: Returns random numbers with a specified mean. vcs_dist_poisson(seed, mean) Type Returns: int Type Arguments: int * int Related routines: Description Random number Name seed mean Description Pointer to a seed integer value. An integer that is the average value of the possible returned random numbers.
For your convenience, VCS provides the acc_fetch_paramval_str routine to directly return a string pointer.
acc_fetch_paramval_str
Returns the value of a string parameter directly as char*.
Table 0-1.
acc_fetch_paramval_str
Synopsis: Syntax: Returns the value of a string parameter directly as char*. acc_fetch_paramval_str(param_handle) Type Returns: char* Type Arguments: Related routines: handle Description string pointer Name param_handle Description Handle to a module parameter or specparam.
acc_fetch_paramval
Monitors instance ports. See acc_lsi_dumpports_call on page 41 for details. acc_lsi_dumpports_close Closes specified VCDE files. See acc_lsi_dumpports_close on page 43 for details. acc_lsi_dumpports_flush Flushes cached data to the VCDE file on disk. See acc_lsi_dumpports_flush on page 44 for details. acc_lsi_dumpports_limit Sets the maximum VCDE file size. See acc_lsi_dumpports_limit on page 45 for details. acc_lsi_dumpports_misc Processes miscellaneous events. See acc_lsi_dumpports_misc on page 46 for details. acc_lsi_dumpports_off Suspends VCDE file dumping. See acc_lsi_dumpports_off on page 47 for details. acc_lsi_dumpports_on Resumes VCDE file dumping. See acc_lsi_dumpports_on on page 48 for details. acc_lsi_dumpports_setformat Specifies the format of the VCDE file. See acc_lsi_dumpports_setformat on page 50 for details.
acc_lsi_dumpports_vhdl_enable Enables or disables the inclusion of VHDL drivers in the determination of driver values. See acc_lsi_dumpports_vhdl_enable on page 51 for details.
acc_lsi_dumpports_all
Syntax
int acc_lsi_dumpports_all(char *filename)
Synopsis Adds a checkpoint to the file. This is a PLI interface to the $dumpportsall system task. If the filename argument is NULL, this routine adds a checkpoint to all open VCDE files. Returns The number of VCDE files that matched. Example E-11 Example of acc_lsi_dumpports_all
#include "acc_user.h" #include "vcs_acc_user.h" handle instance = acc_handle_by_name("test_bench.device", 0); char *outfile = "device.evcd"; /* use IEEE format for this file */ acc_lsi_dumpports_setformat(USE_DUMPPORTS_FORMAT_IEEE); if (acc_lsi_dumpports_call(instance, outfile)) { /* rut-roh, error ... */ } acc_lsi_dumpports_limit(100000, outfile); ...
if (time == yada_yada) acc_lsi_dumpports_off(outfile); ... if (time == yada_yada_yada) { /* add checkpoint (no need to enable dumping) */ acc_lsi_dumpports_all(outfile); acc_lsi_dumpports_flush(outfile); } ... if (resume_dumping_now) acc_lsi_dumpports_on(outfile); ...
Caution This routine may affect files opened by the $dumpports and $lsi_dumpports system tasks.
acc_lsi_dumpports_call
Syntax
int acc_lsi_dumpports_call(handle instance, char *filename)
Synopsis Monitors instance ports. This is a PLI interface to the $lsi_dumpports task. The default file format is the original LSI format, but you can select the IEEE format by calling the routine acc_lsi_dumpports_setformat() prior to calling this routine. Your tab file will need the following acc permissions:
acc=cbka,cbk,cbkv:[<instance_name>|*].
Returns Zero on success, non-zero otherwise. VCS displays error messages through tf_error(). A common error is specifying a file name also being used by a $dumpports or $lsi_dumpports system task. Example E-12 Example of acc_lsi_dumpports_all
#include "acc_user.h" #include "vcs_acc_user.h" handle instance = acc_handle_by_name("test_bench.device", 0); char *outfile = "device.evcd"; acc_lsi_dumpports_setformat(USE_DUMPPORTS_FORMAT_IEEE); if (acc_lsi_dumpports_call(instance, outfile)) { /* error */ }
Caution Multiple calls to this routine are allowed, but the output file name must be unique for each call. For proper dumpports operation, your tasks miscellaneous function must call acc_lsi_dumpports_misc() with every call it gets. This ensures that the dumpports routines sees all of the simulation events needed for proper update and closure of the dumpports (extended VCD) files. For example, your miscellaneous routine would do the following:
my_task_misc(int data, int reason) { acc_lsi_dumpports_misc(data, reason); ... }
acc_lsi_dumpports_close
Syntax
int acc_lsi_dumpports_call(handle instance, char *filename)
Synopsis Closes specified VCDE files. This routine reads the list of files opened by a call to the system tasks $dumpports and $lsi_dumpports or the routine acc_lsi_dumpports_call() and closes all that match either the specified instance handle or the filename argument. One or both arguments can be used. If the instance handle is non-null, this routine closes all files opened for that instance. Returns The number of files closed. Example E-13 Example of acc_lsi_dumpports_close
#include "acc_user.h" #include "vcs_acc_user.h" handle instance = acc_handle_by_name("test_bench.device", 0); char *outfile1 = "device.evcd1"; char *outfile2 = "device.evcd2"; acc_lsi_dumpports_setformat(USE_DUMPPORTS_FORMAT_LSI); acc_lsi_dumpports_call(instance, outfile1); acc_lsi_dumpports_call(instance, outfile2); ... acc_lsi_dumpports_close(NULL, outfile1); ... acc_lsi_dumpports_close(NULL, outfile2);
Caution A call to this function can also close files opened by the $lsi_dumpports or $dumpports system tasks.
acc_lsi_dumpports_flush
Syntax
int acc_lsi_dumpports_flush(char *filename)
Synopsis Flushes cached data to the VCDE file on disk. This is a PLI interface to the $dumpportsflush system task. If the filename is NULL all open files are flushed. Returns The number of files matched. Example E-14 Example of acc_lsi_dumpports_flush
#include "acc_user.h" #include "vcs_acc_user.h" handle instance = acc_handle_by_name("test_bench.device", 0); char *outfile = "device.evcd"; /* use IEEE format for this file */ acc_lsi_dumpports_setformat(USE_DUMPPORTS_FORMAT_IEEE); if (acc_lsi_dumpports_call(instance, outfile)) { /* rut-roh */ } acc_lsi_dumpports_limit(100000, outfile); ...
if (time == yada_yada) acc_lsi_dumpports_off(outfile); ... if (time == yada_yada_yada) { /* add checkpoint (no need to enable dumping) */ acc_lsi_dumpports_all(outfile); acc_lsi_dumpports_flush(outfile); } ... if (resume_dumping_now) acc_lsi_dumpports_on(outfile); ...
acc_lsi_dumpports_limit
Syntax
int acc_lsi_dumpports_limit(unsigned long filesize, char *filename)
Synopsis Sets the maximum VCDE file size. This is a PLI interface to the $dumpportslimit task. If the filename is NULL, the file size is applied to all files. Returns The number of files matched. Example E-15 Example of acc_lsi_dumpports_limit
#include "acc_user.h" #include "vcs_acc_user.h" handle instance = acc_handle_by_name("test_bench.device", 0); char *outfile = "device.evcd";
PLI Access Routines E-45
/* use IEEE format for this file */ acc_lsi_dumpports_setformat(USE_DUMPPORTS_FORMAT_IEEE); if (acc_lsi_dumpports_call(instance, outfile)) { /* rut-roh */ } acc_lsi_dumpports_limit(100000, outfile); ... if (time == yada_yada) acc_lsi_dumpports_off(outfile); ... if (time == yada_yada_yada) { /* add checkpoint (no need to enable dumping) */ acc_lsi_dumpports_all(outfile); acc_lsi_dumpports_flush(outfile); } ... if (resume_dumping_now) acc_lsi_dumpports_on(outfile); ...
Caution This routine may affect files opened by the $dumpports and $lsi_dumpports system tasks.
acc_lsi_dumpports_misc
Syntax
void acc_lsi_dumpports_misc(int data, int reason)
For proper dumpports operation, your tasks miscellaneous function must call this routine for each call it gets. Returns No return value. Example E-16 Example or acc_lsi_dumpports_misc
#include "acc_user.h" #include "vcs_acc_user.h" void my_task_misc(int data, int reason) { acc_lsi_dumpports_misc(data, reason); ... }
acc_lsi_dumpports_off
Syntax
int acc_lsi_dumpports_off(char *filename)
Synopsis Suspends VCDE file dumping. This is a PLI interface to the $dumpportsoff system task. If the file name is NULL, dumping is suspended on all open files. Returns The number of files that matched. Example E-17 of acc_lsi_dumpports_offExample
handle instance = acc_handle_by_name("test_bench.device", 0); char *outfile = "device.evcd"; /* use IEEE format for this file */ acc_lsi_dumpports_setformat(USE_DUMPPORTS_FORMAT_IEEE); if (acc_lsi_dumpports_call(instance, outfile)) { /* rut-roh */ } acc_lsi_dumpports_limit(100000, outfile); ... if (time == yada_yada) acc_lsi_dumpports_off(outfile); ... if (time == yada_yada_yada) { /* add checkpoint (no need to enable dumping) */ acc_lsi_dumpports_all(outfile); acc_lsi_dumpports_flush(outfile); } ... if (resume_dumping_now) acc_lsi_dumpports_on(outfile); ...
Caution This routine may suspend dumping on files opened by the $dumpports and $lsi_dumpports system tasks.
acc_lsi_dumpports_on
Syntax
int acc_lsi_dumpports_on(char *filename)
Synopsis Resumes VCDE file dumping. This is a PLI interface to the $dumpportson system task. If the filename is NULL, dumping is resumed on all open files. Returns The number of files that matched. Example E-18 Example of acc_lsi_dumpports_on
#include "acc_user.h" #include "vcs_acc_user.h" handle instance = acc_handle_by_name("test_bench.device", 0); char *outfile = "device.evcd"; /* use IEEE format for this file */ acc_lsi_dumpports_setformat(USE_DUMPPORTS_FORMAT_IEEE); if (acc_lsi_dumpports_call(instance, outfile)) { /* rut-roh */ } acc_lsi_dumpports_limit(100000, outfile); ... if (time == yada_yada) acc_lsi_dumpports_off(outfile); ... if (time == yada_yada_yada) { /* add checkpoint (no need to enable dumping) */ acc_lsi_dumpports_all(outfile); acc_lsi_dumpports_flush(outfile); } ... if (resume_dumping_now) acc_lsi_dumpports_on(outfile);
...
Caution This routine may resume dumping on files opened by the $dumpports and $lsi_dumpports system tasks.
acc_lsi_dumpports_setformat
Syntax
int acc_lsi_dumpports_setformat(lsi_dumpports_format_type format)
Where the valid lsi_dumpports_format_types are as follows: USE_DUMPPORTS_FORMAT_IEEE USE_DUMPPORTS_FORMAT_LSI Synopsis Specifies the format of the VCDE file. Use this routine to specify which output format (IEEE or the original LSI) should be used. This routine must be called before acc_lsi_dumpports_call(). Returns Zero if success, non-zero if error. Errors are reported through tf_error(). Example E-19 Example of acc_lsi_dumpports_setformat
handle instance = acc_handle_by_name("test_bench.device", 0); char *outfile1 = "device.evcd1"; char *outfile2 = "device.evcd2"; /* use IEEE format for this file */ acc_lsi_dumpports_setformat(USE_DUMPPORTS_FORMAT_IEEE); if (acc_lsi_dumpports_call(instance, outfile1)) { /* error */ } /* use LSI format for this file */ acc_lsi_dumpports_setformat(USE_DUMPPORTS_FORMAT_LSI); if (acc_lsi_dumpports_call(instance, outfile2)) { /* error */ } ...
Caution The runtime plusargs +dumpports+ieee and +dumpports+lsi have priority over this routine. The format of files created by calls to the $dumpports and $lsi_dumpports tasks are not affected by this routine.
acc_lsi_dumpports_vhdl_enable
Syntax
void acc_lsi_dumpports_vhdl_enable(int enable)
The valid enable integer parameters are as follows: 1 enables VHDL drivers 0 disables VHDL drivers
Synopsis Use this routine to enable or disable the inclusion of VHDL drivers in the determination of driver values. Returns No return value. Example E-20 Example of acc_lsi_dumpports_vhdl_enable
#include "acc_user.h" #include "vcs_acc_user.h" handle instance = acc_handle_by_name("test_bench.device", 0); char *outfile1 = "device.evcd1"; char *outfile2 = "device.evcd2"; /* Include VHDL drivers in this report */ acc_lsi_dumpports_vhdl_enable(1); acc_lsi_dumpports_call(instance, outfile1); /* Exclude VHDL drivers from this report */ acc_lsi_dumpports_vhdl_enable(0); acc_lsi_dumpports_call(instance, outfile1); ...
Caution This routine has precedence over the +dumpports+vhdl+enable and +dumpports+vhdl+disable runtime options.
acc_mod_lcb_add Registers a line callback routine with a module so that VCS calls the routine whenever VCS executes the specified module. See acc_mod_lcb_add on page 53 for details. acc_mod_lcb_del Unregisters a line callback routine previously registered with the acc_mod_lcb_add() routine. See acc_mod_lcb_del on page 55 for details. acc_mod_lcb_enabled Tests to see if line callbacks is enabled. See acc_mod_lcb_enabled on page 57 for details. acc_mod_lcb_fetch Returns an array of breakable lines. See acc_mod_lcb_fetch on page 57 for details. acc_mod_lcb_fetch2 Returns an array of breakable lines. See acc_mod_lcb_fetch2 on page 59 for details. acc_mod_sfi_fetch Returns the source file composition for a module. See acc_mod_sfi_fetch on page 61 for details.
acc_mod_lcb_add
Syntax
void acc_mod_lcb_add(handle handleModule, void (*consumer)(), char *user_data)
Synopsis Registers a line callback routine with a module so that VCS calls the routine whenever VCS executes the specified module. The prototype for the callback routine is:
void consumer(char *filename, int lineno, char *user_data, int tag)
The tag field is a unique identifier that you use to distinguish between multiple include files. Protected modules cannot be registered for callback. This routine will just ignore the request. Returns No return value. Example E-21 Example of acc_mod_lcb_add
#include <stdio.h> #include "acc_user.h" #include "vcs_acc_user.h" /* VCS callback rtn */ void line_call_back(filename, lineno, userdata, tag) char *filename; int lineno; char *userdata; int tag; { handle handle_mod = (handle)userdata; io_printf("Tag %2d, file %s, line %2d, module %s\n", tag, filename, lineno, acc_fetch_fullname(handle_mod)); }
/* register all modules for line callback (recursive) */ void register_lcb (parent_mod) handle parent_mod; { handle child = NULL; if (! acc_object_of_type(parent_mod, accModule)) return; io_printf("Registering %s\n", acc_fetch_fullname (parent_mod)); acc_mod_lcb_add (parent_mod, line_call_back, parent_mod); while ((child = acc_next_child (parent_mod, child))) { register_lcb (child); } }
acc_mod_lcb_del
Syntax
void acc_mod_lcb_del(handle handleModule, void (*consumer)(), char *user_data)
Synopsis Unregisters a line callback routine previously registered with the acc_mod_lcb_add() routine. Returns No return value. Example E-22 Example of acc_mod_lcb_del
/* VCS 4.x callback rtn */ void line_call_back(filename, lineno, userdata, tag) char *filename; int lineno; char *userdata; int tag; { handle handle_mod = (handle)userdata; io_printf("Tag %2d, file %s, line %2d, module %s\n", tag, filename, lineno, acc_fetch_fullname(handle_mod)); } /* unregister all line callbacks (recursive) */ void unregister_lcb (parent_mod) handle parent_mod; { handle child = NULL; if (! acc_object_of_type(parent_mod, accModule)) return; io_printf("Unregistering %s\n", acc_fetch_fullname (parent_mod)); acc_mod_lcb_del (parent_mod, line_call_back, parent_mod); while ((child = acc_next_child (parent_mod, child))) { register_lcb (child); } }
Caution The module handle, consumer routine, and user data arguments must match those supplied to the acc_mod_lcb_add() routine for a successful delete.
For example, using the result of a call such as acc_fetch_name() as the user data will fail, because that routine returns a different pointer each time it is called.
acc_mod_lcb_enabled
Syntax
int acc_mod_lcb_enabled()
Synopsis Test to see if line callbacks is enabled. By default, the extra code required to support line callbacks is not added to a simulation executable. You can use this routine to determine if line callbacks have been enabled. Returns Non-zero if line callbacks are enabled; 0 if not enabled. Example E-23 Example of acc_mod_lcb_enabled
if (! acc_mod_lcb_enable) { tf_warning("Line callbacks not enabled. Please recompile with -line."); } else { acc_mod_lcb_add ( ... ); ... }
acc_mod_lcb_fetch
Syntax
p_location acc_mod_lcb_fetch(handle handleModule)
Synopsis Returns an array of breakable lines. This routine returns all the lines in a module that you can set breakpoints on. Returns The return value is an array of line number, file name pairs. Termination of the array is indicated by a NULL file name field. The calling routine is responsible for freeing the returned array.
typedef struct t_location { int line_no; char *filename; } s_location, *p_location;
Returns NULL if the module has no breakable lines or is source protected. Example E-24 Example of acc_mod_lcb_fetch
#include <stdio.h> #include "acc_user.h" #include "vcs_acc_user.h" void ShowLines(handleModule) handle handleModule; { p_location plocation; if ((plocation = acc_mod_lcb_fetch(handleModule)) != NULL) { int i; io_printf("%s:\n", acc_fetch_fullname(handleModule)); for (i = 0; plocation[i].filename; i++) {
acc_mod_lcb_fetch2
Syntax
p_location2 acc_mod_lcb_fetch2(handle handleModule)
Synopsis Returns an array of breakable lines. This routine returns all the lines in a module that you can set breakpoints on. The tag field is a unique identifier used to distinguish include files. For example, in the following Verilog module, the breakable lines in the first include of the file sequential.code have a different tag than the breakable lines in the second include. (The tag numbers will match the vcs_srcfile_info_t>SourceFileTag field. See the acc_mod_sfi_fetch() routine for details.)
module x; initial begin include sequential.code include sequential.code end endmodule
Returns The return value is an array of location structures. Termination of the array is indicated by a NULL filename field. The calling routine is responsible for freeing the returned array.
typedef struct t_location2 { int line_no; char *filename; int tag; } s_location2, *p_location2;
Returns NULL if the module has no breakable lines or is source protected. Example E-25 Example of acc_mod_lcb_fetch2
#include <stdio.h> #include "acc_user.h" #include "vcs_acc_user.h" void ShowLines2(handleModule) handle handleModule; { p_location2 plocation; if ((plocation = acc_mod_lcb_fetch2(handleModule)) != NULL) { int i; io_printf("%s:\n", acc_fetch_fullname(handleModule)); for (i = 0; plocation[i].filename; i++) { io_printf(" file %s, line %d, tag %d\n", plocation[i].filename, plocation[i].line_no, plocation[i].tag); } acc_free(plocation); } }
acc_mod_sfi_fetch
Syntax
vcs_srcfile_info_p acc_mod_sfi_fetch(handle handleModule)
Synopsis Returns the source file composition for a module. This composition is a file name with line numbers, or, if a module definition is in more than one file, it is an array of vcs_srcfile_info_s struct entries specifying all the file names and line numbers for the module definition. Returns The returned array is terminated by a NULL SourceFileName field. The calling routine is responsible for freeing the returned array.
typedef struct vcs_srcfile_info_t { char *SourceFileName; int SourceFileTag; int StartLineNum; int EndLineNum; } vcs_srcfile_info_s, *vcs_srcfile_info_p;
Returns NULL if the module is source protected. Example E-26 Example of acc_mod_sfi_fetch
#include <stdio.h> #include "acc_user.h" #include "vcs_acc_user.h" void print_info (mod) handle mod; { vcs_srcfile_info_p infoa;
io_printf("Source Info for Module %s:\n", acc_fetch_fullname(mod)); if ((infoa = acc_mod_sfi_fetch(mod)) != NULL) { int i; for (i = 0; infoa[i].SourceFileName != NULL; i++) { io_printf(" Tag %2d, StartLine %2d, ", infoa[i].SourceFileTag, infoa[i].StartLineNum); io_printf("EndLine %2d, SrcFile %s\n", infoa[i].EndLineNum, infoa[i].SourceFileName); } acc_free(infoa); } }
This routine inserts a trailer section containing the endprotected compiler directive into the output file. It also toggles the encryption flag to false so that subsequent calls to vcsSpWriteString() and vcsSpWriteChar() will NOT cause their data to be encrypted. See vcsSpEncodeOff on page 67 for details. vcsSpEncodeOn This routine inserts a trailer section containing the protected compiler directive into the output file. It also toggles the encryption flag to false so that subsequent calls to vcsSpWriteString() and vcsSpWriteChar() will have their data encrypted. See vcsSpEncodeOn on page 68 for details. vcsSpEncoding This routine gets the current state of encoding. See vcsSpEncoding on page 70 for details. vcsSpGetFilePtr This routine just returns the value previously passed to the vcsSpSetFilePtr() routine. See vcsSpGetFilePtr on page 71 for details. vcsSpInitialize Allocates a source protect object. See vcsSpInitialize on page 72 for details. vcsSpOvaDecodeLine Decrypts one line. See vcsSpOvaDecodeLine on page 73 for details. vcsSpOvaDisable
PLI Access Routines E-63
Switches to regular encryption. See vcsSpOvaDisable on page 74 for details. vcsSpOvaEnable Enables the OpenVera assertions (OVA) encryption algorithm. Tells VCSs encrypter to use the OVA IP algorithm. See vcsSpOvaEnable on page 75 for details. vcsSpSetDisplayMsgFlag Sets the DisplayMsg flag. See vcsSpSetDisplayMsgFlag on page 77 for details. vcsSpSetFilePtr Specifies the output file stream. See vcsSpSetFilePtr on page 77 for details. vcsSpSetLibLicenseCode Sets the OEM license code. See vcsSpSetLibLicenseCode on page 78 for details. vcsSpSetPliProtectionFlag Sets the PLI protection flag. See vcsSpSetPliProtectionFlag on page 79 for details. vcsSpWriteChar Writes one character to the protected file. See vcsSpWriteChar on page 80 for details. vcsSpWriteString Writes a character string to the protected file. See vcsSpWriteString on page 81 for details.
Example E-27 outlines the basic use of the source protection routines. Example E-27 Using the Source Protection Routines
#include <stdio.h> #include "enclib.h" void demo_routine() { char *filename = "protected.vp"; int write_error = 0; vcsSpStateID esp; FILE *fp; /* Initialization */ if ((fp = fopen(filename, "w")) == NULL) { printf("Error: opening file %s\n", filename); exit(1); } if ((esp = vcsSpInitialize()) == NULL) { printf("Error: Initializing src protection routines.\n"); printf(" Out Of Memory.\n"); fclose(fp); exit(1); } vcsSpSetFilePtr(esp, fp); /* tell rtns where to write */ /* Write output */ write_error += vcsSpWriteString(esp, "This text will *not* be encrypted.\n"); write_error += vcsSpEncodeOn(esp); write_error += vcsSpWriteString(esp, "This text *will* be encrypted."); write_error += vcsSpWriteChar(esp, \n); write_error += vcsSpEncodeOff(esp);
write_error += vcsSpWriteString(esp, "This text will *not* be encrypted.\n"); /* Clean up */ write_error += fclose(fp); vcsSpClose(esp); if (write_error) { printf("Error while writing to %s\n", filename); } }
Caution If you are encrypting SDF or Verilog code that contains include directives, you must switch off encryption (vcsSpEncodeOff), output the include directive and then switch encryption back on. This ensures that when the parser begins reading the included file, it is in a known (non-decode) state. If the file being included has proprietary data it can be encrypted separately. (Dont forget to change the include compiler directive to point to the new encrypted name.)
vcsSpClose
Syntax
void vcsSpClose(vcsSpStateID esp)
Synopsis This routine frees the memory allocated by vcsSpInitialize(). Call it when source encryption is finished on the specified stream.
vcsSpEncodeOff
Syntax
int vcsSpEncodeOff(vcsSpStateID esp)
Synopsis This function performs two operations: 1. It inserts a trailer section that contains some closing information used by the decryption algorithm into the output file. It also inserts the `endprotected compiler directive in the trailer section. 2. It toggles the encryption flag to false so that subsequent calls to vcsSpWriteString() and vcsSpWriteChar() will NOT cause their data to be encrypted. Returns Non-zero if there was an error writing to the output file, 0 if successful. Example E-29 Example of vcsSpEncodeOff
vcsSpStateID esp = vcsSpInitialize(); FILE *fp = fopen("protected.file", "w"); int write_error = 0; * if (fp == NULL) exit(1);
vcsSpSetFilePtr(esp, fp); if (vcsSpWriteString(esp, "This text will *not* be encrypted. ++write_error; if (vcsSpEncodeOn(esp)) ++write_error; if (vcsSpWriteString(esp, "This text *will* be encrypted. ++write_error; if (vcsSpEncodeOff(esp)) ++write_error; if (vcsSpWriteString(esp, "This text will *not* be encrypted. ++write_error; fclose(fp); vcsSpClose(esp);
Caution You must call vcsSpInitialize() and vcsSpSetFilePtr() before calling this routine.
vcsSpEncodeOn
Syntax
int vcsSpEncodeOn(vcsSpStateID esp)
Synopsis This function performs two operations: 1. It inserts a header section which contains the protected compiler directive into the output file. It also inserts some initial header information used by the decryption algorithm.
2. It toggles the encryption flag to true so that subsequent calls to vcsSpWriteString() and vcsSpWriteChar() will have their data encrypted. Returns Non-zero if there was an error writing to the output file, 0 if successful. Example E-30 Example of vcsSpEncodeOn
vcsSpStateID esp = vcsSpInitialize(); FILE *fp = fopen("protected.file", "w"); int write_error = 0; if (fp == NULL) exit(1); vcsSpSetFilePtr(esp, fp); if (vcsSpWriteString(esp, "This text will *not* be encrypted.\n")) ++write_error; if (vcsSpEncodeOn(esp)) ++write_error; if (vcsSpWriteString(esp, "This text *will* be encrypted.\n")) ++write_error; if (vcsSpEncodeOff(esp)) ++write_error; if (vcsSpWriteString(esp, "This text will *not* be encrypted.\n")) ++write_error; fclose(fp); vcsSpClose(esp);
Caution You must call vcsSpInitialize() and vcsSpSetFilePtr() before calling this routine.
vcsSpEncoding
Syntax
int vcsSpEncoding(vcsSpStateID esp)
Synopsis Calling vcsSpEncodeOn() and vcsSpEncodeOff() turns encoding on and off. Use this function to get the current state of encoding. Returns 1 for on, 0 for off. Example E-31 Example of vcsSpEncoding
vcsSpStateID esp = vcsSpInitialize(); FILE *fp = fopen("protected.file", "w"); if (fp == NULL) { printf("ERROR: file ..."); exit(1); } vcsSpSetFilePtr(esp, fp); ... if (! vcsSpEncoding(esp)) vcsSpEncodeOn(esp) ... if (vcsSpEncoding(esp)) vcsSpEncodeOff(esp); fclose(fp); vcsSpClose(esp);
vcsSpGetFilePtr
Syntax
FILE *vcsSpGetFilePtr(vcsSpStateID esp)
Synopsis This routine just returns the value previously passed to the vcsSpSetFilePtr() routine. Returns File pointer or NULL if not set. Example E-32 Example of vcsSpGetFilePtr
vcsSpStateID esp = vcsSpInitialize(); FILE *fp = fopen("protected.file", "w"); if (fp != NULL) vcsSpSetFilePtr(esp, fp); else /* doh! */ ... if ((gfp = vcsSpGetFilePtr(esp)) != NULL) { /* Add comment before starting encryption */ fprintf(gfp, "\n// TechStuff Version 2.2\n"); vcsSpEncodeOn(esp); }
Caution Don't use non-vcsSp* routines (like fprintf) in conjunction with vcsSp* routines, while encoding is enabled.
vcsSpInitialize
Syntax
vcsSpStateID vcsSpInitialize(void)
Synopsis This routine allocates a source protect object. Returns a handle to a mallocd object which must be passed to all the other source protection routines. This object stores the state of the encryption in progress. When the encryption is complete, this object should be passed to vcsSpClose() to free the allocated memory. If you need to write to multiple streams at the same time (perhaps youre creating include or SDF files in parallel with model files), you can make multiple calls to this routine and assign a different file pointer to each handle returned. Each call mallocs less than 100 bytes of memory. Returns The vcsSpStateID pointer or NULL if memory could not be mallocd. Example E-33 Example of vcsSpStateID
Caution This routine must be called before any other source protection routine. A NULL return value means the call to malloc() failed. Your program should test for this.
vcsSpOvaDecodeLine
Syntax
vcsSpStateID vcsSpOvaDecodeLine(vcsSpStateID esp, char *line)
Synopsis This routine decrypts one line. Use this routine to decrypt one line of protected IP code such as OVA code. Pass in a null vcsSpStateID handle with the first line of code and a non-null handle with subsequent lines. Returns Returns NULL when the last line has been decrypted. Example E-34 Example of vcsSpOvaDecodeLine
#include "enclib.h" if (strcmp(linebuf, "protected_ip synopsys\n")==0) { /* start IP decryption */ vcsSpStateID esp = NULL; while (fgets(linebuf, sizeof(linebuf), infile)) { /* linebuf contains encrypted source */ esp = vcsSpOvaDecodeLine(esp, linebuf); if (linebuf[0]) { /* linebuf contains decrypted source */
} /* next line should be endprotected_ip */ fgets(linebuf, sizeof(linebuf), infile); if (strcmp(linebuf, "endprotected_ip\n")!=0) { printf("warning - expected endprotected_ip\n"); } }
vcsSpOvaDisable
Syntax
void vcsSpOvaDisable(vcsSpStateID esp)
Synopsis This routine switches to regular encryption. It tells VCSs encrypter to use the standard algorithm. This is the default mode. Returns No return value. Example E-35 Example of vcsSpOvaDisable
#include "enclib.h" #include "encint.h" int write_error = 0; vcsSpStateID esp; if ((esp = vcsSpInitialize()) printf("Out Of Memory"); vcsSpSetFilePtr(esp, fp); /* previously opened FILE* pointer */ /* Configure for OVA IP encryption */ vcsSpOvaEnable(esp, "synopsys");
if (vcsSpWriteString(esp, "This text will NOT be encrypted.\n")) ++write_error; if (vcsSpEncodeOn(esp)) ++write_error; if (vcsSpWriteString(esp, "This text WILL be encrypted.\n")) ++write_error; if (vcsSpEncodeOff(esp)) ++write_error; if (vcsSpWriteString(esp, "This text will NOT be encrypted.\n")) ++write_error; /* Switch back to regular encryption */ vcsSpOvaDisable(esp); if (vcsSpEncodeOn(esp)) ++write_error; if (vcsSpWriteString(esp, "This text WILL be encrypted.\n")) ++write_error; if (vcsSpEncodeOff(esp)) ++write_error; vcsSpClose(esp);
vcsSpOvaEnable
Syntax
void vcsSpOvaEnable(vcsSpStateID esp, char *vendor_id)
Synopsis Enables the OpenVera assertions (OVA) encryption algorithm. Tells VCSs encrypter to use the OVA IP algorithm. Returns No return value.
PLI Access Routines E-75
Example E-36
Example of vcsSpOvaEnable
#include "enclib.h" #include "encint.h" int write_error = 0; vcsSpStateID esp; if ((esp = vcsSpInitialize()) printf("Out Of Memory"); vcsSpSetFilePtr(esp, fp); /* previously opened FILE* pointer */ /* Configure for OVA IP encryption */ vcsSpOvaEnable(esp, "synopsys"); if (vcsSpWriteString(esp, "This text will NOT be encrypted.\n")) ++write_error; if (vcsSpEncodeOn(esp)) ++write_error; if (vcsSpWriteString(esp, "This text WILL be encrypted.\n")) ++write_error; if (vcsSpEncodeOff(esp)) ++write_error; if (vcsSpWriteString(esp, "This text will NOT be encrypted.\n")) ++write_error; /* Switch back to regular encryption */ vcsSpOvaDisable(esp); if (vcsSpEncodeOn(esp)) ++write_error; if (vcsSpWriteString(esp, "This text WILL be encrypted.\n")) ++write_error; if (vcsSpEncodeOff(esp)) ++write_error; vcsSpClose(esp);
vcsSpSetDisplayMsgFlag
Syntax
void vcsSpSetDisplayMsgFlag(vcsSpStateID esp, int enable)
Synopsis This routine sets the DisplayMsg flag. By default, the VCS compiler does not display decrypted source code in its error or warning messages. Use this routine to enable this display. Returns No return value. Example E-37 Example of vcsSpSetDisplayMsgFlag
vcsSpSetFilePtr
Syntax
void vcsSpSetFilePtr(vcsSpStateID esp, FILE *fp)
Synopsis This routine specifies the output file stream. Before using the vcsSpWriteChar() or vcsSpWriteString() routines, you must specify the output file stream. Returns No return value. Example E-38 Example of vcsSpSetFilePtr
FILE *fp = fopen("protected.file", "w"); if (fp != NULL) vcsSpSetFilePtr(esp, fp); else /* abort */
vcsSpSetLibLicenseCode
Syntax
void vcsSpSetLibLicenseCode(vcsSpStateID esp, unsigned int code)
Synopsis This routine sets the OEM library license code that will be added to each protected region started by vcsSpEncodeOn(). This code can be used to protect library models from unauthorized use. When the VCS parser decrypts the protected region, it verifies that the end user has the specified license. If the license does not exist or has expired, VCS exits. Returns No return value. Example E-39 Example of vcsSpSetLibLicenseCode
unsigned int lic_code = MY_LICENSE_CODE; vcsSpStateID esp = vcsSpInitialize(); ... /* The following text will be encrypted and licensed */ vcsSpSetLibLicenseCode(esp, code); /* set license code */ vcsSpEncodeOn(esp); /* start protected region */ vcsSpWriteString(esp, "this text will be encrypted and
licensed"); vcsSpEncodeOff(esp);
/* The following text will be encrypted but unlicensed */ vcsSpSetLibLicenseCode(esp, 0); /* clear license code */ vcsSpEncodeOn(esp); /* start protected region */ vcsSpWriteString(esp, "this text encrypted but not licensed"); vcsSpEncodeOff(esp); /* end protected region */
Caution The rules for mixing licensed and unlicensed code is determined by your OEM licensing agreement with Synopsys. The code segment in Example E-39 shows how to enable and disable the addition of the license code to the protected regions. Normally you would call this routine once, that is, after calling vcsSpInitialize() and before the first call to vcsSpEncodeOn().
vcsSpSetPliProtectionFlag
Syntax
void vcsSpSetPliProtectionFlag(vcsSpStateID esp, int enable)
Synopsis This routine sets the PLI protection flag. You can use it to disable the normal PLI protection that is placed on encrypted modules. The output files will still be encrypted, but CLI and PLI users will not be prevented from accessing data in the modules. This routine only affects encrypted Verilog files. Encrypted SDF files, for example, are not affected.
Caution Turning off PLI protection will allow users of your modules to access object names, values, etc. In essence, the source code for your module could be substantially reconstructed using the CLI commands and ACC routines.
vcsSpWriteChar
Syntax
void vcsSpSetPliProtectionFlag(vcsSpStateID esp, int enable)
Synopsis This routine writes one character to the protected file. If encoding is enabled (see vcsSpEncodeOn on page 68) the specified character is encrypted as it is written to the output file. If encoding is disabled (see vcsSpEncodeOff on page 67) the specified character is written as-is to the output file (no encryption.) Returns Non-zero if the file pointer has not been set (see vcsSpSetFilePtr on page 77) or if there was an error writing to the output file (out-of-disk-space, etc.)
PLI Access Routines E-80
vcsSpStateID esp = vcsSpInitialize(); FILE *fp = fopen("protected.file", "w"); int write_error = 0; if (fp == NULL) exit(1); vcsSpSetFilePtr(esp, fp); if (vcsSpWriteChar(esp, a)) /* This char will *not* be encrypted.*/ ++write_error; if (vcsSpEncodeOn(esp)) ++write_error; if (vcsSpWriteChar(esp, b)) /* This char *will* be encrypted. */ ++write_error; if (vcsSpEncodeOff(esp)) ++write_error; fclose(fp); vcsSpClose(esp);
Caution vcsSpInitialize() and vcsSpSetFilePtr() must be called prior to calling this routine.
vcsSpWriteString
Syntax
int vcsSpWriteString(vcsSpStateID esp, char *s)
Synopsis This routine writes a character string to the protected file. If encoding is enabled (see vcsSpEncodeOn on page 68) the specified string is encrypted as it is written to the output file. If encoding is disabled (see vcsSpEncodeOff on page 67) the specified string will be written as-is to the output file (no encryption.) Returns Non-zero if the file pointer has not been set (see vcsSpSetFilePtr on page 77) or if there was an error writing to the output file (out-of-disk-space, etc.) Returns 0 if the write was successful. Example E-42 Example of vcsSpWriteString
vcsSpStateID esp = vcsSpInitialize(); FILE *fp = fopen("protected.file", "w"); int write_error = 0; if (fp == NULL) exit(1); vcsSpSetFilePtr(esp, fp); if (vcsSpWriteString(esp, "This text will *not* be encrypted.\n")) ++write_error; if (vcsSpEncodeOn(esp)) ++write_error; if (vcsSpWriteString(esp, "This text *will* be encrypted.\n")) ++write_error; if (vcsSpEncodeOff(esp)) ++write_error; if (vcsSpWriteString(esp, "This text will *not* be encrypted.\n"))
Caution vcsSpInitialize() and vcsSpSetFilePtr() must be called prior to calling this routine.
acc_object_of_type
Syntax
bool acc_object_of_type(accGenerated, sigHandle)
Synopsis This routine returns true if the signal is in a generate block. Returns 1 - if the signal is in a generate block. 0 - if the signal is not in a generate block.
Vcsinit()
When VCS is run in slave mode, you can call this function to elaborate the design and to initialize various data structures, scheduling queues, etc. that VCS uses. After this routine executes, all the initial time 0 events, such as the execution of initial blocks, are scheduled. Call the vmc_main(int argc, char *argv) routine to pass runtime flags to VCS before you call VcsInit().
VcsSimUntil()
This routine tells VCS to schedule a stop event at the specified simulation time and execute all scheduled simulation events until it executes the stop event. The syntax for this routine is as follows:
VcsSimUntil (unsigned int* t)
Argument t is for specifying the simulation time. It needs two words. The first [0] is for simulation times from 0 to 232 -1, the second is for simulation times that follow. If any events are scheduled to occur after time t, their execution must wait for another call to VcsSimUntil. If t is less than the current simulation time, VCS returns control to the calling routine.
Index
Symbols
-a filename B-65 -ams_discipline B-54 -ams_iereport B-54 -assert B-9 -C B-51 -c B-47 -CC B-49 -cc B-49 -CFLAGS B-49 -cm assert B-14 -comp64 B-16, B-25 -cpp B-50 -debug B-64 -debug_all B-64 -debug_pp B-64 -doc 2-3, B-8 -e name_for_main B-37 -E program runtime option C-30 -extinclude B-22, D-8 -f filename B-35 -full64 B-24 -gui 2-6, 5-7 -h 2-3, B-7 -help 2-3, B-7 -ID 2-3, B-46 -jnumber_of_CPUs B-50 -l C-21 -l filename 2-7, B-64, C-20 -ld linker B-47 -LDFLAGS B-47 -lmc-swift B-42 -lmc-swift-template B-42 -lname B-47 -load 20-34, B-40 -Mdir B-6 -Mdirectory B-6 -Mlib=dir B-7 -negdelay B-33 -noIncComp B-7 -ntb B-16 -ntb_cmp B-17 -ntb_define B-16 -ntb_filext B-16 -ntb_incdir B-17 -ntb_opts B-17 -ntb_sfname B-20 -ntb_vipext B-21 -ntb_vl B-21 -o name B-66 -O number B-51 -O0 B-51 -ova_enable_case B-15 -override_timescale B-58 -P pli.tab B-38
IN-1
-parameters 2-6, 4-5, B-55 -platform B-66 -PP D-18 -pvalue 2-6, 4-5, B-55 -q 2-7, B-43, C-20 -R 2-6, B-25, B-65 -sysc B-61 -u B-65 -ucli 5-6 -V 2-7, B-43, C-20 -v 2-3, B-4 -vcd filename C-24 -Vt B-43 -Xman B-53 -Xmangle B-53 -Xnoman B-54 -Xnomangle B-54 -Xova B-15 -y 2-4, B-4 assert hier=file.txt B-13 celldefine B-44, B-46, D-2, D-3 default_nettype D-2 define D-3 delay_mode_distributed D-5 delay_mode_path D-5 delay_mode_unit D-5 delay_mode_zero D-5 else D-3 elseif D-3 endcelldefine D-2 endif D-3 endprotect D-6 endprotected D-7 endrace B-56 ifdef D-4 include B-22, D-8 specifying the search directories B-61 with a different verion of Verilog B-22 line D-10 noportcoerce 3-28, D-8 nounconnected_drive D-10
portcoerce D-8 protect B-53, D-7 protected D-7 race B-56 resetall D-3 timescale B-58, D-8 unconnected_drive D-10 undef D-5 uselib D-9 vcs_mipdexpand D-6 "A" specifier of abstract access 20-48 "C" specifier of direct access 20-48 **NC 3-14 %CELL 20-14, 20-17 %TASK 20-14 +abstract 20-123 +acc+2 B-37 +acc+3 B-37 +acc+4 B-37 +acc+level_number 20-20, B-37 +ad B-54 +allhdrs 20-123 +allmtm B-25 +applylearn 20-2420-31 +applylearn+filename B-37 +auto2protect B-52 +auto3protect B-52 +autoprotect B-52 +charge_decay B-26 +define+macro=value 2-7, B-65 +delay_mode_distributed 9-36, B-27 +delay_mode_path 9-36, B-26 +delay_mode_unit 9-36, B-26 +delay_mode_zero 9-36, B-26 +deleteprotected B-52 +incdir 2-5, B-61 +iopath+edge B-29 +libext 2-5, B-5 +liborder 2-5, B-5 +librescan B-6 +libverbose B-6, B-42
IN-2
+lint B-42 +list 20-123 +maxdelays B-26, B-27, C-24 +memcbk B-64 +mindelays B-26, B-27, C-25 +module module_identifier C-17 +multisource_int_delays 9-21, B-27 +nbaopt B-27 +neg_tchk 9-57, 9-64, B-34 +no_notifier 9-57, B-31, C-18 +no_pulse_msg C-20 +no_tchk_msg 9-57, B-31, C-18 +nocelldefinepli+0 B-44 +nocelldefinepli+1 B-45 +nocelldefinepli+2 B-45 +noerrorIOPCWM B-62, B-63 +nolibcell B-44 +nospecify 9-58, B-31 +notimingcheck 9-58, B-31, C-18 +ntb_cache_dir C-3 +ntb_delete_disk_cache C-3 +ntb_disable_cnst_null_object_warning C-3 +ntb_enable_checker_trace C-4 +ntb_enable_checker_trace_on_failure C-4 +ntb_enable_solver_trace_on_failure C-5 +ntb_enable_solver_trace_on_failure=value C-5 +ntb_exit_on_error C-5 +ntb_load C-6 +ntb_random_seed C-6 +ntb_random_seed_automatic C-6 +ntb_solver_array_size_warn C-7 +ntb_solver_debug 14-7, C-7 extract 14-13, 14-16 profile 14-12, 14-16 serial 14-15 trace 14-9, 14-11, 14-15 +ntb_solver_debug_filter 14-9, 14-11, 14-13, C-8 +ntb_solver_mode C-9 +ntb_solver_mode=value C-9
+NTC2 9-63, B-34 +old_ntc B-34 +optconfigfile 8-5, 8-6, B-24 +overlap 9-67, B-34 +override_model_delays C-31 +pathpulse B-30 +pli_unprotected B-52 +plusarg_ignore B-36 +plusarg_save B-36 +plus-options C-31 +prof B-35 +protect file_suffix B-52 +pulse_e/number 9-23, 9-24, 9-26, 9-31, 9-32, B-32 +pulse_int_e 9-22, 9-23, 9-24, 9-26, B-32 +pulse_int_r 9-22, 9-23, 9-24, 9-26, B-32 +pulse_on_detect 9-32, B-33 +pulse_on_event 9-32, B-32 +pulse_r/number 9-23, 9-24, 9-26, 9-31, 9-32, B-32 +putprotect+target_dir B-53 +race=all 3-20, B-56, B-57 +rad 8-5, B-24 +sdf_nocheck_celltype B-28 +sdfprotect file_suffix B-53 +sdfverbose C-20 +systemverilogext B-21 +tetramax B-62 +timopt 9-38 +transport_int_delays 9-22, 9-24, 9-26, B-28 +transport_path_delays 9-21, 9-24, 9-26, B-28 +typdelays B-26, B-27, C-26 +UVM_VERBOSITY= 19-215 +v2k B-61 +vc 20-122, B-40 +vcs+dumpoff+t+ht C-24 +vcs+dumpon+t+ht C-24 +vcs+finish 5-27, C-19 +vcs+flush+all B-41, C-27 +vcs+flush+dump B-41, C-27 +vcs+flush+fopen B-41, C-27
IN-3
+vcs+flush+log B-41, C-27 +vcs+ignorestop C-31 +vcs+initreg+0|1|random| C-28 +vcs+initreg+random B-23 +vcs+learn+pli 20-2420-28, C-31 +vcs+lic+vcsi B-46, C-27 +vcs+lic+wait C-28 +vcs+loopdetect+number B-66 +vcs+loopreport+number B-66 +vcs+mipd+noalias C-32 +vcs+nostdout C-21 +vcs+stop 5-26, C-19 +vcs+vcdpluson B-63 +vcsi+lic+vcs B-46, C-27 +vcsi+lic+wait B-46 +verilog1995ext B-22 +verilog2001ext B-21 +vpddrivers C-23 +vpdfile 5-7 +vpdfileswitchsize 5-7 +vpdfileswitchsize+number_in_MB C-22 +vpdnoports C-23 +vpdportsonly C-23 +vpdupdate C-23 +vpi B-38 +vpi+1 B-38 +vpi+1+assertion B-39 +warn 3-48, B-43 $assert_category_start 17-23, 17-26 $assert_category_stop 17-22 $assert_monitor 17-9, D-26 $assert_monitor_off 17-9, D-27 $assert_monitor_on 17-9, D-27 $assert_set_category 17-15, 17-22 $assert_set_severity 17-14 $assert_severity_stop 17-22 $assertkill D-12 $assertoff D-11 $asserton D-12 $async$and$array D-37 $bitstoreal D-28
$countdrivers D-41 $deposit D-41 $disable_warnings D-34 $display D-29 $dist_exponential D-39 $dist_normal D-39 $dist_poisson D-39 $dist_uniform D-39 $dumpall D-13 $dumpfile D-13 $dumpflush D-13 $dumplimit D-13 $dumpoff D-13 $dumpon D-13 $dumpports 7-20, D-15 $dumpportsall D-17 $dumpportsflush D-17 $dumpportslimit D-17 $dumpportsoff D-16 $dumpportson D-16 $dumpvars D-13 $enable_warnings D-34 $error D-11 $fatal 17-34, D-11 $fclose D-30 $fdisplay D-30 $ferror D-30 $fflush D-14, D-30 $fflushall D-14 $fgetc D-30 $fgets D-30 $finish D-33 $fmonitor D-30 $fopen B-41, D-30 increasing the frequency of flushing B-41 $fread D-31 $fscanf D-31 $fseek D-31 $fstobe D-31 $ftell D-31 $fwrite D-31
IN-4
$get_initial_random_seed D-39 $getpattern D-41 $gr_waves D-14 $hold D-35 $info D-11 $itor D-28 $log D-28 $lsi_dumpports 3-483-53, 7-19, D-15 $monitor D-29 $monitoroff D-29 $monitoron D-29 $nolog D-28 $past ignoring B-14 $period D-35 $printtimescale D-33 $q_add D-37 $q_exam D-38 $q_full D-38 $q_initialize D-38 $q_remove D-38 $random 3-46, D-39 $readmemb D-32 $readmemh D-32 $realtime D-38 $realtobits D-28 $recovery D-35 $recrem D-36 checking timestamp and timecheck conditions B-34 diabling delayed versions of signals in other timing checks B-34 $removal D-36 $reset D-40 $reset_count D-40 $reset_value D-40 $restart D-42 $rtoi D-29 $save D-42 $sdf_annotate D-41
$setup D-36 $setuphold D-36 checking timestamp and timecheck conditions B-34 diabling delayed versions of signals in other timing checks B-34 $skew D-37 $sreadmemb D-32 $sreadmemh D-32 $stime D-38 $stop D-33 $strobe D-29 $sync$nor$plane D-37 $system D-27 $systemf D-27 $test$plusargs D-40 $time D-38 $timeformat D-33 $ungetc D-32 $uniq_prior_checkoff system task 12-53 $uniq_prior_checkon system task 12-53 $value$plusargs 5-8 $vcdplusdeltacycleoff 7-18 $vcdplusdeltacycleon 7-18 $vcdplusmemoff 7-8 $vcdplusmemon 7-8 $vcdplusmemorydump 7-8 $vcdplusxx system tasks ignoring C-22 $warning D-11 $width D-37 $write D-29 $writememb D-33 $writememh D-33
Numerics
64-bit compilation and 32-bit simulation B-25 compilation and simulation B-24
IN-5
A
-a filename B-65 "A" specifier of abstract access 20-48 +abstract 20-123 abstract access for C/C++ functions access routines for 20-7320-117 enabling with a compile-time option 20-123 using 20-7120-117 +acc+level_number 20-20, B-37 ACC capabilities 20-27, B-37 cbk 20-12, 20-18 cbka 20-12 enabling debugging B-37 frc 20-12, 20-18 gate 20-13 mip 20-13 mipb 20-13 mp 20-13 prx 20-13 r 20-12, 20-17 rw 20-12, 20-18 s 20-13 specifying 20-1020-19 tchk 20-13 access routines for abstract access of C/C++ functions 20-7320-117 accessing signed variablesa 19-121 +ad B-54 adaptor code generating 19-108 AICMs information messages B-54 +allhdrs 20-123 +allmtm B-25 alt_retain 9-5 -ams_discipline B-54 -ams_iereport B-54 ansi argument to -ntb_opts B-17 ANSI mode in OpenVera files B-17 aop advice
before/after/around 13-16 dominates 13-7 extends directive 13-3 placement element after 13-11 around 13-11 +applylearn 20-2420-31 arb.v 11-5 args PLI Specificaction 20-8 array output and inout argument type 20-64 array index 14-26 array members 14-31 assembler passing options to B-49 -assert B-9, C-10 -assert assertion_block_identifier C-17 -assert funchier 17-29, 17-30 -assert hier=file.txt B-13 -assert no_default_msg 17-32 assert no_default_msg 17-32 assert no_fatal_action 17-33 -assert quiet 17-32 -assert report 17-32 $assert_monitor 17-9, D-26 $assert_monitor_off 17-9, D-27 $assert_monitor_on 17-9, D-27 assertion failure messages controlling 17-31 assertion waring messages suppressing B-8 Assertions SystemVerilog enabling or disabling a module or a hierarchy B-10 assertions OpenVera B-15 blind signals B-20 bounds check in dynamic and fixed-size arrays B-18 bounds check in dynamic arrays B-17 bounds check in fixed-size arrays B-18 circular dependency check B-18
IN-6
display on screen B-18 disabling default failure messages C-12 encrypted IP mode filename extension B-21 encryption tokens file B-19 file name extension B-16 file-by-file preprocessing disabling B-18 include directory path B-17 including case violations in the global failure count C-18 interface ports named ifc_signal B-20 left padding in strings B-18 RVM enabling B-18 shell module name vera_shell specifying B-20 signal property access funtions enabling B-20 teshbench shell compiling B-21 filename specifying B-20 generating only B-20 not generating B-17 teshbench shell and shared object files generating B-17 specifying the directory B-20 timescale B-19 VMM enabling B-18 Openvera ANSI mode B-17 PSL disabling default failure messages C-12 SystemVerilog cover statements disabling B-14 diabling from a file B-14 disabling B-14 disabling assertion failure messages C-12 but enabling summary information C-12 disabling default failure messages C-12 disabling information in a VPD file B-15 dumping SVA in VPD file disabling C-10 enabling and disabling from a file C-14
specifying module definitions C-17 enabling assertion match (success) messages C-13 enabling runtime options B-9 enabling the -assert hier=file.txt runtime option for turning assertions off B-13 enabling vacuous success messages C-14 enhsnce reporting for assertions in functions B-9 excluding assertion failures with fail action blocks C-12 failure simulation time in Debussy B-15 generationg a report file C-13 adding more information C-14 ignoring $past B-13 maximum number of cover statement specifying the total number of cover statements in the assertion coverage information C-10 monitoring for assertion coverage C-17 no match simulation time in Debussy B-15 not displaying the assert or cover statement summary C-11 not writing the program_name.db database file C-11 specifying configuration file B-9 specifying the maximum number of failures for each assertion C-11 specifying the maximum number of successes for each assertion C-11 specifying the number of failures for an assertion C-10 specifying the rotal number of assertion failures C-10 starting simulation time in Debussy B-15 $assertkill D-12 $assertoff D-11 $asserton D-12 assert.report file C-13 adding more information C-14 $async$and$array D-37 attach_by_id() 19-110 +auto2protect B-52 +auto3protect B-52 auto-inserted connect modules (AICMs)
IN-7
B
bidirectional registered mixed-signal net dispalying a list of B-55 finishing compilation at B-55 bit C/C++ function argument type 20-51 C/C++ function return type 20-50 input argument type 20-63 output and inout argument type 20-64 reg data type in two-state simulation 20-46 $bitstoreal D-28 bounds check in OpenVera dynamic and fixed-size arrays B-18 in OpenVera dynamic arrays B-17 in OpenVera fixed-sise arrays B-18 -boundscheck B-62
C
-C B-51 C 14-37 -c 11-5, B-47 C code generating halt before compiling the generated C code B-51 passing options to the compiler B-49 specifying another compiler B-49 specifying the optimization level B-51 suppressing optimization for faster compilation B-51 C compiler not passing default options B-51 optimization levels B-49 passing options to B-49 specifying B-49 C compiler, environment variable specifying the A-4 "C" specifier of direct access 20-48
C/C++ functions argument direction 20-49, 20-50 argument type 20-49, 20-51 calling 20-5320-55 declaring 20-4720-53 extern declaration 20-48 in a Verilog environment 20-4620-47 return range 20-48 return type 20-48, 20-50 using abstract access 20-7120-117 access routines for 20-7320-117 using direct access 20-6220-71 examples 20-6420-69 C++ generating struct 19-142 precompiled headers 19-176 C++ compiler specifying B-50 call PLI specification 20-7 callbacks for memories and multi-dimensional arrays enabling B-64 calling C/C++ functions in your Verilog code 20-5320-55 case pragmas enabling B-15 cbk ACC capability 20-12, 20-18 cbka ACC capability 20-12 CBug 19-198 -CC B-49 -cc B-49 cell modules excluding from compilation B-44 celldefine B-44, B-46, D-2, D-3 CELLTYPE entries in SDF files disabling B-28 -CFLAGS B-49 -cg_coverage_control C-2 char* direct access for C/C++ functions formal parameter type 20-62 char** direct access for C/C++ functions
IN-8
formal parameter type 20-62 charge decay enabling B-26 +charge_decay B-26 check argument to -ntb_opts B-17 check PLI specification 20-7 check=all B-18 check=fixed B-18 circular dependency check check in OpenVera B-18 display on screen B-18 class 14-30 classes inheritance between 14-32 clock signals 9-379-42 -cm 10-3, C-17 -cm assert B-14 -comp64 B-16, B-25 compilation order 14-33 compiler directives D-1D-10 compile-time options B-1?? specifying in a file B-35 compiling incremental compilation triggering ??8-3 OpenVera testbench shell B-21 verbose messages 2-7, B-43 with include and -extinclude B-22 compression disasbling for VPD files C-23 conditional expressions warning when evaluate to X or Z B-55 filtering out false negatives B-55 configuration file for Radiant technology B-24 constraint solver array size warning C-7 OpenVera trace information C-5 constraints conflicts 14-26 constraint profiling 14-12, 14-16 debugging C-7, C-8
partitions 14-4 test case extraction 14-13, 14-16 copyright information displaying C-20 $countdrivers D-41 coverage groups OpenVera enabling C-2 -cpp B-50
D
data PLI specification 20-8 Data Type Mapping File VCS/SystemC cosimulation interface 19-40 -debug B-64 -debug_all B-64 debug_all, option 5-7 -debug_pp 5-6, B-64 debug_pp, option 5-6 debug, option 5-7 Debussy B-64 assertions failure simulation time B-15 no match simulation time B-15 stating simulation time B-15 declaring C/C++ functions in your Verilog code 20-4720-53 default discrete discipline in VerilogAMS B-54 default_nettype D-2 define D-3 +define+macro=value 2-7, B-65 delay mode distributed behavior B-27 delay mode path behavior B-26 delay mode unit behavior B-26 delay mode zero behavior B-26 delay values back annotating to your design D-41 delay_mode_distributed D-5 +delay_mode_distributed 9-36, B-27 delay_mode_path D-5
IN-9
+delay_mode_path 9-36, B-26 delay_mode_unit D-5 +delay_mode_unit 9-36, B-26 delay_mode_zero D-5 +delay_mode_zero 9-36, B-26 delays changing all to 0 B-26 ignoring module path delays and changing gate, switch, and continuous assignment delays to time precision B-26 ignoring module path delays and using gate, switch, and continuous assignment delays B-27 module path delays X value B-32 with error message B-33 on gates and switches ignoring B-26 specifies using max of min|typ|max delays B-27 specifies using min of min|typ|max delays B-27 specifies using typ of min|typ|max delays B-27 transport delays B-28 +deleteprotected B-52 Denali 27-1 dep_check argument to -ntb_opts B-18 $deposit D-41 Design Description 11-6 diagnostic messages B-43 direct access for C/C++ functions examples 20-6420-69 formal parameters types 20-62 rules for parameter types 20-6220-64 using 20-6220-122 DirectC abstract access specifying B-40 enabling B-40 listing the C/C++ functions B-40 using pass by reference 20-61 vc_hdrs.h file B-40
direction of a C/C++ function argument 20-50 disable B-14 disable soft 14-35 disable_cover B-14 disable_file=filename B-14 $disable_warnings D-34 $display D-29 DISPLAY_VCS_HOME A-3 $dist_exponential D-39 $dist_normal D-39 $dist_poisson D-39 $dist_uniform D-39 DKI communication 19-6 -doc 2-3, B-8 documentation B-8 dominates 14-33 double* direct access for C/C++ functions formal parameter type 20-62 DPI 14-37, 19-175, 19-270 $dumpall D-13 $dumpfile D-13 $dumpflush D-13 $dumplimit D-13 $dumpoff D-13 dumpoff B-15, C-10 $dumpon D-13 $dumpports 7-20, D-15 $dumpportsall D-17 $dumpportsflush D-17 $dumpportslimit D-17 $dumpportsoff D-16 $dumpportson D-16 $dumpvars D-13 dynamic race detection B-56
E
-e name_for_main B-37 -E program C-30 edge sensitivity
IN-10
in SDF file IOPATH entries B-29 else D-3 elseif D-3 enable_diag B-9 enable_hier B-13 $enable_warnings D-34 enabling C-2 only where used in the last simulation 20-27 encryption all modules B-52 but not the module header B-52 but not the module header and parameter declarations B-52 enabling overwriting of existing files B-52 enabling PLI and UCLI access B-52 OpenVera tokens file B-19 SDF files B-53 specifying the directory for encrypted files B-53 specifying with protect endprotect B-52 endcelldefine D-2 endif D-3 ending simulation at a specified time C-19 endprotect D-6 endprotected D-7 Environment variables 1-61-7, A-1A-5 $error D-11 error messages changing to warning B-43 executable specifying the name of B-66 extended summary information displaying C-20 extends 14-33 extends directive advice 13-4 introduction 13-4 extern declaration 20-48 extern declarations 20-69 -extinclude B-22, D-8
F
-f filename B-35 fail action blocks C-12 $fatal D-11 $fclose D-30 $fdisplay D-30 $ferror D-30 $fflush D-14, D-30 $fflushall D-14 $fgetc D-30 $fgets D-30 -file 2-6, B-36 file name extension in Verilog library directories specifying B-5 files tokens.v B-53 filter_past B-13 $finish D-33 finish_maxfail=N C-10 fixed size arrays bounds check B-62 $fmonitor D-30 $fopen B-41, D-30 increasing the frequency of flushing B-41 foreach loops 14-42 four state Verilog data stored in vec32 20-56 fPIC 19-177 frc ACC capability 20-12, 20-18 $fread D-31 $fscanf D-31 FSDB files B-64 $fseek D-31 $fstobe D-31 $ftell D-31 -full64 B-24 function calls context 14-39 DPI 14-37 non-pure 14-38 pure 14-37
IN-11
$fwrite D-31
G
g++ 19-177 gate ACC capability 20-13 gate-level improving runtime performance B-67 gd_pulsewarn 9-7 generating adaptor code 19-108 generics overriding with the -gfile elaboration option B-58 $get_initial_random_seed D-39 $getpattern D-41 -gfile B-58 global_finish_maxfail=N C-10 globalDirective 17-26 gmake A-2 GNU 19-180 $gr_waves D-14 -gui 2-6, 5-7
H
-h 2-3, B-7 hard constraint 14-27 header and summary suppressing C-20 header files pre-compiled 19-177 -help 2-3, B-7 help with compile-time options, runtime options, and environment variables B-7 hier=file_name C-14 $hold D-35 -hsopt=gates B-67
I
-ID 2-3, B-46 IEEE std 1364-2001 enabling B-61
ifc_signal OpenVera interface ports named B-20 ifdef D-4 -ignore B-8 +incdir 2-5, B-61 include D-8 specifying the search directories B-61 increasing the stack guard size 19-185 increasing the stack size 19-184 incremental compilation B-6B-7 central place for descriptor information and object files B-7 disabling B-7 incremental compile directory specifying B-6 $info D-11 information messages about finding module definitrions in a library B-42 lint B-42 -ignore B-8 initializing state variables B-23 inout C/C++ function argument direction 20-50 input C/C++ function argument direction 20-50 int C/C++ function argument type 20-51 C/C++ function return type 20-50 direct access for C/C++ functions formal parameter type 20-62 input argument type 20-63 output and inout argument type 20-64 int* direct access for C/C++ functions formal parameter type 20-62 INTERCONNECT delays rejecting B-32 SDF files B-27 changing to transport delays B-28 negative values enabling B-33 interface 11-7
IN-12
self() 12-58 Interface Description 11-14 internal disk cache for randomization delete before simulation C-3 location C-3 intra-assingment delays removing B-27 IOPATH delays SDF files negative values enabling B-33 +iopath+edge B-29 $itor D-28
J
-jnumber_of_CPUs B-50
K
keywords after 13-11 around 13-11 before 13-11 extends 13-3 virtuals 13-31
L
-l C-21 -l filename 2-7, B-64, C-20 -ld linker B-47 -LDFLAGS options B-47 +libext 2-5, B-5 -libmap 4-12 +liborder 2-5, B-5 +librescan B-6 +libverbose B-6, B-42 licensing using VCS licenses for VCSi B-46 using VCSi licenses for VCS B-46 wait for a license B-46 specifying the wait time B-46
wait for a network license B-46 wait for a VCSi license B-46 -licqueue B-46 -licwait timeout B-46 line D-10 linker linking a library to the executable B-47 linking by hand B-47 passing flags to B-47 specifying B-47 temporary object files B-47 linking linking a specified library to the executable B-47 linking by hand B-47 passing options to the linker B-47 specifying another linker B-47 +lint B-42 lint messages B-42 +list 20-123 LMC SWIFT interface including B-42 -lmc-swift B-42 -lmc-swift-template B-42 -lname B-47 -load 20-34, B-40 $log D-28 log file appending to B-65 simulation specifying C-20 log file buffers increasing the frequency of flushing B-41 log file, environment variable specifying the A-4 log files specifying compilation log file 2-7, B-64 specifying with a system task D-28 loops specifying the maximum number of loops for a simulation event B-66 specifying the maximum number of loops for a simulation event warning B-66
IN-13
M
-m32 19-177 macros text macro defining B-65 main() routine specifying for PLI B-37 make A-2 mangled file source protection B-53 except module and port identifiers B-54 -Marchive B-6, B-47 maxargs PLI specification 20-8 maxcover=N C-10 +maxdelays B-26, B-27, C-24 maxfail=N C-11 maxsuccess=N C-11 MDAs 14-43 -Mdir 19-178, B-6 -Mdirectory B-6 member variables 19-136 +memcbk B-64 memories sparse memory models 3-39 Memory Modeler - Advanced Verification (MMAV) 27-1 memory size limits 3-38 messages about finding module definitions in a library B-42 changing error to warning B-43 lint B-42 quiet mode B-43 verbose diagnostic B-43 verbose mode B-43 including CPU time information B-43 warning disabling B-43 MHPI 19-199 minargs PLI specification 20-8 +mindelays B-26, B-27, C-25
mip ACC capability 20-13 mipb ACC capability 20-13 misc PLI specification 20-8 mixed analog/digital simulation specifying B-54 mixed signal simulation specifying B-54 -Mlib=dir B-7 module description , Verilog 11-15 -module module_identifier C-17 module path delays changing to tranport delays B-28 disabling B-31 disabling for an instance 9-37 suppressing in specific module instances 9-37 X value B-32 X value with error message B-33 $monitor D-29 $monitoroff D-29 $monitoron D-29 mp ACC capability 20-13 multiple packed dimensions 14-42 +multisource_int_delays 9-21, B-27
N
+nbaopt B-27 **NC 3-14 +neg_tchk 9-57, 9-64, B-34 negative multiconcat multiplier allowing B-63 negative timing checks B-33 -negdelay B-33 newsync 19-190 no_default_msg C-12 -no_error ID+ID B-43 no_fatal_action C-12 no_file_by_file_pp argument to -ntb_opts B-18 +no_identifier C-18 +no_notifier 9-57, B-31 +no_pulse_msg C-20
IN-14
+no_tchk_msg 9-57, B-31, C-18 +nocelldefinepli+1 B-45 nocelldefinepli PLI specification 20-9 +nocelldefinepli+0 B-44 +nocelldefinepli+2 B-45 nocovdb C-11 -noerror UPIMI+IOPCWM B-43 -xzcheck B-55 -noIncrComp B-7 +nolibcell B-44 $nolog D-28 nonblocking assignments removing intra-assignment delays B-27 noportcoerce 3-28, D-8 nopostproc C-11 +nospecify 9-58, B-31 -notice 2-7, B-43 notifier register in timincheck system tasks disabling B-31 notifier registers, suppressing the toggling of C-18 +notimingcheck 9-58, B-31, C-18 nounconnected_drive D-10 -ntb B-16 +ntb_cache_dir C-3 -ntb_cmp B-17 -ntb_define B-16 +ntb_delete_disk_cache C-3 +ntb_enable_solver_trace_on_failure C-5 +ntb_exit_on_error C-5 -ntb_filext B-16 -ntb_incdir B-17 +ntb_load C-6 -ntb_noshell B-17 -ntb_opts B-17 print_deps B-18 rvm B-18 sv_fmt B-18 -ntb_opts no_file_by_file_pp 11-28 +ntb_random_seed C-6
+ntb_random_seed_automatic C-6 -ntb_sfname B-20 -ntb_shell_only B-20 -ntb_sname B-20 +ntb_solver_array_size_warn C-7 +ntb_solver_debug 14-7, C-7 extract 14-13, 14-16 profile 14-16 serial 14-15 trace 14-9, 14-15 +ntb_solver_debug_filter 14-9, 14-11, 14-13, C-8 +ntb_solver_mode C-9 -ntb_spath B-20 -ntb_vipext 11-28, B-21 -ntb_vl B-21 +NTC2 9-63, B-34
O
-o name B-66 -O number B-51 -O0 B-51 object files enabling position independent code B-48 specifying temporary B-47 +old_ntc B-34 OpenVera constraint solver mode C-9 coverage groups C-2 diagnostics when randomize() method called C-4 enabling debugging when randomize() method called C-4 exit on error C-5 internal disk cache C-3 delete before simulation C-3 loading the shared object file C-6 on null object handle of object randomized C-3 trace information when randomize() returns 0 C-4
IN-15
trace information when constraint solver fails C-5 operating system commands, executing D-27 +optconfigfile 8-5, 8-6, B-24 optimization suppresssing for faster compilation B-51 output C/C++ function argument direction 20-50 OVA 17-31 ova_enable_case 17-36, B-15 -ova_enable_case_maxfail C-18 ova_enable_case_maxfail 17-35, C-18 -ova_inline B-15 ova_inline 17-36, B-15 +overlap 9-67, B-34 +override_model_delays C-31 -override_timescale B-58 -override-cflags B-51
P
-P pli.tab 20-19, B-38 packed constraints 14-42 packed dimensions 14-42 padding 19-120 parallel compilation B-7, B-51 disabling B-7 specifying the number of forks B-50 -parallel_compile_off B-7 -parameters 2-6, 4-5, B-55 parameters overriding B-55, B-60 overriding with the -gfile elaboration option B-58 partitions in constraints 14-4 pass by reference in DirectC 20-61 pathmap 19-197 +pathpulse B-30 PATHPULSE$ specparam, enabling B-30 performance improving for gate-level designs B-67
$period D-35 -picarchive B-48 placement element after 13-11 around 13-11 -platform B-66 platform directory in the VCS installation returning B-66 PLI ACC capabilities B-37 enabling debugging B-37 allowing access to ports and parameters B-45, B-46 disabling capabilities for celldefine and library modules B-46 disabling capabilities for celldefine modules B-45 enabling in encrypted files B-52 slave mode B-38 specifying the name of your main() routine B-37 PLI specifications args 20-8 call 20-7 check 20-7 data 20-8 maxargs 20-8 minargs 20-8 misc 20-8 nocelldefinepli 20-9 size 20-8 PLI table file 20-620-20 specifying B-38 +pli_unprotected B-52 pli.tab file 20-620-20 specifying B-38 +plusarg_ignore B-36 +plusarg_save B-36 plusargs, checking for on the simv command line D-40 +plus-options C-31 pointer C/C++ function argument type 20-51 C/C++ function return type 20-50
IN-16
input argument type 20-63 output and inout argument type 20-64 port coercion 3-27 Port Mapping File VCS/SystemC cosimulation interface 19-39 portcoerce D-8 position independent code enabling B-48 POSIX 19-198 -PP D-18 -prec 19-182 pre-compiled header files 19-177 print_deps argument to -ntb_opts B-18 $printtimescale D-33 priority keyword 12-46 procedure_prototype example 13-28, 13-29 +prof B-35 profiling B-35 program_name.db database file not writing C-11 proprietary message suppressing C-20 protect B-53, D-7 +protect file_suffix B-52 protected D-7 prx ACC capability 20-13 PSL 17-31 pulse error messages suppressing C-20 +pulse_e/number 9-23, 9-24, 9-26, 9-31, 9-32, B-32 +pulse_int_e 9-22, 9-23, 9-24, 9-26, B-32 +pulse_int_r 9-22, 9-23, 9-24, 9-26, B-32 +pulse_on_detect 9-32, B-33 +pulse_on_event 9-32, B-32 +pulse_r/number 9-23, 9-24, 9-26, 9-31, 9-32, B-32 pulses filtering out narrow pulses B-32 and flag as error B-32
on INTERCONNECT delays
INTERCONNECT delays filtering out SDF files INTERCONNECT delays filtering out
B-32 rejecting narrow pulses B-32 on SDF INTERCONNECT delays B-32 X value B-32, B-33 +putprotect+target_dir B-53 -pvalue 2-6, 4-5, B-55, B-60
Q
-q 2-7, B-43, C-20 $q_add D-37 $q_exam D-38 $q_full D-38 $q_initialize D-38 $q_remove D-38 quiet mode - suppressing header and summary information C-20 proprietary message C-20 simulation report at the end of simulation C-20
R
-R 2-6, B-25, B-65 r ACC capability 20-12, 20-17 -race B-56 race conditions avoiding 3-23-7 continuous assignment evaluations 3-5 generating a report of B-56 in counting events 3-6 in flip-flops 3-4 setting a value twice at the same time 3-3 time zero 3-7 using and setting a value at the same time 3-2 +race=all 3-20, B-57
IN-17
-racecd B-56 race.out file B-56 +rad 8-5, B-24 Radiant techology configuration file B-24 enabling B-24 rand members 14-30 rand_mode() method 12-17 $random 3-46, D-39 random number generator re-seeding C-6 random values setting the seed C-6 after restore C-6 randomize() method 12-17 randomize() serial number 14-15 randomize()solver trace 14-7 $readmemb D-32 $readmemh D-32 real C/C++ function argument type 20-51 input argument type 20-63 output and inout argument type 20-64 $realtime D-38 $realtobits D-28 $recovery D-35 $recrem D-36 checking timestamp and timecheck conditions B-34 diabling delayed versions of signals in other timing checks B-34 reg C/C++ function argument type 20-51 C/C++ function return type 20-50 input argument type 20-63 output and inout argument type 20-64 $reset D-40 $reset_count D-40 $reset_value D-40 resetall D-3 resetting keeping track of the number of resets D-40
passing a value from before to after a reset D-40 resetting VCS to simulation time 0 D-40 Resolving message upon instance resolution B-6 $restart D-42 RETAIN entries SDF files enabling B-28, B-29 return range of a C/C++ function 20-48 return type of a C/C++ function 20-48, 20-50 RTL Verilog example 11-7 $rtoi D-29 runtime options compiling into the executable B-36 prevent compiling into the executable B-36 RVM B-18 rvm B-18 rw ACC capability 20-12, 20-18
S
s ACC capability 20-13 $save D-42 SC_CTHREAD 19-183, 19-184 sc_main 19-190 sc_objects 19-191 sc_report_handler 19-215 sc_stack_size 19-184, 19-186 sc_start 19-190 SC_THREAD 19-183, 19-184 SC_THREADS 19-198 scalar direct access for C/C++ functions formal parameter type 20-62 scalar* direct access for C/C++ functions formal parameter type 20-62 scope randomize method 12-16 SDF 9-5 optimistic mode 9-5 SDF backannotating
IN-18
enabling more than 10 warning and error messages C-20 SDF files compiling separate files for min|typ|max delays B-25 disabling CELLTYPE entries B-28 enabling accurate simulatiuon of multiple non-overlapping violation windows B-34 encryption B-53 INTERCONNECT delays B-27 changing to transport delays B-28 negative values enabling B-33 rejecting B-32 INTERCONNECT entries negative values enabling B-33 IOPATH delays negative values enabling B-33 IOPATH entries edge sensitivirty B-29 negavive values enabling B-33 min|typ|max delays specified in a file B-25 RETAIN entries enabling B-28, B-29 -sdf min|typ|max instance_name file.sdf B-25 $sdf_annotate D-41 +sdf_nocheck_celltype B-28 +sdfprotect file_suffix B-53 -sdfretain 9-5, B-28 -sdfretain=warning B-29 SDFRT_IRV wanring B-29 +sdfverbose C-20 search order of Verilog library directories B-5 rescan B-6 segmentation violation 19-183 SEGV 19-183 sequential devices inferring 3-313-35, 9-379-42 serial2trace.txt file 14-12 $setup D-36
$setuphold D-36 checking timestamp and timecheck conditions B-34 diabling delayed versions of signals in other timing checks B-34 shared object file OpenVera C-6 signal port mismatch changing from an error to a warning condition B-62 signal property access funtions OpenVera enabling B-20 signed variables accessing 19-121 simulation immediately after compilation B-25 simulation report at the end of simulation suppressing C-20 simulation state saving D-42 simv executable specifying a deifferent name B-66 single class 14-29 single packed dimension 14-42 size PLI specification 20-8 $skew D-37 -slave B-38 slave mode in PLI B-38 Smart Order 25-1 soft constraint 14-27 soft constraints 14-26, 14-34 disabling 14-26 prioritization 14-28 soft keyword 14-27 solver trace reporting for the specified randomize() calls 14-15 SOMA 27-2 souce protection enabling overwriting of existing files B-52 enabling PLI and UCLI access B-52 encrypting all modules B-52 but not the module headers B-52
IN-19
but not the module headers and parameter declarations B-52 specifying the directory for protected files B-53 specifying with protect endprotect B-52 source file specifying in a file B-35 source protection mangling B-53 except module and port identifiers B-54 SDF files B-53 sparse memory models 3-39 specify blocks disabling for an instance 9-37 suppressing B-31 in specific module instances 9-37 specifying B-40 srandom(seed) system function C-6, C-7 $sreadmemb D-32 $sreadmemh D-32 stack guard increasing size 19-185 stack overrun diagnosing 19-185 stack size increasing 19-184 state variables 14-25 initializing B-23 Static Race Detection Tool B-56 std randomize() method 12-16 $stimen D-38 $stop D-33 stopping simulation at a specified time C-19 strength information disabling in VPD files C-24 string C/C++ function argument type 20-51 C/C++ function return type 20-50 input argument type 20-63 output and inout argument type 20-64 $strobe D-29
sub-members 19-135 SV and RT assertions browse, enable, and disable B-39 sv_fmt argument to -ntb_opts B-18 SVA 17-31 -sverilog B-8 SWIFT SmartModels generating a template B-42 $sync$nor$plane D-37 -sysc B-61 SYSC_USE_PTHREADS 19-198 -sysc=dpi_if 19-175 -sysc=newsync 19-195 -sysc=nodpi_if 19-175 -sysc=nomulti_start 19-191 -sysc=show_sc_main 19-202 -sysc=stacksize 19-184 1024k 19-191 -sysc=unihier 19-198 syscan 19-175 -prec 19-177 syscan -prec limitations 19-181 syscan utility 19-919-12 $system D-27 system tasks D-11D-46, ??D-46 disabling text output from C-21 IEEE standard system tasks not implemented D-46 SystemC 19-175 accessing Verilog variables 19-115 cosimulating with Verilog 1-2, 19-1 SystemC cosimulation B-64 enabling B-61 time resolution B-61 systemc_user.h 19-213 systemc.h 19-177 $systemf D-27 SystemVerilog 14-26 enabling B-8 specifying the filename extension B-21 SystemVerilog assertions 17-1??
IN-20
T
-t 11-5 target_directory 19-177 tb_timescale argument to -ntb_opts B-19 tchk ACC capability 20-13 temporary object files B-47 $test$plusargs D-40 testbench OpenVera enabling B-16 macro on command line B-16 timescale B-19 testbench template 11-7 +tetramax B-62 TetraMAX testbench simulation in zero delay mode B-62 text macros defining B-65 text output display from system tasks disabling C-21 $time D-38 time scale for the compilation-unit scope B-57 overrideing the timescale compiler directive f4rom the vcs command line B-58 specifying on the vcs command line B-57 $timeformat D-33 -timescale B-57 timescale D-8 timescale OpenVera testbench B-19 timing check system tasks checking timestamp and timecheck conditions B-34 disabling B-31 in specific module instances 9-37 disabling delayed versions of signals B-34 disabling display of timing violations B-31 disabling toggling the notifier register B-31
negative values enabling B-34 timing check system tasks, disabling B-31 timing checks disabling C-18 disabling for an instance 9-37 suppressing the toggling of notifier registers C-18 timing violations disabling B-31 disabling the display of C-18 timming checks disabling the display of timing violations C-18 Timopt the timing optimizer 9-379-42 +timopt 9-38 TLI function call 19-123 TLI adapters 19-270 tli_D 19-142 tli_D 19-140 tli_gen_struct 19-143 tli_get_ 19-115, 19-132 tli_get_bv 19-120 tli_get_int64 19-136 tli_get_logic 19-136 tli_get_lv 19-120 TLI_REGISTER_ID(char *, ) 19-110 tli_set_ 19-115, 19-132 tli_simple 19-112 TLI_UNREGISTER_ID(char *) 19-110 TLI-2 adaptor code 19-106 tliF 19-129 TMPDIR A-3 tokens argument to -ntb_opts B-19 tokens.v file 17-17, B-53 top-level Verilog Module 11-7 transport delays B-28 +transport_int_delays 9-22, 9-24, 9-26, B-28 +transport_path_delays 9-21, 9-24, 9-26, B-28 +typdelays B-26, B-27, C-26 type conversion mechanism 19-138
IN-21
U
U direct access for C/C++ functions formal parameter type 20-62 -u B-65 U* direct access for C/C++ functions formal parameter type 20-62 UB* direct access for C/C++ functions formal parameter type 20-62 UCLI 19-198 dump 19-199 enabling in encrypted files B-52 save and restore 19-194 scope 19-199 -ucli 5-6 unaccelerated definitions and declarations 3-293-30 structural instance declarations 3-30 unconnected_drive D-10 undef D-5 $ungetc D-32 uniq_prior_final compiler switch 12-46 unique keyword 12-46 uniquifying identifier codes in VCD files 7-25 -unit_timescale B-57 uppercase changing Verilog identifiers to B-65 use_sigprop B-20 use_sigprop argument to -ntb_opts B-20 -use_vpiobj 20-34, B-40 uselib D-9 user guides, reference manuals, quick references, tutorials in HTML format B-8 utility, vcsplit 7-48 UVM 19-211
V
-V 2-7, B-43, C-20 -v 2-3, B-4, B-45
+v2k B-61 vacuous success message enabling C-14 $value$plusargs 5-8 +vc 20-122, B-40 vc_2stVectorRef() 20-93 vc_4stVectorRef() 20-91 vc_argInfo() 20-115 vc_arraySize() 20-81 vc_FillWithScalar() 20-112 vc_get2stMemoryVector() 20-108 vc_get2stVector() 20-97 vc_get4stMemoryVector() 20-106 vc_get4stVector() 20-95 vc_getInteger() 20-91 vc_getMemoryInteger() 20-103 vc_getMemoryScalar() 20-102 vc_getPointer() 20-89 vc_getReal() 20-86 vc_getScalar() 20-81 vc_handle definition 20-71 using 20-7220-73 vc_hdrs.h file 20-6920-70 in DirectC B-40 vc_Index() 20-116 vc_Index2() 20-117 vc_Index3() 20-117 vc_is2state() 20-78 vc_is2stVector() 20-80 vc_is4state() 20-77 vc_is4stVector() 20-79 vc_isMemory() 20-76 vc_isScalar() 20-74 vc_isVector() 20-75, 20-118 vc_mdaSize() 20-117 vc_MemoryElemRef) 20-100 vc_MemoryRef() 20-97 vc_MemoryString() 20-110 vc_MemoryStringF() 20-111 vc_put2stMemoryVector() 20-108 vc_put2stVector() 20-97
IN-22
vc_put4stMemoryVector() 20-108 vc_put4stVector() 20-95 vc_putInteger() 20-91 vc_putMemoryInteger() 20-105 vc_putMemoryScalar() 20-103 vc_putMemoryValue() 20-109 vc_putMemoryValueF() 20-109 vc_putPointer() 20-89 vc_putReal() 20-86 vc_putScalar() 20-82 vc_putValue() 20-86 vc_putValueF() 20-87 vc_StringToVector() 20-90 vc_toChar() 20-82 vc_toInteger() 20-82 vc_toString() 20-84 vc_toStringF() 20-85 vc_VectorToString() 20-91 vc_width() 20-81 vcat utility 7-35 VCD file specifying on the vcs command line B-63 -vcd filename C-24 VCD files increasing the frequency of flushing B-41 VCD+ 7-2 Advantages 7-2 System Tasks $vcdplusdeltacycleoff 7-18 $vcdplusdeltacycleon 7-18 $vcdplusmemoff 7-8 $vcdplusmemon 7-8 $vcdplusmemorydump 7-8 vcdiff utility 7-26 syntax 7-27 vcdpost utility 7-23 syntax 7-26 VCS 4-11 predefined text macro D-4 VCS MX V2K Configurations and Libmaps 4-11 VCS_CC A-4
VCS_COM A-4 VCS_HOME B-47 VCS_LIC_EXPIRE_WARNING A-4 VCS_LOG A-4 vcs_mipdexpand D-6 VCS_NO_RT_STACK_TRACE A-4 VCS_SWIFT_NOTES A-4, A-5 VCS_SYSC_STACKSIZE 19-192 +vcs+dumpoff+t+ht C-24 +vcs+dumpon+t+ht C-24 +vcs+finish 5-27, C-19 +vcs+flush+all C-27 +vcs+flush+dump C-27 +vcs+flush+fopen C-27 +vcs+flush+log C-27 +vcs+ignorestop C-31 +vcs+learn+pli 20-2420-28, C-31 +vcs+lic+vcsi C-27 +vcs+lic+wait C-28 +vcs+mipd+noalias C-32 +vcs+nostdout C-21 +vcs+stop 5-26, C-19 +vcsi+lic+vcs C-27 +vcsi+lic+wait B-46 vcsplit utility 7-48 vec32 storing four state Verilog data 20-56 vec32* direct access for C/C++ functions formal parameter type 20-62 vera_portname argument to -ntb_opts B-20 vera_shell Vera shell module name B-20 verbose mode - displaying compile-time and runtime numbers C-20 copyright information C-20 version and extended summary information C-20 Verilog different versions filename extension B-21, B-22 different versionsinclude
IN-23
filename extension B-22 Verilog 1995 specifying the filename extension B-22 Verilog 2001 specifying the filename extension B-21 Verilog 2001 enabling B-61 Verilog identifiers changing to uppwecase B-65 Verilog library directories displaying a message upon instance resolution B-6 file name extensions specifying B-5 specifying B-4 specifying the search order B-5 rescan B-6 Verilog library files specifying B-4 Verilog model, example 11-7 Verilog module 11-7 Verilog module description 11-15 Verilog parameters overriding B-55, B-60 overriding with the -gfile elaboration option B-58 +verilog1995ext B-22 +verilog2001ext B-21 VerilogAMS defaule discrete discipline B-54 version number returning B-46 VHDL generics overriding with the -gfile elaboration option B-58 violation windows using multiple non-overlapping 9-679-72 virtual interface self instance 12-58 vlogan 19-175 vlogan utility 19-2119-22 VMM B-18 void C/C++ function return type 20-50
void* direct access for C/C++ functions formal parameter type 20-62 void** direct access for C/C++ functions formal parameter type 20-62 VPD file specifying on the vcs command line B-63 VPD files D-18 buffer for specifying the size of C-21 disabling file compression C-23 disabling recording in transition times an values defined under celldefine B-45 disabling recording in transition times an values defined under celldefine or in a library B-45 disabling recording strength information C-24 enabling recording in transition times an values defined under celldefine B-44 enabling VPD file locking C-23 ignoring $vcdplusxx system tasks C-22 recording changes on the drivers of resolved nets C-23 recording only ports and their direction C-23 recording ports and their direction C-23 recording signals but not ports C-23 specifying the name C-21 specifying the size of C-22 switching to record another VPD file C-22 +vpdfile 5-7 +vpdfileswitchsize 5-7 VPI 14-40 specifying the registration routine in a shared library B-40 SV and RT assertions browse, enable, and disable B-39 vpi_user.c file specifying B-40 +vpi B-38 VPI PLI access routines enabling B-38 vpi_user.c file B-40
IN-24
W
+warn 3-48, B-43 $warning D-11 warning messages disabling B-43 sover array size warning C-7 $width D-37 wn ACC capability 20-12 $write D-29 $writememb D-33 $writememh D-33
-xlrm gd_pulseprop 9-6 -xlrm gd_pulsewarn 9-7 -xlrm soft 14-28 -xlrm uniq_prior_final compile switch 12-46 -Xman B-53 -Xmangle B-53 XMR 14-24 -Xnoman B-54 -Xnomangle B-54 -Xova 17-36 Xova B-15
Y
-y 2-4, B-4, B-45
X
-xlrm 9-5 -xlrm alt_retain 9-5
Z
zero multiconcat multiplier allowing B-63
IN-25
IN-26