Chapter 2 Models Architectures and Languages 1 Models

Chapter 2 Models, Architectures and Languages 1

Models, Architectures, Languages l Introduction l Models – State, Activity, Structure, Data, Heterogeneous l Architectures – Function-Architecture, Platform-Based l Languages – Hardware: VHDL / Verilog / System. Verilog – Software: C / C++ / Java – System: System. C / SLDL / SDL – Verification: PSL (Sugar, OVL) 2

Models, Architectures, Languages INTRODUCTION 3

Design Methodologies l Capture-and-Simulate – Schematic Capture – Simulation l Describe-and-Synthesize – Hardware Description Language – Behavioral Synthesis – Logic Synthesis l Specify-Explore-Refine – Executable Specification – Hardware-Software Partitioning – Estimation and Exploration – Specification Refinement 4

Motivation 5

Models & Architectures Specification + Constraints Models (Specification ) Design Process Implementation Architectures (Implementation) Models are conceptual views of the system’s functionality Architectures are abstract views of the system’s implementation 6

Behavior Vs. Architecture Models of Computat ion 1 System Behavior Simulation Synthesis Performance models: Emb. SW, comm. and comp. resources System 2 Architecture HW/SW partitionin g, Schedulin g SW estimation Mapping 3 Performance Simulation Communication Refinement 4 Flow To Implementation 7

Models of an Elevator Controller 8

Architectures Implementing the Elevator Controller 9

Current Abstraction Mechanisms in Hardware Systems Abstraction The level of detail contained within the system model l A system can be modeled at – – – l System Level, Algorithm or Instruction Set Level, Register-Transfer Level (RTL), Logic or Gate Level, Circuit or Schematic Level. A model can describe a system in the – Behavioral domain, – Structural domain, – Physical domain. 10

Abstractions in Modeling: Hardware Systems Level Behavior Structure Physical Start here PMS (System) Communicating Processes Processors Memories Switches (PMS) Instruction Set (Algorithm) Input-Output Memory, Ports Processors Board Floorplan Register. Transfer Register Transfers ALUs, Regs, Muxes, Bus ICs Macro Cells Logic Eqns. Gates, Flip-flops Std. cell layout Circuit Network Eqns. Trans. , Connections © IEEE 1990 Cabinets, Cables Work to here Transistor layout [Mc. Farland 90] 11

Current Abstraction Mechanisms for Software Systems Virtual Machine A software layer very close to the hardware that hides the hardware’s details and provides an abstract and portable view to the application programmer Attributes – Developer can treat it as the real machine – A convenient set of instructions can be used by developer to model system – Certain design decisions are hidden from the programmer – Operating systems are often viewed as virtual machines 12

Abstractions for Software Systems Virtual Machine Hierarchy l Application Programs l Utility Programs l Operating System l Monitor l Machine Language l Microcode l Logic Devices 13

MODELS 14

Unified HW/SW Representation l Unified Representation – – High-level system (So. C) architecture description – Implementation (hardware or software) independent – Delayed hardware/software partitioning – Cross-fertilization between hardware and software – Co-simulation environment for communication – System-level functional verification 15

Abstract Hardware-Software Model Unified representation of system allows early performance analysis General Performance Evaluation Identification of Bottlenecks Abstract HW/SW Model Evaluation of Design Alternatives Evaluation of HW/SW Trade-offs 16

HW/SW System Models l State-Oriented Models – Finite-State Machines (FSM), Petri-Nets (PN), Hierarchical Concurrent FSM l Activity-Oriented Models – Data Flow Graph, Flow-Chart l Structure-Oriented Models – Block Diagram, RT netlist, Gate netlist l Data-Oriented Models – Entity-Relationship Diagram, Jackson’s Diagram l Heterogeneous Models – UML (OO), CDFG, PSM, Queuing Model, Programming Language Paradigm, Structure Chart 17

State-Oriented: Finite-State Machine (Mealy Model) 18

State-Oriented: Finite State Machine (Moore Model) 19

State-Oriented: Finite State Machine with Datapath 20

Finite State Machines l Merits – Represent system’s temporal behavior explicitly – Suitable for control-dominated systems – Suitable formal verification l Demerits – Lack of hierarchy and concurrency – State or arc explosion when representing complex systems 21

