Professional Documents
Culture Documents
1990-95 Cadence Design Systems, Inc. All rights reserved. Table of Contents
Printed in the United States of America.
No part of this publication may be reproduced in whole or in part by any means (including photocopying or storage in an information Verilog-XL
storage/retrieval system) or transmitted in any form or by any means without prior written permission from Cadence Design Systems, Inc.
(Cadence).
Information in this document is subject to change without notice and does not represent a commitment on the part of Cadence. The information
contained herein is the proprietary and confidential information of Cadence or its licensors, and is supplied subject to, and may be used only Module 1 Getting Started
by Cadences customer in accordance with, a written agreement between Cadence and its customer. Except as may be explicitly set forth in
such agreement, Cadence does not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or
usefulness of the information contained in this document. Cadence does not warrant that use of such information will not infringe any third Course Objectives .................................................................................................................................... 1-4
party rights, nor does Cadence assume any liability for damages or costs of any kind that may result from use of such information. Course Map.............................................................................................................................................. 1-6
RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph Training Manual Conventions ............................................................................................................... 1-10
(c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013.
Cadence Design Systems, Inc. 555 River Oaks Parkway, San Jose, CA 95134, USA Getting Help........................................................................................................................................... 1-12
Unpublished rights reserved under the copyright laws of the United States. OpenBook Online Documentation Utility ....................................................................................... 1-14
In this manual the screen representation of Framework and any reference to it connotes Design Framework II software.
Other Trademarks
FrameMaker is a registered trademark of Frame Technology Corporation.
PostScript is a registered trademark of Adobe Systems.
UNIX is a registered trademark, licensed exclusively by X/Open Company Ltd.
X Window System is a trademark of the Massachusetts Institute of Technology.
Module 3 Sample Design Module 5 Verilog Data Types and Logic System
A Simple and Complete Example............................................................................................................ 3-4 4-Value Logic System in Verilog ............................................................................................................ 5-4
Device Under Test ................................................................................................................................... 3-6 The Three Unknown Logic Values.......................................................................................................... 5-6
Test Fixture Template .............................................................................................................................. 3-8 Major Data Type Classes ......................................................................................................................... 5-8
Test Fixture Making an Instance................................................................................................. 3-10 Nets ........................................................................................................................................................ 5-10
Test Fixture Describing Stimulus ............................................................................................... 3-12 Types of Nets ................................................................................................................................... 5-12
Activation Versus Execution of Procedural Blocks................................................................... 3-14 Logic Conflict Resolution with Net Data Types.............................................................................. 5-14
Test Fixture Response Generation .............................................................................................. 3-18 Registers................................................................................................................................................. 5-16
A Complete Test Fixture........................................................................................................................ 3-20 Types of Registers............................................................................................................................ 5-18
The cWaves Window............................................................................................................................. 3-22 Declaration Syntax of Verilog Nets and Registers ................................................................................ 5-20
Getting Started with cWaves ........................................................................................................... 3-24 Choosing the Correct Data Type............................................................................................................ 5-22
Node Specifiers for cWaves............................................................................................................. 3-26 Common Mistakes in Choosing Data Types ................................................................................... 5-24
Starting cWaves and Opening a Database ....................................................................................... 3-28 Parameters.............................................................................................................................................. 5-26
Saving the cWaves Environment ..................................................................................................... 3-30 Overriding the Values of Parameters............................................................................................... 5-28
Starting the Verilog-XL Software.......................................................................................................... 3-32 Defparam Statement................................................................................................................... 5-28
Lab 1 Getting Started ............................................................................................................................. 3-33 Module Instance Parameter Value Assignment......................................................................... 5-30
iv Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. v
Verilog-XL Table of Contents Table of Contents Verilog-XL
vi Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. vii
Verilog-XL Table of Contents Table of Contents Verilog-XL
Module 10 Interactive Debugging in Verilog Module 13 User-Defined Tasks and Functions in Verilog
Running in Batch Mode Versus Interactive Mode ................................................................................ 10-4 Verilog Tasks and Functions ................................................................................................................. 13-4
Verilog in the Interactive Mode............................................................................................................. 10-6 Specifications of a CPU Interface.......................................................................................................... 13-6
Entering the Interactive Mode ............................................................................................................... 10-8 Verilog Task........................................................................................................................................... 13-8
Typical Tasks in Interactive Mode ...................................................................................................... 10-10 Verilog Function .................................................................................................................................. 13-10
Setting Breakpoints........................................................................................................................ 10-10 Named Event........................................................................................................................................ 13-12
Traversing the Design Hierarchy ................................................................................................... 10-12 Named Blocks...................................................................................................................................... 13-14
Decompiling the Design ...................................................................................................................... 10-14 Disabling Named Blocks and Tasks .................................................................................................... 13-16
An Example of Traversing the Design................................................................................................. 10-16 Lab 8 Tasks and Functions in Verilog ................................................................................................. 13-17
Displaying Signal Values............................................................................................................... 10-18 Lab 9 Simulating a Complete System.................................................................................................. 13-17
Circuit Patching ............................................................................................................................. 10-20
$deposit .......................................................................................................................................... 10-22 Module 14 Modeling for Synergy
Tracing Simulation Activity .......................................................................................................... 10-24
Synthesis ................................................................................................................................................ 14-4
Source-Level Debugger in Verilog...................................................................................................... 10-26
Saving and Restarting Verilog Simulation .......................................................................................... 10-28 Modeling Style....................................................................................................................................... 14-6
Combinational Logic ............................................................................................................................. 14-8
Interactive Command History.............................................................................................................. 10-30
Procedural Blocks with Event Sensitivity List .................................................................................... 14-10
Lab 5 Behavioral Modeling and Interactive Debugging...................................................................... 10-31
Case Statement..................................................................................................................................... 14-12
Latched Logic ...................................................................................................................................... 14-14
Module 11 Modeling with Continuous Assignments
Simple Sequential Logic ...................................................................................................................... 14-16
Continuous Assignments ....................................................................................................................... 11-4 Asynchronous Reset............................................................................................................................. 14-18
Conditional Operator ............................................................................................................................. 11-6 Synchronous Reset............................................................................................................................... 14-20
Concatenation and Replication Operators ........................................................................................... 11-10 Explicit Style of Finite State Machines ............................................................................................... 14-22
Lab 6 Modeling with Continuous Assignments .................................................................................. 11-11 Implicit Style of Finite State Machines ............................................................................................... 14-24
An Example of an Implicit FSM.......................................................................................................... 14-26
Module 12 Modeling Memories Library Basics ...................................................................................................................................... 14-28
Overview........................................................................................................................................ 14-28
Memory Declaration .............................................................................................................................. 12-4
Modeling ........................................................................................................................................ 14-30
Memory Addressing............................................................................................................................... 12-6 Specify Blocks ............................................................................................................................... 14-32
Loading a Memory Array ...................................................................................................................... 12-8
File Format for $readmemb and $readmemh....................................................................................... 12-10
Modeling Bidirectional Ports............................................................................................................... 12-12
bufif Primitives .............................................................................................................................. 12-14
Continuous Assignments ............................................................................................................... 12-16
Lab 7 Modeling Memories................................................................................................................... 12-17
viii Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. ix
Verilog-XL Table of Contents Table of Contents Verilog-XL
x Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. xi
Verilog-XL Table of Contents
Index
Getting Started
Objectives
Review the course objectives.
Review the course schedule.
Understand the conventions followed in this book.
Learn about OpenBook, the Cadence online documentation utility.
Course Objectives
Course Objectives
These course objectives are mapped with the course schedule on the next page.
Course Map
Support for
Introduction
Verification
Day 1 Day 2
Sample Design Specify Blocks
Course Map
Course Map
Continuous Modeling
Assignments ASIC Libraries
Course Map
Your training manual contains the materials you will use during the lecture.
It contains a copy of every overhead transparency presented by the
instructor (on the top of the page) along with written information pertaining
to these overheads (on the bottom of the page).
Some self-explanatory overheads may not have any explanation in the
lecture portion below them.
There is plenty of space so you can add your own notes.
The Verilog-XL training manual contains an index.
The term select is used in the training manual to describe clicking on a menu
or an icon with the left mouse button.
Getting Help
You can get help with Cadence software from the following sources:
OpenBook
Customer Response Center (CRC)
You can call the Customer Response Center at 1-800-CADENC2
You can send email to crc_customers@cadence.com
The Verilog bulletin board talkverilog@cadence.com
Getting Help
Online Help
Cadence online reference manuals and online help files for each product are installed
automatically when you install the product. You can also order hard copies of the reference
manuals from Cadence. All these online documents are part of the OpenBook system. You
can access this material online in two ways.
You can quickly view relevant product information by clicking the help button on
windows and forms. The information helps you understand how to complete a form or
what you can do in the window.
You start OpenBook from a UNIX shell and search through all Cadence reference
manuals and online help systems installed with each product. You can also use
OpenBook to print the reference manuals.
Personal Contact
If you cannot find the necessary information using any of the above methods, you can
call the Customer Response Center at 1-800-CADENC2.
Talkverilog is an electronic bulletin board designed for Verilog users. Talkverilog is a
great way to share design tips and experiences with other Verilog users, and is
monitored by Verilog experts from Cadence. You can access talkverilog over the
Internet through the address talkverilog@cadence.com.
Objectives
Understand the basics of Hardware Description Language (HDL) and
simulators.
Understand design methodologies.
Understand the Verilog language and the Verilog-XL software.
Simulation Algorithms
Time Driven
Event Driven
Demand Driven
Simulation Algorithms
Time Driven
Each circuit element is evaluated at each time point, producing a new circuit state at
that point of time.
Inefficient, because at any time only 2 to 10 percent of elements in a circuit need to
be evaluated.
Event Driven
Changes in circuit state are recorded. Only those elements that might cause a change
in circuit state, during a given time, are simulated. The simulation propagates values
forward, through the circuit, in response to input pin events.
Most practical and widely used simulation algorithm.
Efficient, because it evaluates when necessary.
Demand Driven
Further refines evaluates when necessary.
Evaluates nets and gates only when their values are needed to provide simulation
output.
Propagates requests for simulation values, backwards through circuit and time.
t+1
Current Simulation
t+2 Time
Et
An event Et at time t
schedules another
event at time t+2 t+3
t+4
When the simulator compiles its data structures, it creates the initial queues
for the time wheel based on the HDL.
Time advances only when every event scheduled at that time is executed.
The time wheel can only go forward.
Architectural/Algorithmic
Register Transfer Logic (RTL)
Gate
Switch
Design Methodologies
Bottom-Up Design Flow
Design timing, performance,
4 and testability is analyzed.
REGISTER REGISTER
The complete design is
3 modeled and tested. ALU PC
STATE RAM
Design Methodologies
Top-Down Design Flow
Design Methodologies
Typical Design Flow
The top-level system is modeled
for functionality and performance
1 using a high-level behavioral inputs CPU outputs
description.
Synthesis Domain
Each major component is
modeled using library REGISTER REGISTER
3 components or ASICs and the ALU PC
design is re-simulated for timing, STATE RAM
functionality and performance.
Verilog HDL
Hardware description language that allows you to describe circuits at different
levels of abstraction and allows you to mix any level of abstraction in the design.
Verilog-XL Software
High speed, event-driven simulator that reads Verilog HDL and simulates the
description to emulate the behavior of real hardware.
Verilog HDL
Verilog HDL
Verilog HDL is a functional verification and simulation language for digital systems.
The Verilog language was released to the public domain in 1990 and is now controlled
by Open Verilog International (OVI).
It is very difficult to separate Verilog HDL from the Verilog-XL simulator, because
dynamically the language behaves the way the simulator works.
Ability to mix different levels of abstraction freely.
One language for all aspects of design, including test and verification of electronic
designs, therefore, only one language needs to be learned.
d q
DFF
clk
qb
clr
endmodule
REG4
d clk clr
module REG4(d,clk,clr,q,qb);
output [3:0] q, qb;
input [3:0] d;
d0 d3
input clk, clr;
DFF DFF
...
DFF d0 (d[0],clk,clr,q[0],qb[0]);
DFF d1 (d[1],clk,clr,q[1],qb[1]);
DFF d2 (d[2],clk,clr,q[2],qb[2]);
q qb DFF d3 (d[3],clk,clr,q[3],qb[3]);
endmodule
Related Products
Veritime is a timing analysis tool.
Verifault-XL is the fault simulator that uses Verilog HDL.
Synergy is the software that allows synthesis and optimization in a top-down
design process.
Related Products
Veritime is the timing analyzer.
Verifault-XL is the fault simulator that uses the Verilog HDL software.
Synergy is the software that allows synthesis and optimization in a top-down design
process.
Sample Design
Objectives
Introduce Verilog structural and behavioral constructs.
Illustrate Verilog in mixed-level simulation.
Test Fixture
// Port declarations
output out;
a input a,b,sel;
a1
sel sel_
// The netlist
out not (sel_, sel);
and (a1, a, sel_);
b b1
and (b1, b, sel);
or (out, a1, b1);
endmodule
// Instantiate modules
// Apply stimulus
// Display results
endmodule
module testfixture;
//MUX instance
MUX2_1 mux (out, a, b, sel);
//Apply stimulus
//Display results
endmodule
initial c always c
c c
c c
c c
c c
c c
c c
c c
initial c always c
c c
c c
c c
c c
c c
c c
c c
Conditions of Execution
All procedure blocks are activated at time 0, waiting to be executed based upon the user
specific conditions.
Procedural blocks are not triggered or executed until the enabling condition evaluates to
TRUE. In absence of the condition, the execution immediately follows the activation.
All procedural blocks execute concurrently, thus allowing you to model the inherent
concurrence in hardware.
For example:
$monitor($time,,out,,a,,b,,sel);
$monitor($time, %b %h %d %o, sig1, sig2, sig3, sig4);
cWaves
The cWaves Window
Status line
Pull-down
menus
Signal Waves
descriptor region
region
Fixed
menu
icons
Time
region
Example:
initial
begin
$shm_open("lab.shm");
$shm_probe();
#1 $stop;// Stop simulation at time 1
end
Node
Signals that Enter the Database
Specifier
none Inputs, outputs, and inouts of the named module instance or the current scope
"A" All nodes contained in the named module instance, or the current scope
(including the inputs, outputs and inouts)
"S" Inputs, outputs, and inouts of the named module instance or the current scope,
and of instantiations lower in the hierarchy than the named module instance,
except for library cells
"C" Inputs, outputs, and inouts of the named module instance or the current scope,
and of instantiations lower in the hierarchy than the named module instance,
including library cells
"AS" All the nodes in the named instance or the current scope (including the inputs,
outputs and inouts), and in all instantiations below it, except inside library
cells
"AC" All the nodes in the named instance or the current scope (including the inputs,
outputs and inouts) and in all instantiations below it, even inside library cells
6/29/95 Cadence Design Systems, Inc. 3-26
Sample Design 3-27
You start the Verilog-XL software by typing verilog on the command line, along with some
command line options and the names, of the files that you want to simulate.
Labs
endmodule
Strings
Strings are enclosed in double quotes and must be specified on one line.
Verilog recognizes normal C escape Characters (\t, \n, \\, \ and %%).
Strings are used frequently to generate formatted output from Verilog.
A new line using a carriage return can not be used in strings.
Strings
C escape characters
\t = tab
\n = newline
\\ = backslash
\ = quote mark ()
%% = % sign
Identifiers
Identifiers
Examples of legal identifiers
shift_reg_a
busa_index
_bus3
Examples of illegal identifiers
34net // Does not begin with an alphabetical character or _
a*b_net // Contains a non-alphanumeric character
n@238
Escaped Identifiers
Escaped identifiers start with backslash (\) and end with white space.
They can contain any printable ASCII character.
Backslash and the white space are not part of the identifier.
Escaped Identifiers
Case Sensitivity
Case Sensitivity
Verilog is a case-sensitive language. For example, identifiers that do not match in case
are considered unique.
All Verilog keywords are in lower case. For example, you type input, not INPUT.
You can run Verilog in the case-insensitive mode by specifying -u at the command line.
All identifiers are then converted to upper case, but the keywords remain in lower case.
$<identifier>
$ sign denotes Verilog system tasks and functions
A number of system tasks and functions are available to perform different
operations such as
Finding the current simulation time ($time)
Displaying/monitoring the values of the signals ($display, $monitor)
Stopping the simulation ($stop)
Finishing the simulation ($finish)
Note:For more information on system tasks and functions , see the module "Support for
Verification".
Every time signals a or b change value, this system task displays the values of the current
simulation time; signal a in binary format, and signal b in hexadecimal format.
The default base is decimal.
#<delay specification>
The pound sign (#) character denotes the delay specification for both gate
instances and procedural statements.
Compiler Directives
You indicate compiler directives with a grave accent ().
These directives cause the Verilog-XL compiler to take some special action.
Compiler directives remain active until overridden or deactivated.
Theresetall compiler directive resets all the compiler directives to their
default values (only if there is a default value).
`protect file1.v `protect file1.v
Active
regions
file2.v for protect `endprotect file3.v
`endprotect
file3.v file2.v
Verilog-XL Verilog-XL
Compiler Directives
You indicate compiler directives with a grave accent ().
These directives cause the Verilog-XL compiler to take special action.
Compiler directives remain active across source files.
A compiler directive is active from the point that it is encountered in the source stream
until it is deactivated or overridden by another compiler directive.
A good modeling practice is to have a resetall compiler directive before calling any
other compiler directives, because it resets all the compiler directives to their default
values (only if there is a default value).
Text Substitution
Thedefine compiler directive provides a simple text-substitution facility.
define <name> <macro_text>
<name> will substitute <macro_text> at compile time.
Typically used to make the description more readable.
define not_delay #1
Definition of not_delay
define and_delay #2
define or_delay #1
module MUX2_1 (out,a,b,sel);
output out; Use of not_delay
input a,b,sel;
not not_delay not1(sel_,sel);
and and_delay and1(a1,a,sel_);
and and_delay and2(b1,b,sel);
or or_delay or1(out,a1,b1);
endmodule
Text Substitution
+define+
The +define+ command line plus argument can be used to define macro
names as strings.
The option has the following syntax when it defines a macro name as a
string:
+define+<MACRO_NAME>="<MACRO_STRING>"
For example:
verilog +define+gate="or" test.v
module test;
define gate and
reg a,b;
gate (c,a,b);
initial
begin
a=0; b=1;
$monitor ($time,,c,a,b);
$finish;
end
endmodule
+define+
If you simulate the code in the above example with a command line that does not include
a +define+ option, the value of c fluctuates because the compiler directive defines
macro gate as an and gate. If you include the following +define+ option in the command
line, the value of c remains constant because the option defines gate as an or gate.
+define+gate="or"
When a command line +define+ option overrides a `define macro definition,
Verilog-XL displays a warning similar to this.
Warning! Text macro (gate) not-redefined, using value
from command line. (or) [Verilog-TMOVR]
"/net/ashley/home/def1.v", 2:
Note: The warning indicates that the option redefines the macro, regardless of the fact that the text in the warning
is inconclusive.
You can define a macro name to be a string of any length with the +define+ option.
There is no limit on the number of +define+ macros that you define.
Text Inclusion
Use the include compiler directive to insert the contents of an entire file.
include "global.v"
include "parts/count.v"
include "../../library/mux.v"
Use the +incdir command-line option to specify the search directories for
the file to be included.
+incdir+<directory1>+<directory2>+. . .<directoryN>
Text Inclusion
You can use theinclude compiler directive to insert the contents of an entire file.
include "<file_name>"
<file_name> is the name of the file that is to be included.
<file_name> can be a relative or full UNIX path.
Search directories, for the file_name to be included, can be specified using the +incdir
command-line option. Verilog will first look for the file in the current directory and then
it will search the directories in the order that they are listed on the command line with
the +incdir option.
You can nestinclude up to a maximum of eight levels.
You can useinclude to
include global or commonly used definitions which can be stored in a separate file.
Typically, the file containingdefine commands is included.
include tasks without encapsulating repeated code within module boundaries, so that
maintenance of the code becomes easier.
Timescale in Verilog
The timescale compiler directive declares the time unit and its precision.
timescale 1 ns / 100 ps
The timescale compiler directive cannot appear inside a module
boundary.
Simulation speed is greatly affected if there is a large difference between the
time units and precision.
timescale 1 ns / 10 ps
// All the time units are in multiples of 1 nanosecond
module MUX2_1 (out,a,b,sel);
output out;
input a,b,sel;
not #1 not1(sel_,sel);
and #2 and1(a1,a,sel_);
and #2 and2(b1,b,sel);
or #1 or1(out,a1,b1);
endmodule
Timescale in Verilog
The timescale compiler directive declares the time unit and its precision.
timescale <time_unit> / <time_precision>
<time_unit> specifies the units of measurement for delays and time.
<time_precision> tells Verilog how to round delay values before using them in
simulation.
The <time_precision> must be at least as precise as the <time_unit>.
The <time_precision> and <time_unit> both consist of an integer and a character string
representing the magnitude and the unit respectively. The valid integers are 1, 10, and
100. The valid unit strings are s(second), ms(milisecond), ns(nanosecond),
us(microsecond), ps(picosecond), and fs(femtosecond). Any combination of these is
allowed.
The simulation speed is greatly reduced if there is a large difference between the time
units and the precision because the timewheel advances by the multiples of the
precision. For example, if we have timescale 1s/1ps, then to advance 1 second, the
timewheel scans its queues 1012 times versus a timescale 1s/1ms where it needs to scan
these queues only 103 times.
The smallest precision of all the timescale directives determines the time unit of
the simulation.
timescale 1ns/10ps
module1 (. . .);
. . .
Simulation takes place
endmodule
in units of 100fs,
timescale 100ns/1ns that is, the timewheel
module2 (. . .); will advance in
. . . multiples of 100fs.
endmodule
timescale 1ps/100fs
module3 (. . .);
. . .
endmodule
buf
Zero, Low, False, Logic Low, Ground,
0 VSS, Negative Assertion
buf
One, High, True, Logic High, Power,
1 VDD, VCC, Positive Assertion
bufif1
HiZ, High Impedance, Tri-Stated,
Z Disabled Driver (Unknown)
0
a
a b s0 s1 out
s0
x x 0 0 z
out
0 x 1 0 0
x 0 0 x L (0 or z)
x 1 0 x H (1 or z)
b
0 1 1 1 x
s1
Nets
Registers
Parameters
Nets
a
a1
sel
out
b b1
Nets
Nets
Nets are continuously driven by the devices that drive them. In the example, net out is
driven by the or gate.
Verilog automatically propagates a new value onto a net when the drivers on the net
change value. This means that, whatever value is on the or gate, will be automatically
driven onto the net out.
Types of Nets
Various net types are available for modeling design-specific and
technology-specific functionality.
Net Types Functionality
wire, tri For standard interconnection wires
(default)
wor, trior For multiple drivers that are Wire-ORed
wand, triand For multiple drivers that are Wire-ANDed
trireg For nets with capacitive storage
tri1 For nets which pull up when not driven
tri0 For nets which pull down when not driven
supply1 For power rails
supply0 For ground rails
Nets that are not declared explicitly default to single bit nets of type wire.
This can be overridden by using the default_nettype <nettype> compiler
directive.
Types of Nets
Various net types are available for modeling design-specific and technology-specific
functionality.
Net types tri and wire are identical in functionality. You can use the different names to
enhance readability. For example, you can use tri for the nets that have multiple drivers.
Another reason to declare a net as a tri is to indicate that this net can be driven to a high
impedance state.
Nets that are explicitly not declared, default to a single-bit wire. You can override this
by using the default_nettype <nettype> compiler directive. With this directive, all the
nets not declared explicitly will default to the <nettype> in the compiler directive.
b b b
a 0 1 x z a 0 1 x z a 0 1 x z
0 0 x x 0 0 0 0 0 0 0 0 1 x 0
1 x 1 x 1 1 0 1 x 1 1 1 1 1 1
x x x x x x 0 x x x x x 1 x x
z 0 1 x z z 0 1 x z z 0 1 x z
y y y
Registers
a
reg_a a1
sel
reg_sel
out
reg_b b1
b
Registers
A register holds its value until a new value is assigned to it.
Registers are used extensively in behavioral modeling and in applying stimuli. In the
example above, reg_a, reg_b and reg_sel are used to apply stimuli to the 2:1
multiplexer.
Values are applied to registers from procedural blocks which are behavioral constructs.
Types of Registers
Register Functionality
Types
reg Unsigned integer variable of varying bit width
integer Signed integer variable, 32-bits wide. Arithmetic
operations produce 2s complement results.
real Signed floating-point variable, double precision
time Unsigned integer variable, 64-bits wide (Verilog-XL
stores simulation time as a 64-bit positive value.)
Register data types are not to be confused with structural storage elements.
Types of Registers
reg is the most common register type. You can declare it to be scalar or vector. A reg is
closely associated with hardware.
You typically use integer for manipulations of quantities that are not regarded as
hardware.
real has the same usage as integer, except that you use it for real numbers.
time stores and manipulates simulation time quantities.
Net Declaration
<nettype> <range>? <delay_spec>? <<net_name> <, net_name>*>
Register Declaration
<register_type> <range>? <<register_name> <, register_name>*>
Examples
reg a; // A scalar register
wand w; // A scalar net of type wand
reg [3:0] v; // A 4-bit vector register from msb to lsb
reg [7:0] m,n; // Two 8-bit registers
tri [15:0] busa; // A 16-bit tri-state bus
wire [0:31] w1, w2; // Two 32-bit wires with msb = 0
Register Declaration
<register_type> <range>? <<register_name> <, register_name>*>
<register_type> is the type of the register.
<range> is the vector range. It is allowed for reg only.
<register_name> is the register. You can declare more than one register in the same
declaration by using a list of names separated by commas.
Module Boundary
net
Inout Port
net
Listed here are common user errors, along with their typical error messages.
When a procedural assignment is made to a net or you forget to declare a
signal as a reg:
Illegal left-hand-side assignment
Signal connected to the output port is a register:
Gate has illegal output specification
Illegal output port specification
Signal connected to the input port is a register:
Incompatible declaration, (signal) defined as input
Parameters
module mod1(out,in1,in2);
. . .
parameter p1 = 8,
real_constant = 2.039,
x_word = 16bx,
file = /net/usr/design/mem_file.dat;
. . .
wire [p1:0] w1; // A wire declaration using parameter
. . .
endmodule
Parameters
Use parameters to declare run-time constants. They are not variables.
Typically, you use parameters to define delays and widths of variables.
You can use a parameter anywhere that you can use a literal.
Parameter definition syntax is
parameter <list_of_assignments>
where <list_of_assignments> is a comma-separated list of parameters and their values.
module p_values;
...
mod1 I1(out,in1,in2);
defparam
I1.p1 = 6,
I1.file = ../my_mem.dat;
...
endmodule
module mod1(out,in1,in2);
. . .
parameter p1 = 8,
real_constant = 2.039,
x_word = 16bx,
file = /net/usr/design/mem_file.dat;
. . .
endmodule
module top;
...
mod1 #(5, 3.0, 16bx, ../my_mem.dat) I1(out,in1,in2);
...
endmodule
Structural Modeling
Objectives
Learn how to use the Verilog primitives.
Building a hierarchical design.
Delays in Verilog primitives.
Using library cells in Verilog models.
Structural Modeling
Structural Modeling
A structural model is equivalent to a schematic. You connect simple components to
create a more complex component. In order to accomplish this, you use connectivity
constructs of the HDL.
When you use components to create another model, you create instances of these
components.
Verilog Primitives
Verilog Primitives
Verilog provides basic logical functions as predefined primitives therefore, the user does
not have to define this basic functionality.
Most of the ASIC libraries are developed using Verilog primitives and hence form an
integral part of the bottom-up design methodology.
Verilog-XL simulates the predefined primitives with XL algorithms; hence, their
simulation is very fast.
The number of pins for the primitive gate is defined by the number of nets
connected to it.
in1 out
and (out, in1, in2);
in2
in1 out
in2 and (out, in1, in2, in3);
in3
in1
in2 out
in3 and (out, in1, in2, in3, in4);
in4
The number of pins for the primitive gate is defined by the number of nets connected to
it. Thus, you do not need to redefine a new logical function whenever the number of
inputs or the outputs of a logical function change.
All gates except not and buf can have a variable number of inputs, but only a single
output.
The not and buf gates have variable number of outputs, but only one input.
Conditional Primitives
bufif1 bufif0
a out a out
e e
bufif1 (out, a, e) bufif0 (out, a, e)
Conditional Primitives
Primitive Instantiation
Primitive Instantiation
It is optional to specify an instance name for a primitive instantiation.
You can specify an optional delay to define the intrinsic delay of the primitive. In other
words, a signal will take the specified delay time before a change in input is reflected at
the output. Without the delay specification, the primitive operates at zero delay.
You must specify all the outputs of the primitive before inputs to the primitive.
Examples of primitive instantiation
and a1 (out, in[1], in[2]); // Bits of nets in port list.
or #2.0 (out, a, b); // Instance with no name but delay specified.
not (inv1, inv2, in_net); // Instance driving multiple outputs.
not (inv1[1], in_net[1]); // Single bit driving a single vector bit.
Module Instantiation
A module instantiation must have an instance name.
In position mapping port order follows the module declaration , but in named
mapping, it is independent of the position.
module test;
comp1 c1(out1,out2,in1,in2); // Positional Mapping
comp1 c2 (.i2(xx),.i1(yy),.o2(zz),.o1(tt)); // Named Mapping
comp1 c3 (Q,,J,K); // One port left unconnected
endmodule
Module Instantiation
A module instantiation must have an instance name.
Port order follows the module port declaration in position mapping.
Named mapping is independent of the position. You refer to the ports by their names and
specify the nets you want to connect the ports to. The syntax is
.actual_port_name(net_connected_to_port)
You can leave a port unconnected in a module instantiation, but it results in a warning
from Verilog.
Delay specification defines the intrinsic delay through the primitive gate.
Verilog allows (rise, fall, turn-off) delays to be specified on primitives.
These delays can be specified as (minimum : typical: maximum) delays.
By default, Verilog primitives use typical delay values and the inertial delay
algorithm.
While simulating, Verilog uses only one of these delays, which is specified
by the following command line options:
weak1, strong0
Logic Unknown
module and2(...);
...
endmodule
module mux(...);
...
endmodule
module dff(...);
...
endmodule
The `uselib compiler directive specifies where Verilog-XL searches for the
definitions of modules and UDPs instantiated in a design description that
does not include those definitions.
Each `uselib directive explicitly defines the library search that resolves the
instances that follow it until the compiler encounters another `uselib
directive or a `resetall.
If the design description includes no `uselib compiler directives, the compiler
looks to the command line for the options to configure the library search.
The syntax for `uselib is:
<uselib_compiler_directive>::= `uselib <library_reference>*
Use the +define+ command line option and the define compiler directive to
define the paths with which the uselib compiler directive configures the
search.
uselib TTL_LIB
SN7400 U1 (clear,in[0],int_clear);
SN7404 U2 (clear_bar,clear);
uselib TTL_LIB TTL_UDP
SN7474 U3 (slave, ,data0,set_bar,clear_bar);
uselib FAST_LIB
SN7400 U4 (out[3],data0,data1);
endmodule
resetall
Labs
Lab 2 Structural Modeling
Modeling an 8-bit Register with Design Hierarchy Using Library
Components
All the system tasks are called from the procedural blocks or interactive mode.
Note: For more information on interactive mode, see the module "Interactive Debugging in Verilog".
The $time, $realtime, and $stime functions return the current simulation
time.
Each of these functions returns a value that is scaled to the time unit of the
module that invoked it.
$time returns time as a 64-bit integer.
$stime returns time as a 32-bit integer.
$realtime returns time as a real number.
You can use the $timeformat system task and the %t formatter to globally control
how time values are displayed.
$timeformat(<unit>,<precision>,<suffix>,<min_width>)
$display prints out the current values of the signals in the argument list.
$display automatically prints a new line.
$display supports different bases.
$write is identical to $display except that it does not print a new line
character.
$write($time, %b \t %h \t %d \t %o \n, sig1, sig2, sig3,
sig4);
$write($time, %b \t, sig1, %h \t, sig2, %d \t, sig3, %o
\n, sig4);
$write
$write displays the values of the argument list when it is encountered in the source
description but does not print a new line character automatically as $display does.
$write supports different bases.
$writeb
$writeo
$writeh
$strobe
$strobe delays the argument evaluation just prior to the advance of the simulation time.
As a result of the $strobe, steady state values of the signals are obtained; this is different
from $display and $write, which can print the intermediate value of the signal.
$strobe supports different bases.
$strobeb
$strobeo
$strobeh
12/7/95 Cadence Design Systems, Inc. 7-14
Support for Verification 7-15
$monitor displays the values of the argument list whenever any of the
arguments change.
Any subsequent $monitor overrides the previous call to $monitor.
Continuous monitoring can be controlled by $monitoron and $monitoroff
system tasks.
$monitor supports different default bases.
$monitor($time, %b \t %h \t %d \t %o, sig1, sig2, sig3,
sig4);
$monitor($time, %b \t, sig1, %h \t, sig2, %d \t, sig3,
%o, sig4);
$fopen("<name_of_file>")
$fclose(<multichannel_descriptor>);
. . .
integer messages,broadcast,cpu_chann,alu_chann;
initial
begin
cpu_chann = $fopen("cpu.dat"); if(cpu_chann == 0) $finish;
alu_chann = $fopen("alu.dat"); if(alu_chann == 0) $finish;
messages = cpu_chann | alu_chann;
// includes standard output and verilog.log
broadcast = 1 | messages;
end
// at every positive edge of clock print the following line to alu.dat
always @(posedge clock)
$fdisplay(alu_chann, "acc= %h f=%h a=%h b=%h",acc,f,a,b);
Specify Blocks
Objectives
Specify path delays.
Specify timing checks for a module.
A specify block defines the timing section of the module in a separate block.
Typical tasks you perform inside a specify block
Describe various paths across the module and assign delays to those
paths.
Describe timing checks.
A specify block is bounded by the keywords specify and endspecify.
Parameters are declared using the specparam keyword in a specify block.
2
Distribute the delay
across each gate 3
Use a specify block
to specify pin-to-pin
delays for each path.
specify
(A => O) = 2;
(B => O) = 3;
(C => O) = 1;
endspecify
endmodule
(r *> o1, o2) = (1, 2); // Rise and Fall delay for r to o1 and o2.
// Delay specified for all the paths for each vector of a and o.
(a[7:0] *> o[7:0]) = 6.3;
(a, b *> q, qb) = 12:15:18; *> signifies full connections. All the
inputs connect to all the outputs.
is equivalent to
(a => q) = 12:15:18;
=> signifies parallel connection and
(b => q) = 12:15:18;
can be between two scalar or two
(a => qb) = 12:15:18; vectors of same size.
(b => qb) = 12:15:18;
Example
(C => Q) = (5, 12, 17, 10, 6, 22);
specify
specparam ao = 2,
bo = 3, co = 1;
(A => O) = ao;
(B => O) = bo;
(C => O) = co;
endspecify
endmodule
Path destinations can have only one driver inside the module.
Verilog Error Message
Error! Multiple path delays defined to node <path_destination>;
Path delay outputs must have only one driver within the module
[Verilog-PDOMOD]
All the destinations of a module path must be acceleratable. Verilog issues an error
message if the destination is not a Verilog primitive or if it is driven by behavioral
Verilog code.
Path destinations can have only one driver inside the module. When wired logic is the
path destination, Verilog issues an error message because you have more than one
driver.
You can remove these errors by buffering the output. Insert the buf primitive between
the destination of the module path and the driver.
in out
delay=2
specify
(clk => q) = 12;
(data => q) = 10;
(clr, pre *> q) = 4;
specparam
PATHPULSE$ = 3;
PATHPULSE$clk$q = ( 2, 9 ) ;
PATHPULSE$clr$q = 1 ;
endspecify
$setup reports a violation if the period that elapsed from a change in data to
posedge clk is less than 20.
$setup(data, posedge clk, 20, notifier);
$hold reports a violation if the period that elapsed from posedge clk to
change in data is smaller than 11.
$hold(posedge clk, data, 11, notifier);
$setuphold is the combination of the $setup and $hold timing checks. This
statement sets up a setup check of 20 and a hold check of 11.
$setuphold(posedge clk, data, 20, 11, notifier);
20 11
clk
data
notifier is a Verilog register that toggles its value every time a violation is reported. It
is an optional argument.
threshold is an optional argument that filters out spikes and glitches.
Labs
Lab 3 Modeling with Path Delays and Timing Checks
Modeling a D Flip-Flop with Path Delays and Timing Checks
Behavioral Modeling
Objectives
Learn the basics of behavioral modeling.
Learn the operators available in Verilog.
Learn the high-level programming language constructs available in Verilog.
Behavioral Modeling
DFF
Clr
At every positive edge of Clk
If Clr is not low
Data Q Set Q to the value of Data
Set Qb to inverse of Data
DFF
Qb
V
Behavioral Modeling
Behavioral modeling enables you to describe the system at a high-level of abstraction.
At this level of abstraction, implementation is not as important as the high-level
description of a functional block or the system.
Behavioral modeling in Verilog is described by specifying a set of concurrently active
procedural blocks in a high-level programming language that together describe the
operation of the system.
High-level programming language constructs are available in Verilog for behavioral
modeling. Some of these are
Assignment Statements
Looping Statements
Conditional Statements
Procedural Blocks
initial c always c
c c
c c
c c
c c
c c
c c
c c
Procedural Blocks
Procedural blocks are the basis for behavioral modeling.
Procedural blocks are of two types
initial procedural blocks, which execute only once.
always procedural blocks, which execute in a loop.
Procedural blocks have the following components
Procedural assignment statements to describe the data flow within the block.
Timing controls to control the triggering of the block and the execution of the
statements in the block.
High-level programming language constructs that describe the functional operation
of the block.
Simple Delay
#10 rega = regb;
#(cycle/2) clk = ~clk; // cycle is declared as a parameter
0 10 30 50 70 90 110
clk
set
15 48 70
q
33 43 93 103
Procedural Assignment
Procedural Assignment
Given:
a = 1011
b = 0010
a | b = 1011 |a=1 a || b = 1
a & b = 0010 &a=0 a && b = 1
Equality Operators
= is the assignment operator. It copies the value of the RHS of the
expression to the LHS.
== is the equality operator.
== 0 1 x z a = 2b1x;
b = 2b1x;
0 1 0 x x
if (a == b)
1 0 1 x x $display(a is equal to b);
else
x x x x x $display(a is not equal to b);
z x x x x
Equality Operators
= is the assignment operator. It copies the value of the RHS of the expression to the LHS.
== is the equality operator.
It returns 1 or true if the bits that you are comparing are known, that is, if they are 0
or 1 and are equal.
It returns 0 or false if bits being compared are known and are not equal.
It returns x or unknown if one or both of the bits that you are comparing are unknown,
such as x or z.
=== is the identity operator.
It returns 1 or true if the bits that you are comparing are the same, including x and z.
It returns 0 or false if the bits that you are comparing are known and are not equal.
!= is the inequality operator and works the same way as the == operator.
!== is the inverse of the === operator and it works the same way.
Block Statements
Block Statements
Block statements are used to group two or more statements together so that they act as
one statement, syntactically.
Sequential block statements are enclosed between the keywords begin and end. The
statements in this block are executed in a sequential manner.
Parallel block statements are enclosed between the keywords fork and join. The
statements in this block are executed concurrently.
Intra-assignment timing controls delay the assignment to the left-hand side but do not delay
the evaluation of the right-hand side.
Syntax
<intra-assignment_timing>
::=left-hand side = <delay_control> right-hand side;
::=left-hand side = <event_control> right-hand side;
This can be used to concisely model register swaps and shifts.
Conditional Statements
If and If-Else Statements
initial
if (index > 0) // Beginning of Outer if
if (rega > regb) // Beginning of the 1st inner if
result = rega;
else
result = 0; // End of the 1st inner if
else
if (index == 0)
$display(Note : Index is zero);
else
$display(Note : Index is negative);
Conditional Statements
If and If-Else Statements
The case statement is a special multiway conditional statement that tests whether the
expression matches one of a number of other expressions and branches accordingly.
The case statement does a bit-by-bit comparison for an exact match.
The default statement is optional. It is executed when none of the statements match the
case expression. If, however, it is not specified, no action is taken by Verilog.
Use of multiple default statements is illegal.
It is a good programming practice to always use the default statement, especially to check for
X and Z.
The casez and casex are two other types of case statements are provided to allow handling of
dont-care conditions in the comparisons. Dont care values (z values for casez, z and x values
for casex), in any bit of either the case expression or the case items, are treated as dont-care
conditions during the comparison, and that bit position is not considered. The question mark
(?) is used to specify dont-care bits in a casez or casex statement.
Looping Statements
Repeat Loop
module multiplier(result, op_a, op_b);
parameter size=8;
input [size:1] op_a,op_b;
output [2*size:1] result;
reg [2*size:1] shift_opa,result;
reg [size:1] shift_opb;
always @(op_a or op_b)
begin
result = 0;
shift_opa = op_a; // zero extend left
shift_opb = op_b;
repeat (size)
begin
#10 if (shift_opb[1]) result = result + shift_opa;
shift_opa = shift_opa << 1; // logical left shift
shift_opb = shift_opb >> 1; // logical right shift
end
end
endmodule
Looping Statements
Repeat Loop
A repeat loop executes a block of statements a fixed number of times.
The code above implements a shift and add multiplier.
...
reg [7:0] tempreg
....
....
while (tempreg)
begin
if (tempreg[0]) count = count + 1;
tempreg = tempreg >> 1; // Right Shift
end
endmodule
A while loop executes a statement (or block of statements) as long as its expression is
true (or nonzero).
If the expression starts out false, the statements are not executed.
endmodule
Simulation advances when all the events in the event queue finish. In a zero-delay loop, events
keep getting added at the same time slot. Due to this, the simulation gets stuck at that time slot.
In the overhead example, simulation events are occurring but simulation time does not
advance. This typically happens when there is an always loop with no timing controls.
Verilog HDL designs can include VHDL models that Cadences VHDL
simulator (Leapfrog) simulates.
You can link a slave Leapfrog simulator to the Verilog-XL executable. The
slave simulator will simulate the VHDL models that are incorporated into a
Verilog design by using a special definition.
Labs
Lab 4 Behavioral Modeling
Modeling a 5-bit Counter
In batch mode, all the results are analyzed at the end of simulation run.
In interactive mode, the simulation is analyzed as the simulation
progresses.
C1 > $showscopes;
Directory of scopes at current scope level:
module (adder), instance (u1)
module (latch), instance (u2)
// counter_test.v
7 module counter_test;
8 reg [4:0]
8 data; // = 5h1d, 29
9 reg
9 rst, // = 1h1, 1
9 load, // = 1h0, 0 Current states of
9 clk; // = 1h1, 1 declared variables
10 wire [4:0]
10 cnt; // = 5h2, 2
14 counter
14 c1(cnt, clk, data, rst, load);
17 always The asterisk * specifies a
17* #10 currently active procedural
17 clk = ~clk; statement
A
B C
D E F G
$list; $list(D);
C1 > $showvars(o1);
o1 (top) wire = StX, schedule = StX
HiZ <- (top.m1): bufif1 g3(o1, i3, c3);
schedule = St1
St1 <- (top.m1): bufif1 g2(o1, i2, c2);
St0 <- (top.m1): bufif1 g1(o1, i1, c1);
C2 >
Circuit Patching
force and release can be used to interactively patch the design.
These commands allows the drivers on nets or statements to be overridden
for a controlled period of time.
The $list_forces system task lists the currently active force statements.
Note:More system tasks used for source-level debugging are described in the Verilog-XL
Reference Manual.
Verilog has the ability to save the simulation data structure into a permanent file
and restart the simulation from the time of save.
module checkpoint;
initial
// Save the simulation data structures after 500 ns.
#500 $save(save.dat);
// Incrementally save the simulation after every 100000 ns
initial
begin
#100000 $incsave(inc1.dat);
#100000 $incsave(inc2.dat);
#100000 $incsave(inc3.dat);
#100000 $incsave(inc4.dat);
end
endmodule
Command history:
C1* forever
@(posedge clk)
Active commands
$stop;
C2 $list;
C3 $display(clear);
C4* $history;
Labs
Lab 5 Behavioral Modeling and Interactive Debugging
Modeling an Arithmetic Logic Unit (ALU)
Continuous Assignments
wire eq;
assign eq = (a == b);
Continuous Assignments
Continuous assignments drive values onto a net.
Any changes in the RHS of the continuous assignment are evaluated and the LHS is
updated with the new value.
You can model combinational logic with continuous assignments without using gates
and interconnect nets.
Continuous assignments drive a net that has been previously declared. It is an error if the
net is not declared.
Strength specification for a net in a continuous assignment
wire (strong1,weak0) [7:0] net1 = net2 & net3;
Delay specified for the continuous assignment
tri #10 xor_net = a^b;
Multiple assignments in one declaration
wire and_net = a1&a2,
or_net = a1|a2;
Concatenation at LHS
assign {carry_out, sum} = ina + inb + carry_in;
Multiple continuous assignments with delay of 5
assign #5 c = a[0], d = {r1, r2, r3}, f[3:2] = {r3, r4};
6/29/95 Cadence Design Systems, Inc. 11-4
Modeling with Continuous Assignments 11-5
Conditional Operator
in out
enable
Conditional Operator
The conditional operator is similar to the case statement. The value assigned to the LHS
is the one that results true from the expression evaluation.
The default is specified to ensure proper behavior for any case that is not enumerated. In the
overhead example, it would be when one of the bits of sel is unknown.
Byte Swap
wire [15:0] new_word = {word[7:0], word[15:8]};
Sign Extension
word = {{8{byte[7]}}, byte};
Labs
Lab 6 Modeling with Continuous Assignments
Modeling a Scalable Multiplexer.
Modeling Memories
Objectives
Learn how to model memories with Verilog HDL.
Memory Declaration
Memory Declaration
In Verilog syntax, you declare a memory as an array of registers.
where
<msb> and <lsb> determine the word size of the memory
<memory_name> is the name of the memory array
<first_addr> and <last_addr> determine the depth of the memory
You can declare word size and the memory depth with any legal expression.
Memory Addressing
. . .
reg [8:1] mema [0:255];// declare memory called mema
reg [8:1] mem_word;// temp register called mem_word
. . .
// Display contents of the 6th memory address
$displayb(mema[5]);
. . .
// Display the msb of the 6th memory word
mem_word = mema[5];
$displayb(mem_word[8]);
. . .
Memory Addressing
A memory element is addressed by giving the location as the address to a previously
defined memory array.
You can address a bit, or a part of a memory word. To do so, store the memory location
addressed in a temporary register of the correct width and then the bits can be accessed.
$readmem<base>(<filename>,<mem_name>,<start>?,<finish>?);
$readmemb(mem_file.txt, mem);
rd_wr_
io_port Module
Logic
data
Labs
Lab 7 Modeling Memories
Modeling a RAM with a Bidirectional Data Bus
Both functions and tasks let you execute common procedures from different
places in a description.
They help to simplify the complex behavior of the design.
You typically use a function in Verilog to create a new operation.
A task describes a separate piece of hardware.
A task can contain delays while a function cannot.
A function has only input parameters and it returns a single value.
A task can have input, output, and inout parameters.
Verilog Task
. . .
always @(sys_clk)
begin
if (read_request == 1)
begin
read_mem(IR, PC);
// Event and Function calls
end
end
task read_mem;
output [15:0] data_in;
input [15:0] addr;
@(posedge read_grant)
begin
ADDRESS = addr;
#15 data_in = data;
end
endtask
. . .
Verilog Task
Key Features:
Task is enabled when the task name is encountered in the Verilog description.
Task definition is contained in the module definition.
The arguments passed to the task are in the same order as the task I/O declarations.
You can use timing controls freely in the statement.
Tasks define a new scope in Verilog.
Verilog Function
always @(sys_clk)
begin
. . .
IR = swap_bits(IR);
. . .
end
function [16:1] swap_bits;
input [16:1] in_vec;
reg [15:0] temp_reg;
integer i;
begin
for (i = 16; i >= 1; i = i-1)
temp_reg[16 -i] = in_vec[i];
swap_bits = temp_reg;
end
endfunction
. . .
Verilog Function
Key Features:
A function definition cannot contain any timing-control statements.
It must contain at least one input and does not contain any output or inout port.
A function returns only one value, which is the value of the function itself. Therefore,
parameters cannot be declared as output or inout.
The arguments passed to the function are in the same order as the function input
parameter declarations.
The function definition must be contained within the module definition.
A function cannot enable a task. However, a task can enable a function.
Functions define a new scope in Verilog.
Named Event
event read_complete;
. . .
always @(sys_clk)
begin
if (read_request == 1)
begin
// Task and Function calls
->read_complete;
end
end
always @(read_complete)
begin
read_request = 1b0;
ADDRESS = 16bz;
$display(Data Received, Read is Complete);
end
. . .
Named Event
A Named event is a data type that you trigger in a procedural block to enable actions.
You must declare a named event before you can reference it.
Named events have no duration and carry no value.
You can only make an event occur from a procedure.
The -> operator is the trigger for the named event.
Named Blocks
Named Blocks
You can name a block by adding : <name_of_block> after the keywords begin or fork.
You can declare local variables in the named block.
You can disable a named block.
Named blocks define a new scope in Verilog.
Labs
Synthesis
Top-Down Design
Requirements
Analysis Begin Top-Down design
at the highest level of
System abstraction and finish at
Partitioning the lowest level.
Behavioral / Functional
Specification
Behavioral / Functional
Verification
Synthesis and
Optimization
Gate Level
Verification
Synthesis
Modeling Style
Modeling Style
There will always be a modeling style policy for synthesis tools.
You can write Verilog descriptions for which there are no hardware representations
in the digital domain.
Synthesis results are sensitive to the input description.
Goals of the modeling style:
Efficient for simulation
Synthesizable with predictable results
Helps you describe more efficient hardware
Two basic rules for writing Verilog descriptions that are synthesizable:
Gate-level simulation should match functional-level simulation. (You can verify
functionality at the RTL level).
Sequential designs should work independently of technology-specific propagation
delays.
Combinational Logic
A
B
E OUT
module orand(OUT,A,B,C,D,E); C
input A,B,C,D,E; D
output OUT;
or (or1,A,B);
or (or2,C,D); A netlist structure of combinational
and (OUT,or1,or2,E); primitives with no feedback
endmodule loops
module orand(OUT,A,B,C,D,E);
input A,B,C,D,E;
output OUT;
assign OUT = E &(A|B)&(C|D); A continuous assignment
statement with no feedback
endmodule loop
Combinational Logic
For logic to be combinational, the output must have only one possible value for any
combination of input values. There must be no timing or order dependencies.
If your description meets this definition, it can be synthesized as combinational logic.
There are three modeling styles that meet these requirements:
A netlist structure of combinational primitives with no feedback loops.
A continuous assignment statement with no feedback loops.
A procedural block with an event sensitivity list, which has no assignments to nodes
on the sensitivity list.
reg OUT;
always @(A or B or C or D or E) Complete Sensitivity List
if (E)
OUT = (A|B)&(C|D);
else
OUT = 0;
reg OUT;
always @(E)
if (E)
assign OUT = (A|B)&(C|D); Dynamic Sensitivity List
else
assign OUT = 0;
Case Statement
module mux(A,B,C,D,OUT,SEL);
input [3:0] A,B,C,D; A
4
output[3:0] OUT; B 4
OUT
input [1:0] SEL; C
reg [3:0] OUT; D
... 2
always @(SEL or A or B or C or D)
SEL
case(SEL)
2b00:OUT = A;
2b01:OUT = B; Case Statement
2b10:OUT = C;
2b11:OUT = D;
default: OUT = 4bx;
endcase
endmodule
Case Statement
Latched Logic
module latch (OUT, IN, ENABLE);
input [7:0] IN; 8
in D
output [7:0] OUT;
8
input ENABLE; out
en G
reg [7:0] OUT;
always @(ENABLE)
if(ENABLE)
assign OUT = IN; Using the assign/deassign
else statements
deassign OUT;
endmodule
Latched Logic
Latched logic is implied when there are storage devices independent from a clock;
latches are modeled in a style similar to the procedural style for combinational logic.
Storage is implied when there is a branch in a procedural block in which the data signal
is not assigned.
In the first example, there is no else clause, so a latch is created to hold the value of
OUT when ENABLE is deasserted.
In the second example, OUT is disconnected from IN when ENABLE is deasserted, so
it holds the last value of IN, which requires a latch. This is more efficient for simulation.
input[1:0] SEL;
input CLK;
reg [3:0] OUT;
...
Edge-sensitive
always @(posedge CLK)
Event Control
case(SEL)
2b00: OUT = A;
2b01: OUT = B;
2b10: OUT = C;
4
2b11: OUT = D; A
B 4
default: OUT = 4bx; C
D
4
endcase D >
OUT
2
endmodule SEL CLK
Asynchronous Reset
module mux_dffrs
(Q,A,B,SEL,CLK,RES,SET); 2
output [1:0] Q; A 2 D S
input [1:0] A,B; B
> R_ Q[1]
input SEL,CLK,RES,SET;
reg [1:0] Q; SEL
D S
always @(posedge CLK) > R_ Q[0]
if (SEL)
Q = A; CLK
SET
else RES
Q = B;
always @(posedge CLK or posedge RES
always @(RES or SET) or posedge SET)
case({RES,SET}) if (RES)
2b10: assign Q = 2b00; Q = 2b00;
2b01: assign Q = 2b11; else if (SET)
default: deassign Q; Q = 2b11;
endcase else
if (SEL)
endmodule Q = A;
else
A separate block is used to Q = B;
describe the asynchronous
reset.
Asynchronous Reset
You can model reset for any type of storage device, edge or level sensitive.
Asynchronous reset can be modeled in a separate, combinational block with the
assign/deassign statements.
A separate reset block is usually more efficient for simulation.
Asynchronous reset can be modeled in a single block with asynchronous and
synchronous branches.
There must be exactly one synchronous branch in the conditional statement. A branch
with no condition is considered synchronous.
Synchronous Reset
module mux_dffrs (Q,A,B,SEL,CLK,RES,SET);
output [1:0] Q;
input [1:0] A,B;
Reset and Set branches
input SEL,CLK,RES,SET;
reg [1:0] Q;
SEL
B[1:0]
RES
Synchronous Reset
Check the status of the reset signal at every clock edge.
If your target library does not contain a storage device with synchronous reset, the reset
is implemented in the data path.
endmodule
Library Basics
Overview
Synergy library is based on the Verilog Simulation Library.
All library cell descriptions must conform to the Synergy HDL Synthesizer
and Optimizer Modeling Style Guide.
Constructs you can use to model Synergy libraries are:
Verilog primitives
Continuous assignments
UDPs
Procedural blocks
All library cell descriptions must be delimited by celldefine and
endcelldefine.
A Library must contain at least one time scale directive.
Library Basics
Overview
For consistency purposes, you should separate all additions to the existing models that
are synthesis specific (including specparams), using the conditional compilation
constructs (`ifdef, etc.) with the symbol SYNTH.
Note: For more information, refer to the Synergy Library Development Guide.
UDPs
You can use UDPs to augment the set of predefined primitive elements.
UDPs can represent sequential as well as combinational elements.
The behavior is described in a truth table.
A UDP can replace 10 to 20 built-in primitives.
UDPs
UDPs permit the user to augment the set of predefined primitive elements, for example,
they can be accelerated with the XL algorithm.
UDPs can represent sequential as well as combinational elements.
Their behavior is described in a truth table (which takes less time to evaluate than two
built-in accelerated primitives).
A UDP can replace 10 to 20 built-in primitives. Thus, the simulation time and the
memory requirements can be reduced significantly, especially if there are a number of
instances of that module.
UDP Features
UDP Features
UDPs can have only one output. Thus if the functionality requires more than one output,
then the additional primitives need to be connected to the output of the UDP or several
UDPs can be used together.
UDPs can have 1 to 10 inputs. However, the memory requirements increase
dramatically as the number of inputs increase from 5. The table below shows the
memory requirement per definition for the number of inputs.
# inputs Memory (k bytes)
1-5 <1
6 5
7 17
8 56
9 187
10 623
UDP Examples
Combinational UDP: 2-1 Multiplexer
? in the table represents iteration over 0, 1 or x logic values.
The first two entries say that if s = 1 then, irrespective of the value of the input b, the
value on the output o, will be same as that of input a.
The next two entries say that if s = 0 then, irrespective of the value of the input a, the
value on the output o, will be same as that of input b.
The last two entries are put in to reduce pessimism. We say that if both the inputs, a and
b, have the same logic value, then even if sel = x, the output o will have the same value
as inputs a or b. This behavior cannot be modeled using Verilog built-in primitives.
Cin Cin
A U_ADDR2_S Sum
A G2 Sum
B G1 B
G4 G5 Cout
U_ADDR2_C
G3 Cout
UDP Examples
Combinational UDP: Full Adder
The full adder can be implemented using only two combinational UDPs instead of five
Verilog defined primitives.
For a large number of instantiations of the full adder, the memory requirements will be
greatly reduced since the full adder now consists of only two primitives (versus five in
the original design).
UDP Examples
UDP Examples
Edge-Sensitive Sequential UDP: D Flip Flop
The table has edge terms representing transitions on inputs.
At most, one input transition may be specified in any table entry statement.
All input transitions must be specified if any are specified.
Delay Modeling
Delay Modeling
The default module path delay algorithm in Verilog-XL uses an efficient method for
choosing delays. It selects path delays without considering circuit logic. It is possible for
the delay that the default algorithm chooses for a transition to be a delay specified for a
path that could not have caused the transition. State-dependent path delays can help in
resolving this type of problem.
The path delays through the cells can be dependent on the state of the cell inputs.
This behavior is modeled using SDPDs by the conditional-expression clause of the
path-delay statement.
All possible input states must be accounted. Otherwise that state is simulated with
distributed delays, if found, or with zero delays.
Multiple states may be combined in a conditional expression.
Delays of X Transitions
Transitions between 0, 1, and Z can be explicitly defined.
Delays involving X transitions are derived from other delays.
The calculation for delay values for X transitions is based on the following
pessimistic rules:
Transitions from a known state to an unknown state should occur as
quickly as possible.
Transitions from a unknown state to a known state should take as long
as possible.
(<inputs> => <outputs>)=(< 0->1 >,< 1->0 >,< 0->Z >,< Z->1 >,< 1->Z >, < Z->0 >);
(C => Q) = (5, 12, 17, 10, 6, 22);
0 -> x = min(5, 17) = 5
1 -> x = min(12, 6) = 6
z -> x = min(10, 22) = 10
x -> 0 = max(12, 22) = 22
x -> 1 = max(5, 10) = 10
x -> z = max(17, 6) = 17
Delays of X Transitions
Labs
Delay Calculation The process of calculating the delays for each component based
on the loading, drive strength, etc.
Delay The process of placing the delays calculated from an external
Backannotation source into the Verilog data structures.
Programming Programming Language Interface or PLI provides procedural
Language Interface access to the Verilog data structures.
Central Delay Central Delay Calculator or CDC is a common delay calculator
Calculator that is used by all the tools in the design flow.
Timing Driven Complete front-to-back design flow where timing information
Design forms the glue between different stages.
SDF Standard Delay Format
RSPF Reduced Standard Parasitic File
MIPD Module Input Port Delay
SITD Single-Source Interconnect Transport Delay
MITD Multi-Source Interconnect Transport Delay
PLI based
Custom delay calculators
ASIC vendor supplied
Central delay calculator
Design Composition
SDF Annotator
Simulation
SDF User
Synthesis Delays Equation
SDF
Constraints
Simulation Connectivity
Information
CDC
Timing Analysis
RSPF
File
SDF Floor Planner
Constraints
RSPF
File
Place & Route
VerilogDomain
For a typical timing-driven top-down design methodology, the delay calculation is done
by
Reading connectivity information of the gate-level netlist.
Using the reduced parasitic information from the floor planner.
Using the reduced parasitic information from the place and route tool.
The Verilog domain in the timing-driven top-down design methodology is marked by
the shaded region.
The Central Delay Calculator (CDC) ensures consistency between the front-end and
back-end tools since the common delay calculation algorithm is used for all tools.
Maintenance is easier since only one delay calculator needs to be maintained versus four
if a different delay calculator was being used for each tool (simulation, synthesis, timing,
P&R).
The timing information can be freely used by any tool since it is placed in a Standard
Delay Format (SDF).
Using the connectivity information, the CDC calculates the approximate delays.
CDC also calculates delays using parasitic information from the back-end tools, like
Place and Route, and Floorplanner. and places the calculated delays in the SDF which
can be read into Verilog data structures.
The delay values are placed into an SDF file.
The SDF annotator reads the timing data from the SDF file and annotates the timing
information to the Verilog family tool using the PLI.
Note: MIPDs describes the delay to a module input or inout port. Delays are inertial and affect three transitions:
to 1, to 0, and to Z.
SITDs are like MIPDs, but with transport delays and with global and local pulse control. SITDs affect six
transitions: 0 to 1, 1 to 0, 0 to Z, Z to 0, 1 to Z, and Z to 1.
MITDs are like SITDs, but allow you to specify unique delays for each source-load path.
SDF Example
(DELAYFILE
(DESIGN system)
(DATE Mon Jun 1 14:54:29 PST 1992)
(VENDOR Cadence)
(PROGRAM delay_calc)
(VERSION 1.6a,4)
(DIVIDER /) ; Character used as hierarchical dividing character
(VOLTAGE 4.5:5.0:5.5)
(PROCESS worst)
(TIMESCALE 1ns) ; The time units of the delays specified
(CELL
(CELLTYPE system) ; The name of the top level cell
(INSTANCE block_1) ; Instance name for the top level cell
(DELAY (ABSOLUTE
(INTERCONNECT P1/z B1/C1/i1 (.145:.148:.156) (.125:.127:.128)))))
(CELL
(CELLTYPE INV)
(INSTANCE ) ; This specification is for all cells
(DELAY (INCREMENT
(IOPATH i1 z (.345::.348) (.325::.329)))))
)
SDF Example
The header information of the SDF file configures the entire SDF file.
Delay values can be specified for a specific instance of a cell, or for all instances.
Delay values can be either absolute or incremental.
Verilog Family
Veritime Verilog-XL Verifault-XL
PLI
SDF Annotator
SDF File
For Example:
>verilog testfixture.v +sdf_verbose +sdf_error_info
Where verilog is the name of the Verilog executable, the name of the Verilog source code is
testfixture.v and the rest of the string are SDF options.
Command Explanation
+sdf_verbose Writes detailed information about the backannotation process to
the annotation log file.
+sdf_error_info This command displays the PLI error messages.
timescale 1ns/1ns
module top (ck,d1,q1);
...
dff u2 (q1,ckin,d1);
buffer1 u1 (ckin,ck);
...
initial
begin
$sdf_annotate ("sdffiles/iopath.sdf", , ,"logfiles/sdf.log");
$sdf_annotate ("sdffiles/timingcheck.sdf", ,logfiles/sdf.log);
$sdf_annotate ("sdffiles/port.sdf", , ,"logfiles/sdf.log");
$sdf_annotate ("sdffiles/interconnect.sdf", , "logfiles/sdf.log");
end
Start
Turbo No
Option
Yes
Turbo
license No
available?
Yes
XL license No
available?
Run Turbo
with 5-7X Yes NO LICENSE
available
Run XL
Controlling Acceleration
Controlling Acceleration
+caxl: The plus option +caxl accelerates continuous assignments that conform to some
restrictions.
+switchxl: The +switchxl plus option invokes the Switch-XL algorithm to accelerate the
simulation of bidirectional switches.
+no_turbo: This option disables the Turbo algorithm and makes Verilog apply the XL
algorithm.
If a simulation runs significantly faster with the other performance options prior to
using Turbo, then using them with Turbo still yields better overall performance.
Turbo Algorithm
XL Algorithm
+caxl
+switchxl
Twin Turbo
The Twin Turbo option +twin_turbo, causes the simulation to generate and
utilize compiled code for processing behavioral constructs in the selected
Turbo mode.
The Twin Turbo functionality operates in conjunction with each of the
existing Turbo modes.
Twin Turbo
The terms compiled code simulation and interpreted simulation refer to the way in which a
simulator operates on a designs source description. An interpreted simulator reads the source
code of a design/stimulus description and from it, builds an internal representation or data
structure of primitive operations. During simulation, these operations representing the
designs behavior are interpreted, or processed by the simulator, one at a time.
A Compiled Code (CC) simulator converts the HDL description into a computer program,
then executes the program to run the simulation. Many CC simulators convert the HDL
description into a standard programming language and then use the machine compiler to
convert the program into an executable.
The Twin Turbo mode is a Direct Compiled Implementation that converts the description
directly into machine code, thus bypassing the inefficient step of running the standard
compiler. With the introduction of Twin Turbo mode in the Verilog-XL Turbo 2.1 release,
performance enhancements have been added by augmenting Turbos interpreted simulation
method with a new compiled code implementation. In Twin Turbo mode, machine code
instructions are generated for all behavioral source code prior to simulation. During
simulation, machine instruction sequences representing behavioral code execute at the system
speed of the host computer. The compiled code executes considerably faster than the
interpreted pseudocode utilized in the Turbo mode, yet all of the flexibility and interactive
debugging capabilities are maintained.
Note: For more information see Appendix A, "Verilog-XL Twin Turbo Mode".
+twin_turbo (continued)
OPTIONS LEVEL EFFECT
+twin_turbo Twin Turbo extension -$listcounts disabled
of default Turbo mode -Twin Turbo optimizations
+twin_turbo with Twin Turbo extension -Default Turbo mode
+turbo of first-level Turbo mode optimizations
-Twin Turbo optimizations
+twin_turbo with Twin Turbo extension -Assignment optimizations
+turbo+2 of second-level Turbo -Scalar to compact node
mode conversion
-First-level Turbo mode
optimizations
-Twin Turbo optimizations
+twin_turbo with Twin Turbo extension -Delayed evaluation of
+turbo+3 of third-level Turbo mode complex continuous
assignment expressions
(can impact event order)
-Second-level Turbo mode
optimizations
-Twin Turbo optimizations
+twin_turbo (continued)
The Twin Turbo functionality operates in conjunction with each of the existing Turbo modes.
Specifying the Twin Turbo option causes the simulation to generate and utilize compiled code
for processing behavioral constructs in the selected Turbo mode. Because Twin Turbo is an
extension of the existing Verilog-XL Turbo capability, no additional licensing is required. The
VXL-TURBO feature string in the license file supports both Turbo and Twin Turbo.
The XL Algorithm
supported primitives:
buf and xor not nand xnor or nor
bufif0 bufif1 notif0 notif1
The XL Algorithm
The table above shows the primitives and net types that the XL algorithm accelerates.
The XL algorithm also accelerates UDPs.
Any unsupported items are automatically processed by the non-XL algorithm.
Specifying the driving strength of gate has no impact on whether or not the XL algorithm
can accelerate it.
always @(clk)
begin
always @(clk)
if (status == 2b00)
case(status)
out = Y;
2b00: out = Y;
if (status == 2b01)
2b01: out = A;
out = A;
2b10: out = 1bz;
if (status == 2b10)
2b11: out = B;
out = 1bz;
endcase
if (status == 2b11)
out = B;
end
Event control
Objectives
Learn about the Verilog-XL Graphical Environment
Verilog Control Window (VCW)
cWaves
Language Sensitive Editor (LSE)
Hierarchy Browser (HB)
Verilog Results Analyzer (VRA)
Verilog Control A Motif compliant graphical interface. Use the VCW to advance
Window (VCW) and interrupt simulation, break into and alter simulation, control
scope and so on.
cWaves The Cadence waveform viewing tool. Shows simulation results
graphically as waveforms.
Language Sensitive The LSE lets you enter, analyze and debug a Verilog description.
Editor (LSE) When run as part of the environment, you can use the LSE to
select signals for interaction with simulation. The LSE also offers
a subset of the interactions with simulation that the VCW
provides.
Hierarchy Browser A graphical tool for navigating through a design and for
(HB) traversing the various scopes within the design.
Verilog Results A graphical window that lets you invoke cWaves, the LSE, and
Analyzer (VRA) the HB to analyze the results of simulation jobs run in batch
mode.
TMS Text Management System
Use +venv to invoke the complete environment (VCW and LSE with access to
cWaves and HB).
% verilog +venv <command_line_options> <design_files>
Use +vcw to invoke the VCW without the other environment windows.
% verilog +vcw <command_line_options> <design_files>
Use +venv if you want access to the complete environment. This invokes the VCW and
the LSE with the source description of the top-level module. The VCW includes the
Tools menu, which allows you to invoke cWaves and the Hierarchy Browser.
Use +vcw if you want to invoke only the VCW.
VCW
Toolbox and
Messages Selection
Pull-Down
Fixed Status
Menus Area Transcript
Menu
VCW
The VCW contains six areas:
Seven pull-down menus available at the top of the VCW. (The Tools menu is not
available if you invoke the environment with +vcw).
The fixed menu on the left-hand side of the VCW. Fourteen buttons provide quick
access to common interactive operations.
The Toolboxes and Selection areas enable you to set breakpoints or implement post
selection.
The Status area provides information about the progress of simulation.
The Message window displays messages concerning your interaction with the
simulation.
The Transcript area displays the output from interactive simulation. You can also enter
interactive commands at the prompt.
VCW
Use the VCW pull-down menus and fixed menu to:
Advance and interrupt simulation
Show the values of signals
Show source
Control scope
Break into and alter simulation
VCW
Selecting Objects
Post selection
1. Press command button or select pulldown menu item.
2. Select object in LSE. Verilog-XL executes the command.
3. Select next object.
4. Press the Post Selection: Done button in the Toolbox and Selection Area.
Selecting Objects
For post selection, no object can be selected before you select the command.
To select objects in X windows, use Customize Preferences and make sure the
Use in VCW Selection option is on.
If you use Post Selection mode, select objects in the LSE (for example, X window
selection does not work).
File Menu
File Menu
Accessing SHM databases:
File SHM Open: Open a new SHM database or specify an existing database.
File SHM Save: Save the currently open SHM database with its current name.
File SHM Save As: Save the currently open SHM database to another SHM
database that you specify. Renaming the SHM database with the name of a preexisting
database overwrites the preexisting database.
File SHM Close: Save and close the currently open SHM database.
Reinvoking:
File Reinvoke: Reinvoke Verilog-XL using the same command line options on the
same design in the same working directory. Current breakpoints remain set, and the
currently probed signals remain displayed on the waveform display. Preferences set on
any menu are also saved. Allows you to quickly patch or change a design, recompile
it, and then resimulate up to the original problem.
Quitting:
If you invoked with +vcw, use File Quit VCW to exit the VCW.
If you invoked with +venv, use File Quit Env to exit the environment.
Run Menu
Run Menu
Continue/Interrupt (Continue/Interrupt button): Allows you to continue or interrupt
simulation. Interrupt puts the simulation in interactive mode, in which all objects are
frozen in their current states. Continue resumes simulation.
Event Step (Step button): By default, advances simulation by one event. To adjust the
number of events:
Select Run Defaults Step and manipulate the Step Increment slider.
Click on the Step button with the right mouse button and select the number of steps.
Source Step: Advances simulation to the next point with one of the following
characteristics:
Gate or switch output is determined
One or more statements within a behavioral construct are about to undergo evaluation
To control the number of source steps, manipulate the slider in the Step Defaults form
generated by Run Defaults Step.
Reset to Time Zero: Returns all values to their initial states. Use the Continue button
to resume simulation. Preserves breakpoints but clears scope. No recompilation.
Finish: Completes simulation. Leaves the VCW up so that you can review the transcript,
but does not save a Verilog-XL data structure.
Defaults: Pops up the Step Defaults form, which you use to set the default number of
event steps for the Event Step command or the Step button.
12/8/95 Cadence Design Systems, Inc. 18-16
Verilog Environment 18-17
Show Menu
Show Menu
Display Values: Implements $display. Use Show Defaults Display to do the
formatting.
Monitor: Implements $monitor. Show Monitor Monitor Off ends the
monitoring. Use Show Defaults Monitor to do the formatting.
Show Variables: Implements $showvars. Use Customize Preferences to configure.
Waveform...: There are three ways to invoke cWaves from the VCW:
Show Waveform.
Waveform button.
Tools cWaves. This brings up an empty cWaves window.
Show Scopes: Implements $showscopes.
Read Source: In the environment, output appears in the LSE. For standalone, output
appears in the Transcript as decompilations of source code ($list).
Show Defaults Read gives you a choice of reading the source in the LSE, the
Transcript, or both.
Trace On: Shows the course of simulation. Information includes current simulation
time, location in the source file of the active statement, decompilation of the statement,
and result of executing the statement.
History: Type the command number to re-execute (for example, C11 $showscopes;).
Defaults: Allows you to view and set defaults for the Display Values, Monitor,
Waveform, and Read Source commands.
Set Menu
Set Menu
Breakpoint...: Generates a form that lets you set time, source line, or signal-based
breakpoints.
Patch...: Implements a force. Assigns values to signals independent of the simulation
process. Can assign 0, 1, X, Z, or an expression. Use Set Release to remove a patch.
Release: Releases currently patched signals.
Value...: Sets values of registers. Any assignment to a register makes it lose the value
setting. Can assign 0, 1, X, Z, or an expression. Use Verilog syntax for the value (1bz).
Scope: Implements $scope.
Up button sets scope to the parent of the current scope.
Pop button moves to next lower scope. Use the right mouse button to view and select
a scope.
Focus: Source stepping is active only within the current foci.
Defaults: Sets defaults for the Breakpt button, which allows you to set signal-based
breakpoints.
Customize Menu
Preferences...:
Customize Menu
User Preferences form: Configures the selection function associated with interactive
operations.
X Primary Selection
(Use in VCW Selection)
Invokes the operation on objects selected in X windows outside the environment.
Selections in the LSE override selections in X windows.
X Primary Selection
(Use for Seeding Forms)
Makes X windows selections appear on popup forms. Selections in the LSE override
selections in X windows.
Selection Scheme: Prompt Mode
Makes the operation generate a form that enables you to choose multiple signals by
typing their names or by selecting them in the LSE.
Tools Menu
Tools Menu
Help Menu
Help Menu
Verilog Help: Task oriented help on modeling, verifying your design, controlling
Verilog, debugging, improving performance, and so on.
Click on About Help at the bottom of the help screen for detailed information on how
to use this help system.
Related Products: No online help available for LSE.
About Help: Explanations on how to use bubble help and hypertext links to
documentation.
Bubble help. Point at any item and:
Shift and press the middle mouse button.
Help key
Hypertext links to documentation for Verilog, cWaves, Hierarchy Browser
Breakpt button
Set Default Breakpoints
Set Breakpoints
Breakpoints Toolbox
Standalone:
% lemacs filename.v
3. Select Analysis Save & Analyze to save and analyze the description.
Debug Mode
When used with the VCW as part of the environment, the LSE:
Acts as a source code browser
Provides the Debug, Selections, and Hierarchy menus, which allow you to:
Interrupt/Continue
Step
Reset
Set scope
Set, disable, enable, and delete source or signal breakpoints
Select or clear classes and subclasses of objects
Navigate through the design hierarchy
Debug Mode
Hierarchy Browser
Lets you browse your design hierarchy.
Synchronized with other tools, such as LSE, so that selections from any tool are
reflected in the other tools.
To invoke the HB, use Tools Hierarchy Browser. The HB displays the top
level of your design.
Hierarchy Browser
Specify number of
levels to expand.
Dumping a large database of simulation results slows down the simulation and
can create very large files.
Try to limit the results being dumped to the results file.
VRA (continued)
Some ideas for limiting the amount of data in the results file:
Dump data only from the part of the design that you are interested in, plus some other
vital design nodes.
Dump only the registers and not the nets. These can often provide enough information
in a synchronous design to identify problems.
Dump areas that you have changed and treat all other areas as library components that
cannot be debugged.
Take checkpoints (saving the simulation state) throughout the simulation at regular
intervals so that a section of simulation time can be rerun with the data being dumped
later.
Take checkpoints regularly, and use the Verilog language to instruct the simulator to
return automatically to the previous checkpoint and dump data if a problem is found.
Break the simulation down into smaller units.
Labs
Appendix A
Introduction
Performance Expectations
The information in this appendix comes from an application note written by Cadence Technical
Marketing. The results of over 35 customer design test cases show that running in the Twin Turbo mode improves
performance at various levels, depending on the design style used and Turbo options invoked. An
Purpose average performance improvement of 1.5 X over Verilog-XL Turbo can be expected at the behavioral
and RTL level, with performance gains up to 2 X.
This appendix
Introduces the new Verilog-XL Twin Turbo enhancements All performance improvements in this document are relative to Verilog-XL version 2.0.5 run in
turbo+2 and turbo+3 modes, the highest performance configuration available prior to Verilog-XL 2.1.
Describes the implementation The table below shows performance data from seven customer test cases.
Shows how to invoke the new capability
Shows how to achieve optimal performance
This document provides Verilog users with an overview of the new Verilog-XL Twin Turbo DESIGN LEVEL SOURCE STIMULUS TIME IMPROVEMENT
performance enhancements. It describes the technology implementation, how to invoke this new
Memory Controller RTL/gate 1,100 lines 57,400 cycles 196 sec 1.7 X over Turbo
capability, and how to achieve optimal performance from Verilog-XL Turbo simulations.
Graphics Processor behavioral 1,000 lines 144 cycles 12 sec 1.5 X over Turbo
The new Compiled Code implementation called Twin Turbo gives the Verilog-XL Turbo 2.1 release Microcontroller RTL 56,000 lines 633 cycles 38 sec 2.0 X over Turbo
(9404) behavioral performance enhancements over existing Verilog-XL Turbo. Twin Turbo improves ALU RTL 23,000 lines 296 cycles 28 sec 1.5 X over Turbo
the simulation performance of designs that are predominately modeled at the behavioral and RTL level
by up to 2 X. Cache Controller RTL/gate 2,000 lines 1,024 cycles 897 sec 1.6 X over Turbo
RISC CPU RTL/gate 86,900 lines 5,704 cycles 816 sec 1.4 X over Turbo
The initial release of Twin Turbo has some minor usage restrictions, which are discussed in this LFSR RTL/gate 3,171 lines 20,000 cycles 113 sec 1.7 X over Turbo
document. Subsequent Verilog-XL Turbo releases will include a robust Twin Turbo implementation
without these restrictions.
6/29/95 Cadence Design Systems, Inc. A-1 A-2 Cadence Design Systems, Inc. 6/29/95
Appendix A Appendix A
Figure 1 illustrates a simple Verilog procedural assignment, its corresponding interpreted data
Compiled Code Simulation structure, pseudocode generated in Turbo mode, and machine code generated in Twin Turbo mode.
The terms compiled code simulation and interpreted simulation refer to the way in which a simulator
operates on a designs source description. An interpreted simulator reads the source code of a LOAD A
=
design/stimulus description and from it builds an internal representation or data structure of primitive
LOAD B
operations. During simulation, these operations representing the designs behavior are interpreted, or initial Z - Z = function(A,B,C)
processed, by the simulator one at a time. A Compiled Code (CC) simulator converts the HDL CALL multiply
Z = ((A * B) - C);
description into a computer program, then executes the program to run the simulation. Many CC * C LOAD C
simulators convert the HDL description into a standard programming language (e.g., C) and then use
CALL subtract
the machine compiler to convert the program into an executable. The Twin Turbo mode is a Direct A B
Compiled Implementation that converts the description directly into machine code, thus bypassing the STOR Z
inefficient step of running the standard compiler.
Behavioral source code Data structure Pseudocode Machine instructions
Versions of Verilog-XL prior to the 1.7 release (9303) were based solely on a interpreted simulation
implementation. At compile and link time, the design and stimulus descriptions are parsed and used to Figure 1: Examples of the various levels of code representation
build an internal representation or data structure of the designs functionality. During simulation, a
significant amount of time is spent manipulating the internal data structure tree in order to fetch and
store simulation values. In versions 1.7 and higher, the Turbo mode enhances performance by adding
highly efficient function calls or pseudocode to the data structure and optimizing memory transfers.
With the introduction of the Twin Turbo mode in the Verilog-XL Turbo 2.1 release (9404),
performance enhancements have been added by augmenting Turbos interpreted simulation method
with a new compiled code implementation. In Twin Turbo mode, machine code instructions are
generated for all behavioral source code prior to simulation. During simulation, machine instruction
sequences representing behavioral code execute at the system speed of the host computer. In Twin
Turbo mode, the compiled code executes considerably faster than the interpreted pseudocode utilized
in the Turbo mode, yet all of the flexibility and interactive debugging capabilities are maintained.
6/29/95 Cadence Design Systems, Inc. A-3 A-4 Cadence Design Systems, Inc. 6/29/95
Appendix A Appendix A
The new Twin Turbo functionality operates in conjunction with each of the existing Turbo modes. The new Twin Turbo mode of the Verilog-XL Turbo 2.1 release (9404) has some usage restrictions. No
Specifying the Twin Turbo option causes the simulation to generate and utilize compiled code for Twin Turbo mode restrictions apply to any Verilog hardware description language constructs. These
processing behavioral constructs in the selected Turbo mode. Because Twin Turbo is an extension of restrictions affect simulation checkpointing, using the behavioral profiler, and single-step tracing:
the existing Verilog-XL Turbo capability, no additional licensing is required. The VXL-TURBO feature
string in the license file supports both Turbo and Twin-Turbo. - The interrupt button in the Verilog Control Window (VCW) may disappear when Twin
Turbo is invoked along with the Verilog Environment (-s +venv +twin_turbo).
Running with +noxl on the command line provides a workaround, but at the expense of
gate-level acceleration.
- The checkpointing system tasks $save and $restart and the (-r) command line option
are not supported in the current release of Verilog 2.1 in +twin_turbo mode, but will be
COMMAND LINE OPTIONS PERFORMANCE LEVEL EFFECT supported in subsequent releases.
+twin_turbo Twin Turbo extension of - $listcounts disabled
default Turbo mode - Twin Turbo optimizations
- The behavioral profiling system tasks $startprofile and $listcounts and the
+profile command line option are not supported in the current release of Verilog in
+twin_turbo with +turbo Twin Turbo extension of - Even count and profiler disabled +twin_turbo mode.
first-level Turbo mode - Default Turbo mode optimizations
- Twin Turbo optimizations - The $settrace system task (-t) command line option and the single step (,) interactive
command display incorrect results in +twin_turbo mode. These mistaken values are the
+twin_turbo with +turbo+2 Twin Turbo extension of - Assignment optimizations
second-level Turbo mode - Scalar to compact node conversion
result of an optimization that causes the right-hand side of expressions to be displayed as
- First-level Turbo mode optimizations unknown (x), even though the actual values are known. The user may add the +settrace
- Twin Turbo optimizations option on the command line to get the proper display values, but at the expense of some
optimization.
+twin_turbo with +turbo+3 Twin Turbo extension of - Delayed evaluation of complex
third-level Turbo mode continuous assignment expressions - The performance enhancements of +twin_turbo are currently disabled when Verilog-XL
(can impact event order)
- Second-level Turbo mode
is run in the Verilog Model Export mode in a VHDL/Verilog cosimulation.
optimizations
- Twin Turbo optimizations
6/29/95 Cadence Design Systems, Inc. A-5 A-6 Cadence Design Systems, Inc. 6/29/95
Appendix A Appendix A
Because machine code instructions are generated in Twin Turbo mode to represent sequences of Users evaluating a simulation for performance considerations should not assume that a design is
behavioral code statements, the linking time of the simulation increases approximately 20 to 60%, with composed of an absolute percentage of behavioral and nonbehavioral (gate) level functionality. The
an additional increase in the memory size of approximately 3 to 5%. Although this process incurs critical task in accurately quantifying simulation performance is to determine exactly how much CPU
additional link time, the increase in simulation performance easily makes up for this time. time is spent in behavioral portions of the design relative to nonbehavior portions. This ratio depends
on the stimulus exercises in the design as well as on how efficiently the models implement the designs
Using the third-level Turbo mode (+turbo+3) may create event-ordering differences. Execution of behavior.
certain statements may take place in a different order compared to the regular Verilog-XL behavioral
engine. Event-reordering typically does not occur in synchronous designs, in which non-blocking As the performance improvement of the Turbo modes applies only to the behavioral code, a users
assignments have been used to allow all the inputs of the behavioral statements to be updated before expectations of overall performance must take into account the proportion of time spent processing
the corresponding outputs are evaluated. If result mismatches are observed when comparing the output nonbehavioral code. For example, if 20% of the simulation time is spent processing a users PLI
of two engines, a more severe problem may exist with the design. If event reordering presents a application and/or gate-level portions of a given design, the expected performance improvement
problem, then the design should be simulated using the second-level Turbo optimizations should be reduced by 20%.
(+turbo+2), which executes statements exactly like Verilog-XL, but at the cost of some
performance. The behavior profiler, a utility within Verilog-XL Turbo, identifies the percentage of total CPU time
spent processing behavioral constructs and modules in the source description. The profiler takes
regular samples of the simulation activity and identifies areas that are consuming large portions of
simulation time. The profiler can generate summaries of the simulations performance characteristics
or identify the lines of code that require significant processing. With this information, users can set
proper performance expectations and perhaps rewrite specific sections of code to increased simulation
performance.
To run the profiler in Turbo mode, Verilog-XL must be invoked with the +verbose_profile and
+listcounts options. The profiler is activated by issuing the $startprofile system task from
within a procedural block at time 0 or on the interactive command line. The two system tasks
$reportprofile and $listcounts display in the logfile the activity within the simulation and
how many times particular lines of code were executed. To obtain the most complete profile
information, the $reportprofile and $listcounts tasks should be issued at the end of the
simulation just before the $finish; however, they can be issued interactively at any point in the
simulation.
6/29/95 Cadence Design Systems, Inc. A-7 A-8 Cadence Design Systems, Inc. 6/29/95
Appendix A Appendix A
In Figure 3 a report produced by the $reportprofile task details the percentage of overall CPU
time spent simulating each type of behavioral construct. In this example, the simulator spent 63.6% of
its time in nonblocking procedural assignments and 11.6% in continuous assignments. The OTHERS
Profile ranking by statement: category represents the combination of XL, XL -> NONXL, and SCHEDULING activity and should
be taken into account when calculating overall Turbo performance improvements. It is also useful to
Self% Cum.% Samples Statement know how much simulation time spent initiating calls to system tasks and functions
----- ----- ------- ----------------------- (enable_task_stat) does not benefit from Turbo.
3.3% 3.3% 5668 SCHEDULING
2.3% 5.6% 4038 XL
1.3% 6.9% 2186 test.v, L36, test
0.9% 7.8% 1638 XL -> NON-XL
0.7% 8.5% 1139 cpu.v, L83, test.u1 Profile by statement type:
0.6% 9.1% 1034 cpu.v, L86, test.u1
0.6% 9.6% 1011 alu.v, L17, test.u8 Self% Cum.% Samples Statement type
0.6% 10.2% 982 mem.v, L17, test.u27 ----- ----- ------- --------------
... Report halted at 8 lines 63.6% 63.6% 110344 rtl_delay_stat
11.6% 75.2% 20112 cont_assign
6.5% 81.8% 11344 OTHERS
Figure 2: Profile of statements by ranking 3.9% 85.6% 6734 modport
2.9% 88.6% 5111 event_stat
2.7% 91.3% 4681 norm_node
2.0% 93.3% 3548 if_stat
Figure 2 shows a report produced by the $reportprofile task that lists the percentage of overall 1.7% 95.0% 2924 assign_stat
CPU time spent simulating individual statements in the design. Here, the XL statement indicates the 1.6% 96.6% 2718 seq_block
percentage of time that the XL gate engine is running. The XL -> NONXL is the proportion of time the 1.3% 97.9% 2202 enable_task_stat
simulator is transferring data between the XL and Turbo engines. As the Turbo engine does not 0.8% 98.7% 1387 if_else_stat
improve gate-level simulation, these numbers may be used to calculate the effect of the gate- level 0.6% 99.2% 988 delay_stat
portion of the design compared to the behavioral portion. For example, if one quarter of the design is 0.6% 99.8% 960 expand_decl
simulated using the XL engine (percentage of XL activity = 25%) and then Turbo is invoked, the 0.1% 99.9% 214 forever_stat
resulting performance improvement that Turbo provides only applies to three-quarters of the design 0.1% 100.0% 155 null_stat
because the gate-level part is already accelerated by XL.
Any design should be checked for statements that are taking up a large proportion of the simulation
activity. These proportions may be examined using the $listcounts task, which reports on the
amount of activity within a statement or hierarchical boundary. The design may be examined on a
module-by-module basis through the hierarchy, and any statements with a high sample number should
be checked for efficiency. If these statements are a central part of the designs functionality, they may
be being used efficiently by the simulation; however, often a redundant item of code takes up an
excessive amount of simulation.
6/29/95 Cadence Design Systems, Inc. A-9 A-10 Cadence Design Systems, Inc. 6/29/95
Appendix A Appendix A
Usage:
6/29/95 Cadence Design Systems, Inc. A-11 A-12 Cadence Design Systems, Inc. 6/29/95
Appendix A Appendix A
For example, in synchronous designs many procedural blocks that are triggered only by the positive
Achieving Optimal Performance edge of the system clock can be consolidated for more efficient processing.
Several optimizations can be implemented to improve the performance of the design. In general, the always@(posedge clk) always@(posedge clk)
focus should be on keeping the number of scheduled events scheduled as low as possible. The methods Y = C + D; begin
Y = C + D;
of optimization are: always@(posedge clk) Z = A * B;
Z = A * B; X = E + F;
Use of file I/O and debug statements end
always@(posedge clk)
X = E * F;
Although the performance of file I/O system tasks such as $monitor and $display has been
improved, it is generally best to minimize the use of debug statements that write to file or display
information. Because of the relatively slow access to the computers devices, calls to file I/O system
tasks can significantly affect simulation performance.
Event control
Flow control
Inefficient use of event controls may cause the simulator to execute a particular statement or group
Better performance can be achieved by reducing the simulators workload. For example, combining of statements unnecessarily. Careful attention to specifying the conditions when procedural blocks
several if statements into a single case statement causes the simulator to evaluate the case execute ensures the desired functionality in the fewest possible scheduled events. Of course, if a
statement once to understand the branching condition. If a sequence of if statements is used synthesis tool is used, the HDL rules must not be violated.
instead, the simulator has to evaluate the conditions repeatedly.
always@(d)
always(clk) always@(clk) always@(posedge clk) @(posedge clk)
begin case(status) q = d; q = d;
if (status == 2b00) 2b00: out = Y;
out = Y; 2b01: out = A;
2b10: out = 1bz;
if (status == 2b01) 2b11: out = B;
out = A; endcase
if (status == 2b10)
out = 1bz;
if (status == 2b11)
out = B;
end
Where possible, consolidate multiple procedural blocks that are triggered by the same conditions.
6/29/95 Cadence Design Systems, Inc. A-13 A-14 Cadence Design Systems, Inc. 6/29/95
Appendix A Appendix A
6/29/95 Cadence Design Systems, Inc. A-15 A-16 Cadence Design Systems, Inc. 6/29/95
Appendix B
Statistical Modeling
Statistical Modeling B-1
Statistical Modeling
Objectives
Learn about statistical modeling.
Statistical modeling is the highest level of abstraction that you can use to
analyze a design.
The goal of statistical modeling is to improve performance.
You can detect deadlocks and buffer overflows.
Gate/Switch
gate/switch
(structural)
A Simple Example
DISK
COMPUTER
BUFFER
A Simple Example
p(e)
Poisson Distribution
e
mean
p(e)
Uniform Distribution
pdf
e
start end
Initializing a Queue
module buffer;
/* A number of 20 overflows,
BUFFER
over a period of 40.000 time unit,
is acceptable */
integer MAX_LENGTH;
integer status;
reg queue_value;
initial
begin
MAX_LENGTH = 10;
// Initialize the queue and check for errors
$q_initialize (QUEUE_ID, 1, MAX_LENGTH, status); $q_initialize creates
a new queue.
if(status !==0)
begin
// $display(status = %d, status);
$display(ERROR INITIALIZING THE QUEUE IN THE BUFFER);
$finish;
end
end
endmodule
Initializing a Queue
You can create a new queue using the $q_initialize system task.
$q_initialize (<q_id>, <q_type>, <max_length>, <status>)
The q_id parameter is an integer input which must uniquely identify the new queue.
The q_type parameter is an integer input. The value of the q_type parameter specifies
the following:
1. that the queue should be first-in/first-out
2. that the queue should be last-in/first-out
The max_length parameter is an integer input which specifies the maximum number of
entries that will be allowed on the queue.
The success or failure of the creation is returned as an integer in status.
status What it Means
Parameter Values
0 OK
1 queue full, cannot add
2 undefined q_id
3 queue empty, cannot remove
4 unsupported queue type, cannot create queue
5 specified length <= 0, cannot create queue
6 duplicate q_id, cannot create queue
7 not enough memory, cannot create queue
module disk;
integer SEED, START, END;
integer job_id;
integer delay; DISK
integer status;
integer inform_id;
always
begin BUFFER
delay = $dist_uniform(SEED,START, END);
#delay;
$q_remove(QUEUE_ID, job_id, inform_id, status);
...
When the current value associated with a bar exceeds the predefined height, the bar
changes color to indicate this off-the-scale condition.
Labs
Switch-Level Modeling
Switch-Level Modeling C-1
Switch-Level Modeling
Objectives
Introduce switch-level modeling.
Introduce the Switch-XL algorithm.
Introduce the Switch-RC algorithm.
Learn how to choose an algorithm.
For cmos and nmos circuits, modeling at the switch level better represents
the hardware implementation of a design than modeling at the gate level.
Verilog-XL allows you to simulate switch-level networks with either a default
algorithm or the Switch-XL or the Switch-RC algorithm.
Switch-Level Networks
Different regions of
channel-connected switches
The default algorithm, the Switch-XL and the Switch-RC simulate regions of
channel-connected switches.
Switch-Level Networks
Switch-level networks are composed of bidirectional switches, unidirectional switches
or both, which are those complying with either of the following criteria:
a single switch and the nets that connect to its source and drain terminals.
a group of switches connected together through their source and drain terminals, and
nets connected to the switches source and drain terminals.
The default algorithm, the Switch-XL and the Switch-RC simulate regions of
channel-connected switches.
Switch Instantiation
pctl
nctl
Switch Instantiation
Note:Verilog-XL employs no delays for the pullup and pulldown unidirectional switches.
You cannot specify delays for these switches.
Strength Reduction
Unidirectional Switches
input strength Reduced Input Strength Reduced Strength
Strength
ctl
supply drive pull drive
strong drive pull drive
in out pull drive weak drive
rpmos p1(out, in, ctl);
large capacitor medium capacitor
weak drive medium capacitor
medium capacitor small capacitor
Bidirectional Switches
small capacitor small capacitor
bd1 high impedance high impedance
pullup(a)
pulldown(b)
and (c, a, b);
Strength Reduction
The nmos, pmos and cmos devices pass trough the strength from the data input to the
output, except that a supply strength is reduced to a strong strength.
The rnmos, rpmos, rcmos, rtran, rtranif1, rtranif0 devices reduce the strength of signals
that pass through them according to the table.
S1
2
Strength of Transistors
S2 S3
1 1
Verilog-XL allows you to execute a simulation under the control of the switch-XL algorithm.
Doing so provides you with the following capabilities:
High-speed simulation of bidirectional switches.
Enhanced strength model:
Specify up to 250 drive strengths to switches
Specify charge strengths to nets
The XL algorithm accelerates the simulation of gates and unidirectional switches. The
switch-XL algorithm accelerates the simulation of bidirectional switches. With the switch-XL
algorithm, you can model bidirectional switches without paying a high performance cost.
nmos tranif1
nmos
turn-on delay turn-off delay
ignore
nmos tranif1 nmos nmos
Verilog-XL allows you to execute a simulation under the control of the Switch-RC
algorithm.
The Switch-RC algorithm incorporates detailed timing based on the sizes of
transistors and resistance and capacitance of nets.
It provides more accurate logic and timing analysis of large circuits than the
default or Switch-XL algorithm.
R1
W/L
S1
Size of Transistor
R2 R3
W/L W/L
S2 S3
RC Model
The Switch-RC algorithm incorporates detailed timing based on the sizes of transistors in the
schematic.
The Switch-RC algorithm has its own model for switches and nets that requires additional
information. You supply information for this model in several ways:
Compiler directives define different manufacturing technologies that include mappings
between the real resistances and capacitances in the Switch-RC and the Verilog-XL
standard-strength model.
Switch declarations have lengths and widths that map to resistances defined by the
manufacturing technology.
Net declarations include capacitances and high and low voltage thresholds.
Compiler directives associate each switch or net with a manufacturing technology.
Timing Specification
VCC
R1
OUT
R2//R3 C
R2//R3
Delay
Final State
Timing Specification
Use RC networks to determine final state and final delay.
Using different approximation the Switch-RC algorithm estimates the delay associated
to a network.
The delay is a function of R and C.
Design mistakes in
pullup/pulldown ratio will
w/l be detected by the Switch-RC
algorithm
State-dependent delay
Delay due to the side-path capacitor
Slope-dependent delay
case A case B
R
1 -> 0 R 1 -> 0 ----
C 2 C
R
= RC = ---- C
2
0->1
out
You can use either of two methods to invoke the switch-RC algorithm:
Enter the +switch_res plus option on the command line.
Use the switchrc compiler directive.
Example:
verilog file1.v file2.v +switch_res
Choosing an Algorithm
When do I use the Switch-XL algorithm?
Maximum speed is required.
Simulation focus on functionality checking instead of
timing accuracy.
Speed
Pumping test vectors for regression test.
Accuracy
Check timing and some functionality using a
reasonable number of vectors.
Choosing an Algorithm
If you are interested in functional simulation and specifying discrete delays, your choice
is between the default and Switch-XL algorithms. If the standard-strength model cannot
simulate the circuit, Switch-XL remains as the only option with its integer-strength
model.
The difficult decision is whether to use the default algorithm or the Switch-XL
algorithm when the standard-strength model can simulate the circuit. The choice is
dependent upon the topology of the circuit. If the circuit is a sea of gates implemented
with bidirectionals, Switch-XL outperforms the default algorithm by a factor of five to
fifteen.
If you want a simulation with actual widths, lengths, capacitances, and detailed timing
estimation, you must use Switch-RC. In this case, you want to model some behavior that
is outside the scope of the default and Switch-XL algorithms, such as spike analysis, or
parallel and serial combination of resistors.
Labs
Appendix D
Lab 1
// The netlist
not (sel_, sel);
and (a1, a, sel_);
and (b1, b, sel);
or (out, a1, b1);
endmodule
testfixture.v Lab 2
module testfixture;
clock.v
reg a, b, sel; module clock(clk);
output clk;
//MUX instance reg start;
MUX2_1 mux (out, a, b, sel);
// Apply Stimulus nand #10 (clk, clk, start); //clock oscilator
// Display Results
initial
$monitor($time, " a = %b b = %b sel = %b out = %b", a,b,sel,out);
/*
// This will be used for cWaves during lab 1-3
initial
begin
$shm_open("file.shm");
$shm_probe("A");
#0 $stop;
end
*/
endmodule
D-2 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-3
Appendix D Lab 2 dff.v register.v Appendix D Lab 2
dff.v register.v
timescale 1 ns/100 ps /*************************************************************************
module dff(q, qb, clk, d, rst); * 8-bit register with hierarchy, Verilog Training Course
output q, qb; *************************************************************************/
input clk, d, rst;
timescale 1 ns / 100 ps
module register(r, clk, data, ena, rst);
nand n1 (cf, dl, cbf);
output [7:0] r;
nand n2 (cbf, clk, cf, rst);
input [7:0] data;
nand n3 (dl, d, dbl, rst);
input clk, ena, rst;
nand n4 (dbl, dl, clk, cbf);
nand n5 (q, cbf, qb);
wire [7:0] data, r;
nand n6 (qb, dbl, q, rst);
and a1(load, clk, ena);
endmodule
dff d0 (r[0], , load, data[0], rst),
d1 (r[1], , load, data[1], rst),
d2 (r[2], , load, data[2], rst),
d3 (r[3], , load, data[3], rst),
d4 (r[4], , load, data[4], rst),
d5 (r[5], , load, data[5], rst),
d6 (r[6], , load, data[6], rst),
d7 (r[7], , load, data[7], rst);
endmodule
D-4 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-5
Appendix D Lab 2 register_test.v dff.v Appendix D Lab 3
register_test.v Lab 3
/*************************************************************************
* Stimulus for testing the 8-bit Register - Verilog Training Course dff.v
timescale 1 ns/100 ps
*************************************************************************/ module dff(q, qb, clk, d, rst);
timescale 1 ns / 100 ps output q, qb;
module test; input clk, d, rst;
wire [7:0] reg_out; //declare vector for register output
reg [7:0] data; nand n1 (cf, dl, cbf);
reg ena, rst; nand n2 (cbf, clk, cf, rst);
nand n3 (dl, d, dbl, rst);
nand n4 (dbl, dl, clk, cbf);
register r1(reg_out, clk, data, ena, rst); nand n5 (q, cbf, qb);
nand n6 (qb, dbl, q, rst);
clock c1 (clk); //clock oscilator
specify
initial
begin
$shm_open("lab2.shm");
$shm_probe("A");
#100 $stop;
end
endmodule
D-6 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-7
Appendix D Lab 3 test.v test.v Appendix D Lab 3
test.v
/************************************************************************* initial
* Stimulus to test the D Flip-Flop model with timing checks - Verilog begin
* Training Course, Lab3. $shm_open("database.shm");
* $shm_probe("A");
* This stimulus should cause timing violations under the following #100 $stop;
conditions: end
* with Minimum Delays: No violations
* with Typical Delays: A setup violation endmodule
* with maximum Delays: A setup and a hold violation
*************************************************************************/
module test;
initial
begin
rst = 0; //check that the flip-flop resets
#15 rst = 1;
#50 $finish;
end
D-8 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-9
Appendix D Lab 4 counter.v counter_test.v Appendix D Lab 4
Lab 4 counter_test.v
/********************************************************************
counter.v * Stimulus to test the 5-bit counter - Verilog Training Course
/******************************************************************* *********************************************************************/
* Netlist of a 5-bit counter - Verilog Training course
* timescale 1 ns/1 ns //DELAYS ARE IN NANOSECONDS WITH NO DECIMAL PLACES
*******************************************************************/
timescale 1ns / 1ns module counter_test;
module counter(cnt,clk,data,rst,load); reg [4:0] data;
output [4:0] cnt;
reg rst, load,tmp, clk;
input [4:0] data;
input clk, rst, load; wire [4:0] cnt;
D-10 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-11
Appendix D Lab 4 counter_test.v alu.v Appendix D Lab 5
initial Lab 5
begin
clk= 0;
alu.v
always @(accum)
#1.2 zero= (!accum);
always
@(negedge clock) #3.5
case (opcode)
Add : alu_out = accum + data;
And : alu_out = accum & data;
Xor : alu_out = accum ^ data;
pass_data : alu_out = data ;
pass_acum_0,
D-12 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-13
Appendix D Lab 5 alu.v alu_test.v Appendix D Lab 5
pass_acum_1, alu_test.v
pass_acum_6,
/*********************************************************************
pass_acum_7 : alu_out = accum;
default : begin * Stimulus for the ALU design - Verilog Training Course
$display("\nWARNING FROM ALU: Undefined opcode: %b\n", opcode); *********************************************************************/
alu_out = 8'bx; timescale 1ns / 1ns
end module alu_test;
endcase wire [7:0] alu_out;
reg [7:0] data, accum;
endmodule reg [2:0] opcode;
reg start_clk;
integer i;
define period 20
define prop_delay 4
/**********************************************************************
* GATE LEVEL CLOCK OSCILLATOR
**********************************************************************/
nand #(period/2) (clk, clk, start_clk);
initial
begin
start_clk = 0;
#(period/2) start_clk = 1;
end
D-14 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-15
Appendix D Lab 5 alu_test.v alu_test.v Appendix D Lab 5
D-16 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-17
Appendix D Lab 5 alu_test.v scale_mux.v Appendix D Lab 6
endmodule
D-18 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-19
Appendix D Lab 6 test_mux.v mem.v Appendix D Lab 7
test_mux.v Lab 7
module test_mux;
mem.v
reg [7:0] a, b; /*********************************************************************
wire [7:0] out; * Model of RAM Memory - Verilog Training Course.
reg sel; *********************************************************************/
D-20 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-21
Appendix D Lab 7 mem_test.v mem_test.v Appendix D Lab 7
mem_test.v #9 read = 0;
/*************************************************************************
* Stimulus for the RAM model - Verilog Training Course $display("\n Setting all memory cells to alternating patterns...",$stime);
*************************************************************************/ #10 addr = 0;
timescale 1ns / 1ns repeat (16)
begin
module memtest; data = 8'hAA;
#1 write = 1; #9 write = 0;
reg read, write; #10 addr = addr + 1;
reg [4:0] addr; data = 8'h55;
wire [7:0] data; #1 write = 1; #9 write = 0;
reg [7:0] expected; #10 addr = addr + 1;
integer error_cnt; end
mem m1(data,addr,read,write); $display("\n Doing block read from five memory addresses...");
#10 addr = 5'h05;
initial //display time in nanoseconds expected = 8'h55;
$timeformat(-9, 1, " ns", 9); read = 1;
repeat (5)
initial begin
begin #1 if (data !== expected)
error_cnt = 0; begin
$display("\n Setting all memory cells to zero..."); $display("** ERROR at %t! read back %h from address %h:",
data = 8'h0; $realtime, data, addr, " Expected to read %h", expected);
write = 0; error_cnt = error_cnt + 1;
read = 0; end
addr = 0; #9 addr = addr + 1;
repeat (32) expected = ~expected;
begin end
#1 write = 1; #9 write = 0; read = 0;
#10 addr = addr + 1; #10 addr = 0;
end $display("\n Completed Memory Tests With %0d Errors!\n", error_cnt);
data = 8'hFF; #1 $stop;
end
$display("\n Reading from one memory address...");
#10 addr = 5'h0A; initial
read = 1; begin
#1 if (data !== 8'h00) $shm_open ("lab7.shm");
begin $shm_probe (write,read,addr,data);
$display("** ERROR at %t! read back %h from address %h:", #1 $stop;
$realtime, data, addr, " Expected to read 00"); end
error_cnt = error_cnt + 1; endmodule
end
D-22 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-23
Appendix D Lab 7 mem_test.v_fixed mem_test.v_fixed Appendix D Lab 7
D-24 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-25
Appendix D Lab 7 mem_test.v_fixed control_decoder.v Appendix D Lab 8
initial Lab 8
begin
$shm_open ("lab7.shm");
control_decoder.v
$shm_probe (write,read,addr,data);
#1 $stop; /*************************************************************************
end * This is a COMBINATIONAL LOGIC model of the Sequence Controller -
* Verilog Training Course.
endmodule *
* This model uses combinational logic to generate the control lines used in
* the VeriRisc CPU design. The combinational logic is sensitive to changes
* in logic value on any of the inputs. When any of these inputs change
* value, the model will decode all inputs and apply appropriate values to
* the output control signals.
*************************************************************************/
timescale 1ns / 1ns
module control(load_acc, mem_rd, mem_wr, inc_pc, load_pc, load_ir, halt,
opcode, fetch, zero, clk, clk2, reset);
D-26 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-27
Appendix D Lab 8 control_decoder.v control_decoder.v Appendix D Lab 8
D-28 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-29
Appendix D Lab 8 control_decoder.v control_state.v Appendix D Lab 8
end control_state.v
else
/************************************************************************
begin
inc_pc=0; load_acc=0; load_pc=0; mem_wr=0; mem_rd=0; load_ir=0; halt=0; * This is a State Machine model of the Sequence Contoller -
end * Verilog Training Course.
end *
ADD, * This model uses sequential logic (a state counter) to generate the
AND, * control lines used in the VeriRisc CPU design. Only the "clk" and "fetch"
XOR, * clock inputs are used when this controller is modeled as a state machine.
LDA : begin
* The "clk2" input is not used.
inc_pc=0; load_acc=1; load_pc=0; mem_wr=0; mem_rd=1; load_ir=0; halt=0;
*************************************************************************/
end
JMP : begin
inc_pc=1; load_acc=0; load_pc=1; mem_wr=0; mem_rd=0; load_ir=0; halt=0; timescale 1ns / 1ns
end module control(load_acc, mem_rd, mem_wr, inc_pc, load_pc, load_ir, halt,
STO : begin opcode, fetch, zero, clk, clk2, reset);
inc_pc=0; load_acc=0; load_pc=0; mem_wr=1; mem_rd=0; load_ir=0; halt=0;
end output load_acc, mem_rd, mem_wr, inc_pc, load_pc, load_ir, halt;
endcase input [2:0] opcode;
end input fetch, zero, clk, clk2, reset;
endtask
endmodule reg load_acc, mem_rd, mem_wr, inc_pc, load_pc, load_ir, halt;
wire [2:0] opcode;
D-30 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-31
Appendix D Lab 8 control_state.v control_state.v Appendix D Lab 8
D-32 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-33
Appendix D Lab 8 control_test.v control_test.v Appendix D Lab 8
control_test.v /*************************************************************************
/************************************************************************* * Generate the three input clocks
*************************************************************************/
* Stimulus to test the Sequence Controller - Verilog Training Course
initial
*
fork
* This module contains the following parts: clk=0;
* clk2=1;
* 1. A routine which reads stimulus from a test pattern file and compares fetch=1;
* the simulation results to an expected results file. forever #(period/2) clk = ~clk;
* forever #(period) clk2 = ~clk2;
forever #(period*2) fetch = ~fetch;
* 2. A task which can be invoked interactively to generate a new expected
join
* results file.
*************************************************************************/
/*************************************************************************
* Load in the test vector pattern file and apply each pattern to the
timescale 1ns / 1ns
module controller_test; * controller inputs.
*************************************************************************/
define period 20 initial
define setup_time 2 begin
define prop_delay 6 /* time for changes on inputs to reach outputs */
$readmemb("test_vectors.pat", test_vectors); //load input vector file
define num_vectors 16
define num_results 128 {reset, zero, opcode} = test_vectors[1]; //apply 1st test vector
D-34 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-35
Appendix D Lab 8 control_test.v control_test.v Appendix D Lab 8
/************************************************************************* /*************************************************************************
* Load in the expected results pattern file and compare each pattern to the * Setup graphical waveforms display
* controller outputs. *************************************************************************/
*************************************************************************/ initial //waveforms display
initial begin
begin: DEBUG $shm_open("lab8.shm");
$shm_probe(reset);
$readmemb("expected_results.pat", expected_results); //load file
$shm_probe(clk);
result = 0; $shm_probe(clk2);
num_errors = 0; $shm_probe(fetch);
forever @(clk) //check outputs at every edge of clk $shm_probe(zero);
begin $shm_probe(opcode);
result = result + 1; $shm_probe(mnemonic);
#prop_delay if (actual_results !== expected_results[result]) $shm_probe(inc_pc);
begin
$shm_probe(load_acc);
num_errors = num_errors + 1;
expected = expected_results[result]; $shm_probe(load_pc);
$display("*** Error at %t:",$realtime, $shm_probe(mem_wr);
"\tTest Vector No. %0d: Expected Results No. %0d.", $shm_probe(mem_rd);
(vector - 1), result); $shm_probe(load_ir);
if (load_acc !== expected[6]) $shm_probe(halt);
$display(" load_acc = %b expected: %b",
#1 $stop;
load_acc, expected[6]);
if (mem_rd !== expected[5]) end
$display(" mem_rd = %b expected: %b",
mem_rd, expected[5]);
if (mem_wr !== expected[4]) always @(opcode) //get an ASCII mnemonic for each opcode
$display(" mem_wr = %b expected: %b", begin
mem_wr, expected[4]); case(opcode)
if (inc_pc !== expected[3]) 3'h0 : mnemonic = "HLT";
$display(" inc_pc = %b expected: %b", 3'h1 : mnemonic = "SKZ";
inc_pc, expected[3]); 3'h2 : mnemonic = "ADD";
if (load_pc !== expected[2]) 3'h3 : mnemonic = "AND";
$display(" load_pc = %b expected: %b", 3'h4 : mnemonic = "XOR";
load_pc, expected[2]); 3'h5 : mnemonic = "LDA";
if (load_ir !== expected[1]) 3'h6 : mnemonic = "STO";
$display(" load_ir = %b expected: %b", 3'h7 : mnemonic = "JMP";
load_ir, expected[1]); default : mnemonic = "???";
if (halt !== expected[0]) endcase
$display(" halt = %b expected: %b", end
halt, expected[0]);
// $stop; // Stop on errors for debugging
end
end
end
D-36 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-37
Appendix D Lab 8 control_test.v expected_results.pat Appendix D Lab 8
/************************************************************************* expected_results.pat
* Task to generate a new file of expected results based on the current test //EXPECTED RESULT PATTERNS FOR TESTING THE VeriRisc SEQUENCE CONTROLLER
* pattern file and decoder model. //
* //THE PATTERN ORDER IS: load_acc mem_rd mem_wr inc_pc load_pc load_ir halt
* This task may be called interactively by entering: gen_results; //
*************************************************************************/ 0000000
task gen_results; 0000000
integer results; 0000000
0000000
begin 0000000
$display("\n*** Generating a new expected results file..."); 0000000
if ($stime != 0) 0000000
begin 0000000
$display("\nERROR: The \"gen_results\" routine requires simulation ", 0100000
"be at time zero."); 0100010
$display("The simulation can be reset to time zero by entering ", 0100010
"\"$reset;\"\n"); 0001000
$stop; 0000000
end 0000000
#0 disable DEBUG; //turn off block that checks simulation results 0000000
0000000
results = $fopen("expected_results.pat"); 0100000
$fdisplay(results,"//EXPECTED RESULT PATTERNS FOR TESTING THE ", 0100010
"VeriRisc DECODER"); 0100010
$fdisplay(results,"//"); 0001000
$fdisplay(results,"//THE PATTERN ORDER IS: load_acc mem_rd mem_wr ", 0100000
"inc_pc load_pc load_ir halt"); 1100000
$fdisplay(results,"//"); 1100000
0000000
forever @(clk) 0100000
#prop_delay $fstrobe(results, load_acc, mem_rd, mem_wr, inc_pc, 0100010
load_pc, load_ir, halt); 0100010
end 0001000
endtask 0100000
1100000
endmodule 1100000
0000000
0100000
0100010
0100010
0001000
0100000
1100000
1100000
0000000
0100000
0100010
0100010
0001000
D-38 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-39
Appendix D Lab 8 expected_results.pat expected_results.pat Appendix D Lab 8
0100000 1100000
1100000 0000000
1100000 0100000
0000000 0100010
0100000 0100010
0100010 0001000
0100010 0100000
0001000 1100000
0000000 1100000
0000000 0000000
0010000 0100000
0000000 0100010
0100000 0100010
0100010 0001000
0100010 0000000
0001000 0000000
0000000 0010000
0000100 0000000
0001100 0100000
0000000 0100010
0100000 0100010
0100010 0001000
0100010 0000000
0001000 0000100
0000000 0001100
0001000 0000000
0001000 0100000
0000000 0100010
0100000 0100010
0100010 0001001
0100010 0000000
0001000 0000000
0100000 0000000
1100000
1100000
0000000
0100000
0100010
0100010
0001000
0100000
1100000
1100000
0000000
0100000
0100010
0100010
0001000
0100000
1100000
D-40 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-41
Appendix D Lab 8 run_dec.f test_vector_gen.v Appendix D Lab 8
run_dec.f test_vector_gen.v
/*************************************************************************
control_test.v * Procedural stimulus to test the Sequence Controller - Verilog Training
control_decoder.v * Course.
*
* This module contains the following parts:
run_state.f
*
* 1. A routine which provides procedural stimulus to the inputs of the
control_test.v * controller design.
control_state.v
*
* 2. A routine to generate a test vector file based on the procedural
* stimulus.
*
* 3. A routine to generate an expected results file based on the outputs
* of the controller design.
*************************************************************************/
define period 20
define setup_time 2
define hold_time ((period * 4) - setup_time)
define prop_delay 5
D-42 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-43
Appendix D Lab 8 test_vector_gen.v test_vector_gen.v Appendix D Lab 8
vector_file = $fopen("test_vectors.pat");
$fdisplay(vector_file,"//TEST VECTORS FOR TESTING THE SEQUENCE
CONTROLLER");
$fdisplay(vector_file,"//");
$fdisplay(vector_file,"//THE VECTOR ORDER IS: reset zero_bit opcode");
$fdisplay(vector_file,"//");
D-44 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-45
Appendix D Lab 8 test_vectors.pat clkgen.v Appendix D Lab 9
test_vectors.pat Lab 9
//TEST VECTORS FOR TESTING THE SEQUENCE CONTROLLER
// clkgen.v
//THE VECTOR ORDER IS: reset zero_bit opcode
// /*************************************************************************
0_0_000 * A free-running 3 phase clock oscillator for the VeriRisc CPU system -
1_0_001 * Verilog Training Course.
1_0_010 *
1_0_011 * This module generates 3 clocks with the following specification:
1_0_100
*
1_0_101
* The period for clk = 20 ns, clk2 = 40 ns, and fetch = 60 ns
1_0_110
1_0_111 **************************************************************************
1_1_001 /
1_1_010
1_1_011 timescale 1ns / 1ns
1_1_100 module clkgen(fetch, clk2, clk);
1_1_101 output fetch, clk2, clk;
1_1_110
1_1_111 reg fetch, clk2, clk;
1_1_000
define period 20
initial
fork
clk=0;
clk2=1;
fetch=1;
forever #(period/2) clk = ~clk;
forever #(period) clk2 = ~clk2;
forever #(period*2) fetch = ~fetch;
join
endmodule
D-46 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-47
Appendix D Lab 9 cpu.log cpu.log Appendix D Lab 9
cpu.log
**************************************************************************
Host command: /net/ashley/usr1/9404/tools.sun4/verilog/bin/verilog
* THE FOLLOWING DEBUG TASKS ARE AVAILABLE: *
Command arguments:
* Enter "test1;" to load the 1st diagnostic program, and then continue
-f run.f
simulation.
cpu_test.v
* Enter "test2;" to load the 2nd diagnostic program, and then continue
cpu.v simulation.
clkgen.v * Enter "test3;" to load the Fibonacci program, and then continue simulation.
../lab2-register/register.v * Run cwaves if you would like to see the waveforms for this lab *
../lab4-counter/counter.v **************************************************************************
../lab5-alu/alu.v
../lab7-mem/mem.v L55 "cpu_test.v": $stop at simulation time 0.0 ns
../lab8-control/control.v Type ? for help
-y ../lab2-register/cells_lib C1 > test1;.
+libext+.v
+delay_mode_zero *** RUNNING CPUtest1 - THE BASIC CPU DIAGNOSTIC PROGRAM ***
+caxl *** (THIS TEST SHOULD HALT WITH THE PC AT 17 hex) ***
VERILOG-XL 2.1.2 log file created Feb 8, 1995 11:01:24 TIME PC INSTR OP DATA ADR
VERILOG-XL 2.1.2 Feb 8, 1995 11:01:24 ---------- -- ----- -- ---- ---
2.0 ns 00 HLT 0 zz 00
Copyright (c) 1994 Cadence Design Systems, Inc. All Rights Reserved. 111.0 ns 00 JMP 7 fe 00
Unpublished -- rights reserved under the copyright laws of the United States. 191.0 ns 1e JMP 7 e3 1e
271.0 ns 03 LDA 5 ba 03
Copyright (c) 1994 UNIX Systems Laboratories, Inc. Reproduced with 351.0 ns 04 SKZ 1 20 04
Permission. 431.0 ns 06 LDA 5 bb 06
511.0 ns 07 SKZ 1 20 07
For technical assistance please contact the Cadence Response Center at 591.0 ns 08 JMP 7 ea 08
1-800-CADENC2 or send email to crc_customers@cadence.com 671.0 ns 0a STO 6 dc 0a
751.0 ns 0b LDA 5 ba 0b
For more information on Cadence's Verilog-XL product line send email to 831.0 ns 0c STO 6 dc 0c
talkverilog@cadence.com 911.0 ns 0d LDA 5 bc 0d
991.0 ns 0e SKZ 1 20 0e
Compiling source file "cpu_test.v" 1071.0 ns 10 XOR 4 9b 10
Compiling source file "cpu.v" 1151.0 ns 11 SKZ 1 20 11
Compiling source file "clkgen.v" 1231.0 ns 12 JMP 7 f4 12
Compiling source file "../lab2-register/register.v" 1311.0 ns 14 XOR 4 9b 14
Compiling source file "../lab4-counter/counter.v" 1391.0 ns 15 SKZ 1 20 15
Compiling source file "../lab5-alu/alu.v" 1471.0 ns 17 HLT 0 00 17
Compiling source file "../lab7-mem/mem.v"
Compiling source file "../lab8-control/control.v" *** A HALT INSTRUCTION WAS PROCESSED BY THE CPU ***
Scanning library directory "../lab2-register/cells_lib"
Highest level modules:
cpu_test
D-48 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-49
Appendix D Lab 9 cpu.log cpu.log Appendix D Lab 9
************************************************************************** **************************************************************************
* THE FOLLOWING DEBUG TASKS ARE AVAILABLE: * * THE FOLLOWING DEBUG TASKS ARE AVAILABLE: *
* Enter "test1;" to load the 1st diagnostic program, and then continue * Enter "test1;" to load the 1st diagnostic program, and then continue
* simulation. simulation.
* Enter "test2;" to load the 2nd diagnostic program, and then continue * Enter "test2;" to load the 2nd diagnostic program, and then continue
simulation. simulation.
* Enter "test3;" to load the Fibonacci program, and then continue simulation. * Enter "test3;" to load the Fibonacci program, and then continue simulation.
* Run cwaves if you would like to see the waveforms for this lab * * Run cwaves if you would like to see the waveforms for this lab *
************************************************************************** **************************************************************************
L62 "cpu_test.v": $stop at simulation time 1510.0 ns L62 "cpu_test.v": $stop at simulation time 2710.0 ns
C2 > test2;. C3 > test3;.
*** RUNNING CPUtest2 - THE ADVANCED CPU DIAGNOSTIC PROGRAM *** *** RUNNING CPUtest3 - AN EXECUTABLE PROGRAM ***
*** (THIS TEST SHOULD HALT WITH THE PC AT 10 hex) *** *** This program should calculate the Fibonacci ***
*** number sequence from 0 to 144 ***
TIME PC INSTR OP DATA ADR
---------- -- ----- -- ---- --- TIME FIBONACCI NUMBER
1631.0 ns 00 LDA 5 bb 00 ---------- ----------------
1711.0 ns 01 AND 3 7c 01 2830.0 ns 0
1791.0 ns 02 XOR 4 9b 02 3550.0 ns 1
1871.0 ns 03 SKZ 1 20 03 4270.0 ns 1
1951.0 ns 05 ADD 2 5a 05 4990.0 ns 2
2031.0 ns 06 SKZ 1 20 06 5710.0 ns 3
2111.0 ns 07 JMP 7 e9 07 6430.0 ns 5
2191.0 ns 09 XOR 4 9c 09 7150.0 ns 8
2271.0 ns 0a ADD 2 5a 0a 7870.0 ns 13
2351.0 ns 0b STO 6 dd 0b 8590.0 ns 21
2431.0 ns 0c LDA 5 ba 0c 9310.0 ns 34
2511.0 ns 0d ADD 2 5d 0d 10030.0 ns 55
2591.0 ns 0e SKZ 1 20 0e 10750.0 ns 89
2671.0 ns 10 HLT 0 00 10 11470.0 ns 144
*** A HALT INSTRUCTION WAS PROCESSED BY THE CPU *** *** A HALT INSTRUCTION WAS PROCESSED BY THE CPU ***
D-50 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-51
Appendix D Lab 9 cpu.log cpu.v Appendix D Lab 9
************************************************************************** cpu.v
* THE FOLLOWING DEBUG TASKS ARE AVAILABLE: * /*************************************************************************
* Enter "test1;" to load the 1st diagnostic program, and then continue * Netlist for the VeriRisc CPU design - Verilog Training Course.
simulation. *************************************************************************/
* Enter "test2;" to load the 2nd diagnostic program, and then continue
simulation. timescale 1ns / 1ns
* Enter "test3;" to load the Fibonacci program, and then continue simulation. module cpu(reset);
* Run cwaves if you would like to see the waveforms for this lab * input reset;
**************************************************************************
wire [7:0] data, alu_out, accum;
L62 "cpu_test.v": $stop at simulation time 12230.0 ns wire [4:0] pc_addr, ir_addr, addr;
C4 > $finish; wire [2:0] opcode;
C4: $finish at simulation time 12230.0 ns
//Instantiate the main components in the design
31237 simulation events + 52300 accelerated events
CPU time: 0.7 secs to compile + 0.5 secs to link + 2.2 secs in simulation control cntl (load_acc, mem_rd, mem_wr, inc_pc, load_pc, load_ir, halt,
End of VERILOG-XL 2.1.2 Feb 8, 1995 11:02:15 opcode, fetch, zero, clock, clk2, reset);
alu alu1 (alu_out, zero, opcode, data, accum, alu_clock);
register acm (accum, clock, alu_out, load_acc, reset);
register ireg ({opcode, ir_addr}, clock, data, load_ir, reset);
mem mem1 (data, addr, mem_rd, mem_wr);
counter pc (pc_addr, inc_pc, ir_addr, reset, load_pc);
clkgen clk (fetch, clk2, clock);
//Glue logic
endmodule
D-52 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-53
Appendix D Lab 9 cpu_test.v cpu_test.v Appendix D Lab 9
cpu_test.v cpu1.halt,
/************************************************************************* cpu1.opcode,
* Test stimulus for the VeriRisc CPU design - Verilog Training Course. mnemonic, //display opcode as a mnemonic
* cpu1.data,
* This stimulus provides tasks to load and run 3 different diagnostic test cpu1.accum,
* programs. A program is loaded into the VeriRisc memory and the VeriRisc cpu1.alu_out,
* system is reset. The system should then execute the instructions cpu1.addr,
* in the program. cpu1.pc_addr,
* cpu1.ir_addr);
* This stimulus will monitor the program counter as the program runs, and $stop;
* display what instructions are being executed. The comments in the program end
* files can be used to determine if the program executed as expected.
*************************************************************************/ always @(posedge cpu1.halt) //STOP when HALT instruction decoded
begin
timescale 1ns / 1ns #30 $display("\n*** A HALT INSTRUCTION WAS PROCESSED BY THE CPU ***\n");
module cpu_test; display_debug_message;
$stop;
reg reset_req; end
integer test;
reg [(3*8):0] mnemonic; //array that holds 3 8-bit ASCII characters task display_debug_message;
begin
cpu cpu1(reset_req); //instance of the VeriRisc CPU design $display("\n
***********************************************************************");
initial //display time in nanoseconds $display(" * THE FOLLOWING DEBUG TASKS ARE AVAILABLE: *");
$timeformat(-9, 1, " ns", 12); $display(" * Enter \"test1;\" to load the 1st diagnostic program, and then
continue simulation. *");
$display(" * Enter \"test2;\" to load the 2nd diagnostic program, and then
initial //go to interactive mode at time 0
continue simulation. *");
begin
$display(" * Enter \"test3;\" to load the Fibonacci program, and then
display_debug_message; continue simulation. *");
$shm_open("lab9.shm"); $display(" * Run cwaves if you would like to see the waveforms for this lab
//$shm_probe("A"); *");
$shm_probe(cpu_test.cpu1.reset, $display("
cpu1.alu_clock, *********************************************************************\n");
cpu1.clock, end
cpu1.clk2, endtask
cpu1.fetch,
cpu1.zero,
cpu1.inc_pc,
cpu1.load_acc,
cpu1.load_pc,
cpu1.mem_wr,
cpu1.mem_rd,
cpu1.load_ir,
D-54 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-55
Appendix D Lab 9 cpu_test.v cpu_test.v Appendix D Lab 9
D-56 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-57
Appendix D Lab 9 cpu_test.v CPUtest1.dat* Appendix D Lab 9
D-58 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-59
Appendix D Lab 9 CPUtest1.dat* CPUtest2.dat Appendix D Lab 9
*************************************************************************/
D-60 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-61
Appendix D Lab 9 CPUtest3.dat run.f Appendix D Lab 9
CPUtest3.dat run.f
/************************************************************************* // This file contains the Verilog invocation commands to run
* Test program 3 for the VeriRisc CPU system, Verilog Training Course. // the VeriRisc CPU design. This run file assumes that the
* // file names referenced in other lab directories are the
* This is an actual program that calculates the Fibonacci number sequence // same name as was specified in the lab specifications.
* from 0 to 144. The Fibonacci number sequence is a series of numbers in
* which each number in the sequence is the sum of the preceding two numbers cpu_test.v
* (i.e.: 0, 1, 1, 2, 3, 5, 8, 13 ...). This number sequence is often used cpu.v
* in financial analysis, and can also be found in the patterns of pineapple clkgen.v
* shells and some flower petals.
* ../lab2-register/register.v
* WARNING: Do not run this program before the CPUtest1 and CPUtest2 ../lab4-counter/counter.v
* diagnostic programs have completed successfully. Those who do are ../lab5-alu/alu.v
* asking for endless heartache. ../lab7-mem/mem.v
*************************************************************************/
../lab8-control/control.v
D-62 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-63
Appendix D Lab 10 dff.v dff_udp.v Appendix D Lab 10
Lab 10 dff_udp.v
/*************************************************************************
dff.v * UDP definition for the basic fucntionality of a D Flip-Flop - Verilog
/************************************************************************* * Training Course, Lab 10.
*************************************************************************/
* D Flip-Flop model using a UDP - Verilog Training Course, Lab 10.
*************************************************************************/
primitive dflop(q, d, clk, rst);
output q;
module dff(q, qb, clk, d, rst);
input d, clk, rst;
output q, qb;
input clk, d, rst;
reg q;
dflop (qt, d, clk, rst);
table
buf (q, qt);
// d clk rst : q_old : q_new
not (qb, qt);
? ? 0 : ? : 0;
? ? x : 0 : 0;
specify
0 (01) 1 : ? : 0;
1 (01) 1 : ? : 1;
$setuphold(posedge clk &&& rst, d &&& rst, 3:5:6, 2:3:6);
? (10) 1 : ? : -;
(??) ? ? : ? : -;
(rst *> q, qb) = 3;
? ? (??) : ? : -;
(clk *> q) = (2:3:5, 4:5:6);
endtable
(clk *> qb) = (2:4:5, 3:5:6);
endprimitive
endspecify
endmodule
D-64 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-65
Appendix D Lab 10 test.v test.v Appendix D Lab 10
test.v initial
/************************************************************************* begin
* Stimulus to test the D Flip-Flop model with timing checks - Verilog $shm_open("lab10.shm");
* Training Course, Lab 10. $shm_probe("A");
* #1 $stop;
* This stimulus should cause timing violations under the following end
* conditions:
* endmodule
* with Minimum Delays: No violations
* with Typical Delays: A setup violation
* with maximum Delays: A setup and a hold violation
*************************************************************************/
module test;
initial
begin
end
D-66 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-67
Appendix D Lab 11 register.v register.v_fixed Appendix D Lab 11
Lab 11 register.v_fixed
/*************************************************************************
register.v * 8-bit register with hierarchy, Verilog Training Course, lab 11
/*************************************************************************
*************************************************************************/
* 8-bit register with hierarchy, Verilog Training Course, lab 11
module register(r, clk, data, ena, rst);
*************************************************************************/ output [7:0] r;
module register(r, clk, data, ena, rst); input [7:0] data;
output [7:0] r; input clk, ena, rst;
input [7:0] data;
input clk, ena, rst; wire [7:0] data, r;
endmodule
D-68 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-69
Appendix D Lab 11 register_test.v register_test.v Appendix D Lab 11
register_test.v initial
/************************************************************************* begin
* Stimulus for testing the 8-bit Register - Verilog Training Course, lab 11 error=0;
#20 if(reg_out !== 8'b00000000) begin $display($stime,,"out should be
*************************************************************************/ 8'b00000000 but is 8'b%b",reg_out); error=1; end
module test; #20 if(reg_out !== 8'b11111111) begin $display($stime,,"out should be
8'b11111111 but is 8'b%b",reg_out); error=1; end
wire [7:0] reg_out; //declare vector for register output
#20 if(reg_out !== 8'b01010101) begin $display($stime,,"out should be
reg [7:0] data;
8'b01010101 but is 8'b%b",reg_out); error=1; end
reg ena, rst, start, error;
if (error==0) $display("********** TEST PASSED **********");
else $display("********** TEST FAILED **********");
register r1(reg_out, clk, data, ena, rst);
end
D-70 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-71
Appendix D Lab A buffer.v computer.v Appendix D Lab A
Lab A computer.v
// define QUEUE_ID 0
buffer.v
module computer;
module buffer;
integer SEED , MEAN;
/* A number of 20 overflows, over a period of 40.000 time unit, integer job_id;
is acceptable */ integer delay;
integer status;
integer MAX_LENGTH; integer NUMBER_OF_OVERFLOWS;
integer status;
reg queue_value;
initial
begin
initial SEED = 1; MEAN = 60;
begin job_id = 1;
NUMBER_OF_OVERFLOWS = 0;
MAX_LENGTH = 27; end
// Initialize the queue and check for errors always
$q_initialize (QUEUE_ID, 1, MAX_LENGTH, status); /* Print Warning Messages if the queue is full
if(status !==0) else put a new job in the queue */
begin begin
// $display("status = %d", status); delay= $dist_poisson(SEED, MEAN);
$display("ERROR INITIALIZING THE QUEUE IN THE BUFFER"); #delay;
$finish; if($q_full(QUEUE_ID, status))
end begin
end $display("WARNING - OVERFLOW at time%d for job_id#%d",
$time,job_id);
endmodule NUMBER_OF_OVERFLOWS = NUMBER_OF_OVERFLOWS + 1;
end
else
begin
$q_add(QUEUE_ID, job_id, 0,status);
job_id = job_id + 1;
end
end
endmodule
D-72 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-73
Appendix D Lab A disk.v system.v Appendix D Lab A
disk.v system.v
// define QUEUE_ID 0 define QUEUE_ID 1
endmodule
D-74 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-75
Appendix D Lab B pull_ud.v test.v Appendix D Lab B
Lab B test.v
// switch resistive cmos_1
pull_ud.v switch resistive default
timescale 1ns/1ps
module pull_ud( cnt,a, b, c, y );
input a, b, c,cnt; module test;
output y; reg a, b, c,cnt;
trireg (* const real capacitance = 1.1; *) y; trireg y;
trireg a, b, c;
supply1 vdd; pull_ud ud(cnt,a,b,c,y);
supply0 gnd;
// initial
// switch resistive cmos_1 begin
switch resistive default $timeformat(-9,2,"ns",5);
tranif0 (* const real width=10, length=1; *) p1( vdd ,y ,cnt ); cnt=0;
tranif1 (* const real width=10, length=1; *) n1(y , gnd , a ); a = 0;
tranif1 (* const real width=10, length=1; *) n2(y , gnd , b ); b = 0;
tranif1 (* const real width=2, length=1; *) n3(y , gnd , c ); c = 0;
// #40 cnt=1'b1;
endmodule a = 1;
b = 0;
c = 0;
#20 a = 1'b0;
cnt=0;
#40 a = 0;
b = 1;
c = 0;
cnt=1;
#20 b = 1'b0;
cnt=0;
#40 a = 0;
b = 0;
c = 1;
cnt=1;
#20 c = 1'b0;
cnt=0;
#10 a=0; b=0; c=0;
cnt=1;
#10 $stop;
end
// Display results
initial
$monitor("%t a=%b b=%b c=%b y=%b",$realtime,a,b,c,y);
endmodule
D-76 Cadence Design Systems, Inc. 6/29/95 6/29/95 Cadence Design Systems, Inc. D-77