Topics

1. Topics • Basics of register-transfer design: • data paths and controllers; • ASM charts. • Pipelining.

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

3. Register-transfer system example A register-transfer machine has combinational logic connecting registers: combinational logic Q D combinational logic combinational logic D Q D Q

4. Block diagrams Block diagrams specify structure: wire bundle of width 5

5. Register-transfer simulation • Simulates to clock-cycle accuracy. Doesn’t 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.)

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

7. Sample VHDL code sync: process begin wait until CLOCK’event 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

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

9. 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 data-oriented state; • controller evaluates irregular functions, sets control signals for data path.

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

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

12. Conditionals and multiplexers if x = ‘0’ then reg1 <= a; else reg1 <= b; end if; code register-transfer

13. Alternate data path-controller systems controller controller controller data path data path data path one controller, one data path two communicating data path-controller systems

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

15. Sample ASM chart

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

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

18. Implementing operations in an ASM state state with one addition two additions requires two adders

19. 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 s2 x = a + b x = c + d y = a + d

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

21. Function unit sharing example mux allows + to compute a+b, a+c

22. Conditionals • Conditional chooses which state to execute next based on primary input or present state value. • Can be drawn in either of two ways: a = b F x T 00 01 10 11

23. Execution of conditionals • An ASM chart describes a Moore sequential machine. If the logic associated with an ASM chart fragment doesn’t correspond to a legal sequential machine, then it isn’t a legal ASM chart. • Conditional can evaluate only present state or primary input value on present cycle.

24. Implementing an ASM branch in a Moore machine ASM chart state transition graph of controller

25. Mealy machines and ASM • Mealy machine requires a conditional output. • ASM notation for conditional output: i1 0 y = c + d

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

27. Data path-controller extraction

28. Pipelines • Provide higher utilization of logic: Combinational logic

29. Pipeline metrics • Throughput: rate at which new values enter the system. • Initiation interval: time between successive inputs. • Latency: delay from input to output. • Delay through logic is D, n blocks. • L = D. • T = n/D. • P = D/n.

30. Clock period and throughput vs. pipeline depth

31. Simple pipelines • Pure pipelines have no control. • Choose latency, throughput. • Choose register locations with retiming. • Overhead: • Setup, hold times. • Power.

32. Pipelining registers

33. Bad cutset for pipelining

34. Utilization • Must fill, drain pipe at start and end of computation. • Given D cycles of data, n-stage pipe: • U = D/(D+n)

35. Complex pipelines • Actions in pipeline depend on data or external events. • Data dependencies may be forward or backward. • Actions on pipe: • Stall values. • Abort operation. • Bypass values.

36. Pipeline with feedforward constraint

37. Pipeline with feedback constraint

38. Pipeline with shared hardware

39. Pipeline control • Controllers are necessary when pipe stages take conditions. • Unconditional pipe stage controller has one state, one transition.

40. Pipeline with distributed control

41. Pipeline controller with condition

42. Distributed control for pipeline flush

43. Control for hardware sharing

44. Product machine for distributed control • Distributed control is hard to verify because state is not centralized. • Product machine form identifies global control actions. • Can verify using symbolic simulation, model checking.