VHDLsim CMSG

VHDL Simulation
Coding and Modeling

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

All technical data contained in this publication is subject to the export control laws of the United States of America.
Disclosure to nationals of other countries contrary to United States law is prohibited. It is the readers responsibility to
determine the applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Registered Trademarks
AMPS, Arcadia, CoCentric, COSSAP, Cyclone, DelayMill, DesignPower, DesignSource, DesignWare, Eagle Design
Automation, EPIC, Formality, in-Sync, LEDA, ModelAccess, ModelTools, PathBlazer, PathMill, PLdebug, PowerArc,
PowerMill, PrimeTime, RailMill, SmartLogic, SmartModel, SmartModels, SNUG, Solv-It, SolvNet, Stream Driven
Simulator, Synopsys, TestBench Manager, TetraMAX, TimeMill, and VERA are registered trademarks of Synopsys, Inc.
Trademarks
BCView, Behavioral Compiler, BOA, BRT, Cedar, ClockTree Compiler, DC Expert, DC Expert Plus, DC Professional,
DC Ultra, DC Ultra Plus, Design Advisor, Design Analyzer, Design Compiler, DesignSphere, DesignTime, Direct RTL,
Direct Silicon Access, DW8051, DWPCI, ECL Compiler, ECO Compiler, ExpressModel, Floorplan Manager,
FoundryModel, FPGA Compiler II, FPGA Express, Frame Compiler, HDL Advisor, HDL Compiler, Integrator, Interactive
Waveform Viewer, Liberty, Library Compiler, ModelSource, Module Compiler, MS-3200, MS-3400, NanoSim, OpenVera,
Physical Compiler, PowerCODE, PowerGate, Power Compiler, ProFPGA, Protocol Compiler, RoadRunner, Route
Compiler, RTL Analyzer, Schematic Compiler, Scirocco, Shadow Debugger, SmartLicense, SmartModel Library, Source-
Level Design, SWIFT, Synopsys Eaglei, Synopsys EagleV, SystemC, System C (logo), Test Compiler, TestGen,
TimeTracker, Timing Annotator, Trace-On-Demand, VCS, VCS Express, VCSi, VHDL Compiler, VHDL System Simulator,
VirSim, VMC, and VSS are trademarks of Synopsys, Inc.
Service Marks
DesignSphere and TAP-in are a service marks of Synopsys, Inc.
All other product or company names may be trademarks of their respective owners.
Printed in the U.S.A.
Document Order Number: 36547-000SA

VHDL Simulation Coding and Modeling Style Guide, 7.1.1 Beta
ii
Contents
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
SolvNet Online Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
1. General Guidelines
VHDL Coding Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
VHDL Value and Character Limits. . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
2. Testbench Guidelines
General Testbench Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Clock Generation from the Testbench . . . . . . . . . . . . . . . . . . . . . . . 2-5
Clock Generation from the Main Clock . . . . . . . . . . . . . . . . . . . . . . 2-8
Reset Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Data Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
iii
Stimulus and Response Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Message Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
3. Design Guidelines
Pullups and Pulldowns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Vectorization and Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Combinatorial Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Sequential Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
Clock Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Gate-level Modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
4. Memory Model Guidelines

General Memory Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Sparse Memory Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Dual Port Memories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Appendix A. Templates for Register Inference

D Latches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
D Latch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
D Latch with Asynchronous Reset or Set . . . . . . . . . . . . . . . . . A-5
D Latch with Asynchronous Reset and Set . . . . . . . . . . . . . . . . A-6
D Flip-Flops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7
D Flip-Flop with Positive or Negative Edge Trigger . . . . . . . . . . A-7
D Flip-Flop with Asynchronous Reset or Set . . . . . . . . . . . . . . . A-8
iv
D Flip-Flop with Asynchronous Set and Reset . . . . . . . . . . . . . A-9
D Flip-Flop with Synchronous Reset or Set . . . . . . . . . . . . . . . . A-10
D Flip-Flop with Synchronous and Asynchronous Load . . . . . . A-11
D Flip-Flop with Asynchronous Reset, Set, Load, and Synchronous
Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-12
JK Flip-Flops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13
JK Flip-Flop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-13
JK Flip-Flop with Asynchronous Reset and Set. . . . . . . . . . . . . A-14
Toggle Flip-Flops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15
Toggle Flip-Flop with Asynchronous Reset or Set . . . . . . . . . . . A-15
Toggle Flip-Flops with Enable and Asynchronous Reset. . . . . . A-17
Appendix B. Supported Language Constructs for VCS MX Cycle

Cycle Simulation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2
Design Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3
Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-5
Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7
Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-8
Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-8
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-9
Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-10
Operands and Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-11
Subprograms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-14
Sequential Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-14
Concurrent Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-16
Predefined Language Environment . . . . . . . . . . . . . . . . . . . . . . B-17
v
Cycle Testbench Process Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . B-18
The textio Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-18
Wait Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-19
Multiple Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-20
VHDL Reserved Words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-21
Appendix C. Cycle Simulation and LRM Differences
Index
vi
About This Manual
This manual describes methods of coding VHDL designs for use by

the VCS MX simulator. Use this guide to fine-tune your VHDL design
code so that the models function correctly, simulate faster, and
produce a synthesizable design.
Each section in this manual presents a number of rules and

guidelines. The rules, which are presented first, describe what you
must follow to code a functional model. The guidelines provide
recommendations about how you can produce higher simulation
performance.
This chapter includes the following sections:
Audience
Related Publications
SolvNet Online Help
Customer Support
Conventions
vii
Audience
This manual is intended for experienced VHDL designers. It is

assumed you already know the concepts and principles in the IEEE
Standard VHDL 1076-1993 and are familiar with working in an UNIX
environment.
Related Publications
For additional information about VCS MX, see Synopsys Online

Documentation (SOLD), which is included with the software at
installation_directory/doc/online/sim/sc_home.pdf
or Documentation on the Web, which is available through SolvNet on

the Synopsys Web page at
http://www.synopsys.com
Also, the Reuse Methodology Manual by M. Keating and P. Bricaud,

Kluwer Academic Publishers, contains information about VHDL
simulation.
viii
SolvNet Online Help
SolvNet is the Synopsys electronic knowledge base. It contains

information about Synopsys and its tools and is updated daily. For
more information about SolvNet, send e-mail to
solvitfb@synopsys.com
or go to the Synopsys Web page at
http://www.synopsys.com
and click SolvNet.
Customer Support
If you have problems, questions, or suggestions, contact the

Synopsys Technical Support Center in one of the following ways:
Send e-mail to
support_center@synopsys.com
Call (800) 245-8005 from within the continental United States or

call (650) 584-4200 from outside the continental United States,
from 7:00 a.m. to 5:30 p.m. Pacific time, Monday through Friday.
ix
Conventions
The following conventions are used in Synopsys documentation.
Convention Description
courier Indicates command syntax.
In command syntax and examples, shows
system prompts, text from files, error
messages, and reports printed by the
system.
courier italic Indicates a user specification, such as
object_name
courier bold In command syntax and examples, indicates
user input (text the user types verbatim).
[ ] Denotes optional parameters, such as pin1
[pin2, . . pinN]
| Indicates a choice among alternatives, such
as
low | medium | high
This example indicates that you can enter

one of three possible values for an option:
low, medium, or high.
_ Connects two terms that are read as a single
term by the system. For example,
design_space.
(Control-c) Indicates a keyboard combination, such as
holding down the Control key and pressing c.
\ Indicates a continuation of a command line.
/ Indicates levels of directory structure.
Edit > Copy Shows a menu selection. Edit is the menu
name and Copy is the item on the menu.
x
1
General Guidelines 1
VHDL coding style is the most important factor affecting simulation
speed. VHDL is a behavioral language, so you can write a model
many different ways. How you write your VHDL design models can
affect the performance of both the VHDL Analyzer and simulator.
This chapter describes the general coding guidelines for the following
topics:
VHDL coding style

VHDL value and character limits
This chapter does not attempt to teach VHDL coding rules and
practices in general. For information about writing design descriptions
in VHDL, see the IEEE Standard VHDL Language Reference Manual
or any of the quality books related to designing with VHDL.
General Guidelines
1-1
VHDL Coding Style
This section provides general guidelines to produce maximum

simulation speed. Cycle simulation refers to simulating a complete or
partial design description in VCS MX cycle mode.
Guideline
Use the highest level of abstraction as possible to code your design.
The higher the level of abstraction of the modeling style, the faster
the simulation run. Thus, RTL style simulates faster than gate-level
and behavioral style simulates faster than RTL.
Guideline
Use variables rather than signals, especially when modelling memory
contents. Variables require much less memory and overhead which
yields to faster simulation.
Guideline
Group functionality into processes according to the signals that
activate that functionality. VCS MX cycle frequently groups related
processes as part of the overall cycle optimization techniques.
However, in event simulation, this task remains for the designer to
accomplish.
Guideline
Use commonly accepted synthesis coding templates. For sequential
processes, only include the clock and any required asynchronous
control signals in the sensitivity list. Use the synthesis accepted style
for synchronous and asynchronous controlled sequential processes
(see the Templates for Register Inference appendix).
General Guidelines
1-2
Guideline
Use complete sensitivity lists for combinatorial processes. Although
it is possible to not include all signals read in a combinatorial style
process in the sensitivity list (which can speed event simulation), but
using incomplete sensitivity lists can result in simulation/synthesis
and event simulation/cycle simulation mismatches.
VCS MX cycle automatically completes an incomplete sensitivity list

in a combinatorial process just as synthesis does.
Guideline
Minimize the use of text I/O. This includes minimizing the use of Read
and Write routines to parse or construct a formatted LINE-type
variable (whether that line is read or written from a file or not).
Guideline
Use subprograms for large processing blocks. Using subprograms
for small and simple blocks of code slows down the simulation.
The subprograms in the standard libraries (Std., IEEE, and Synopsys)

are optimized by VCS MX.
For user-defined subprograms, the simulation overhead for each