State-Oriented: Petri Nets l System model consisting of places, tokens, Petri Nets: a transitions, arcs, and a marking – Places - equivalent to conditions and hold tokens – Tokens - represent information flow through system – Transitions - associated with events, a “firing” of a transition indicates that some event has occurred – Marking - a particular placement of tokens within places of a Petri net, representing the state of the net Example: Input Places Token Transition Output Place 22

State-Oriented: Petri Nets 23

Petri Nets l Merits – Good at modeling and analyzing concurrent systems – Extensive theoretical and experimental works – Used extensively for protocol engineering and control system modeling l Demerits – “Flat Model” that becomes incomprehensible when system complexity increases 24

State-Oriented: Hierarchical Concurrent FSM 25

Hierarchical Concurrent FSM l Merits – Support both hierarchy and concurrency – Good for representing complex systems l Demerits – Concentrate only on modeling control aspects and not data and activities 26

Activity-Oriented: Data Flow Graphs (DFG) 27

Data Flow Graphs l Merits – Support hierarchy – Suitable for specifying complex transformational systems – Represent problem-inherent data dependencies l Demerits – Do not express control sequencing or temporal behaviors – Weak for modeling embedded systems 28

Activity-Oriented: Flow Charts 29

Flow Charts l Merits – Useful to represent tasks governed by control flows – Can impose an order to supersede natural data dependencies l Demerits – Used only when the system’s computation is well known 30

Structure-Oriented: Component Connectivity Diagrams 31

Component Connectivity Diagrams l Merits – Good at representing system’s structure l Demerits – Behavior is not explicit l Characteristics – Used in later phases of design 32

Data-Oriented: Entity-Relationship Diagram 33

Entity-Relationship Diagrams l Merits – Provide a good view of the data in a system – Suitable for representing complex relationships among various kinds of data l Demerits – Do not describe any functional or temporal behavior of a system 34

Data-Oriented: Jackson’s Diagram 35

Jackson’s Diagrams l Merits – Suitable for representing data having a complex composite structure l Demerits – Do not describe any functional or temporal behavior of the system 36

Heterogeneous: Control/Data Flow Graphs (CDFG) l l l Graphs contain nodes corresponding to operations in either hardware or software Often used in high-level hardware synthesis Can easily model data flow, control steps, and concurrent operations because of its graphical nature 5 Example: X 4 Y + + + Control Step 1 Control Step 2 + Control Step 3 37

Control/Data Flow Graphs l Merits – Correct the inability to represent control dependencies in DFG – Correct the inability to represent data dependencies in CFG l Demerits – Low level specification (behavior not evident) 38

Heterogeneous: Structure Chart 39

Structure Charts l Merits – Represent both data and control l Demerits – Used in the preliminary stages of system design 40

Heterogeneous: Object-Oriented Paradigms (UML, …) l l Use techniques previously applied to software to manage complexity and change in hardware modeling Use OO concepts such as – Data abstraction – Information hiding – Inheritance l Use building block approach to gain OO benefits – Higher component reuse – Lower design cost – Faster system design process – Increased reliability 41

Heterogeneous: Object-Oriented Paradigms (UML, …) Object-Oriented Representation Example: 3 Levels of abstraction: Register Read Write ALU Add Sub AND Shift Processor Mult Div Load Store 42

43

Object-Oriented Paradigms l Merits – Support information hiding – Support inheritance – Support natural concurrency l Demerits – Not suitable for systems with complicated transformation functions 44

Heterogeneous: Program State Machine (PSM) 45

Program State Machine l Merits – Represent a system’s state, data, control, and activities in a single model – Overcome the limitations of programming languages and HCFSM models 46

Heterogeneous: Queuing Model 47

Queuing Models l Characteristics – Used for analyzing system’s performance – Can find utilization, queuing length, throughput, etc. 48

Codesign Finite State Machine (CFSM) l CFSM is FSM extended with – Support for data handling – Asynchronous communication l CFSM has – FSM part • Inputs, outputs, states, transition and output relation – Data computation part • External, instantaneous functions 49

Codesign Finite State Machine (CFSM) l CFSM has: – Locally synchronous behavior • CFSM executes based on snap-shot input assignment • Synchronous from its own perspective – Globally asynchronous behavior • CFSM executes in non-zero, finite amount of time • Asynchronous from system perspective l GALS model – Globally: Scheduling mechanism – Locally: CFSMs 50

