Upload
griselda-french
View
214
Download
1
Tags:
Embed Size (px)
Citation preview
GEZEL Modeling and Simulation
Patrick Schaumont
Virginia TechDept. of Electrical and Computer Engineering
September 2010
2
Outline
• RTL Architecture vs Modeling• Datapath
• Cycle-based modeling• Expressions in hardware• Modules
• Finite State Machines• FSMD
• Tools• Simulation• Value Change Dump
• Hierarchy• Semantics
• Proper FSMD• Transformations
• Library Modules• Examples
3
RTL
• RTL = Register Transfer Level• An abstraction level above logic gates that
abstracts time in clock cycles
LogicFunction
R2 R1
R1= LogicFunction(R2) 1 RegisterTransfer
4
RTL
• The Logic Function can be anything that can be computed in a single clock cycle
LogicFunction
R2 R1
One Clock Cycle
5
RTL
• Bit-parallel description: R2 and R1 can be wider than a single bit
LogicFunction
R2 R1
One Clock Cycle
= =
6
RTL
• For example, Logic Function = inversion• R1 = ~R2
• Number of inverters = Wordlength of R2
• WL R1 = WL R2
R2 R1
n
8
RTL
• RTL is Technology Independent• How much work you can do in a clock cycle
• depends on the target technology used to implement the Logic Function
• depends on the clock frequency selected for the design
LogicFunction
R2 R1
9
RTL
• Therefore, the RTL designer needs to make sure that the Logic Function will be able to complete within a single clock cycle
R2 R1
n
R2 R1
mult
n
n2n
short delay
long delay
one clock cycle
short delay
long delay
timingviolation
10
RTL
• So RTL is a ...• bit-parallel,• technology-independent,• (and, in this course)
synchronous, single-clock
way to model hardware implementations
11
Simulation Cycle
• The simulation cycle of RTL goes through two phases:• Evaluate (Logic Function)• Update (Registers)
LogicFunction
R2 R1
12
Simulation Cycle
• The simulation cycle of RTL goes through two phases:• Evaluate (Logic Function)• Update (Registers)
LogicFunction
R2 R1
Evaluate: Read output of R2, Calculate Logic, Determine input of R1Update: For all registers, copy the input value to the output value
13
Simulation Cycle
• The simulation cycle of RTL goes through two phases:• Evaluate (Logic Function)• Update (Registers)
LogicFunction
R2 R1one clock cycle
Evaluate Update
14
Simulation Cycle
• All evaluate phases are evaluated simultaneously (like real hardware)• Input R2 = LogFun1(Output R3) and
Input R1 = LogFun2(Output R2)
LogicFunction
1
R3 R2
LogicFunction
2
R1
15
Equivalent Finite State Machine
LogicFunction
1
R3
R2
LogicFunction
2
R1
R3
R2
R1
Current ClockCycle
Next ClockCycle
LogicFunction
1
R3 R2
LogicFunction
2
R1
(not a physical wire)
you can think of this as
16
Equivalent Finite State Machine
• Arbitrary networks of logic and registers can always be reduced to single, equivalent finite state machine
LogicFunction
R R
LogicFunction
R
Current ClockCycle
Next ClockCycle
implemented as:
17
Simulation
• Cycle-based Simulation has two phases ...• Evaluate:
to calculate the outputs of the logic gates• Update:
to determine the outputs of registers
one clock cycle
Just after the edge,you know only the outputs of the registers
Just before the edge,you have determinedthe inputs of the registers
18
RTL Modeling
• There are many languages available for RTL Modeling: VHDL, Verilog are mainstream. Others are SystemC, BlueSpec, MyHDL, ..
• We use GEZEL• http://rijndael.ece.vt.edu/gezel
• Anything you write in GEZEL, you can also write in VHDL, Verilog, SystemC
• GEZEL can also be translated (automatically) into VHDL
19
Outline
• RTL Architecture vs Modeling• Datapath
• Cycle-based modeling• Expressions in hardware• Modules
• Finite State Machines• FSMD
• Tools• Simulation• Value Change Dump
• Hierarchy• Semantics
• Proper FSMD• Transformations
• Library Modules• Examples
21
Expressions in Hardware
• 3-bit counter• reg is a register variable• ns(3) means unsigned, 3-bit• Note that the clock signal is implicit
add 1
R1reg r1 : ns(3);always { r1 = r1 + 1;}
22
Expressions in Hardware
reg r1 : ns(3);always { r1 = r1 + 1;}
Cycle Input r1Output r1
0 10123456789
Registers are assumed to be 0 in cycle 0(Like the clock signal, the reset signal is implicit)
23
Expressions in Hardware
reg r1 : ns(3);always { r1 = r1 + 1;}
Cycle Input r1Output r1
0 101 212 323 434 545 656 76789
What happens in cycle 7?
24
Expressions in Hardware
reg r1 : ns(3);always { r1 = r1 + 1;}
Cycle Input r1Output r1
0 101 212 323 434 545 656 767 078 109 21
Overflow to zero!
25
Wire Variables
reg r : ns(3);sig v : ns(3);always { v = r + 1; r = v << 1;}
• sig is a wire variable• Wires have no memory; they are aliases for
expressions
add 1
R
<< 1V
26
Wire Variables
Cycle Input rOutput r
0 0123
reg r : ns(3);sig v : ns(3);always { v = r + 1; r = v << 1;}
27
Wire Variables
Cycle Input rOutput r
0 201 223
reg r : ns(3);sig v : ns(3);always { v = r + 1; r = v << 1;}
28
Wire Variables
Cycle Input rOutput r
0 201 622 63 6
reg r : ns(3);sig v : ns(3);always { v = r + 1; r = v << 1;}
29
Wire Variables
Cycle Input rOutput r
0 201 622 663 66
reg r : ns(3);sig v : ns(3);always { v = r + 1; r = v << 1;}
(1 1 0) + 1 = (1 1 1)(1 1 1) << 1 = (1 1 1 0)(1 1 1 0) on ns(3) = (1 1 0)
30
Lexical Order
reg r : ns(3);sig v : ns(3);always { v = r + 1; r = v << 1;}
• Lexical order of expressions is irrelevant• Assignment on sig can be substituted on the
expression
reg r : ns(3);sig v : ns(3);always { r = v << 1; v = r + 1;}
=
31
Lexical Order
reg r : ns(3);reg v : ns(3);always { v = r + 1; r = v << 1;}
• Lexical order of expressions is irrelevant• Assignment on reg are all parallel
reg r : ns(3);reg v : ns(3);always { r = v << 1; v = r + 1;}
=
How does this circuit look like?
32
Lexical Order
reg r : ns(3);reg v : ns(3);always { v = r + 1; r = v << 1;}
• Lexical order of expressions is irrelevant• Assignment on reg are all parallel
reg r : ns(3);reg v : ns(3);always { r = v << 1; v = r + 1;}
=
RV << 1 + 1
33
Lexical Order
• The detailed steps taken by the simulator are as follows:
reg r : ns(3);sig v : ns(3);always { r = v << 1; v = r + 1;}
• At the start of a clock cycle, only r (reg) is known• We cannot evaluate v<<1 until we know v• Therefore, the simulator will first evaluate v = r + 1• Next, the simulator can evaluate the new value for
r
34
Another Example
reg r : tc(3);sig v1, v2 : tc(3);always { v2 = -r; v1 = (r < 0) ? v2 : r; r = (v1 << 1) | 1;}
• tc(3) is a two's complement 3-bit value• | is a bitwise-or• What is the structural equivalent of this
design?
35
Another Example
reg r : tc(3);sig v1, v2 : tc(3);always { v2 = -r; v1 = (r < 0) ? v2 : r; r = (v1 << 1) | 1;}
• tc(3) is a two's complement 3-bit value• | is a bitwise-or
R<0
unary-
(<<1)| 1
v2
v1
36
Expressions in Hardware
reg r : tc(3);sig v1, v2 : tc(3);always { v2 = -r; v1 = (r < 0) ? v2 : r; r = (v1 << 1) | 1;}
• tc(3) is a two's complement 3-bit value• | is a bitwise-or• What is the behavior of this design?
Cycle Read R V1 Write R
0 01
2
3
4
37
Expressions in Hardware
reg r : tc(3);sig v1, v2 : tc(3);always { v2 = -r; v1 = (r < 0) ? v2 : r; r = (v1 << 1) | 1;}
• tc(3) is a two's complement 3-bit value• | is a bitwise-or
Cycle Read R V1 Write R
0 0 0 11 1 1 3
2 3 3 -1
3 -1 1 3
4 3 3 -1
38
Impossible Design?
• What is the meaning of this design?
sig b : ns(3);always { b = b + 1;}
add 1
b
39
Impossible Design?
• What is the meaning of this design?• We cannot know b without knowing b ..• This is construction is invalid in RTL• Simulator flags this as a design error
('combinational loop')
sig b : ns(3);always { b = b + 1;}
add 1
b
41
Impossible Design?
• Does this solve the issue ?• No ! • The dependencies through wire variables still
show a loop
sig a, b : ns(3);always { a = b + 1; b = a;}
add 1
ab
42
GEZEL Operators
• GEZEL operators = Most C operators that can be conveniently mapped to a hardware implementation• Bitwise: a|b, a&b, a^b, ~a• Selection: a ? b : c• Arithmetic: a+b, a-b, a*b, -a• Arithmetic: a<<n, a>>n• Comparison: a<b, a>b, a<=b, a>=b, a!=b, a==b
• Tricky operators (not supported):• Division, Modulo, Power• Math functions
43
GEZEL Operators
• Data types are signed (tc), unsigned (ns), arbitrary-wordlength
• Bit & type manipulation operators• Bit-selection: a[2]
a = 1 0 1 1 -> a[2] = 0• Sub-vector: a[3:2]
a = 1 0 1 1 -> a[3:2] = a[2:3] = 1 0• Concatenation: a # b
a = 1 0 0 b = 1 1 -> a # b = 1 0 0 1 1• Cast: (type) a
a = 0 1 0 -> (ns(2)) a = 1 0 (decimal: 2) a = 0 1 0 -> (tc(2)) a = 1 0 (decimal: -2)
44
GEZEL Operators
• What does this implement ?
reg shift, seed : ns(5);reg ld : ns(1);always { shift = ld ? seed : (shift << 1) | (shift[1] ^ shift[4]); }
45
GEZEL Operators
• What does this implement ?
reg shift, seed : ns(5);reg ld : ns(1);always { shift = ld ? seed : (shift << 1) | (shift[1] ^ shift[4]); }
0 1 2 3 4
seed[0] ld ld ld ld ldseed[1] seed[2] seed[3] seed[4]
46
GEZEL Operators
• What does this implement ?
reg v : ns(6);sig j : ns(3);always { j = 3; v = (tc(1)) j;}
47
GEZEL Operators
• What does this implement ?
reg v : ns(6);sig j : ns(3);always { j = 3; v = (tc(1)) j;}
j
v
j[0]
48
Lookup Tables
• There are no array variables (or for-loops)• There are lookup tables for constant arrays
reg adr : ns(3);sig value : ns(8);lookup T1 : ns(8) = {5, 1, 3, 2, 4, 3, 6, 7};always { value = T1(adr);}
49
Modules
• Expressions by themselves can be encapsulated in modules which have input and output ports
• Modules promote design reuse, abstraction
XOR Module
A
B
Q
50
Modules
• Input- and Output ports
dp accumulator(in i : ns(3); out o : ns(3)) { reg a : ns(3); always { a = a + i; o = a;}
a+ oi
accumulator
51
Modules
• Let's try GCD ..
dp gcd(in ld : ns(1); in a_in, b_in : ns(10); out result : ns(10); out done : ns(1)) { reg a, b : ns(10); always { a = ld ? a_in : (a > b) ? a - b : a; b = ld ? b_in : (a > b) ? b : b - a; done = (a == b); result = (a == b) ? a : 0; }}
52
Modules
• Input/output ports
dp gcd(in ld : ns(1); in a_in, b_in : ns(10); out result : ns(10); out done : ns(1)) { reg a, b : ns(10); always { a = ld ? a_in : (a > b) ? a - b : a; b = ld ? b_in : (a > b) ? b : b - a; done = (a == b); result = (a == b) ? a : 0; }}
ld a_in b_in
result done
53
Modules
• Register-transfer expressions ..
dp gcd(in ld : ns(1); in a_in, b_in : ns(10); out result : ns(10); out done : ns(1)) { reg a, b : ns(10); always { a = ld ? a_in : (a > b) ? a - b : a; b = ld ? b_in : (a > b) ? b : b - a; done = (a == b); result = (a == b) ? a : 0; }}
a
a
ba_in
> -
54
Outline
• RTL Architecture vs Modeling• Datapath
• Cycle-based modeling• Expressions in hardware• Modules
• Finite State Machines• FSMD
• Tools• Simulation• Value Change Dump
• Hierarchy• Semantics
• Proper FSMD• Transformations
• Library Modules• Example
55
Control Design in RTL
• So far, we only discussed expressions inside of modules
• We can describe control, but it needs to be modeled explicitly
dp gcd(in ld : ns(1); in a_in, b_in : ns(10); out result : ns(10); out done : ns(1)) { reg a, b : ns(10); always { a = ld ? a_in : (a > b) ? a - b : a; b = ld ? b_in : (a > b) ? b : b - a; done = (a == b); result = (a == b) ? a : 0; }}
56
Control Design in RTL
• So far, we only discussed expressions inside of modules
• We can describe control, but it needs to be modeled explicitly
• We will describe an RTL model that combines (datapath) expressions with Finite State Machines
FSMD
57
Control Design in RTL
• The controller is able to select between different logic functions through commands
R2 R1
state
next-state
fA
fB
controller
multifunctionaldatapath
command
58
Control Design in RTL
• GCD datapath w/ two commands: load, work
dp count(in ld : ns(1); in a_in, b_in : ns(10); out result : ns(10); out done : ns(1)) { reg a, b : ns(10); reg ldr : ns(1); always { ldr = ld; done = (a == b); } sfg load { a = a_in; b = b_in; } sfg work { a = (a > b) ? a - b : a; b = (a > b) ? b : b - a; }}
ld a_in b_in
result done
cmdloadwork
59
Control Design in RTL
• Compare:
with:
sfg load { a = a_in; b = b_in; } sfg work { a = (a > b) ? a - b : a; b = (a > b) ? b : b - a; }
always { a = ld ? a_in : (a > b) ? a - b : a; b = ld ? b_in : (a > b) ? b : b - a;}
60
Control Design in RTL
• When work executes the datapath is equivalent to:
dp count(in ld : ns(1); in a_in, b_in : ns(10); out result : ns(10); out done : ns(1)) { reg a, b : ns(10); reg ldr : ns(1); always { ldr = ld; done = (a == b); a = (a > b) ? a - b : a; b = (a > b) ? b : b - a; }}
61
Control Design in RTL
• When load executes the datapath is equivalent to:
dp count(in ld : ns(1); in a_in, b_in : ns(10); out result : ns(10); out done : ns(1)) { reg a, b : ns(10); reg ldr : ns(1); always { ldr = ld; done = (a == b); a = a_in; b = b_in; }}
62
Control Design in RTL
• The commands are generated in an FSM controller
dp count(..) { sfg load {..} sfg work {..}}
fsm ctl_count(count) { initial s0; state s1; @s0 (load) -> s1; @s1 (work) -> s1;}
ld a_in b_in
result done
cmd
loadwork
FSM
63
Control Design in RTL
• The controller is a finite state machine
dp count(..) { sfg load {..} sfg work {..}}
fsm ctl_count(count) { initial s0; state s1; @s0 (load) -> s1; @s1 (work) -> s1;}
S0
S1
_/load
_/work
64
Control Design in RTL
• A controller can also implement decisions
dp count(in ld : ns(1); ..) { reg ldr : ns(1); always {ldr = ld;} sfg load {..} sfg work {..}}
fsm ctl_count(count) { initial s0; state s1; @s0 if (~ldr) then (load) -> s0; else (work) -> s1; @s1 (work) -> s1;}
S0
S1
ldr/work
_/work
~ldr/load
65
Control Design in RTL
• A controller can also implement decisions
dp count(in ld : ns(1); ..) { reg ldr : ns(1); always {ldr = ld;} sfg load {..} sfg work {..}}
fsm ctl_count(count) { initial s0; state s1; @s0 if (~ldr) then (load) -> s0; else (work) -> s1; @s1 (work) -> s1;}
ld a_in b_in
result done
loadwork
FSMldr
Decisions requirestatus signals
66
Control Design in RTLdp count(in ld : ns(1); in a_in, b_in : ns(10); out result : ns(10); out done : ns(1)) { reg a, b : ns(10); reg ldr : ns(1); always { ldr = ld; done = (a == b); } sfg load { a = a_in; b = b_in; } sfg work { a = (a > b) ? a - b : a; b = (a > b) ? b : b - a; }}fsm ctl_count(count) { initial s0; state s1; @s0 if (~ldr) then (load) -> s0; else (work) -> s1; @s1 (work) -> s1;}
Withseparatedcontroldescription
FSMDFinite State Machine
+ Datapath
67
Control Design in RTL
dp gcd(in ld : ns(1); in a_in, b_in : ns(10); out result : ns(10); out done : ns(1)) { reg a, b : ns(10); always { a = ld ? a_in : (a > b) ? a - b : a; b = ld ? b_in : (a > b) ? b : b - a; done = (a == b); result = (a == b) ? a : 0; }}
Withintegrateddatapathandcontrol
68
FSMD vs plain RTL
• FSMD avoids writing multiplexers (a ? b : c)• FSMD keeps data processing and control
sequencing separated• FSMD allows the designer to use symbolic
control states
69
FSMD
state
next-state
state
next-state
datapath
FSM
status
command
• Logically, an FSMD is two FSM stacked on top of one another
70
Outline
• RTL Architecture vs Modeling• Datapath
• Cycle-based modeling• Expressions in hardware• Modules
• Finite State Machines• FSMD
• Tools• Simulation• Value Change Dump
• Hierarchy• Semantics
• Proper FSMD• Transformations
• Library Modules• Example
72
Example: Kernel
dp gcd(in ld : ns(1); in a_in, b_in : ns(10); out result : ns(10); out done : ns(1)) { reg a, b : ns(10); always { a = ld ? a_in : (a>b) ? a - b : a; b = ld ? b_in : (a>b) ? b : b-a; $display($cycle, $hex " a ", a, " b ", b); done = (a == b); result = (a == b) ? a : 0; }}
73
Example: TestBench
dp gcdtst(out ld : ns(1); out a, b : ns(10)) { sfg load { ld = 1; a = 20; b = 24; } sfg idle { ld = 0; a = 0; b = 0; }}fsm f_gcdtst(gcdtst) { initial s0; state s1; @s0 (load) -> s1; @s1 (idle) -> s1;}
system S { gcd(ld, a, b, r, done); gcdtst(ld, a, b);}
GCD
GCDTST
a b ld
a b ld
r done
79
Outline
• RTL Architecture vs Modeling• Datapath
• Cycle-based modeling• Expressions in hardware• Modules
• Finite State Machines• FSMD
• Tools• Simulation• Value Change Dump
• Hierarchy• Semantics
• Proper FSMD• Transformations
• Library Modules
80
Hierarchy
• Hierarchy is commonly used in hardware to support reuse and abstraction
• Key idea: Modules can include other modules, rather than expressions
XOR Module
A
B
Q
Write this module once: Use (copies of) this module many times:
xor1
xor2
xor3
81
Hierarchy
dp and1(in a, b : ns(1); out q : ns(1)) { always { q = a & b; }}dp and2 : and1dp or (in a, b : ns(1); out q : ns(1)) { always { q = a | b; }}dp not1(in a : ns(1); out q : ns(1)) { always { q = ~a; }}dp not2 : not1dp xor(in a, b : ns(1); out q : ns(1)) { sig ia, ib, q1, q2 : ns(1); use not1(a, ia); use not2(b, ib); use and1(a, ib, q1); use and2(ia, b, q2); use or(q1, q2, q); always { $display("q1 ", q1, " q2 ", q2); }}
82
Hierarchy
dp and1(in a, b : ns(1); out q : ns(1)) { always { q = a & b; }}dp and2 : and1dp or (in a, b : ns(1); out q : ns(1)) { always { q = a | b; }}dp not1(in a : ns(1); out q : ns(1)) { always { q = ~a; }}dp not2 : not1dp xor(in a, b : ns(1); out q : ns(1)) { sig ia, ib, q1, q2 : ns(1); use not1(a, ia); use not2(b, ib); use and1(a, ib, q1); use and2(ia, b, q2); use or(q1, q2, q); always { $display("q1 ", q1, " q2 ", q2); }}
use = instantiate another module (dp)
83
Hierarchy
dp and1(in a, b : ns(1); out q : ns(1)) { always { q = a & b; }}dp and2 : and1dp or (in a, b : ns(1); out q : ns(1)) { always { q = a | b; }}dp not1(in a : ns(1); out q : ns(1)) { always { q = ~a; }}dp not2 : not1dp xor(in a, b : ns(1); out q : ns(1)) { sig ia, ib, q1, q2 : ns(1); use not1(a, ia); use not2(b, ib); use and1(a, ib, q1); use and2(ia, b, q2); use or(q1, q2, q); always { $display("q1 ", q1, " q2 ", q2); }}
: = create an exact copy of an existing module
84
Outline
• RTL Architecture vs Modeling• Datapath
• Cycle-based modeling• Expressions in hardware• Modules
• Finite State Machines• FSMD
• Tools• Simulation• Value Change Dump
• Hierarchy• Semantics
• Proper FSMD• Transformations
• Library Modules• Example
85
Semantics
• We already discussed that some GEZEL (RTL) programs are invalid constructions
sig b : ns(3);always { b = b + 1;}
add 1
b
86
Semantics
• We can define a fixed set of rules that will guarantee that a given hardware description translates to valid hardware
• Rule #1: During any clock cycle, no circular definition may exist between signals• No circular dependencies, even across multiple
modules (input-output connections)• All signals (wires) must eventually be defined in
terms of registers or constants
87
Semantics
• We can define a fixed set of rules that will guarantee that a given hardware description translates to valid hardware
• Rule #2: Any signal (wire) that is read during a clock cycle, must also be defined in the same clock cycle• There can be no unknowns among the
operands of any expression (there can be no 'X'es in the simulation)
• Since a wire has no storage, it means there must be an expression that defines a value for that wire
88
Semantics
• We can define a fixed set of rules that will guarantee that a given hardware description translates to valid hardware
• Rule #3: During any clock cycle, all output ports of a module must be defined (assigned)• No outputs can remain unknown, so that any
module which reads the outputs will always obtain a stable value
89
Semantics
• We can define a fixed set of rules that will guarantee that a given hardware description translates to valid hardware
• Rule #4: Each signal/register may be assigned only once during a clock cycle• Signal/register definitions must always be
unambiguous
90
Semantics
• Rule #1: During any clock cycle, no circular definition may exist between signals
• Rule #2: Any signal (wire) that is read during a clock cycle, must also be defined in the same clock cycle
• Rule #3: During any clock cycle, all output ports of a module must be defined (assigned)
• Rule #4: Each signal/register may be assigned only once during a clock cycle
91
Semantics
• An FSMD that complies with these 4 rules is called a proper FSMD
• We can prove (mathematically) that networks of proper FSMD are race-free: there will never be any 'X' or 'U' in the simulation
• The GEZEL simulator enforces the rules for proper FSMD at runtime• You will get simulation error when your FSMD is
not proper.
96
Outline
• RTL Architecture vs Modeling• Datapath
• Cycle-based modeling• Expressions in hardware• Modules
• Finite State Machines• FSMD
• Tools• Simulation• Value Change Dump
• Hierarchy• Semantics
• Proper FSMD• Transformations
• Library Modules• Example
97
Library Modules
• Most of our design efforts will be in solving hardware/software co-design problems
• The simulation models need to do more than simulate just hardware; the models also include non-hardware components
• Typical Example:
ARM Instruction-SetSimulator
GEZEL HardwareSimulation Kernel
C programfor ARM
GEZELProgram
98
ipblock = Library Modules
• GEZEL provides a generic way to model non-FSMD components: Library Modules
• Library Modules are used to capture• RAM Blocks• Test-bench modules, eg. random number
generator• HW/SW interfaces of microprocessors• Microprocessors• and many more ..
99
Library Modules
ipblock RAM(in address : ns(3); in wr, rd : ns(1); in idata : ns(8); out odata : ns(8)) { iptype "ram"; ipparm "size = 8"; ipparm "wl = 8";}
Interface similar to FSMD
100
Library Modules
ipblock RAM(in address : ns(3); in wr, rd : ns(1); in idata : ns(8); out odata : ns(8)) { iptype "ram"; ipparm "size = 8"; ipparm "wl = 8";}
iptype specifies the kindof library module.In this case, a RAM
101
Library Modules
ipblock RAM(in address : ns(3); in wr, rd : ns(1); in idata : ns(8); out odata : ns(8)) { iptype "ram"; ipparm "size = 8"; ipparm "wl = 8";}
ipparm specifies additional parametersIn this case, number ofpositions and wordlength
102
Library Modules
In all other respects, ipblock work just like other modules (dp)dp ramreader { reg a : ns(3); reg di : ns(8); sig do : ns(8); sig wr, rd : ns(1); use RAM(a, wr, rd, di, do); always { $display($cycle, " a ", a, " di ", di, " do ", do, " wr ", wr, " rd ", rd); a = a + 1; } sfg write { wr = 1; rd = 0; di = di + 1; } sfg read { wr = 0; rd = 1; }}fsm c_ramreader(ramreader) { initial s0; state s1; @s0 if (a == 7) then (read) -> s1; else (write) -> s0; @s1 if (a == 7) then (write) -> s0; else (read) -> s1;}system S { ramreader;}
> fdlsim ramreader.fdlram: set size 8ram: set wl 80 a 0/1 di 0/1 do 0 wr 1 rd 01 a 1/2 di 1/2 do 0 wr 1 rd 02 a 2/3 di 2/3 do 0 wr 1 rd 03 a 3/4 di 3/4 do 0 wr 1 rd 04 a 4/5 di 4/5 do 0 wr 1 rd 05 a 5/6 di 5/6 do 0 wr 1 rd 06 a 6/7 di 6/7 do 0 wr 1 rd 07 a 7/0 di 7/7 do 0 wr 0 rd 18 a 0/1 di 7/7 do 0 wr 0 rd 19 a 1/2 di 7/7 do 0 wr 0 rd 110 a 2/3 di 7/7 do 1 wr 0 rd 111 a 3/4 di 7/7 do 2 wr 0 rd 112 a 4/5 di 7/7 do 3 wr 0 rd 1
103
Outline
• RTL Architecture vs Modeling• Datapath
• Cycle-based modeling• Expressions in hardware• Modules
• Finite State Machines• FSMD
• Tools• Simulation• Value Change Dump
• Hierarchy• Semantics
• Proper FSMD• Transformations
• Library Modules• Examples
104
Recap - the FSMD model
• Write cycle-accurate hardware descriptions with expressions on reg and sig variables
• Group expressions in datapath instructions• always - instruction executed every cycle• sfg xyz - instruction executed in a given cycle
(determined through a controller)
• Capture controller in a FSM• Every clock cycle, one transition can select one
or more datapath instructions• Transitions may use datapath reg as conditions
105
Updown Counter
dp updown(in dn : ns(1); out c : ns(8)) { reg cnt : ns(3); reg dnr : ns(1); always { dnr = dn; c = cnt; } sfg up { cnt = cnt + 1; } sfg down { cnt = cnt - 1; }}fsm ctl_updown(updown) { initial s0; state s1; @s0 if (dnr) then (down) -> s1; else (up) -> s0; @s1 if (~dnr) then (up) -> s0; else (down) -> s1;}dp drive(out s : ns(1); in c : ns(8)) { reg k : ns(5); always { k = k + 1; s = k[3]; $display($cycle, " s=", s, " c=", c); }}system S { updown(s, c); drive(s, c);}
106
Updown Counter
dp updown(in dn : ns(1); out c : ns(8)) { reg cnt : ns(3); reg dnr : ns(1); always { dnr = dn; c = cnt; } sfg up { cnt = cnt + 1; } sfg down { cnt = cnt - 1; }}fsm ctl_updown(updown) { initial s0; state s1; @s0 if (dnr) then (down) -> s1; else (up) -> s0; @s1 if (~dnr) then (up) -> s0; else (down) -> s1;}
cnt+1
-1
s0
s1
dnr
~dnr/up dnr/down
dnr/down
~dnr/up
108
Simulate Updown Counter
cnt+1
-1
s0
s1
dnr
~dnr/up dnr/down
dnr/down
~dnr/up
one clock cycle
just after the clock edge, weevaluate the FSMD
step 1: determine state transition1
109
Simulate Updown Counter
cnt+1
-1
s0
s1
dnr
~dnr/up dnr/down
dnr/down
~dnr/up
one clock cycle
just after the clock edge, weevaluate the FSMD
step 1: determine state transitionif (S == s0) and (dnr == 1)we select sfg down and go to s1.
1
110
Simulate Updown Counter
cnt+1
-1
s0
s1
dnr
~dnr/up dnr/down
dnr/down
~dnr/up
one clock cycle
just after the clock edge, weevaluate the FSMD
step 1: determine state transition - select sfg down, go to s1
step 2: "go to s1"= define next state of FSM
"execute down" = define next value of cnt "execute always"
= define next value of dnr
always { dnr = dn; c = cnt; } sfg up { cnt = cnt + 1; } sfg down { cnt = cnt - 1; }
111
Simulate Updown Counter
cnt+1
-1
s0
s1
dnr
~dnr/up dnr/down
dnr/down
~dnr/up
one clock cycle
just after the clock edge, weevaluate the FSMD
step 1: determine state transition - select sfg down, go to s1
step 2: "go to s1"= define next state of FSM
"execute down" = define next value of cnt "execute always"
= define next value of dnr
At the next clock edge, update the registers= update FSM state, cnt, dnr
112
Simulate Updown Counter
dp updown(in dn : ns(1); out c : ns(8)) { reg cnt : ns(3); reg dnr : ns(1); always { dnr = dn; c = cnt; } sfg up { cnt = cnt + 1; } sfg down { cnt = cnt - 1; }}fsm ctl_updown(updown) { initial s0; state s1; @s0 if (dnr) then (down) -> s1; else (up) -> s0; @s1 if (~dnr) then (up) -> s0; else (down) -> s1;}dp drive(out s : ns(1); in c : ns(8)) { reg k : ns(5); always { k = k + 1; s = k[3]; $display($cycle, " s=", s, " c=", c); }}system S { updown(s, c); drive(s, c);}
sk cnt dnr S
drive updown
5
6
7
8
9
10
5/6
6/7
7/8
8/9
9/10
10/11
0
0
0
1
1
1
5/6
6/7
7/0
0/1
1/0
0/7
S0/S0
S0/S0
S0/S0
S0/S0
S0/S1
S1/S1
0/0
0/0
0/0
0/1
1/1
1/1
cycle
... ... ... ......