subprogram call can be high (especially if using signal class
parameters). Even when used to encapsulate reusable code, ensure
a proper trade-off between the overhead of the call and the processing
performed by the subprogram.
General Guidelines
1-3
Guideline
Use the following IEEE standard VHDL types:
std_logic
std_logic_vector
std_ulogic
std_ulogic_vector
numeric_std signed and unsigned
std_logic_arith signed and unsigned
Guideline
Avoid bit-blasting. Bit-blasting refers to separation of vector signals
into scalar elements that are then operated on individually and then
re-grouped into the vector signal. Perform vector-level operations and
manipulations when possible.
Guideline
Perform operations only when necessary. For example, do not
convert a value into a string that is used only to report a message for
some exceptional condition. Ensure the value to string conversion
only occurs if the exception occurs.
Guideline
For loops in VCS MX cycle are unrolled. This can result in large
generated code which impacts performance if the number of iterations
is large and the loop contains significant operations. To decrease the
size of unrolled for loop code,
General Guidelines
1-4
Reduce the number of iterations (if possible). For example, use
vector operations or slice assignments instead of bit-level
operations and assignment.
Keep code that is loop-invariant outside the loop.
Reduce operations and calculations inside the loop. For example,
eliminate common expressions by using temporary variables.
Guideline
Structure branch logic optimally to avoid unnecessary expression
evaluation. For example, the following code is inefficient as both
condA and condB are always evaluated:
if condA then
target <= valueA;
end if;
if condB then
target <= valueB;
end if;
It is more efficient to write the code as
if condB then
target <= valueB;
elsif condA then
target <= valueA;
end if;
condA is only evaluated when condB is false. Also, it is best in

if-then-elsif statements to order the expressions in descending order
of their likelihood of evaluating TRUE (consistent with the goals of
synthesis results for the inferred priority encoder).
General Guidelines
1-5
Guideline
Minimize the number of signal assignments in a process. Signal
assignments are easy to write, but they require significant processing
under-the-hood. This overhead does not exist for combinatorial
signals in cycle simulation. The following is an example of an
inefficient description:
S <= default;
case sel is
when "00" => S <= valA;
when "01" => S <= valB;
when "10" => S <= valC;
when others => null;
end case;
This description executes two signal assignment statements in three

out of four situations. Use variables to hold the assigned value and
then perform the signal assignment at the end, as in the following
example:
var := default;
case sel is
when "00" => var := valA;
when "01" => var := valB;
when "10" => var := valC;
when others => null;
end case;
S <= var;
General Guidelines
1-6
VHDL Value and Character Limits
This section provides the rules for VHDL value and character limits.
Rule
The value range for VHDL objects is as follows:
Item Value Range

Integer and physical objects 2147483648 (231) to
(except time)
2147483647 (2311)
VHDL objects of type TIME 4611686018427387904 (262) to
4611686018427387903 (2621)
Rule
The maximum number of characters you can use in items in your
VHDL design code is as follows:
Item Maximum Character Lengths

Configuration name 250 characters
Package name 248 characters
Entity name + architecture name 248 characters
VHDL code line length 1024 characters
General Guidelines
1-7
General Guidelines
1-8
2
Testbench Guidelines 1
This chapter presents a number of coding rules and guidelines for
testbenches. These guidelines help you construct VHDL testbenches
that are efficient for VCS MX in event and cycle mode.
This chapter describes the testbench coding guidelines for the

following topics:
General testbench guidelines

Clock generation from the testbench
Clock generation from the main clock
Reset generation
Data generation
Stimulus and response files
Testbench Guidelines
2-1
In general, a testbench to be simulated in VCS MX cycle is limited to
the same VHDL constructs as synthesis and the design being
simulated in cycle mode. In addition to the synthesis policy, the cycle
testbench supports the use of behavioral style wait statements, assert
statements, and TEXTIO constructs.
2-2
General Testbench Guidelines
VCS MX automatically detects and identifies processes that are to

be simulated in cycle mode and fit the testbench guidelines (as
presented in this chapter) as cycle testbench processes.
The presence of a behavioral wait statement indicates a cycle

testbench process. Although you can use behavioral wait statements
to model other design functionalities, such as a PLL, cycle simulation
identifies the process as a cycle testbench process and report this
information in the elaboration output.
A testbench process is shown in Example 2-1.
Example 2-1 Sample Testbench Process

architecture behavior of TB is
begin
CLOCK: process
begin
CLK <= '0';
wait for 50 ns;
CLK <= '1';
wait for 50 ns;
end process CLOCK;
end behavior;
Rule
For a cycle testbench, use processes with behavioral wait statements
to create timing in the testbench and to model asynchronous activity.
Behavioral wait statements do not conform to the synthesis policy.
For example, wait for time is a behavioral wait statement. Thus,
these processes are identified as testbench processes (see above).
2-3
Do not use the after clause to produce delays or timing in your
models, cycle simulation ignores the after clause.
The only statement that causes a delay to occur in cycle simulation

is the wait for time statement. Most of the wait statements supported
by cycle simulation are shown in bold in Example 2-2.
Example 2-2 Using Various Kinds of Behavioral wait Statements

--Process with explicit wait for time statement
--This is a testbench process
process
begin
RESET <= '0';
wait for 50 ns;
RESET <= '1';
wait for 50 ns;
RESET <= '0';
wait;
end process;
--Process with explicit wait until edge statement

--This is a synthesizable (non-testbench) sequential style
process
begin
wait until CLK = 1;
B <= A;
end process;
--Process with explicit wait on or sensitivity list
--statement process
--Synthesizable (non-testbench) process style
begin
wait on CLK;
CLKA <= CLK;
end process;
--Combination of wait on, until, and or statement

--Synthesizable (non-testbench) process style
wait on IN1 until CLK = 0;
2-4
Guideline
Limit the use of behavioral waits that indicate cycle testbench
processes to the smallest number of processes possible. Testbench
processes cannot be optimized as effectively. Therefore, simulation
performance can be negatively impacted by a large number of cycle
testbench processes.
Guideline
Separate testbench code into non-synthesizable (behavioral) and
synthesizable style processes. Use behavioral code to read and write
data and to generate clocks and resets. Use non-testbench
processes (that is, synthesizable style) to model the synchronous
portions of the testbench, for example, to manipulate data in a finite
state machine.
Clock Generation from the Testbench
This section provides rules and guidelines for generating clocks from
the testbench.
Rule
When using cycle simulation for the testbench as well as the design,
use a process suspension statement (wait) to create time and
generate clocks and waveforms. Do not use a scheduling statement
(after) to create timing. Cycle simulation ignores after clauses in signal
assignment statements.
2-5
Example 2-3 shows a simple clock process that fails to analyze for
cycle mode because of the multiple waveforms and after clause
(shown in bold). Example 2-4 shows a simple clock process that
generates the desired 50 ns clock period waveform.
Example 2-3 Using the after Clause Waveform Fragment Fails Analysis
junk : process
begin
CLK <= 0, 1 after 25 ns; --ERROR HERE
wait for 50 ns;
end process;
Example 2-4 Using the wait for time Statement Generates a Clock
clock : process
begin
CLK <= 0;
wait for 25 ns;
CLK <= 1;
wait for 25 ns;
end process;
Guideline
Generate clocks and asynchronous resets from a testbench process.
Testbench-driven clocks are globally implemented and simulate
faster than clocks generated in local design modules.
Guideline
When simulating the testbench in cycle mode, use separate
processes to generate multiple asynchronous clocks. VCS MX cycle
can simulate multiple clocks and each clock can contain different
(unrelated) clock periods. It is simplest and most efficient to use
multiple processes containing only wait for time statements to define
each clock, as shown in Figure 2-1 and Example 2-5.
2-6
Figure 2-1 Separate Processes to Generate Multiple Clocks
TESTBENCH DESIGN
Combo Combo
SEQ Logic Logic SEQ
Separate Testbench
Processes Clock A
Combo Combo
SEQ Logic Logic SEQ
Testbench
Clock B
Example 2-5 Using Separate Processes to Generate Multiple Clocks

clockA: process
begin
CLKA <= '0';
wait for 25 ns;
CLKA <= '1';
wait for 25 ns;
end process;
clockB: process
begin
CLKB <= '0';
wait for 33 ns;
CLKB <= '1';
wait for 33 ns;
end process;
2-7
Clock Generation from the Main Clock
Ideally, you must only use wait for time statements to create clocks
when simulating in cycle mode. In some cases, you might want to
create a clock that is synchronized to another clock or the main clock.
Examples of these derived clocks include clock dividers, clock
multipliers, and phase lock loops.
Creating a clock from another clock usually causes a delta delay

between the main clock and the derived clock. These delta delays
can cause undesirable behavior if both the main clock and the derived
clocks are used in the design. Thus, use the following guideline for
properly generating derived clocks when using cycle simulation (you
can simulate the testbench in cycle or event mode).
Guideline
When deriving clocks from a main clock, use only the derived clocks
in the design. The main clock must be restricted to the processes that
create the other clocks.
Example 2-6 shows a process that generates a clock divider.
Example 2-6 Creating a Clock Divider

divider: process
begin
clk50 <= '0';
clk100 <= '0';
clk200 <= '0';
loop -- forever
for j in 1 to 2 loop
for k in 1 to 2 loop
wait on clk;
clk200 <= not clk200;
end loop;
2-8
clk100 <= not clk100;
end loop;
clk50 <= not clk50;
end loop;
end process divider;
Note that the clock (clk200) has the same frequency as the main clock
(clk), but it is delayed by a delta cycle. The derived clocks occur
simultaneously and are the ones used by the design.
Reset Generation
This section provides rules and guidelines for creating resets from
the testbench. These rules and guidelines apply to asynchronous
resets because cycle simulation treats resets and clocks the same
way. You can also generate synchronous resets using the same
guidelines. These guidelines also apply to modeling other
asynchronous signals such as interrupt signals.
In general, apply the same rules to reset signals that you apply for
clocks. For instance, use minimum number of buffers or temporary
signals for connecting the reset signal to the registers.
Rule
Always pulse the reset signal to the active state from the inactive
state. Asynchronous resets in cycle simulation are edge triggered
even if in the registers they appear to be level sensitive. To ensure
the registers are reset properly, always create a reset process that
toggles the reset condition value. Example 2-7 creates a pulse for an
active-low reset.
2-9
Example 2-7 Generating Reset from a Testbench
reset: process
begin
RST<= 1;
wait for 25 ns;
RST<= 0;
wait for 100 ns;
RST<= 1;
wait;
end process;
Guideline
When simulating the design in cycle simulation (with the testbench
in either cycle or event), model asynchronous resets as you do clocks,
that is, generate resets globally from a testbench process. Use a wait
statement with no condition or time to indefinitely suspend the
processes that contain the reset.
Data Generation
This section provides guidelines for creating data other than simple
clocks in a testbench when simulating the design in cycle mode. You
can simulate the testbench in either cycle or event mode.
Rule
Avoid race conditions between data and clock. Applying the data and
active edge of the clock simultaneously might cause a race condition
during simulation and most likely unexpected results. This usually
causes mismatches between event simulation and cycle simulation.
2-10
To keep data synchronized with the clock while avoiding a race
condition, apply the data at a different point in the clock period than
at the active edge(s) of clock. If the clock has only one active edge,
apply the data during the inactive clock edge as shown in
Example 2-8.
Example 2-8 Synchronizing Data with Inactive Clock Edge

