High-level Synthesis and System Synthesis

1
High-level Synthesis and System Synthesis

• SOURCES-
• Mark Manwaring
• Kia Bazargan
• Giovanni De Micheli
• Gupta
• Youn-Long Lin

Camposano, J. Hofstede, Knapp, MacMillenLin
2
Why the level of automation must go up and up?
3
What Went Wrong with early approaches to design
automation ?

1. Too much emphasis on incremental work on
   algorithms and point tools
2. Unrealistic assumption on component capability,
   architectures, timing, etc
3. Lack of quality-measurement from the low level
4. Too many promises on fully automated system
   (silicon compiler??)

4
Example of a Silicon Compiler System
Initial specification
5
Benchmarks for a silicon compiler

6
VLSI Design Tools

• Design Capturing/Entry
• Analysis and Characterization
• Synthesis/Optimization
• Physical (Floor planning, Placement, Routing)
• Logic (FSM, Retiming, Sizing, DFT)
• High Level(RTL, Behavioral)
• Management

7
Design Methodology Progress
Capture and Simulate
8
Why not Synthesis?
Why Synthesis?
Productivity
Performance Loss
Correctness
Unsynthesizability
Re-Targetability
Inertial
9
Structural
Behavioral
Block
Algorithm
FSM
RTL
Boolean
Gate
Xtor
GDSII
Placement
Y-Chart Dan D Gajski
Floorplan
Physical
10
Structural
Behavioral
Block
Algorithm
FSM
RTL
Boolean
Gate
Xtor
GDSII
Placement
Layout Synthesis
Floorplan
Physical
11
Structural
Behavioral
Block
Algorithm
FSM
RTL
Boolean
Gate
Xtor
GDSII
Placement
Logic Synthesis
Floorplan
Physical
12
Structural
Behavioral
Block
Algorithm
FSM
RTL
Boolean
Gate
Xtor
GDSII
Placement
High-Level Synthesis
Floorplan
Physical
13
Target Architectures

• Bus-based
• Multiplexer-based
• Register file
• Pipelined
• RISC, VLIW
• Interface Protocol

14
Goal of synthesis for future systems

• From
• Behavioral specification at System
  Level(Algorithms)
• To
• Structural implementation at Register Transfer
  Level of Data path (ALUs, REGs, MUXs) and
  Controller
• Generally restricted to a single process
• Generally data path is optimized controller is
  by-product

15
Levels of Abstraction

• Our Abstraction levels
• System
• Register
• Logic

• In Camposano
• Behavioral
• Register-Transfer (RTL)
• Logic

16
Abstraction levels
Level
Behavior
Structure
Synthesisstep
System
High-level
Logic
Physical
17
Intermediate Representation



Data Flow Graph
Control Flow Graph
18
(No Transcript)
19
(No Transcript)
20
(No Transcript)
21
(No Transcript)
22
What are possible levels of synthesis? What are
possible styles? How to automate big tasks?
23
(No Transcript)
24
Layout Synthesis
25
Compass Placement Routing ( 0.6µm gate array)
26
Layout Level
27
Logic Synthesis
28

• Reminder about blocks and connections in data path

29
Variants of simple FSMD architectures
Controlling /activation pulses
control
Data Path


Controlling /activation pulses
control
Data Path
Status signals
30
Variants of simple FSMD architectures
Controlling /activation pulses
Data Path
control
Instructions
Status signals
31
FSM with Data Path (FSMD)
32
Details of control signals
Register a) RTL level b) with control signal
details
controls Reg_EO Enable Output Reg_EI Enable
Input RegFile_EI RegFile_SI ltpgt
33
Control of register files
control signals RegFile_EO1 RegFile_SO1
ltpgt RegFile_EO2 RegFile_SO2 ltpgt RegFile_EI RegF
ile_SI ltpgt
Register a) RTL level b) with control signal
details
34
The role of tri-state signals
Scheduling and allocation problems are similar
Tri-state signals in buses instead of multiplexing
35
Multiplexing

36
Communication with a memory
External address-bus
External data-bus
Internal bus
37
Pipeline Design Issues

• Pipelined processor design
• Pipeline is an implementation issue.
• A behavioral representation should not specify
  the pipeline.
• Most processor instruction sets are conceived
  with an implementation in mind.
• The behavior is defined to fit an implementation
  model.

38
Semantics of variables

• Variables are implemented in hardware by
• Registers.
• Wires.
• The hardware can store information or not.
• Cases
• Combinational circuits.
• Sequential circuits.

39
Semantics of variables
Semantics of variables

• Combinational circuits.
• Multiple-assignment to a variable.
• Conflict resolution.
• Oring.
• Last assignment.

40
Semantics of variables
Semantics of variables

• Sequential circuits.
• Multiple-assignment to a variable.
• Variable retains its value until reassigned.
• Problem
• Variable propagation and observability.

41
Example
Semantics of variables

• Multiple reassignments
• x 0 x 1 x 0
• Interpretations
• Each assignment takes a cycle. --gt pulse.
• x assumes value 0.
• x assumes value 0 after a short glitch.