Network of CFSMs: Depth-1 Buffers l Globally Asynchronous, Locally Synchronous (GALS) model F B=>C C=>F G C=>G F^(G==1) CFSM 1 C=>A C CFSM 2 C C=>B A B C=>B (A==0)=>B CFSM 3 51

Typical DSP Algorithm l Traditional DSP – Convolution/Correlation – Filtering (FIR, IIR) – Adaptive Filtering (Varying Coefficient) – DCT 52

Specification of DSP Algorithms l Example – y(n)=a*x(n)+b*x(n-1)+c*x(n-2) l Graphical Representation Method 1: Block Diagram (Data-path architecture) – Consists of functional blocks connected with directed edges, which represent data flow from its input block to its output block x(n) a x(n-1) D b D x(n-2) c y(n) 53

Graphical Representation Method 2: Signal-Flow Graph l l SFG: a collection of nodes and directed edges Nodes: represent computations and/or task, sum all incoming signals Directed edge (j, k): denotes a linear transformation from the input signal at node j to the output signal at node k Linear SFGs can be transformed into different forms without changing the system functions. – Flow graph reversal or transposition is one of these transformations (Note: only applicable to single-input-singleoutput systems) 54

Signal-Flow Graph l l Usually used for linear time-invariant DSP systems representation Example: x(n) a b c y(n) 55

Graphical Representation Method 3: Data-Flow Graph l l DFG: nodes represent computations (or functions or subtasks), while the directed edges represent data paths (data communications between nodes), each edge has a nonnegative number of delays associated with it. DFG captures the data-driven property of DSP algorithm: any node can perform its computation whenever all its input data are available. D x(n) a D b c y(n) 56

Data-Flow Graph l Each edge describes a precedence constraint between two nodes in DFG: – Intra-iteration precedence constraint: if the edge has zero delays – Inter-iteration precedence constraint: if the edge has one or more delays (Delay here represents iteration delays. ) – DFGs and Block Diagrams can be used to describe both linear single-rate and nonlinear multi-rate DSP systems l Fine-Grain DFG D x(n) a D b c y(n) 57

Examples of DFG l Nodes are complex blocks (in Coarse-Grain DFGs) FFT l Adaptive filtering IFFT Nodes can describe expanders/decimators in Multi. Rate DFGs Decimator Expander N samples N/2 samples 2 1 1 2 N samples 58

Graphical Representation Method 4: Dependence Graph l l DG contains computations for all iterations in an algorithm. DG does not contain delay elements. Edges represent precedence constraints among nodes. Mainly used for systolic array design. 59

ARCHITECTURES 60

Architecture Models Southwest Medical Center Oklahoma City, Oklahoma "You hear the planned possibilities, but it is nothing like the visual concept of a model. You get the impact of the complete vision. " Galyn Fish Director of PR, Southwest Medical. Center 61

System Level Design Science l Design Methodology: – Top Down Aspect: • Orthogonalization of Concerns: – Separate Implementation from Conceptual Aspects – Separate computation from communication • Formalization: precise unambiguous semantics • Abstraction: capture the desired system details (do not overspecify) • Decomposition: partitioning the system behavior into simpler behaviors • Successive Refinements: refine the abstraction level down to the implementation by filling in details and passing constraints – Bottom Up Aspect: • IP Re-use (even at the algorithmic and functional level) • Components of architecture from pre-existing library 62

Separate Behavior from Microarchitecture l. System Behavior l. Implementation Architecture – Functional specification of – Hardware and Software system – No notion of hardware or software! – Optimized Computer Mem 13 User/Sys Control 3 Sensor Synch Control 4 Front End 1 Transport Decode 2 Rate Buffer 5 Rate Buffer 9 Video Decode 6 Audio Decode/ Output 10 MPEG Frame Buffer 7 DSP Processor External I/O Video Output 8 Peripheral Audio Decode Processor Bus Rate Buffer 12 DSP RAM Control Processor System RAM Mem 11 63