clock: process
begin
CLK <= '0';
wait for 25 ns;
CLK <= '1';
wait for 25 ns;
end process;
data: process
begin
while not (data_done) loop
DATA1 <= X1;
DATA2 <= X2;
...
wait for 50 ns; -- in-active clock edge
...
You can also use wait until clkevent and clk=0" instead of wait for
time to synchronize a data generation process with the clock, as
shown in Example 2-9.
Example 2-9 Synchronizing Data with Inactive Clock Edge

(Alternative Coding)
clock: process
begin
CLK <= '0';
wait for 25 ns;
CLK <= '1';
wait for 25 ns;
end process;
data: process
begin
2-11
while not (data_done) loop
DATA1 <= X1;
DATA2 <= X2;
...
wait until clkevent and clk=0;
...
Guideline
Separate data generation from resets and clocks. Use separate
processes for these different functions as shown in Figure 2-2.
Figure 2-2 Separate Processes to Generate Data, Clock, and Reset
TESTBENCH DESIGN
Separate Testbench Combo SEQ Combo Combo SEQ

Processes Data Logic Logic Logic
RST RST
Testbench
Clock
Testbench
Reset
Guideline
For efficiency, model your testbench such that it executes
synchronously with the design you are testing. Remember that cycle
simulates the designs functionality and not timing delays. Apply data
at once on cycle boundaries using wait statements based on the clock
period. Example 2-10 shows an asynchronous testbench where data
is applied through out the clock period. Example 2-11 shows a
synchronous testbench where data is applied at once based on the
clock period.
2-12
Example 2-10 Using an Asynchronous Testbench (Not Recommended)
data: process
begin
...
elsif (memory_phase = true) then
wait for 5 ns; -- setup time
DATA1 <= X1;
DATA2 <= X2;
DATA3 <= X3;
DATA4 <= X4;
wait for 7 ns; -- finish clock period
else
....
Example 2-11 Using a Synchronous Testbench (Recommended Coding)

data: process
begin
...
elsif (memory_phase = true) then
DATA1 <= X1;
DATA2 <= X2;
DATA3 <= X3;
DATA4 <= X4;
wait for 20 ns; -- sync to clock period
else
...
Guideline
Avoid using multiple subprograms or repeatedly calling the same
subprogram from a process when simulating in cycle mode. This
applies to user-defined subprograms (procedures or functions) and
not to the subprograms already analyzed into the Synopsys supplied
design libraries.
2-13
Subprograms are inlined in cycle simulation (including testbench
processes simulated in cycle mode), causing the virtual size of the
process to increase. Heavy use of subprograms can create virtual
processes so large that they significantly impact performance.This
can lead to very long elaboration times and can cause an out-of-
memory error during elaboration.
To avoid creating large virtual processes, follow these guidelines:
Use the pre-analyzed Synopsys supplied subprograms from

packages in IEEE and Synopsys libraries whenever possible.
Avoid using large complicated subprograms that call other
subprograms.
Use a modeling style that has few calls to subprogram that are
not supplied by Synopsys.
Use multiple processes instead of one big procedural based
process.
Reduce the number of calls to a subprogram. For example, by
performing an operation once instead of multiple times outside a
for-loop when the parameters do not depend on the loop iteration
or replace multiple calls in two or more conditional branches by
one call made unconditionally (even if the results of the
subprogram call are not always needed).
Replace calls to user-defined type conversion functions with type
qualification, especially when used in for loops.
Example 2-12 shows how you can use multiple subprogram calls.
Example 2-13 shows a subprogram that is only called once after the
case statement and not in each branch of the case statement.
2-14
Example 2-12 Using Multiple Procedure Calls (Not Recommended)
decode: process
procedure do_instr(instr:t, data:d) is
begin
....
end do_instr;
begin
case I1 is
when "0000" => do_instr(STOP, data);
when "0001" => do_instr(JMP, data);
when "0010" => do_instr(CALL, data);
...
end case;
Example 2-13 Using Single Procedure Calls (Recommended Coding)
decode: process
procedure do_instr(instr:t, data:d) is
begin
....
end do_instr;
begin
case I1 is
when "0000" => instr := STOP;
when "0001" => instr := JMP;
when "0010" => instr := CALL;
...
end case;
do_instr(instr, data);
...
Another method is to create separate processes and use signals to

communicate the data from one process to the next.
2-15
Stimulus and Response Files
This section provides guidelines for reading and writing stimulus files
from the VHDL testbench by using TEXTIO.
The most common method of reading data from files is using VHDL
TEXTIO files. Other methods of reading data include using (binary)
file I/O, using memories with the load_memory command, or using C
models via the VHDL PLI.
Saving response is done most efficiently by using the VCS MX trace

(dump) command. This command efficiently saves data for later
viewing in the waveform viewer. You can use TEXTIO to store the
results, but because the data is in text format, files are larger and thus
less efficient. Also, you lose the benefit of being able to easily turn
off or restrict the output when using TEXTIO.
VCS MX supports the standard VCD output format in addition to the

VCD+ format.
Rule
When simulating the testbench in cycle mode, access line types
using the read procedures defined in the TEXTIO and std_logic_textio
packages. The analyzer restricts most uses of the line access types
such as indexing when simulating in cycle mode. You can determine
the length of a line using the length attribute.
Example 2-14 shows a method of skipping blank and comment lines

in a file that fails analysis for cycle simulation. Example 2-15 shows
a successful method of skipping blank and comment lines.
2-16
Example 2-14 Indexing a Line Fails Analysis (Not Recommended)
variable L : LINE;
...
--Skip Blank/Comment Lines
while not endfile ( infile ) loop
readline(infile, L );
if Llength = 0
or L(1) = # then next; -- ERRORS
end if;
end loop;
Example 2-15 Indexing a String (Recommended Coding)

variable L : LINE;
...
--Skip Blank/Comment Lines
while not endfile ( infile ) loop
readline(infile, L );
if Llength = 0 then next;
read(L,st(1 to Llength));
if st(1) = # then next;
end if;
end loop;
Example 2-16 shows an alternate method of using TEXTIO. This

procedure reads a string from the file you pass to it and returns both
a string that contains the next line of the file and the length of the
string, which contains good text. When using a temporary string
variable, the unused characters of the string are filled with blanks.
Example 2-16 Procedure to Read a Variable Length String

procedure my_read_line (variable infile : in text; lin :
out string; line_length : out integer) is
variable line_from_file : string(1 to 80) :=
(OTHERS => );
variable L : LINE;
begin
readline(infile, L);
line_length := Llength;
2-17
read(L, line_from_file(1 to Llength));
lin := line_from_file;
return;
end;
Guideline
When simulating the testbench in cycle mode, use procedures from
STD.textio or IEEE.std_logic_textio packages to read and parse the
files. User-defined procedures for reading and parsing files simulate
less efficiently, and heavy use of user-defined procedures can create
large virtual processes, which can cause elaboration problems.
Example 2-17 and Example 2-18 show using user-defined

procedures and TEXTIO for reading stimulus values.
Example 2-17 Using User-Defined Procedures to Read Stimulus

