gezel modeling and simulation

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

Upload: otto-cote

Post on 01-Jan-2016

40 views

Category:

Documents


1 download

DESCRIPTION

GEZEL Modeling and Simulation. Patrick Schaumont Virginia Tech Dept. of Electrical and Computer Engineering September 2010. Outline. RTL Architecture vs Modeling Datapath Cycle-based modeling Expressions in hardware Modules Finite State Machines FSMD Tools Simulation - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: GEZEL Modeling and Simulation

GEZEL Modeling and Simulation

Patrick Schaumont

Virginia TechDept. of Electrical and Computer Engineering

September 2010

Page 2: GEZEL Modeling and Simulation

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

Page 3: GEZEL Modeling and Simulation

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

Page 4: GEZEL Modeling and Simulation

4

RTL

• The Logic Function can be anything that can be computed in a single clock cycle

LogicFunction

R2 R1

One Clock Cycle

Page 5: GEZEL Modeling and Simulation

5

RTL

• Bit-parallel description: R2 and R1 can be wider than a single bit

LogicFunction

R2 R1

One Clock Cycle

= =

Page 6: GEZEL Modeling and Simulation

6

RTL

• For example, Logic Function = inversion• R1 = ~R2

• Number of inverters = Wordlength of R2

• WL R1 = WL R2

R2 R1

n

Page 7: GEZEL Modeling and Simulation

7

RTL

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

• WL R1 = 2x WL R2

R2 R1

mult

n

n2n

Page 8: GEZEL Modeling and Simulation

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

Page 9: GEZEL Modeling and Simulation

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

Page 10: GEZEL Modeling and Simulation

10

RTL

• So RTL is a ...• bit-parallel,• technology-independent,• (and, in this course)

synchronous, single-clock

way to model hardware implementations

Page 11: GEZEL Modeling and Simulation

11

Simulation Cycle

• The simulation cycle of RTL goes through two phases:• Evaluate (Logic Function)• Update (Registers)

LogicFunction

R2 R1

Page 12: GEZEL Modeling and Simulation

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

Page 13: GEZEL Modeling and Simulation

13

Simulation Cycle

• The simulation cycle of RTL goes through two phases:• Evaluate (Logic Function)• Update (Registers)

LogicFunction

R2 R1one clock cycle

Evaluate Update

Page 14: GEZEL Modeling and Simulation

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

Page 15: GEZEL Modeling and Simulation

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

Page 16: GEZEL Modeling and Simulation

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:

Page 17: GEZEL Modeling and Simulation

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

Page 18: GEZEL Modeling and Simulation

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

Page 19: GEZEL Modeling and Simulation

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

Page 20: GEZEL Modeling and Simulation

20

RTL Modeling

• Registers

• Wires

• Circuits

• reg variables

• sig variables

• Expressions

1

Page 21: GEZEL Modeling and Simulation

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;}

Page 22: GEZEL Modeling and Simulation

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)

Page 23: GEZEL Modeling and Simulation

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?

Page 24: GEZEL Modeling and Simulation

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!

Page 25: GEZEL Modeling and Simulation

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

Page 26: GEZEL Modeling and Simulation

26

Wire Variables

Cycle Input rOutput r

0 0123

reg r : ns(3);sig v : ns(3);always { v = r + 1; r = v << 1;}

Page 27: GEZEL Modeling and Simulation

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;}

Page 28: GEZEL Modeling and Simulation

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;}

Page 29: GEZEL Modeling and Simulation

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)

Page 30: GEZEL Modeling and Simulation

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;}

=

Page 31: GEZEL Modeling and Simulation

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?

Page 32: GEZEL Modeling and Simulation

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

Page 33: GEZEL Modeling and Simulation

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

Page 34: GEZEL Modeling and Simulation

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?

Page 35: GEZEL Modeling and Simulation

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

Page 36: GEZEL Modeling and Simulation

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

Page 37: GEZEL Modeling and Simulation

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

Page 38: GEZEL Modeling and Simulation

38

Impossible Design?

• What is the meaning of this design?

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

add 1

b

Page 39: GEZEL Modeling and Simulation

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

Page 40: GEZEL Modeling and Simulation

40

Impossible Design?

• Does this solve the issue ?

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

Page 41: GEZEL Modeling and Simulation

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

Page 42: GEZEL Modeling and Simulation

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

Page 43: GEZEL Modeling and Simulation

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)

Page 44: GEZEL Modeling and Simulation

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]); }

Page 45: GEZEL Modeling and Simulation

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]

Page 46: GEZEL Modeling and Simulation

46

GEZEL Operators

• What does this implement ?