Example of System Behavior Mem 13 Rate Buffer 12 Cable Sensor Synch Control 4 Satellite Dish Front End 1 User/Sys Control 3 Transport Decode 2 Rate Buffer 5 Rate Buffer 9 Video Decode 6 Audio Decode/ Output 10 Mem 11 remote Frame Buffer 7 Video Output 8 monitor speakers 64

IP-Based Design of the System Behavior System Integration Communication Protocol Designed in Felix User Interface Written in C Mem 13 Testbench Designed in BONe. S Rate Buffer 12 Sensor Synch Control 4 Satellite Dish Front End 1 User/Sys Control 3 Transport Decode 2 Rate Buffer 5 Rate Buffer 9 Cable Baseband Processing Designed in SPW Transport Decode Written in C remote Video Decode 6 Frame Buffer 7 Video Output 8 Audio Decode/ Output 10 Mem 11 monitor speakers Decoding Algorithms Designed in SPW 65

The next level of Abstraction … IP Block Performance Inter IP Communication Performance Models Gate Level Model Capacity Load abstract 1970’s abstract RTL cluster RTL Clusters SW Models cluster abstract Transistor Model Capacity Load abstract SDF Wire Load IP Blocks cluster 1980’s 1990’s Year 2000 + 66

IP-Based Design of the Implementation Which Bus? PI? AMBA? Dedicated Bus for DSP? External I/O MPEG Peripheral Audio Decode Do I need a dedicated Audio Decoder? Can decode be done on Microcontroller? DSP Processor Bus Can I Buy an MPEG 2 Processor? Which One? Which DSP Processor? C 50? Can DSP be done on Microcontroller? DSP RAM Which Microcontroller? ARM? HC 11? Control Processor System RAM How fast will my User Interface Software run? How Much can I fit on my Microcontroller? 67

Flexibility Architectural Choices 1/Efficiency (power, speed) 68

Map Between Behavior and Architecture Transport Decode Implemented as Software Task Running on Microcontroller Rate Buffer 12 User/Sys Control 3 Sensor Communication External Over Bus I/O Synch Control 4 Front End 1 Transport Decode 2 Rate Buffer 5 Rate Buffer 9 Video Decode 6 Audio Decode/ Output 10 MPEG Frame Buffer 7 Video Output 8 Peripheral Audio Decode DSP Processor Bus Mem 13 DSP RAM Control Processor System RAM Mem 11 Audio Decode Behavior Implemented on Dedicated Hardware 69

Classic A/D, HW/SW tradeoff Digital expanding De-correlate (spread spectrum) e. g. LO De-modulate Analog vs. Digital tradeoff System Chip DSP Suppose digital limit is pushed A/D Custom DSP DS 1 -bit Modulator Dec. Filter Gen DSP 1 -bit Modulator Gen DSP l RF Front End l Can trade custom analog for hardware, even for software – Power, area critical criteria, or easy functional modification 1 -bit Modulator 70

Example: Voice Mail Pager Modulation Scheme Choice (e. g. BPSK) Q f P I ? De-correlate (spread spectrum) e. g. De-modulate Analog vs. Digital tradeoff ? Gen DSP l Design considerations cross design layers l Trade-offs require systematic methodology and constraint-based hierarchical approach for clear justification 71

Where All is Going Function/Arch. Co-Design Communication-based Design Convergence of Paradigms Analog Platform Design u. Create paradigm shift- not just link methods l. New levels of abstraction to fluidly tradeoff HW/SW, A/D, HF/IF, interfaces, etc- to exploit heterogeneous nature of components l. Links already being forged 72

Deep Submicron Paradigm Shift 2 M Transistors 100 M Metal 100 MHz 2 Wire RC 1 ns/cm 90% New Design 1991 40 M Transistors 2, 000 M Metal 2 600 MHz Wire RC 6 ns/cm Virtual Component Based Design - Minimize Design Time - Maximize IP Reuse - Optimize System Level Cell Based Design - Minimize Area - Maximize Performance - Optimize Gate Level 1996 90% Reused Design 200 x 73

Implementation Design Trends Platform Based Consumer Wireless Automotive EDA Hierarchical Microprocessors High end servers & W/S Micro. P Flat Layout Flat ASIC+ Net & Compute Servers Base stations 74

Level of Abstraction Platform-Based System Architecture Exploration Application Space Function HW/SW System Platform Architectu re RTL - SW Today Mask ASM Tomorrow Effort/Value Architectural Space 75

