Transcript CS 153 Logic Design Lab Professor Ian G. Harris Department of Computer Science

CS 153
Logic Design Lab
Professor Ian G. Harris
Department of Computer Science
University of California Irvine
Purpose of the Course
•
•
•
•
•
Lab companion to CS 151
Design and simulate combinational and sequential logic
Learn basic Verilog
Use an industrial simulation tool (Synopsys)
Understand the internal simulation process to appreciate
its imprecision
Reading Material
• No required book.
• Digital Logic Design (CS 151) book is useful
• Some Verilog book is useful (some are on reserve at the
library)
• Links to Verilog resources are provided on the web page
System Design Flow
Intent
Nat. Lang. Spec.
Exec. Behavior
Designer’s Intent: Vague idea of behavior known only to designer.
Natural Language Specification: “Complete” behavioral description
Written in English (or other).
Executable Behavior: A simulatable description of the behavior.
Written in a procedural language (SystemVerilog, SystemC, …)
HW Design
SW Design
Pre-Designed
HW Behavioral
SW Procedural
COTS HW/SW
HW Structural
Machine Code
Fabrication
Embedded System
Hardware Description Languages
•Languages used to describe hardware designs
•Can be used for synthesis or simulation
•Synthesis is manufacturing an Application Specific Integrated
Circuit (ASIC) or mapping to a Field Programmable Gate Array
(FPGA)
Performance/Area/Power are a priority

•Simulation is for the purpose of checking functionality
Simulation must match the real world

•In this class we are doing simulation, not synthesis
Hardware Design
Behavioral Design vs. Structural Design
c=a+b
f=d+e
if (g)
out = c;
else
out = f;
•Behavioral design describes
functionality as a sequence of
steps.
•Structural design describes an
interconnection of components.
a
b
d
e
g
+
out
+
Structural Description, Modules
module T_FF (q, clock, reset);
.
.
.
.
endmodule
•Represents a physical component, can be instantiated many times
•I/O ports declared at the top
•Typically represents a physical component
•Can be structurally connected to other components
•Cannot be invoked like a function
Instances
module TFF(q, clk, reset);
output q;
input clk, reset;
wire d;
DFF dff0(q, d, clk, reset);
not n1(d, q);
endmodule
module ripple_carry_counter(q, clk, reset);
output [3:0] q;
input clk, reset;
//4
TFF
TFF
TFF
TFF
instances of the module TFF are created.
tff0(q[0],clk, reset);
tff1(q[1],q[0], reset);
tff2(q[2],q[1], reset);
tff3(q[3],q[2], reset);
endmodule
•TFF is instantated within ripple_carry_counter
•DFF and not are instantiated within TFF
•Structural interconnect is established through instantiation
Testbench (Stimulus Block)
module stimulus;
reg clk;
reg reset;
wire[3:0] q;
// instantiate the design block
ripple_carry_counter r1(q, clk, reset);
// Control the clock
initial clk = 1'b0;
always #5 clk = ~clk;
// Control the reset
initial
begin
reset = 1'b1;
#15 reset = 1'b0;
#180 reset = 1'b1;
#10 reset = 1'b0;
#20 $stop;
end
// Monitor the outputs
initial
$monitor($time, " Output q = %d",
endmodule
•The testbench generates the input stimulus
•Observation of data is often included in the testbench
q);