GEZEL Modeling and Simulation Patrick Schaumont Virginia Tech Dept. of Electrical and Computer...

112
GEZEL Modeling and Simulation Patrick Schaumont Virginia Tech Dept. of Electrical and Computer Engineering September 2010

Transcript of GEZEL Modeling and Simulation Patrick Schaumont Virginia Tech Dept. of Electrical and Computer...

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

7

RTL

• Or, for example, Logic Function = squaring• R1 = R22

• WL R1 = 2x WL R2

R2 R1

mult

n

n2n

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

20

RTL Modeling

• Registers

• Wires

• Circuits

• reg variables

• sig variables

• Expressions

1

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

40

Impossible Design?

• Does this solve the issue ?

sig a, b : ns(3);always { a = b + 1; b = a;}

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

71

Simulation Tools

• GEZEL Simulation• fdlsim <filename> <cycles>

• Debug• $display statement

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

74

fdlsim output

$display($cycle, $hex " a ", a, " b ", b);

75

fdlvhd output

76

ghdl simulation

77

gtkwave output

78

Simulation Flow

FDL file

VHDL file(s)

VCD file

fdlsim fdlvhd

ghdl

gtkwave

(debug)

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.

92

Semantics

How to break rule #1

93

How to break rule #2

94

How to break rule #3

95

How to break rule #4

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

107

Simulate Updown Counter

cnt+1

-1

s0

s1

dnr

~dnr/up dnr/down

dnr/down

~dnr/up

one clock cycle

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

... ... ... ......