Digital Wireless Platform Dedicated Logic and Memory Logic A D Accelerators (bit level) Timing recovery Equalizers Analog RF Filters analog digital u. C core (ARM) Java phone book VM Keypad, Display Control ARQ MUD Adaptive Antenna Algorithm s DSP core Source: Berkeley Wireless Research Center 76

Will the system solution match the original system spec? • Limited synergies between HW & SW teams • Long complex flows in which teams do not reconcile efforts until the end • High degree of risk that devices will be fully functional Concept • Development • Verification • System Test ? Software VCXO Hardware • IP Selection • Design • Verification Clock Select STM Tx Synth/ I/F Optics MUX Line STS OHP Cell/ I/F STS XC SPE Data Packet Rx CDR/ Map Framer PP Optics De. MUX I/F m. P 77

EDA Challenge to Close the Gap • Industry averaging 2 -3 iterations So. C design Behavior Level of Abstraction Design Entry Level SW/HW RTL • Need to identify design issues earlier • Gap between concept and logical / Physical implementation Concept to Reality Gap Gate Level “Platform” Historical EDA Focus Silicon Impact of Design Change (Effort/Cost) Source: GSRC 78

AMBA-Based So. C Architecture 79

LANGUAGES 80

Languages l Hardware Description Languages – VHDL / Verilog / System. Verilog l Software Programming Languages – C / C++ / Java l Architecture Description Languages – EXPRESSION / MIMOLA / LISA l System Specification Languages – System. C / SLDL / SDL / Esterel l Verification Languages – PSL (Sugar, OVL) / Open. VERA 81

Hardware Description Languages (HDL) l VHDL (IEEE 1076) l Verilog 1. 0 (IEEE 1364) l Verilog 2. 0 (IEEE 1364) l System. Verilog 3. 0 (to be sent for IEEE review) l System. Verilog 3. 1 (to be sent for IEEE review) 82

System. Verilog 3. 0 l Built-in C types l Synthesis improvements (avoid simulation and synthesis mismatches) l Enhanced design verification – procedural assertions l Improved modeling – communication interfaces 83

System. Verilog 3. 1 l Testbench automation – Data structures – Classes – Inter-process communication – Randomization l Temporal assertions – Monitors – Coverage Analysis 84

System. Verilog Environment for Ethernet MAC 85

Architecture Description Language in SOC Codesign Flow Design Specification Estimators Architecture Description Language IP Library M 1 P 2 P 1 Hw/Sw Partitioning HW SW VHDL, Verilog Verification C Synthesis Compiler Cosimulation On-Chip Memory Rapid design space exploration Quality tool-kit generation Processor Core Off-Chip Memory Synthesized HW Design reuse Interface 86

Architecture Description Languages Objectives for Embedded SOC w Support automated SW toolkit generation § exploration quality SW tools (performance estimator, profiler, …) § production quality SW tools (cycle-accurate simulator, memory-aware compiler. . ) Compiler ADL Architecture Model Compiler Simulator Synthesis Description File Formal Verification w Specify a variety of architecture classes (VLIWs, DSP, RISC, ASIPs…) w Specify novel memory organizations w Specify pipelining and resource constraints 87

Architecture Description Languages l Behavior-Centric ADLs (primarily capture Instruction Set (IS)) ISPS, n. ML, ISDL, SCP/Valen. C, . . . 4 good for regular architectures, provides programmer’s view 8 tedious for irregular architectures, hard to specify pipelining, implicit arch model l Structure-Centric ADLs (primarily capture architectural structure) MIMOLA, . . . 4 can drive code generation and architecture synthesis, can specify detailed pipelining 8 hard to extract IS view l Mixed-Level ADLs (combine benefits of both) LISA, RADL, FLEXWARE, MDes, … 4 contains detailed pipelining information 8 most are specific to single processor class and/or memory architecture 8 most generate either simulator or compiler but not both 88

EXPRESSION ADL Verification Feedback Processor Libraries ASIP Exploration Simulator Toolkit Generator DSP Profiler Exploration Compiler VLIW EXPRESSION ADL Memory Libraries Cache SRAM Prefetch Buffer Frame Buffer Exploration Phase Application Refinement Phase Retargetable Compiler Toolkit Generator Retargetable Simulator EDO On-chip RD RAM Profiler SD RAM Feedback 89