42
Timing semantics
Semantics of variables

• Most procedural HDLs specify a partial order
  among operations.
• What is the timing of an operation?
• A posteriori model
• Delay annotation.
• A priori model
• Timing constraints.
• Synthesis policies.

43
Timing semantics(event-driven semantics)

• Digital synchronous implementation.
• An operation is triggered by some event
• If the inputs to an operation change
• --gt the operation is re-evaluated.
• Used by simulators for efficiency reasons.

44
Synthesis policyfor VHDL and Verilog

• Operations are synchronized to a clock by using
  a wait (or _at_) command.
• Wait and _at_ statements delimit clock boundaries.
• Clock is a parameter of the model
• model is updated at each clock cycle.

45
Verilog examplebehavior of sequential logic
circuit

• module DIFFEQ (x, y, u , dx, a, clock, start)
• input 70 a, dx
• inout 70 x, y, u
• input clock, start
• reg 70 xl, ul, yl
• always
• begin
• wait ( start)
• while ( x lt a )
• begin
• xl x dx
• ul u - (3 x u dx) - (3 y
  dx)
• yl y (u dx)
• _at_(posedge clock)
• x xl u ul y yl
• end
• endmodule

46
Abstract models

• Models based on graphs.
• Useful for
• Machine-level processing.
• Reasoning about properties.
• Derived from language models by compilation.

47
Abstract modelsExamples

• Netlists
• Structural views.
• Logic networks
• Mixed structural/behavioral views.
• State diagrams
• Behavioral views of sequential logic models.
• Dataflow and sequencing graphs.
• Abstraction of behavioral models.

48
Data flow graphs

• Behavioral views of architectural models.
• Useful to represent data-paths.
• Graph
• Vertices operations.
• Edges dependencies.

49
Dataflow graph Example

• xl x dx
• ul u - (3 x u dx) - (3 y dx)
• yl y u dx
• c xl lt a

50
Example of Data Flow Graph continued
xl x dx ul u - (3 x u dx) - (3 y
dx) yl y u dx c xl lt a
51
Sequencing graphs

• Behavioral views of architectural models.
• Useful to represent data-path and control.
• Extended data flow graphs
• Operation serialization.
• Hierarchy.
• Control- flow commands
• branching and iteration.
• Polar source and sink.

52
Example of sequencing graph
53
Example of Hierarchy
54
Example of branching
55
Example of iteration

• diffeq
• read (x y u dx a)
• repeat
• xl x dx
• ul u - (3 x u dx)
  - (3 y dx)
• yl y u dx
• c x lt a
• x xl u ul y yl
• until ( c )
• write (y)

56
Example of iteration
57
Semantics of sequencing graphs

• Marking of vertices
• Waiting for execution.
• Executing.
• Have completed execution.
• Execution semantics
• An operation can be fired as soon as all its
  immediate predecessors have completed execution

58
Vertex attributes

• Area cost.
• Delay cost
• Propagation delay.
• Execution delay.
• Data-dependent execution delays
• Bounded (e.g. branching).
• Unbounded (e.g. iteration, synchronization).

59
Properties of sequencing graphs

• Computed by visiting hierarchy bottom-up.
• Area estimate
• Sum of the area attributes of all vertices.
• Worst-case - no sharing.
• Delay estimate (latency)
• Bounded-latency graphs.
• Length of longest path.

60
Summary on specification models

• Hardware synthesis requires specialized language
  support.
• VHDL and Verilog HDL are mainly used today
• Similar features.
• Simulation-oriented.
• Synthesis from programming languages is also
  possible.
• Hardware and software models of computation are
  different.
• Appropriate hardware semantics need to be
  associated with programming languages.
• Abstract models
• Capture essential information.
• Derivable from HDL models.
• Useful to prove properties.

61

• Control Design

62
(No Transcript)
63
(No Transcript)
64
Control 1
Control design

• Control of
• Registers
• Functional units
• Multiplexers and 3-state drivers
• Memory

65
Simple micro-programmed controller
MUX
Control signals fromROM or data path
INCR
Programcounter
Jump address
MicrocodeROM
Mode registers
Control lines
Control lines
66
Control 2
Control design issues

• To avoid false combinational cycles, either the
  inputs or the outputs of the controller are
  registered.
• Note the one cycle delay between a condition and
  the resulting reaction in the controller.
• Controller can even be pipelined,
• which can remove the controller from the critical
  path,
• but increases the delay for the conditions.

67
Overview of Hardware Synthesis
converts the program text file into strings of
tokens. Tokens can be specified by regular
expressions. In the UNIX world, the lex tools
are popular for this.

• The syntax of a programming language is specified
  by a grammar. (A grammar defines the order and
  types of tokens.) This analysis organized streams
  of tokens into an abstract syntax tree.

68
Overview of Hardware Synthesis
Generate a symbol table. Check for uniqueness of
symbols and information about them.
analyze the semantics, or meanings, of the
program.
determine the order and organization of operations