(Not Recommended)
use std.textio.all;
procedure read_hex(l:inout line; value: out
std_logic_vector) is
begin
bit_pos:=1023;
while (l'length>0) loop
read(l,chr);
if (chr/=lf or chr/=nul) then
case chr is
when '0' => hex_char:="0000";
when '1' => hex_char:="0001";
when '2' => hex_char:="0010";
...
begin -- architecture
read_it: process
variable vline : line;
begin
readline (infile, vline);
read_hex (vline, v1);
2-18
Example 2-18 Using IEEE TEXTIO to Read Stimulus
(Recommended Coding)
use IEEE.std_logic_textio.all;
begin -- architecture
read_it: process
variable vline : line;
begin
readline (infile, vline);
hread (vline, v1);
Guideline
Avoid advancing simulation time based on time value read from the
TEXTIO file (Example 2-19). This style leads to an inefficient
testbench as the vector file controls the amount of time to advance.
Usually your vector file contains more than one line per clock. This
might be efficient only when your vector file contains waits for several
clocks before advancing time. Example 2-20 shows the wait for time
statement as the recommended coding style for reading and applying
vectors.
Example 2-19 Reading and Applying Vectors (Not Recommended)

while not endfile( infile ) loop
readline( infile, L );
read(L, vNEWTIME);
wait for vNEWTIME - $NOW;
read(L, vDATA1);
DATA1 <= vDATA1;
read(L, vDATA2);
DATA2 <= vDATA2;
...
end loop;
2-19
Example 2-20 Reading and Applying Vectors (Recommended Coding)
while not endfile(infile) loop
readline(infile, L);
wait for 50 ns; -- One clock
read(L, vDATA1);
DATA1 <= vDATA1;
read(L, vDATA2);
DATA2 <= vDATA2;
...
end loop;
Message Files
During simulation, you might want to print messages for failures or to

record other information.
Guideline
Use TEXTIO instead of assert statements to print messages. TEXTIO
supports most data types and allows writing to multiple files. Asserts
are limited to strings only, and data types must be converted to strings
by inefficient functions. Example 2-21 shows the use of TEXTIO for
printing messages.
Example 2-21 Using TEXTIO to Print Messages

if (S1 /= ADATA) then
write(L, string(Signal S1 ( ));
write(L, S1);
write(L, string() Data is incorrect ));
writeline (outfile, L);
end if;
2-20
Guideline
Control the severity levels of assertions to reduce the amount of
assertion output when using assertions. VCS MX provides assertion
filtering capabilities with the following two simulation environment
variables:
ASSERT_IGNORE
Controls which user-defined assertions are ignored based on
severity level.
ASSERT_IGNORE_OPTIMIZED_LIBS
Controls the filtering of assertion messages generated from within
the optimized libraries (for example, IEEE.Numeric_Std,
IEEE.Std_Logic_1164).
By carefully planning the severity level of your assertions and by
setting these simulation environment variables, you can filter out
informational and non-error warning messages. This improves your
simulation performance and reduces the volume of data in the
simulation results which must be checked for true design errors.
Guideline
Use assert statements for printing text messages to avoid
performance degradation.
2-21
2-22
3
Design Guidelines 1
VCS MX cycle mode is designed to provide the best possible capacity
and performance for simulating synthesizable, register-transfer level
descriptions of synchronous circuits. However, as your VHDL code
departs from the coding style recommended for cycle simulation, a
gradual degradation in simulation performance occurs.
This chapter describes coding guidelines that allow you to get the
maximum advantage of the inherent speed and capacity from cycle
simulation. These guidelines will also improve the quality of your
synthesis results.
This chapter describes the design coding guidelines for the following
topics:
Pullups and pulldowns

Vectorization and loops
Design Guidelines
3-1
Combinatorial logic
Sequential logic
Clock generation
Gate-level modeling
For more information about design coding styles, see the VHDL
Compiler Reference Manual.
Pullups and Pulldowns
This section provides guidelines for modeling pullups and pulldowns.
Guideline
Use only the strong corresponding states (0, 1, X, Z) of the standard
types to model pullups and pulldowns. Cycle simulation maps weak
states to strong ones, it maps H states to 1, L to 0. For example,
in cycle mode H and 0 states are resolved to X, because the H
is really a 1.
Guideline
Remove weak state pullups and pulldowns from the design, because
they do not simulate correctly. Use the types defined in the standard
IEEE.std_logic_1164 package to model pullups and pulldowns. For
pullups, use the tri1 and tri1_vector types. For pulldowns, use the tri0
and tri0_vector types.
Design Guidelines
3-2
In Example 3-1, pu_bit is resolved to 1 and pu_bus is resolved to
1101.
Example 3-1 Defining A Pullup

signal pu_bus : tri1_vector(3 downto 0);
signal pu_bit: tri1;
p1 : process
begin
...
pu_bit <= Z;
pu_bus <= ZZZZ;
...
end process p1;
p2 : process
begin
...
pu_bit <= Z;
pu_bus <= ZZ01;
...
end process p1;
Guideline
If the pullup or pulldown functionality is implemented in an I/O PAD,
it is best to simulate the PAD cells in event simulation and only partition
the DUT into cycle simulation mode.
Most designs are already organized hierarchically where the PAD

cells are instantiated at or above the level of hierarchy containing the
DUT instance. Therefore, it is usually easy to leave the PADs in the
event partition.
Note:
There might be other reasons for PAD cells to remain in event.
For example, signal assignments with after clauses which cannot
be modeled easily as cycle testbench processes and for which
the delays are necessary to ensure correct results.
Design Guidelines
3-3
Vectorization and Loops
The guidelines for vectorization and loops are presented in this

section.
Guideline
Use vector assignments and operations wherever possible.
Vectorization improves runtime performance because cycle
simulation maps vector operations to word operations on the target
computer.
Guideline
Use vectorization to make your code more compact and readable.
For example, you can set an entire array of arrays to zero (such as
arrays representing a RAM) as shown in Example 3-2.
Example 3-2 Using Vectorization

ram_array := (others => (others => 0));
Guideline
Do not use for loops to iterate over an array index, you lose the
compactness and performance advantages of vectorization.
Example 3-3 shows a slow method for computing a bitwise XOR. The
vectorized version in Example 3-4 produces a faster runtime
performance.
Example 3-3 Using Bitwise XOR with FOR loop (Not Recommended)
function SLOW_XOR(bbit : std_logic;
avec : std_logic_vector)
return std_logic_vector is
variable cvec : std_logic_vector(avecrange);
begin
for I in avecrange loop
Design Guidelines
3-4
cvec(I) := avec (I) XOR bbit;
end loop;
return(cvec);
end;
Example 3-4 Using Bitwise XOR with Vectorization

function FAST_XOR(bbit : std_logic;
avec : std_logic_vector)
return std_logic_vector is
variable cvec, temp : std_logic_vector(avecrange);
begin
temp := (others => bbit);
cvec := avec XOR temp;
return(cvec);
end;
The cycle elaborator unrolls for loops for maximum runtime

efficiency. Long for loops increase the size of the code generated
for cycle and the time it takes to elaborate. The elaborator issues a
warning when it encounters an excessively long for loop.
Combinatorial Logic
This section provides guidelines to help you ensure that your

combinatorial logic simulates correctly and efficiently.
Guideline
Use complete sensitivity lists for combinatorial processes. Incomplete
sensitivity lists can cause a mismatch between cycle simulation (and
synthesis) and event simulation, as shown in Example 3-5 and Figure
3-1.
Design Guidelines
3-5
Example 3-5 shows a VHDL process that yields an OR gate when
synthesized and behaves like an OR gate in cycle simulation. Figure
3-1 shows an event simulator that complies with strict VHDL
semantics and does not propagate changes on signal B through the
gate until signal A changes.
Example 3-5 Using an Incomplete Sensitivity List (Not Recommended)

process (A)
begin
C <= A or B;
end process;
Figure 3-1 Effect of Incomplete Sensitivity List

A A
B B
C C
Cycle Simulation Event Simulation
Guideline
In case and if statements, be sure to cover all possible conditions,
and for each condition, specify what happens to all output signals.
Incomplete specifications, such as in Example 3-6, can lead to the
inference of unwanted latches in cycle simulation (and VHDL
Compiler).
In general, case statements execute faster than multiple if

statements. Use if-then-else-endif constructs only when you need
priority encoding.
Design Guidelines
3-6
Example 3-6 Using Incomplete if and case Statements
(Not Recommended)
process (A, B) begin
if (A = 1) then
Q <= B;
end if;--missing else clause!
end process;
process (C) begin

case (C) is
when 0 => Q <= 1; P <= 0;
when others => Q <= 0; --missing assignment
--to signal P
end case;
end process;
Guideline
Do not insert VHDL assertion statements in combinatorial logic,
although they are supported in cycle simulation. Using assertion
statements in combinatorial logic can result in assertion message
mismatches between cycle and event simulation. The order in which
combinatorial processes are executed is not guaranteed in cycle
simulation. Nor does cycle simulation guarantee that combinatorial
processes are even executed during a given evaluation cycle.
Guideline
Do not use feedback loops that do not include a single register
element. They can degrade both simulation performance and
synthesis results. The cycle elaborator detects and reports warning
for such loops.
The cycle elaborator attempts to break combinatorial feedback loops

by inserting the equivalent of a register. This might or might not result
in correct functionality during simulation. Therefore, it is best to avoid
combinatorial loops.
Design Guidelines
3-7
Sequential Logic
This section provides guidelines that ensure your sequential logic

simulates correctly and efficiently.
Guideline
Do not explicitly instantiate registers (flip-flops and latches) in the
source code, instead, let VCS MX infer them. This method can help
you to meet the design requirements without adhering to a particular
technology.
Certain VHDL templates imply (by VCS MX and the synthesis tools)
a particular register type. Example 3-7 shows a template for a
sequential process. A full catalog of templates is provided in the
Templates for Register Inference appendix.
Example 3-7 Using a Basic Sequential Template

sync : process (CLK) begin
if (CLKEVENT and CLK = 1) then
...
endif;
end process;
Design Guidelines
3-8
Clock Generation
There are three different ways to generate a clock signal: global,

gated, or combinatorial. In cycle mode, global clocks generated from
a central place such as the testbench produce the highest
performance, and combinatorial clocks produce the lowest
performance. For information about coding testbench-driven global
clocks, see the Testbench Guidelines chapter.
This section presents the guidelines for coding design-driven gated

clocks.
Guideline
Keep the gated clock process in a separate architecture, and make
the clock as global as possible. Example 3-8 shows the gated clock
architecture in bold.
Example 3-8 Using Separate Architecture for Gated Clocks

Architecture RTL of Gated_clock is
begin
CLK_GATE <= (GATING_LOGIC);
end RTL;
p1: process ( CLK_GATE ) BEGIN
if (CLK_GATEEVENT and CLK_GATE=1) then
...
end if;
end process;
p2: process ( CLK_GATE ) BEGIN
if (CLK_GATEEVENT and CLK_GATE=1) then
...
end if;
end process;
Design Guidelines
3-9
Guideline
In zero-delay simulation (such as in cycle simulation), use an inverse
polarity sequential device to model the gated logic, or replace the
gated clock with a synchronous load if the clock and gate signals are
both generated from the same logic and they occur at the same time.
Otherwise, the gated clock does not function correctly.
If the clock and gate signals occur at a different time, the gated clock
will function properly.
Figure 3-2 Gated Clock Signal
DESIGN
SEQ
Gate Gated_CLK
Gating
Logic
CLK
Design Guidelines
3-10
Guideline
If you are using multiple clocks and gate signals, generate the clocks
at different times and make the gate signal occur before the clock
signals. For example, as shown in Figure 3-3, the CLKA and CLKB
signals must occur at different times and the Enable signal must
happen before the clock signals.
Figure 3-3 Multiple Clocks and Gate Signal
DESIGN
Combo Combo
SEQ Logic SEQ Logic SEQ
CLKA CLKB
Gating
Logic
Enable
Clocks must be at
different times
Design Guidelines
3-11
Guideline
Use negative edge registers in gating logic to ensure that the enable
and clock edge occur at different times. Later, you can replace the
negative edge registers with real logic for gate-level timing simulation.
Figure 3-4 shows a negative edge sequential device that is used in
the gating logic.
Figure 3-4 Negative Edge Sequential Device
DESIGN
Combo
SEQ Logic
CLK SEQ
Gated_CLK
Enable
Combo
SEQ Logic Gate
SEQ
Gating Logic
Falling edge sequential device guarantees that enable

and clock edge do not occur simultaneously.
Guideline
Do not use clock buffering because clock buffering can break up
processes into separate functions. Use one trigger function for each
clock region.
Design Guidelines
3-12
Gate-level Modeling
Cycle simulation ignores timing delays except when modeled using

a testbench style, see the Testbench Guidelines chapter. Therefore,
VITAL components are simulated in cycle using only their
functionality. All timing information for VITAL components, including
Wire Delays, Path Delays, and Timing Checks, are discarded when
simulated in cycle mode. This is referred to as functional VITAL
simulation. Functional VITAL simulation is automatically enabled and
cannot be disabled in cycle simulation. If a design is dependent on
accurate timing, it cannot be simulated in cycle mode. It is a natural
consequence of functional VITAL simulation that no SDF back-
annotation can be performed.
In event simulation, to enable functional VITAL simulation of all VITAL

models in the design, specify the novitaltiming option on the scsim
command line.
Guideline
Do not use gate-level simulation in cycle mode as it degrades
simulation performance. However, if it is necessary to use some gate-
level models, cycle simulation can handle VITAL Level 1 compliant
models in a functional mode. Ensure that both the design and the
VITAL component do not depend on accurate timing through the
VITAL component for correct results.
Design Guidelines
3-13
Guideline
When using VITAL Level 0 compliant models, ensure that the coding
style of the architecture closely follows that required for Level 1
compliant models in any of the timing areas (Wire Delay, Path Delay,
and Timing Checks) that the model includes.
Because there are no rules and guidelines for the architecture's

coding style in a Level 0 compliant model, VCS MX might not correctly
ignore and only ignore the timing aspects of a Level 0 model. It is
recommended that Level 0 architectures follow, as closely as
possible, the style of Level 1 architectures to ensure that VCS MX
correctly identifies the timing aspects of the model.
If you encounter problems in simulating Level 0 compliant VITAL

models in functional VITAL or cycle mode, contact the Synopsys
Technical Support Center for help on the coding style.
Note:
Because all VITAL Level 1 compliant models are also Level 0
compliant, it is important to note that this guideline applies only to
those models which are only Level 0 compliant and not Level 1
compliant.
Guideline
Use VITAL models that conform to the VITAL 95 standard. VCS MX
does not support VITAL 2000.
Guideline
The GTECH library can be used for gate-level modeling with cycle
simulation. The GTECH library is compiled for cycle simulation.
Design Guidelines
3-14
Guideline
Use the novitaltiming option to scsim to enable fast functional event
simulation with VCS MX. Use this switch only if the design is not
dependent on accurate timing through the VITAL components.
Design Guidelines
3-15
Design Guidelines
3-16
4
Memory Model Guidelines 1
This chapter presents several rules and guidelines for coding ROM
and RAM memory models. These guidelines show examples of
coding both synchronous and asynchronous memory models. The
examples also show how to use the mem_api package to create
efficient sparse memory models. VCS MX provides the best
simulation performance when you use these guidelines.
This chapter describes coding rules and guidelines for the following
topics:
General memory guidelines

Sparse memory models
Memory Model Guidelines

4-1
VCS MX provides two basic types of memory models: sparse and
dense. In general, use the sparse memory model for larger memories
(100 KB and larger). For smaller memories, use a dense model. The
dense model refers to using a VHDL variable or signal for the memory
element. For both sparse and dense memories, a synchronous
coding style is recommended whenever possible. The mem_api
package provides optimal runtime performance for your sparse
memory models. For more information about the mem_api package,
see the Synopsys Standard Packages chapter in the VHDL
Simulation User Guide.

4-2
General Memory Guidelines
This section provides one rule and several guidelines for coding
memory models.
Rule
Do not use multi-dimensional arrays to model the memory, as shown
in Example 4-1. VCS MX cycle does not support multi-dimensional
arrays. Instead, use an array of arrays as shown in Example 4-2.
Example 4-1 Using Two Dimensional Arrays (Not Supported)

type ram9x4 is array(511 downto 0, 15 downto 0)
of std_logic;
Guideline
Use arrays of std_logic_vector type to load and dump memories. VCS

MX does not support loading arrays of integers. Example 4-2 shows
the use of std_logic_vector type in bold. Example 4-3 shows, in bold,
the use of arrays of integers that is not recommended.
Example 4-2 Using Arrays of std_logic_vector Type for Loading and

Dumping Memories (Recommended Coding)
type ram9x4 is array (511 downto 0)
of std_logic_vector (15 downto 0);
Example 4-3 Using Arrays of Integers for Loading Memories

(Not Recommended)
type ram9x4 is array (511 downto 0)
of integer;

4-3
Guideline
In general, use synchronous memory models when possible.
Synchronous memories usually provide faster simulation
performance compared to asynchronous memories.
Guideline
Clear dense memories by using a vector assignment and others
clauses instead of for loops. Example 4-4 shows, in bold, how to
properly clear a memory at reset.
Example 4-4 Using Synchronous Memory Models (Recommended Coding)

mem5: process( clk, rst)
type ram_t is array( 0 to 15) of
std_logic_vector( 15 downto 0);
variable rama : ram_t;
begin
if (rst = 0) then
rama := (others => (others => 0));
elsif (clkevent and clk = 1) then
if (we = 0) then
rama (conv_integer(addr)) := datain;
end if;
dataout <= rama (conv_integer(addr));
end if;
end process;
Guideline
For asynchronous memories, use variables in the memory process.
With asynchronous memory models, you can use multiple enables
or clocks. Example 4-5 shows an asynchronous memory model that
contains a reset, write enable, read enable, and chip select.

4-4
Note, this memory modeling style (multiple clocks, enables, resets,
and the wait statement) results in the cycle elaborator identifying the
process(es) as testbench process(es). While this degrades the
performance, it is the best method for modeling certain types of
memories such as dual port RAMs.
Example 4-5 Using Asynchronous Dense Memory Models

architecture async of ram is
begin
mem: process
variable rama : ram_t;
begin
wait on we, re, cs, rst;
if (cs = 0) then
if (rst = 0) then
rama := (others => (others => 0));
else
if (we = 1) then
rama(conv_integer(waddr)) := datain;
end if;
if (re = 1) then
dataout <= rama(conv_integer(raddr));
end if;
end if;
end process;

4-5
Sparse Memory Models
This section provides examples for coding sparse (approximately

100KB and larger) memory models.
Guideline
Use functions and procedures in the mem_api package to model
sparse memory models.
Example 4-6 and Example 4-7 show a sparse ROM and a RAM
modeled using the mem_api package. Basically, you use the previous
dense memory examples, but you only replace the variable
assignments with the signal assignment that calls the mem_init
function. The reading and writing to the memory is done using the
mem_read and mem_write procedures defined in the mem_api
package.
Example 4-6 Using a Sparse ROM (Recommended Coding)

Library IEEE;
Use IEEE.mem_API.all;
entity ROM is
generic (n_addr : natural; n_data : natural);
port (addr : in std_logic_vector(n_addr - 1 downto 0);
data : out std_logic_vector(n_data - 1 downto 0);
rclk : in std_logic );
end;
architecture CYCLONE of ROM is
signal handle : memHandle := mem_init(MK_ROM, n_addr,
n_data);
begin
READER: process (rclk)
variable v : std_logic_vector(n_data - 1 downto 0);
begin
if (rclkevent and rclk = 1) then
mem_read(handle, addr, v);
data <= v;

4-6
end if;
end process;
end;
Example 4-7 Using a Sparse Synchronous RAM (Recommended Coding)

Library IEEE;
Use IEEE.mem_API.all;
entity RAM is
generic (n_addr : natural; n_data : natural);
port (addr : in std_logic_vector(n_addr - 1 downto 0);
datain : in std_logic_vector(n_data - 1 downto 0);
dataout : out std_logic_vector(n_data - 1 downto 0);
rw : in std_logic
clk : in std_logic );
end;
architecture CYCLONE of RAM is
signal handle : memHandle := mem_init(MK_RAM, n_addr,
n_data);
begin
READER_WRITER: process (clk)
variable v : std_logic_vector(n_data - 1 downto 0);
begin
if (clkevent and clk = 1) then
if (rw = 0) then
mem_write(handle, addr, datain);
else
mem_read(handle, addr, v);
dataout <= v;
end if;
end if;
end process;
end;

4-7
Dual Port Memories
The guidelines for effectively modeling dual port memories in VCS

MX cycle are provided in this section.
Guideline
If the memory functionality checks for simultaneous read/write or

write/write conflicts between the two ports to the same address, model
this functionality with a single process. This process references two
clocks, two enables, and so on. Thus, it is simulated as a testbench
process.
Guideline
Do not use the 'Event attribute except as permitted for sequential

coding guidelines. Specifically, do not use the 'Event attribute to
perform read/write or write/write conflict checks in multi-port memory
models. Instead, model the conflict checks as shown in Example 4-8.
Example 4-8 Dual Port RAM Modeling with Read/Write Conflict Checks
architecture behave of dual_port_ram is
type ram_type is array(0 to 2**addr_bits) of word;
begin
read_write : process(rsta, clka, rstb, clkb)

variable ram : ram_type;
variable address : Natural;
variable porta_read : Boolean;
variable porta_write : Boolean;
begin
porta_read := FALSE;
porta_write := FALSE;
if rsta = 1 then
data_outa <= (others => 0);

4-8
elsif clkaevent and clka = 1 then
if wea = 1 then
address := to_integer(addra);
ram(address) := data_ina;
porta_write := TRUE;
end if;
if (wea = 1) or (ena = 1) then
address := to_integer(addra);
data_outa <= ram(address);
porta_read := TRUE;
end if;
end if;
if rstb = 1 then
data_outb <= (others => 0);
elsif clkbevent and clkb = 1 then
if web = 1 then
if porta_read and addra = addrb then
data_outa <= (others => X);
end if;
address := to_integer(addrb);
ram(address) := data_inb;
end if;
if (web = 1) or (enb = 1) then
if porta_write and addra = addrb then
data_outb <= (others => X);
else
address := to_integer(addrb);
data_outb <= ram(address);
end if;
end if;
end process read_write;
end architecture behave;

4-9
4-10
A
Templates for Register Inference A
This appendix contains templates for inferring the following types of
sequential devices:
D Latches
D Flip-Flops
JK Flip-Flops
Toggle Flip-Flops
For more detailed information about inferring latches and flip-flops,
see the Register, Multibit, Multiplexer, and Three-State Inference
chapter in the VHDL Compiler Reference Manual. Note, that VCS
MX ignores the directives and attributes that control the VHDL
Compilers inference mechanism. VCS MX relies entirely on the
structure of the template when it infers a register element.
Templates for Register Inference

A-1
D Latches
The examples in this section are templates for D latches. A D latch

has the following four possible input pins:
AD
Asynchronous Data loaded when AL is active
AL
Asynchronous Load, also known as the gate or enable pin
AR
Asynchronous Reset
AS
Asynchronous Set
D Latch
Example A-1 infers a D latch with an enable and data input only. There
are no asynchronous or synchronous controls as inputs.
The AL pin of the latch is specified by the condition in the if statement.

In the following examples, this object is called enable. For each object
conditionally assigned, a latch is synthesized. In the following
examples, this is y, a single bit. Therefore, only one latch is inferred.
If you infer a D latch using the template in Example A-1, you must
ensure that the enable and data objects can be controlled from ports
of the top-level design or through combinatorial logic to ensure
initialization during simulation.

A-2
Example A-1 D Latch
entity d_latch is
port (enable, data: in std_logic;
y: out std_logic );
end d_latch;
architecture rtl of d_latch is

begin
infer: process (enable , data )
begin
if (enable = 1) then
y <= data;
end if;
end process infer;
end rtl;
In Example A-2, data and gate are inputs to the AD pin on a latch
enabled by enable. In this example, the AL pin on the latch is not
driven by combinatorial logic, but the AD pin is. The AL pin is driven
by the enable port, which is the only expression listed in the condition
for the if statement. Figure A-1 illustrates a D latch with gated
asynchronous data.
Figure A-1 D Latch with Gated Asynchronous Data (AD)

A-3
Example A-2 D Latch with Data and with Gate
entity d_latch_enp is
port ( enable , gate , data : in std_logic;
q : out std_logic);
end d_latch_enp;
architecture rtl of d_latch_enp is

begin
infer : process ( enable , gate, data ) begin
if ( (enable) = 1 ) then
q <= data and gate ;
end if;
end process infer;
end rtl;
Contrast Example A-3 with the previous example. In Example A-3,

the AL pin of the latch is driven by combinatorial logic, and the AD
pin is not. Note that the condition in the if statement is an expression.
The expression is synthesized into the logic that drives the AL pin of
the latch. Figure A-2 illustrates a D latch with gated enable.
If the test plans include scan-based methodologies, a gated enable

is not recommended.
Figure A-2 D Latch with Gated Enable

A-4
Example A-3 D Latch with Gated Enable
library IEEE;
use IEEE.std_logic_1164.all;
entity d_latch_en is
port ( enable , gate , d : in std_logic;
q : out std_logic);
end d_latch_en;
architecture rtl of d_latch_en is

begin
infer : process ( enable , gate, d ) begin
if enable = 1 then
if gate = 1 then
q <= d;
end if;
end if;
end process infer;
end rtl;
D Latch with Asynchronous Reset or Set
Example A-4 and Example A-5 infer D latches with asynchronous

reset and set, respectively.
Example A-4 D Latch with Asynchronous Reset

entity d_latch_async_reset is
port ( enable , data , reset : in std_logic;
q : out std_logic);
end d_latch_async_reset;
architecture rtl of d_latch_async_reset is

begin
infer : process ( enable , data , reset ) begin
if (reset = 1) then
q <= 0;
elsif ( enable = 1 ) then
q <= data;
end if;

A-5
end process infer;
end rtl;
Example A-5 D Latch with Asynchronous Set

entity d_latch_async_set is
port (enable , data , set: instd_logic;
q : outstd_logic );
end d_latch_async_set;
architecture rtl of d_latch_async_set is

begin
infer: process (enable , data , set)
begin
if (set = 0) then
q <= 1;
elsif (enable = 1) then
q <= data;
end if;
end process infer;
end rtl;
D Latch with Asynchronous Reset and Set
Example A-6 infers a D latch with active low asynchronous reset and
set. Set has priority over reset in the logic synthesized for these
examples.
Example A-6 D Latch with Asynchronous Set and Reset

entity d_latch_async is
port ( enable , data , reset , set :in std_logic; q : out
std_logic);
end d_latch_async;
architecture rtl of d_latch_async is

begin
infer : process ( enable , data , reset , set ) begin
if (set = 0) then
q <= 1;
elsif (reset = 0) then

A-6
q <= 0;
elsif ( enable = 1 ) then
q <= data;
end if;
end rtl;
D Flip-Flops
For additional information about inferring D flip-flops, see the

Register, Multibit, Multiplexer, and Three-State Inference chapter in
the VHDL Compiler Reference Manual.
D Flip-Flop with Positive or Negative Edge Trigger
Example A-7 and Example A-8 infer D flip-flops with no extra

asynchronous or synchronous controls. If you infer this type of D flip-
flop, you must be able to control the D and clock pins from the input
ports or through combinatorial logic to initialize the circuit during
simulation. If this is not the case, infer a D flip-flop with asynchronous
reset or set or with a synchronous reset or set.
Example A-7 D Flip-Flop with Positive Edge Trigger

entity dff_pos is
port ( data , clk : in std_logic ;
q : out std_logic );
end dff_pos;
architecture rtl of dff_pos is

begin
infer : process ( clk ) begin
q <= data;
end if;

A-7
end process infer;
end rtl;
Example A-8 D Flip-Flop with Negative Edge Trigger

entity dff_neg is
port ( data , clk : in std_logic ;
end dff_neg;
architecture rtl of dff_neg is

begin
q <= data;
end if;
end process infer;
end rtl;
D Flip-Flop with Asynchronous Reset or Set
Example A-9 and Example A-10 illustrate how to describe D flip-flops

with asynchronous reset or set.
Example A-9 D Flip-Flop with Asynchronous Reset

entity dff_async_reset_orig is
port ( data , clk , reset : in std_logic ;
end dff_async_reset_orig;
architecture rtl of dff_async_reset_orig is

begin
infer : process ( clk , reset) begin
if (reset = 1) then
q <= 0;
q <= data;
end if;
end process infer;

A-8
end rtl;
Example A-10 D Flip-Flop with Asynchronous Set

entity dff_async_set_orig is
port ( data , clk , set : in std_logic ;
end dff_async_set_orig;
architecture rtl of dff_async_set_orig is

begin
infer : process ( clk , set) begin
if (set = 0) then
q <= 1;
q <= data;
end if;
end process infer;
end rtl;
D Flip-Flop with Asynchronous Set and Reset
Example A-11 infers a D flip-flop with active low asynchronous set

and reset pins. set has priority over reset.
Example A-11 D Flip-Flop with Asynchronous Set and Reset

entity dff_async is
port ( data , clk , reset , set: in std_logic ;q: out
std_logic );
end dff_async;
architecture rtl of dff_async is
begin
infer : process ( clk , reset , set)
if (reset = 1) then
q = 0;
elsif (set = 1) then
q = 1;
q = data;

A-9
end if;
end rtl
D Flip-Flop with Synchronous Reset or Set
The previous examples illustrate how to infer a D flip-flop with

asynchronous controlsone way to initialize or control the state of a
sequential device. The other method is to synchronously reset or set
the flip-flop, as shown in Example A-12 and Example A-13.
Example A-12 D Flip-Flop with Synchronous Reset

entity dff_sync_reset is
-- dff w/ pos edge clock and active low sync. reset
port ( data , clk , reset : in std_logic ;
end dff_sync_reset;
architecture rtl of dff_sync_reset is

begin
if (reset = 0) then
q <= 0;
else q <= data;
end if;
end if;
end process infer;
end rtl;
Example A-13 D Flip-Flop with Synchronous Set

entity dff_sync_set is
port ( data , clk , set : in std_logic ;
end dff_sync_set;
architecture rtl of dff_sync_set is

begin

A-10
if (set = 1) then
q <= 1;
else q <= data;
end if;
end if;
end process infer;
end rtl;
D Flip-Flop with Synchronous and Asynchronous Load
D flip-flops can have asynchronous or synchronous controls. To infer

a component from HDL with both synchronous and asynchronous
controls, you must check the asynchronous conditions before you
check the synchronous conditions.
Example A-14 describes a D flip-flop with a synchronous load (called

sload) and an asynchronous load (called aload).
Example A-14 D Flip-Flop with Synchronous and Asynchronous Load

entity dff_a_s_load is
port( sload, aload, adata, sdata , clk : in std_logic;
end dff_a_s_load;
architecture rtl of dff_a_s_load is

begin
infer: process (clk , aload)
begin
if (aload = 1) then
q <= adata;
if (sload = 1) then
q <= sdata;

A-11
end if;
end if;
end process infer;
end rtl;
D Flip-Flop with Asynchronous Reset, Set, Load, and

Synchronous Load
Example A-15 is similar to the previous example because there are

asynchronous and synchronous controls. The difference is the
addition of asynchronous reset and set.
Example A-15 D Flip-Flop with Asynchronous Reset, Set, and Load, and
Synchronous Load
entity dff_arsl_sl is
port( reset, set, aload, sload, clk :in std_logic;
adata,sdata : in std_logic_vector (3 downto 0);
q : out std_logic_vector (3 downto 0) );
end dff_arsl_sl;
architecture rtl of dff_arsl_sl is

begin
infer: process (clk , reset , set , aload)
begin
if (reset = 1) then
q <= (0000);
elsif (set = 1) then
q <= 1111;
elsif (aload = 1) then
q <= adata;
if (sload = 1) then
q <= sdata;
end if;
end if;
end process infer;
end rtl;

A-12
JK Flip-Flops
This section describes JK flip-flops and JK flip-flops with

asynchronous reset and set.
JK Flip-Flop
Example A-16 shows a JK flip-flop with the truth table shown in Table
A-1.
Table A-1 JK Flip-Flop

J K CLK Qn + 1
0 0 Rising Qn
0 1 Rising 0
1 0 Rising 1
1 1 Rising QnB
X X Falling Qn
Use caution when using a JK flip-flop because the initialization of the

flip-flop is done synchronously. The simulator might not correctly reset
the flip-flop if J, K, and CLK cannot be controlled from the top-level
ports of the design.
Example A-16 JK Flip-Flop

entity JK is
port( J: in std_logic;
K ,
CLK : in std_logic;
Q_out : out std_logic );
end JK;
architecture rtl of JK is
signal Q : std_logic;

A-13
begin
infer: process
variable JK : std_logic_vector ( 1 downto 0);
begin
wait until (CLKevent and CLK = 1);
JK := (J & K);
case JK is
when 01 => Q <= 0;
when 10 => Q <= 1
when 11 => Q <= not (Q);
when 00=> Q <= Q;
when others=> Q <= X;
end case;
end process infer;
Q_out <= Q;
end rtl;
JK Flip-Flop with Asynchronous Reset and Set
Example A-17 describes a positive edge-triggered JK flip-flop with

active high asynchronous set and reset.
Example A-17 JK Flip-Flop with Asynchronous Set and Reset

entity jk_async_sr is
port (RESET, SET, J, K, CLK : in std_logic;
Q_out : out std_logic );
end jk_async_sr;
architecture rtl of jk_async_sr is

signal Q : std_logic;
begin
infer : process (CLK , RESET , SET)
variable JK : std_logic_vector ( 1 downto 0);
begin
if (RESET = 1) then
Q <= 0;
elsif (SET = 1) then
Q <= 1;
elsif (clkevent and CLK = 1) then

A-14
JK := (J & K);
case JK is
when 01 => Q <= 0;
when 10 => Q <= 1;
when 11 => Q <= not(Q);
when 00 => Q <= Q;
when others => Q <= X;
end case;
end if;
Q_out <= Q;
end process infer;
end rtl;
Toggle Flip-Flops
This section describes toggle flip-flops with asynchronous reset or

set, and toggle flip-flops with enable and asynchronous reset.
Toggle Flip-Flop with Asynchronous Reset or Set
Example A-18 and Example A-19 are toggle flip-flops with

asynchronous reset or set. Toggle flip-flops must have an
asynchronous control, otherwise, it is impossible to initialize the flip-
flop to a known state.
Example A-18 Toggle Flip-Flop with Asynchronous Reset

entity t_async_reset is
port( RESET , CLK : in std_logic;
Q : out std_logic );
end t_async_reset;
architecture rtl of t_async_reset is

signal tmp_q : std_logic;
begin
infer: process (CLK , RESET) begin

A-15
if (RESET = 1) then
tmp_q <= 0;
elsif (CLKevent and CLK = 0) then
tmp_q <= not (tmp_q);
end if;
end process infer;
Q <= tmp_q;
end rtl;
Example A-19 Toggle Flip-Flop with Asynchronous Set

entity t_async_set is
port( SET ,
CLK : in std_logic;
end t_async_set;
architecture rtl of t_async_set is

begin
infer: process (CLK , SET) begin
if (SET = 1) then
tmp_q <= 1;
elsif (CLKevent and CLK = 1)
then tmp_q <= not (tmp_q);
end if;
end process infer;
Q <= tmp_q;
end rtl;

A-16
Toggle Flip-Flops with Enable and Asynchronous Reset
Example A-20 describes an enabled toggle flip-flop with

asynchronous reset. The toggle occurs only if the enable (called
TOGGLE) is high.
Example A-20 Toggle Flip-Flop with Enable and Asynchronous Reset

entity t_async_en_r is
port( RESET , TOGGLE , CLK : in std_logic;
end t_async_en_r;
architecture rtl of t_async_en_r is

begin
infer: process (CLK , RESET )
begin
if (RESET = 1) then
tmp_q <= 0;
elsif (CLKevent and CLK = 1) then
if (TOGGLE = 1) then
tmp_q <= not (tmp_q);
end if;
end if;
end process infer;
Q <= tmp_q;
end rtl;

A-17
A-18
B
Supported Language Constructs for VCS MX
Cycle A
The cycle simulation coding style supports and builds on the
Synopsys synthesis coding style as defined in the VHDL Compiler
Reference Manual.
This appendix provides a list of all the synthesizable VHDL language

constructs supported by VCS MX in cycle mode and additional
constructs that are supported only in a cycle testbench process.
Cycle Simulation Policy

Cycle Testbench Process Policy
Note:
For information about the IEEE and VCS MX supported and
unsupported VHDL93 language constructs, see the VHDL93
Features Appendix in the VHDL Simulation User Guide.
Supported Language Constructs for VCS MX Cycle

B-1
Cycle Simulation Policy
This section lists VHDL language constructs and describes the level
of support provided for each constructs in cycle simulation. A
construct can be supported, ignored, or unsupported. Ignored
constructs can appear in your VHDL code without causing an error,
they simply have no effect. Unsupported means that the construct
cannot appear in your VHDL code. Either the VHDL Analyzer or the
cycle elaborator generate an error message when they find an
unsupported construct.
Note:
VCS MX ignores the synthesis translate_off, translate_on,
synthesis_off, and synthesis_on directives. The simulators
attempt to parse and generate executable code from the VHDL
source code between such directives. Therefore, all such VHDL
code must either conform to the cycle simulation policy or the
cycle testbench policy. (See the Cycle Testbench Policy later in
this appendix.)
Note:
VCS MX supports the pragma_resolution_method (which accepts
wired_and, wired_or, or three_state as the value) and
pragma_resolution_nodrivers (which accepts pullup or pulldown
as the value) pragmas.
Constructs are listed in the following order:
Design units
Data types
Declarations

B-2
Specifications
Names
Attributes
Operators
Operands and expressions
Subprograms
Sequential statements
Concurrent statements
Predefined language environment
Design Units
entity
The entity statement part is ignored.
In VCS MX, the root of a cycle partition cannot have generics. Nor
can it have ports of an unconstrained type.
Otherwise, generics are supported, except for those of type record

(which is a synthesis limitation as well).
Default values for ports are supported.
architecture
Multiple architectures are supported for an entity.
Global interaction between signals declared in packages are not

supported.

B-3
configuration
Configuration declarations and block configurations are
supported in VCS MX cycle.
Within a configuration, the following are not supported:
- Using type conversion functions

- Changing the default formal port binding to local port binding
- Declare attribute specifications
package
Packages are supported.
The following packages from IEEE library are not supported:
- MATH_COMPLEX
- STD_LOGIC_COMPONENTS
The following packages from SYNOPSYS library are not
supported:
- DISTRIBUTIONS
- INTEGER_QUEUES
- INTEGER_ZQUEUES
- BV_ARITHMETIC
library
Libraries and separate compilation are supported.

B-4
Data Types
For bits and bit-vectors, use the std_logic and std_logic_vector types
defined in the IEEE std_logic_1164 package or the SIGNED and
UNSIGNED types from either the IEEE Numeric_Std or
std_logic_arith packages.
enumeration
Enumeration is supported.
integer
Integer is supported.
Integer types are automatically converted to bit vectors whose

width is as small as possible to accommodate all possible values
of the types range, either in unsigned binary for nonnegative
ranges or in 2s-complement form for ranges that include negative
numbers.
physical
The only supported physical type is time.
floating
Floating-point type declarations are supported.

B-5
array
Array ranges and indexes are supported.
Multidimensional arrays are unsupported, but arrays of arrays and

the types VitalStateTableType and VitalTruthTableType in the
VITAL_Primitives package are supported. VitalStateTableType
and VitalTruthTableType are supported only within the context of
VITAL components.
Array ranges and indexes can be integers or enumerated types.
record
Record data types are supported except in subprogram
declarative part. But, variables of a record type can be declared
in a subprogram declarative part.
access
Access type declarations are unsupported.
Only the line type is supported. Slicing and indexing a line variable
are unsupported. The TextIO Read and Write routines must be
used to manipulate line variables.
file
File names in a declaration must be globally static.
incomplete type declarations

Incomplete type declarations are unsupported.

B-6
Declarations
constant
Constant declarations are supported except for deferred constant
declarations.
signal
The register and bus declarations are treated as normal signals
only.
Only predefined resolution functions are supported. These

functions are defined in the std_logic_1164 package.
Only signal declarations that are from a globally static type are
supported.
Signal declarations in packages are unsupported. Signal

declaration in a generate statement is unsupported. But, a block
can be declared within the generate statement and the signal
declared within the block.
variable
Only declarations that are from a globally static type are
supported. Except declarations within a subprogram can depend
on input parameters (such as the range of an input vector
parameter can be used to define a temporary variable of the same
size).
Shared variables are unsupported.
file
File declarations are supported in packages.

B-7
Only static string names are supported for file names.
interface
buffer and linkage are translated to out and inout, respectively.
The driving or sourcing value of buffer ports can be read within
the design entity.
The 1987 and 1993 IEEE Standard Language Reference Manual

states that a buffer cannot have multiple drivers. In cycle, a signal
of mode buffer can have multiple drivers if they are declared of
some resolved type (std_logic for example.)
alias
Aliases of objects (signals, variables, constants) are supported.
All other aliases are not supported in cycle mode.
component
Component declarations are supported.
Specifications
disconnection
Disconnection specifications are unsupported.
Names
simple
Simple names are supported.

B-8
selected
Selected names are supported.
operator symbols
Operator symbols are supported.
indexed
Indexed names are supported but indexing objects of type line is
unsupported.
slice
Slice names are supported but slicing objects of type line is
unsupported.
Attributes
predefined
The only supported predefined attributes are base, left, right, high,
low, range, reverse_range, and length.
event and stable

The event and stable attributes are supported only when used in
conformance with accepted synthesis sequential coding
templates. For example (not all-inclusive)
wait until clkevent and clk = '1';
Or

B-9
process (clk)
begin
if clkevent and clk = 0 then
...
end if;
end process;
Synopsys-defined
The only attribute supported by Cyclone is the TABLE attribute.
There are two table attributes. The cyclone_table_eval_fn
attribute enables table optimization and the
cyclone_table_input_width attribute tells the cycle elaborator how
many inputs there are. For example,
attribute cyclone_table_eval_fn of eval_table:function

is TRUE;
attribute cyclone_table_input_width of
eval_table:function is 5;
user-defined
User-defined attributes are unsupported.
Operators
logical
Logical operators are supported. The operators sll, srl, sla, sra,
ror, rol and xnor are supported only for the IEEE Numeric_Std
SIGNED and UNSIGNED types.
relational
Relational operators are supported.

B-10
addition
Concatenation and arithmetic operators (multiplication and
absolute value) are supported.
signing
Sign operators are supported.
multiplying
The * (multiply) operator is supported.
The / (division), mod, and rem operators are supported.
miscellaneous
The ** operator is supported.
The abs operator is supported.
operator overloading
Operator overloading is supported.
short-circuit operations
The short-circuit behavior of operators is only supported in a cycle
testbench process.
Operands and Expressions
based literals
Based literals are supported.

B-11
null ranges, null slices, and null arrays
Null ranges, null slices, and null arrays are unsupported.
null range example,
1 downto 12
null slice example,
BUSA(5 to 0)
null array example:
type MY_ARRAY is array (0 downto 5) of BIT;
null string literals

Null string literals (for example, ) are unsupported.
physical literals
Only physical literals of types time are supported.
strings
Strings are supported.
aggregates
The use of types as aggregate choices is unsupported.
Record aggregates are supported. Named association of record

formals is unsupported.

B-12
function calls
Function conversions on input ports are unsupported, since type
conversions on formal ports in a connection specification are
unsupported. The new and deallocate functions are unsupported.
qualified expressions
Qualified expressions are supported.
type conversion
Type conversion is supported. Type conversions on formal ports
in a port map are unsupported.
allocators
Allocators are unsupported.
static expressions
Static expressions are supported.
Extended identifiers are unsupported.

universal expressions
Floating-point expressions are supported.
Precision is limited to 32 bits, all intermediate results are

converted to integer.

B-13
Subprograms
Default values for parameters are supported. Assigning to indexes

and slices of unconstrained out parameters are supported.
Subprogram recursion is unsupported if the recursion is not

bounded by a static value.
Only predefined resolution functions are supported. These

functions are defined in the std_logic_1164 package.
Inout signal parameters are unsupported.
Sequential Statements
wait
Outside a testbench process, the wait statement is unsupported
unless it is in one of the following synthesizable sequential
template forms as the first statement in the process:
wait until clock = VALUE;

wait until clockevent and clock = VALUE;
wait until not clockstable and clock = VALUE;
VALUE is0,1, or an enumeration literal whose encoding is 0 or

1. A wait statement in this form is interpreted as wait until the
falling (VALUE is0) or rising (VALUE is1) edge of the signal
named clock.
Additional forms of wait statements are supported in cycle

testbenches. See the Cycle Testbench Policy section later in this
appendix.
assertion

B-14
Assertion statements are supported.
report
report statement is unsupported.
signal
Guarded signal assignment is unsupported.
transport and after are ignored.
Multiple waveform elements in signal assignment statements are

unsupported.
Use of pulse rejection is unsupported.
variable
Variable statements are supported.
procedure call
Type conversion on formal parameters is unsupported.
Assignment to single bits of vectored parameters is unsupported.
if
if statements are supported.
case
case statements are supported.

B-15
loop
for loops are supported, but enumeration values cant be used
as loop bounds.
while loops are supported.
Loop statements with no iteration scheme (infinite loops) are

supported.
next
next statements are supported.
exit
exit statements are supported.
return
return statements are supported.
null
null statements are supported.
Concurrent Statements
The following are supported concurrent statements:
process
concurrent procedure call
concurrent assertion
generate

B-16
block
Guards on block statements are unsupported.
Ports and generics in block statements are unsupported.
concurrent signal assignment

The guarded and transport keywords are ignored. Multiple
waveforms are unsupported.
Postponed processes are unsupported.

component instantiation
Type conversion on the formal port in the port map is unsupported.
Predefined Language Environment
The following are supported predefined language type, function,

package, and attributes:
severity_level type
time type
now function
TEXTIO package
predefined attributes
The only supported predefined attributes are: base, left, right,
high, low, range, reverse_range, and length.
The event and stable attributes are supported only in the if and
wait statements following the synthesis coding style.

B-17
The image attribute is supported only if the prefix is of integer or
boolean type.
Indexing range or reverse_range is unsupported since only one

dimensional arrays are supported.
Cycle Testbench Process Policy
For best performance in VCS MX cycle, your design must be fully

synthesizable. However, in a testbench process a wider variety of
wait statements are supported. The simulator automatically identifies
testbench processes based on the use of behavioral style wait
statements.
The textio Package
The textio package provides procedures for reading and writing ASCII
files during simulation. All textio procedures defined in the IEEE VHDL
Standard Language Reference Manual are supported. In addition,
the procedures defined in the Synopsys package
IEEE.std_logic_textio are supported.
Note:
You cannot read from stdin using textio routines within a cycle
partition in VCS MX.

B-18
Wait Statements
The VHDL wait is a sequential statement that suspends a process.

The following wait statement is supported in both the cycle subset for
models and the testbench code:
wait until (edge);
Where edge refers to an expression that tests for the positive or

negative edge of a signal. The syntax of an edge expression is
SIGNALevent and SIGNAL = 1 -- rising edge

NOT SIGNALstable and SIGNAL = 1 -- rising edge
SIGNALevent and SIGNAL = 0 -- falling edge
NOT SIGNALstable and SIGNAL = 0 -- falling edge
An edge can also be
SIGNAL = 1 -- rising edge

Signal = 0 -- falling edge
In testbench processes, the use and location of these wait statements

are more flexible as compared to edge statements. The wait
statements do not need to be the first statement in the process.
In testbench processes, a broader range of wait statements is

supported, including the following types:
wait;
The process suspends forever.
wait on signal_list;
The process activates whenever there is an event on any of the
signals in the signal list.

B-19
wait until expression;
The process activates when expression becomes TRUE.
wait for time;

The process suspends for the length of time specified.
You can also use on, until, and for clauses in combination, as in
wait on IN1 until CLK = 0;
Multiple Clocks
In a testbench process, you can have multiple clocks with edge

conditionals for each clock. This style is common in multi-ported
memories.

B-20
VHDL Reserved Words
Do not use the following words as identifiers, they are reserved for
the VHDL language:
a for port
abs function procedure
access g process
after generate postponed
alias generic pure
all group r
and guarded range
architecture i record
array impure register
assert in reject
attribute inertial rem
b inout report
begin is rol
block l ror
body label s
buffer library select
bus literal severity
c linkage shared
case loop signal
component m sla
configuration mod sll
constant n sra
d nand srl
disconnect next subtype
downto not t
e null the
else o to
elsif of transport
end open type
entity or u
exit out unaffected
f p unit
file package until

B-21
v
variable
w
wait
when
while
with
x
xnor
xor

B-22
C
Cycle Simulation and LRM Differences A
This appendix lists areas where VCS MX cycle execution and
elaboration semantics vary from those defined by the IEEE Standard
VHDL Language Reference Manual.
This information is provided to help you use cycle simulation more

effectively. This list is by no means exhaustive and is not considered
all inclusive.
Gated Clock Evaluation

Cycle and event simulators evaluate gated clock signals differently.
In Cycle, both the original clock and the gated clock are evaluated in
the same step. In event simulators, the original clock and the gated
clock are evaluated in two steps, that is, two delta cycles.
Cycle Simulation and LRM Differences

C-1
Process Drivers
Cycle simulation does not perform interprocess evaluation of drivers
as described in the IEEE Standard VHDL Language Reference
Manual. If you drive different segments of a bus from different
processes, the cycle simulator does not require signals to be a
resolved type.
For example, consider the following process driver statements:
Architecture A of E is
Signal foo : std_ulogic_vector (1 to 7);
begin
p1: process (sws)
begin
for i in 1 to 3 loop
foo(i) <=sws;
end loop;
end process;
p2: process (swr)
begin
for i in 4 to 7 loop
foo(i) <=swr;
end loop;
end process;
end;
Cycle simulators determines that the segments of foo assigned in

processes p1 and p2 are disjoint and, therefore, does not require the
signal foo to be a resolved type.
According to the LRM, p1 and p2 drive the entire vector foo (because
the index i is not static). The signal foo must be a resolved type.

C-2
Resolution Functions
Cycle simulation does not support composite resolution functions.
Sensitivity Lists
In most cases, cycle ignores the user-supplied process sensitivity list
(the same as synthesis).
Signal Initialization
Cycle simulators do not follow the LRM semantics for process
evaluation at simulation startup. Cycle simulators only execute the
combinatorial and testbench processes at time 0, whereas event
simulators execute all the processes (combinatorial and sequential)
at time 0. As with synthesis, do not depend on the LRM semantics
for the correct initialization of the design, especially in sequential logic
design.

C-3
C-4
Index
Symbols E
length attribute 2-16 expressions B-11
A F
after clause 2-4, 2-5 for loops 3-4
array index 3-4
assert statements 2-21
attributes B-9
G
gated clocks C-1
C
case statements 3-6
H
clock divider 2-8 help -ix
clock generation 2-5, 2-8
combinatorial logic 3-5 I
comment lines 2-16
IEEE.std_logic_textio package 2-18
if statements 3-6
D initialization, signal C-3
data generation 2-10
data types B-5 K
declarations B-7
keywords B-21
design units B-3
documentation, SolvNet -ix
IN-1
L SolvNet -ix
specifications B-8
latches
inference 3-6 statements
case 3-6
limits
VHDL values 1-7 concurrent B-16
if 3-6
incomplete 3-6
M sequential B-14
wait B-19
multiple clocks 2-6
STD.textio package 2-18
stimulus files 2-16
N subprograms 2-13, B-14
names B-8 synthesizable code 2-5
nonsynthesizable code 2-5
T
O templates
online documentation -ix definition 3-8
operands B-11 testbenches
policy B-18
operators B-10
TEXTIO file 2-16, 2-17
P U
predefined language environment B-17
user-defined procedures 2-18
printing messages 2-20
process drivers C-2
pullups and pulldowns 3-2 V
values, maximum and minimum in VHDL 1-7
R vectors
assignments 3-4
race conditions 2-10 for loops 3-4
reserved words B-21 VHDL
reset generation 2-6, 2-9 coding style
resolution functions C-3 effect on simulation speed 1-1
keywords B-21
language
S implementation limits 1-7
sensitivity lists 3-5, C-3 predefined language environment B-17
sequential logic 3-8 reserved words B-21
signal initialization C-3 virtual processes 2-14
IN-2
W
wait statements 2-3, 2-5, 2-8, 2-11
IN-3
IN-4

VHDLsim CMSG

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

VHDLsim CMSG

Transféré par

Droits d'auteur :

Formats disponibles

VHDL Simulation

Coding and Modeling

Destination Control Statement

Printed in the U.S.A.

Document Order Number: 36547-000SA

4. Memory Model Guidelines

Appendix A. Templates for Register Inference

Appendix B. Supported Language Constructs for VCS MX Cycle

Appendix C. Cycle Simulation and LRM Differences

This manual describes methods of coding VHDL designs for use by

Each section in this manual presents a number of rules and

This chapter includes the following sections:

This manual is intended for experienced VHDL designers. It is

For additional information about VCS MX, see Synopsys Online

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

Also, the Reuse Methodology Manual by M. Keating and P. Bricaud,

SolvNet is the Synopsys electronic knowledge base. It contains

or go to the Synopsys Web page at

and click SolvNet.

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

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

The following conventions are used in Synopsys documentation.

This example indicates that you can enter

VHDL coding style

This section provides general guidelines to produce maximum

VCS MX cycle automatically completes an incomplete sensitivity list

The subprograms in the standard libraries (Std., IEEE, and Synopsys)

For user-defined subprograms, the simulation overhead for each

It is more efficient to write the code as

condA is only evaluated when condB is false. Also, it is best in

This description executes two signal assignment statements in three

Item Value Range

Item Maximum Character Lengths

This chapter describes the testbench coding guidelines for the

General testbench guidelines

VCS MX automatically detects and identifies processes that are to

The presence of a behavioral wait statement indicates a cycle

A testbench process is shown in Example 2-1.

Example 2-1 Sample Testbench Process

The only statement that causes a delay to occur in cycle simulation

Example 2-2 Using Various Kinds of Behavioral wait Statements

--Process with explicit wait until edge statement

--Combination of wait on, until, and or statement

Clock Generation from the Testbench

Example 2-5 Using Separate Processes to Generate Multiple Clocks

Creating a clock from another clock usually causes a delta delay

Example 2-6 shows a process that generates a clock divider.

Example 2-6 Creating a Clock Divider

Example 2-8 Synchronizing Data with Inactive Clock Edge

Example 2-9 Synchronizing Data with Inactive Clock Edge

Figure 2-2 Separate Processes to Generate Data, Clock, and Reset

Separate Testbench Combo SEQ Combo Combo SEQ

Example 2-11 Using a Synchronous Testbench (Recommended Coding)

To avoid creating large virtual processes, follow these guidelines:

Use the pre-analyzed Synopsys supplied subprograms from

Example 2-13 Using Single Procedure Calls (Recommended Coding)

Another method is to create separate processes and use signals to

Saving response is done most efficiently by using the VCS MX trace

VCS MX supports the standard VCD output format in addition to the

Example 2-14 shows a method of skipping blank and comment lines

Example 2-15 Indexing a String (Recommended Coding)

Example 2-16 shows an alternate method of using TEXTIO. This

Example 2-16 Procedure to Read a Variable Length String