reg v : ns(6);sig j : ns(3);always { j = 3; v = (tc(1)) j;}

Page 47: GEZEL Modeling and Simulation

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]

Page 48: GEZEL Modeling and Simulation

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);}

Page 49: GEZEL Modeling and Simulation

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

Page 50: GEZEL Modeling and Simulation

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

Page 51: GEZEL Modeling and Simulation

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; }}

Page 52: GEZEL Modeling and Simulation

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

Page 53: GEZEL Modeling and Simulation

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

> -

Page 54: GEZEL Modeling and Simulation

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

Page 55: GEZEL Modeling and Simulation

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; }}

Page 56: GEZEL Modeling and Simulation

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

Page 57: GEZEL Modeling and Simulation

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

Page 58: GEZEL Modeling and Simulation

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

Page 59: GEZEL Modeling and Simulation

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;}

Page 60: GEZEL Modeling and Simulation

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; }}

Page 61: GEZEL Modeling and Simulation

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; }}

Page 62: GEZEL Modeling and Simulation

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

Page 63: GEZEL Modeling and Simulation

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

Page 64: GEZEL Modeling and Simulation

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

Page 65: GEZEL Modeling and Simulation

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

Page 66: GEZEL Modeling and Simulation

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

Page 67: GEZEL Modeling and Simulation

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

Page 68: GEZEL Modeling and Simulation

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

Page 69: GEZEL Modeling and Simulation

69

FSMD

state

next-state

state

next-state

datapath

FSM

status

command

• Logically, an FSMD is two FSM stacked on top of one another

Page 70: GEZEL Modeling and Simulation

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

Page 71: GEZEL Modeling and Simulation

71

Simulation Tools

• GEZEL Simulation• fdlsim <filename> <cycles>

• Debug• $display statement

Page 72: GEZEL Modeling and Simulation

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; }}

Page 73: GEZEL Modeling and Simulation

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

Page 74: GEZEL Modeling and Simulation

74

fdlsim output

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

Page 75: GEZEL Modeling and Simulation

75

fdlvhd output

Page 76: GEZEL Modeling and Simulation

76

ghdl simulation

Page 77: GEZEL Modeling and Simulation

77

gtkwave output

Page 78: GEZEL Modeling and Simulation

78

Simulation Flow

FDL file

VHDL file(s)

VCD file

fdlsim fdlvhd

ghdl

gtkwave

(debug)

Page 79: GEZEL Modeling and Simulation

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

Page 80: GEZEL Modeling and Simulation

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

Page 81: GEZEL Modeling and Simulation

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); }}

Page 82: GEZEL Modeling and Simulation

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)

Page 83: GEZEL Modeling and Simulation

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

Page 84: GEZEL Modeling and Simulation

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

Page 85: GEZEL Modeling and Simulation

85

Semantics

• We already discussed that some GEZEL (RTL) programs are invalid constructions

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

add 1

b

Page 86: GEZEL Modeling and Simulation

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

Page 87: GEZEL Modeling and Simulation

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

Page 88: GEZEL Modeling and Simulation

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

Page 89: GEZEL Modeling and Simulation

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

Page 90: GEZEL Modeling and Simulation

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

Page 91: GEZEL Modeling and Simulation

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.

Page 92: GEZEL Modeling and Simulation

92

Semantics

How to break rule #1

Page 93: GEZEL Modeling and Simulation

93

How to break rule #2

Page 94: GEZEL Modeling and Simulation

94

How to break rule #3

Page 95: GEZEL Modeling and Simulation

95

How to break rule #4

Page 96: GEZEL Modeling and Simulation

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

Page 97: GEZEL Modeling and Simulation

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

Page 98: GEZEL Modeling and Simulation

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 ..

Page 99: GEZEL Modeling and Simulation

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

Page 100: GEZEL Modeling and Simulation

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

Page 101: GEZEL Modeling and Simulation

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

Page 102: GEZEL Modeling and Simulation

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

Page 103: GEZEL Modeling and Simulation

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

Page 104: GEZEL Modeling and Simulation

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

Page 105: GEZEL Modeling and Simulation

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);}

Page 106: GEZEL Modeling and Simulation

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

Page 107: GEZEL Modeling and Simulation

107

Simulate Updown Counter

cnt+1

-1

s0

s1

dnr

~dnr/up dnr/down

dnr/down

~dnr/up

one clock cycle

Page 108: GEZEL Modeling and Simulation

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

Page 109: GEZEL Modeling and Simulation

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

Page 110: GEZEL Modeling and Simulation

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; }

Page 111: GEZEL Modeling and Simulation

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

Page 112: GEZEL Modeling and Simulation

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

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