System. C History Synopsys ATG UC Irvine 1996 Synopsys “Scenic” Synopsys System. C v 0. 90 Sep. 99 “Fridge” Frontier Design A/RT Library 1991 imec 1992 VSIA SLD Data Types Spec (draft) Co. Ware “N 2 C” 1997 Fixed Point Types Abstract Protocols System. C v 1. 0 Apr. 00 System. C v 1. 1 Jun. 00 90

System. C Highlights l Features as a codesign language – Modules – Processes – Ports – Signals – Rich set of port and signal types – Rich set of data types – Clocks – Cycle-based simulation – Multiple abstraction levels – Communication protocols – Debugging support – Waveform tracing 91

Current System Design Methodology C/C++ System Level Model Refine Analysis Results Manual Conversion VHDL/Verilog Simulation Synthesis Rest of Process 92

Current System Design Methodology (cont’d) l Problems – Errors in manual conversion from C to HDL – Disconnect between system model and HDL model – Multiple system tests 93

System. C Design Methodology System. C Model Simulation Refinement Synthesis Rest of Process 94

System. C Design Methodology (cont’d) l Advantages – Refinement methodology – Written in a single language – Higher productivity – Reusable testbenches 95

System. C Programming Model l Mod 1 Mod 2 l Mod 3 A set of modules interacting through signals. Module functionality is described by processes. 96

System. C programming model (cont’d) l System (program) debug/validation – Testbench • Simulation, Waveform view of signals – Normal C++ IDE facilities • Watch, Evaluate, Breakpoint, . . . l sc_main() function – instantiates all modules – initializes clocks – initializes output waveform files – starts simulation kernel 97

A Simple Example: Defining a Module l Complex-number Multiplier (a+bi)*(c+di) = (ac-bd)+(ad+bc)i a b c d e Complex Multiplier f (cmplx_mult) SC_MODULE(cmplx_mult) { sc_in<int> a, b; sc_in<int> c, d; sc_out<int> e, f; . . . } 98

A Simple Example: Defining a Module (cont’d) SC_MODULE(cmplx_mult) { sc_in<int> a, b; sc_in<int> c, d; void cmplx_mult: : calc() { e = a*c-b*d; f = a*d+b*c; sc_out<int> e, f; void calc(); } SC_CTOR(cmplx_mult) { SC_METHOD(calc); sensitive<<a<<b<<c<<d; } } 99

Completing the Design M 1 a b M 2 input_gen c d Complex Multiplier e f M 3 display Clk. signal() clk 100

Completing the Design: input_gen module SC_MODULE(input_gen) { sc_in<bool> clk; sc_out<int> a, b; sc_out<int> c, d; void input_gen: : generate() { int a_val=0, c_val=0; void generate(); while (true) { a = a_val++; wait(); c = (c_val+=2); wait(); } SC_CTOR(input_gen) { SC_THREAD(generate); sensitive_pos(clk); } } } 101

Completing the Design: display module SC_MODULE(display) { sc_in<int> e, f; void display: : show() { void show(); SC_CTOR(display) { SC_METHOD(show); sensitive<<e<<f; } cout<<e<<‘+’<<f<<“in ”; } } 102

Putting it all together: sc_main function #include <systemc. h> int sc_main() M 2. a(a); M 2. b(b); M 2. c(c); M 2. d(d); M 2. e(e); M 2. f(f); { M 3. e(e); M 3. f(f); input_gen M 1(“I_G”); cmplx_mult M 2(“C_M”); display M 3(“D”); sc_signal<int> a, b, c, d, e, f; sc_clock clk(“clk”, 20, 0. 5); sc_start(100); return 0; } M 1. clk(clk. signal()); M 1. a(a); M 1. b(b); M 1. c(c); M 1. d(d); 103

104

105

106

Property Specification Language (PSL) l l l Accellera: a non-profit organization for standardization of design & verification languages PSL = IBM Sugar + Verplex OVL System Properties – Temporal Logic for Formal Verification l Design Assertions – Procedural (like System. Verilog assertions) – Declarative (like OVL assertion monitors) l For: – Simulation-based Verification – Static Formal Verification – Dynamic Formal Verification 107