Topics: Basics of Register-Transfer Design

Topics
Basics of register-transfer design:

data paths and controllers;
ASM charts.
Modern VLSI Design 3e: Chapter 8
Copyright
1998, 2002 Prentice Hall PTR
Register-transfer design
A register-transfer system is a sequential
machine.
Register-transfer design is structural
complex combinations of state machines may
not be easily described solely by a large state
transition graph.
Register-transfer design concentrates on
functionality, not details of logic design.
Copyright
Register-transfer system example

A register-transfer machine has combinational
logic connecting registers:
Q D
combinational
logic
combinational
logic
combinational
logic
Copyright
Block diagrams
Block diagrams specify structure:
Copyright
wire bundle
of width 5
Register-transfer simulation
Simulates to clock-cycle accuracy. Doesnt
guarantee timing.
Important to get proper function of machine
before jumping into detailed logic design.
(But be sure to take into account critical
delays when choosing register-transfer
organization.)
Copyright
Simulation coding
Hardware description languages are typically

supported by a simulation system: VHDL,
Verilog, etc.
Simulation engine takes care of scheduling events
during simulation.
Can hand-code a simulation in a programming

language.
Must be sure that register-transfer events happen in
proper order.
Copyright
Sample VHDL code

sync: process begin
wait until CLOCKevent and CLOCK=1;
state <= state_next;
end process sync;
combin: process begin
case state is
when S0 =>
out1 <= a + c;
state_next <= S1;
...
end process combin;
sync process models

registers
combin process models
combinational logic
Copyright
Sample C simulator
while (TRUE) {
switch (state) {
case S0:
x = a + b;
state = S1;
next;
case S1:
...
}
}
loop executed once

per clock cycle
each case corresponds
to a state; sets outputs,
next state
Copyright
Data path-controller systems
One good way to structure a system is as a

data path and a controller:
data path executes regular operations
(arithmetic, etc.), holds registers with dataoriented state;
controller evaluates irregular functions, sets
control signals for data path.
Copyright
Data and control are equivalent
We can rewrite control into data and visa

versa:
control: if i1 = 0 then o1 <= a; else o1 <=
b; end if;
data: o1 <= ((i1 = 0) and a) or ((i1 = 1)
and b);
Data/control distinction is useful but not

fundamental.
Copyright
Data operators
Arithmetic operations are easy to spot in

hardware description languages:
x <= a + b;
Multiplexers are implied by conditionals.

Must evaluate entire program to determine
which sources of data for registers.
Multiplexers also come from sharing adders,
etc.
Copyright
Conditionals and multiplexers

if x = 0 then
reg1 <= a;
else
reg1 <= b;
end if;
code
register-transfer
Copyright
Alternate data path-controller

systems
controller
controller
data path
data path
one controller,
one data path
controller
data path
two communicating
data path-controller
systems
Copyright
ASM charts
An ASM chart is a register-transfer
description.
ASM charts let us describe function without
choosing a partitioning between control and
data.
Once we have specified the function, we can
refine it into a block diagram which
partitions data and control.
Copyright
Sample ASM chart
Copyright
ASM state
An ASM state specifies a machine state and

a set of actions in that state. All actions
occur in parallel.
s1
x=a+b
y=c-d+e
o1 = 1
name of state (notation only)

Copyright
Actions in state
Actions in a state are unconditionally
executed.
A state can execute as many actions as you
want, but you must eventually supply
hardware for all those actions.
A register may be assigned to only once in a
state (single-assignment rule).
Copyright
Implementing operations in an
ASM state
state with one addition

two additions requires two adders
Copyright
Sequences of states
States are linked by transitions.
States are executed sequentially. Each state
may take independent actions (including
assigning to a variable assigned to in a
previous state).
s1
x=a+b
s2
x=c+d
y=a+d
Copyright
Data paths from states

Maximum amount of hardware in data path
is determined by state which executes the
most functionality.
Function units implementing data
operations may be reused across states, but
multiplexers will be required to route values
to the shared function units.
Copyright
Function unit sharing example
mux allows +
to compute
a+b, a+c
Copyright
Conditionals
Conditional chooses which state to execute
next based on primary input or present state
value.
Can be drawn in either of two ways:
x
00
01
a=b
10
11
T
Copyright
Execution of conditionals
An ASM chart describes a Moore sequential
machine. If the logic associated with an
ASM chart fragment doesnt correspond to
a legal sequential machine, then it isnt a
legal ASM chart.
Conditional can evaluate only present state
or primary input value on present cycle.
Copyright
Implementing an ASM branch in

a Moore machine
ASM chart
state transition
graph of
controller
Copyright
Mealy machines and ASM

Mealy machine requires a conditional
output.
ASM notation for conditional output:
i1
y=c+d
Copyright
Extracting data path and

controller
ASM chart notation helps identify data,
control.
Once you choose what values and operations
go into the data path, you can determine by
elimination what goes into the controller.
Structure of the ASM chart gives structure of
controller state transition graph.
Copyright
Data path-controller extraction
Copyright

Topics: Basics of Register-Transfer Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Topics: Basics of Register-Transfer Design

Uploaded by

Copyright:

Available Formats

Topics

Basics of register-transfer design:

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

Register-transfer system example

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

Hardware description languages are typically

Can hand-code a simulation in a programming

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

Sample VHDL code

sync process models

1998, 2002 Prentice Hall PTR

Modern VLSI Design 3e: Chapter 8

loop executed once

1998, 2002 Prentice Hall PTR

Data path-controller systems

One good way to structure a system is as a

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

Data and control are equivalent

We can rewrite control into data and visa

Data/control distinction is useful but not

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

Arithmetic operations are easy to spot in

Multiplexers are implied by conditionals.

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

Conditionals and multiplexers

1998, 2002 Prentice Hall PTR

Alternate data path-controller

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

Sample ASM chart

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

An ASM state specifies a machine state and

name of state (notation only)

1998, 2002 Prentice Hall PTR

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

state with one addition

1998, 2002 Prentice Hall PTR

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

Data paths from states

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

Function unit sharing example

Modern VLSI Design 3e: Chapter 8

1998, 2002 Prentice Hall PTR

1998, 2002 Prentice Hall PTR

Modern VLSI Design 3e: Chapter 8