coen 691b: embedded system design lecture 1:...

Samar Abdi(slides courtesy of A. Gerstlauer, D. Gajski and R. Doemer)

Assistant Professor

Electrical and Computer Engineering

Concordia University

http://www.ece.concordia.ca/~samar

COEN 691B: Embedded System Design

Lecture 1: Introduction, Course Logistics

Lecture Outline

• What are Embedded Systems and why should we care?

• Course organization/policies

• ES modeling

• ES design methodologies

• Languages

• Case study for the programming assignments

2Intro to Real-Time Systems

COEN 691B: Embedded System Design 3

Embedded Systems• Systems that are part of a larger system

– Application-specific• Diverse application areas

– Tight constraints• Real-time, performance, power, size• Cost, time-to-market, reliability

• Ubiquitous– Far bigger market than general-

purpose computing (PCs, servers)• $46 billion in ‘04, >$90 billion by 2010,

14% annual growth• 4 billion devices in ‘04• 98% of processors sold

[Turley02, embedded.com]


System Design is hard…


… and getting harder• Growing system complexities

– Increasing application demands• Networked and distributed• Cyber-physical integration• Increasingly programmable & customizable

– Technological advances• Multi-Processor System-On-Chip (MPSoC)

10,000

1,000

100

10

1

0.1

0.01

0.001

Logi

c tr

ansi

sto

rs p

er

chip

(in

mill

ion

s)

100,000

10,000

1000

100

10

1

0.1

0.01

Pro

du

ctiv

ity

(K)

Tran

s./S

taff

-Mo

.

IC capacity

Productivity

Gap

Source: SEMATECH; Courtesy of: T. Givargis, F. Vahid. “Embedded System Design”, Wiley 2002.


General-Purpose Computing• Reaching physical limits of technology scaling

– Power/utilization/… walls and dark silicon

– Efficiency/optimality vs. flexibility/generality

Opportunity and need for specialization

Heterogeneous multi-core /Asynchronous CMP

GP-GPUs


Source: T. Noll, RWTH Aachen, via R. Leupers, “From ASIP to MPSoC”, Computer Engineering Colloquium, TU Delft, 2006

Processor Implementation Options


Multi-Processor System-on-Chip (MPSoC)

Frontside Bus

SystemMemory

Local Bus

Local RAM

Bridge

SharedRAM

DSP Bus

DSP RAM

MemoryController

GPU

DSP

HardwareAccelerator

CPU

HardwareAccelerator

VideoFront End


MPSoC Challenges

Applications

ProgrammingModel?

• Complexity– High degree of parallelism at

various levels– High degree of design freedom– Multiple optimization objectives

design constraints

• Heterogeneity – Of components

• Processors, memories, busses

– Of design tasks• Architecture, mapping, scheduling


System levelSystem level

Abstraction Levels• Move to higher levels of abstraction [ITRS07,

itrs.net]Electronic system-level (ESL) design

1E0

1E1

1E2

1E3

1E4

1E5

1E6

1E7

Number of componentsLevel

Gate

RTL

Algorithm

Transistor

Ab

stra

ctio

n

Acc

ura

cy

Source: R. Doemer, UC Irvine


System-Level Design• From specification

– Functionality, behavior• Application algorithms• Constraints

• To implementation– Architecture

• Spatial and temporal order• Components and

connectivity• Across hardware and

software

Design automation at the system level– Modeling and simulation– Synthesis– Verification

Proc

Proc

Proc

Proc

Proc

Requirements, constraints

Implementation (HW/SW synthesis)

SystemDesign

DCT

TX

ARM

M1Ctrl

I/O4

HW

DSP

MBUS

BUS1 (AHB) BUS2 (DSP)

Arb

iter1

IP Bridge

DCTBus

I/O3I/O2I/O1

DMA

M1

Enc DecJpeg

Codebk

stripe

SI BO BI SO

DCT

MP3

Lecture Outline



• ES modeling


• Languages



Course Logistics

• Course website:

http://www.ece.concordia.ca/~samar/coen691b

• Lectures: F, 17:45 – 20:15, MB-S2.285

• Office hours: M, W 15:00 – 16:00, EV 5.183

• All lectures slides will be made available on course website

– Immediately after the class

13COEN 691B: Embedded System Design

Grading

• No Final Exam

• Midterm (20%)

– November 11, in class

– Fixed and no make-up test offered

• Programming assignments(40% total)

• Project (40%)

– All submissions must be made on EAS

• Login with ENCS account to https://fis.encs.concordia.ca/eas


https://fis.encs.concordia.ca/eas

Programming Assignments• Total four programming assignments

– To be done independently or in teams of two

– First assignment will be posted by next class

• SystemC modeling for embedded system specification– Digital camera example (JPEG encoder)

– Original C model will be posted on course website this weekend

– All SystemC models will be refined stepwise from the original C model

– All models must be validated for functional correctness against the C model



Project• Teams of 2-3 students allowed• Possible project ideas will be listed on course website by next class

• Project goals– Independent research or development project

• ES design example/case study for an application• ES design automation tool

– Literature review, proposal, implementation– Final report and presentation in publishable quality

• Project timeline– Abstract (Submit by Sept. 30)– Detailed problem definition and review of related work (present on October

28)– Demonstration and final presentation (December 2)– Final report (Submit by December 7)

Plagiarism

• Midterms, Programming Assignment and Projects require original work

– Strictly enforced

– All plagiarism cases will be reported

– Please refer to Concordia’s code of conduct:

http://provost.concordia.ca/academicintegrity/code/



Textbooks• Main textbook

– D. Gajski, S. Abdi, A. Gerstlauer, G. Schirner, Embedded System Design: Modeling, Synthesis, Verification, Springer, 2009 (“orange book”)

• SystemC Reference– T. Groetker, S. Liao, G. Martin, S. Swan,

System Design with SystemC, Kluwer, 2002 (“black book")• Several online tutorials and examples available

• Additional reading material (papers) will be posted on the webpage as the course progresses

Lecture Outline



• ES modeling


• Languages




Modeling• A model:

– Abstraction of physical realityMathematical formula, drawing/blueprint, data

• Core of any design process– Specification

• Define (formally!) desired characteristics, “golden” reference

– Exploration• Validate design choices

– Analysis and evaluation• Static analysis• Simulation/experiments

Predict before the system is builtContract of what to buildDetect problems early (and cheaply)

Simulator

Model

Stimuli Results

Correctness of model? Accuracy vs. simplicity


System Specification• Capture requirements (what)

– Functional• Free of any implementation

details (not how)

– Non-functional• Quality metrics• Performance constraints

• Formal representation– Models of computation

• Objects and compositions• Concurrency and time

– Executable• Analysis or simulation

Application developmentPrecise description of desired system behavior

Complete and unambiguous

Natural language Ambiguous Incomplete

C1

P5

P3

P4

dP1

P2

d

C2


System Architecture

Application mapping

Allocation

Partitioning

Scheduling

Bri

dg

e

P1 P3

CPU Mem

HW IP

P5

C1, C2

Arb

ite

r

P4P2

C1, C2CPU Bus IP Bus

• Processing elements (PEs)– Processors

• General-purpose, programmable• Digital signal processors (DSPs)• Application-specific instruction

set processor (ASIP)• Custom hardware processors• Intellectual property (IP)

– Memories

• Communication elements (CEs)– Transducers, bus bridges– I/O peripherals

• Busses– Communication media

• Parallel, master/slave protocols• Serial and network media


System Implementation• Hardware

– Microarchitecture– Register-transfer level (RTL)

• Software binaries– Application object code– Real-time operating

system (RTOS)– Hardware abstraction layer (HAL)

• Interfaces– Pins and wires– Arbiters, muxes, interrupt

controllers (ICs), etc.– Bus protocol state machines

CP

U

Mem

Bridge

HW IP

Arbiter

HAL

RTOS

EXEIC

Program

Specification for further manufacturing

Logic synthesis

Layout


Bri

dg

e

CPU Mem

HW IP

Arb

iter

v1

C1

B1 B2

B3 B4

C2

CommunicationComputation &

System SynthesisFront-End

Software / HardwareSynthesisBack-End

TLM

Inst

ruct

ion

-Set

Sim

ula

tor

(ISS

) C-b

ased

RTL

Software Object Code

Hardware VHDL/Verilog

Application specification

Transaction-Level Models

TLMTLMTLMn

Platform library

System-Level Design Flow

System-Level Design Languages (SLDLs)

C/C++ code


Models vs. Languages

• Computation models describe system behavior– Conceptual notion, e.g., recipe, sequential program

• Languages capture models– Concrete form, e.g., English, C

• Variety of languages can capture one model– E.g., sequential program model C,C++, Java

• One language can capture variety of models– E.g., C++ → sequential program model, object-oriented

model, state machine model• Certain languages better at capturing certain models

Models

Languages

Recipe

SpanishEnglish Japanese

Poetry Story Sequent.program

C++C Java

Statemachine

Data-flow

Recipes vs. English Sequential programs vs. C

Source: T. Givargis, F. Vahid. “Embedded System Design”, Wiley 2002.


Text vs. Graphics

• Models versus languages not to be confused with text versus graphics– Text and graphics are just two types of languages

• Text: letters, numbers

• Graphics: circles, arrows (plus some letters, numbers)


…

X = 1;

if (N)

Y = X + 1;

…

N?

X =1

Y = X + 1


Simulation vs. Synthesis• Ambiguous semantics of languages

Simulatable but not synthesizable or verifiable Impossible to automatically discern implicit meaning Need explicit set of constructs

case X iswhen X1=>

.

.

.when X2=>

Finite state machine

Controller

3.415

2.715

--

--

Look-up table

Memory

Source: D. Gajski, UC Irvine

Lecture Outline



• ES modeling


• Languages




Design Flow

• Design methodology

– Sequence of design models

– Flow of transformations between models

• Models

– Well-defined, rigorous semantics

– Systematic flow from specification to implementation

• Languages

– Representation of models in machine-readable form


Evolution of Design Flows

Specs

Algorithms

Capture &

Simulate

Specs

Algorithms

Describe &

Synthesize

Executable

Spec

Algorithms

Specify, Explore

& Refine

Architecture

Network

SW/HW

Logic

Physical

SW? SW?

Design

Logic

Physical

Design

Logic

Physical

Manufacturing Manufacturing Manufacturing

1960's 1980's 2000's

Functionality

Simulate Simulate

Describe

Algorithms

Connectivity

Protocols

Performance

Timing

System Gap



Y-ChartBehavior(Function)

Structure (Netlist)

Physical (Layout)

Logic

Circuit

Processor

System

RTL

Gates

Transistors

PE,Bus

Specification

Algorithm

Boolean logic

Transfer

(a v b)

Mo

del

s o

f C

om

pu

tati

on

(M

oC

s) Mo

dels o

f Structu

re (Mo

Ss)



Processor Synthesis

Algorithm model (program) Microarchitecture model (RTL)

B1

B2

ALU M em ory

R F / Scratch pad

M U L

B3

AG

PC

CW

Sta

tus

...const

offset

status

address

C M em

IF

IF

BB1

BB2 BB3

Y

YN

N

• Software processor

• Compilation and linking

• Hardware processor

• High-level synthesis



System Synthesis• Structure

• Partitioning, mapping

• Timing

• Scheduling

C 1

P5

P3

P4

dP 1

P 2

d

C 2

Bri

dg

e

P1 P3

C P U M em

H W IP

P5

C 1, C 2

Arb

ite

r

P4P2

C 1, C 2C P U B us IP B us

Specification model (processes) Architecture model (TLM)



Bottom-Up Methodology

• Each level generates library for the next higher level

– Circuit: Standard cells for logic level

– Logic: RTL components for processor level

– Processor: Processing and communication components for system level

– System: System platforms for different applications

• Floorplanning and layout on each level

Behavior(Function)

Structure (Netlist)

Physical (Layout)

Logic

Circuit

Processor

System

Start

RTL

Gates

Transistors

PE,Bus



Top-down Methodology Behavior

(Function)

Structure (Netlist)

Physical (Layout)

System

Start

Transistors

• Functional description is converted into component netlist on each level

• Each component function is decomposed further on the next abstraction level

• Layout is given only for transistor components



Meet-in-the-Middle Methodology Behavior

(Function)

Structure (Netlist)

Physical (Layout)

System

Start

Gates

Transistors

• Gate netlist is hand-off

• Three levels of synthesis

– System is synthesized with processor components

– Processor components are synthesized with RTL library

– RTL components are synthesized with standard cells

• Two levels of layout

– System layout is performed with standard cells

– Standard cells layout with transistors



Platform-Based Design

• Meet-in-the-middle at the system level

– System platform with standard components

– System design reduced to mapping of specification onto pre-defined platform

Behavior(Function)

Structure (Netlist)

Physical (Layout)

Logic

Circuit

Processor

System

Start

RTL

Gates

Transistors

Platform



System Modeling

Basis of any design flow and design automation Inputs and outputs of design steps

Capability to capture complex systems Precise, complete and unambiguous

Models at varying levels of abstraction Level and granularity of implementation detail Speed vs. accuracy

• Design models as an abstraction of a design instance– Representation of some aspect of reality

• Virtual prototyping for validation through simulation or formal analysis– Specification for further implementation/synthesis

• Describe desired functionality Documentation & specification

Abstraction to hide details that are not relevant or not yet knownDifferent parts of the model or different use cases for the same model


Abstraction Levels

Temporal orderLow abstraction

High abstraction

Implementation Detail

Spatial order

physical layout

unstructured

Structure

real time

untimed

Timing


Top-Down Design Flow

Implementation

Architecture

Specification

Logic Design

Product planning

Structure

pure functional

bus functional

RTL / ISA

gates

requirements

Timing

untimed

timing accurate

cycle accurate

gate delays

constraints

System Design

Processor Design



Implementation model

Transaction-level model

Specification model

Logic design

Product planning

pure functional

partitioned

bus functional

RTL / IS

requirements

untimed

scheduled

timing accurate

cycle accurate

constraints

Timed model

Processor design

Communication design

Computation design

Structure Timing



untimed

estimated timing

timing accurate

cycle accurate

constraints

pure functional

transaction level

bus functional

RTL / IS

requirements

Specification model

Algor.IP

Proto.IP

Timed model

Communication refinement

Comp.IP


Softwaresynthesis

Interfacesynthesis

Hardwaresynthesis

RTOSIP

RTLIP

Computation refinement

Capture


Product planning

Logic designStructure Timing


Design MethodologySystem design Validation flow

Specification model

Algor.IP

Proto.IP

Timed model

Communication refinement


Comp.IP

Estimation

ValidationAnalysis

Compilation Simulation model

Estimation

ValidationAnalysis


Estimation

ValidationAnalysis



Softwaresynthesis

Interfacesynthesis

Hardwaresynthesis

Backend Estimation

ValidationAnalysis


RTOSIP

RTLIP

Computation refinement

Capture

Lecture Outline



• ES modeling


• Languages




Languages Represent a model in machine-readable formApply algorithms and tools

• Syntax defines grammar– Possible strings over an alphabet– Textual or graphical

• Semantics defines meaning– Mapping onto an abstract state machine model

• Operational semantics

– Mapping into a mathematical domain (e.g. functions)• Denotational semantics

Semantic model vs. design modelsBasic semantic models can represent many design models

Discrete event model for hardware and system simulation

Design models can be represented in different languages


Evolution of Design Languages

• Netlists– Structure only: components and connectivityGate-level [EDIF], system-level [SPIRIT/XML]

• Hardware description languages (HDLs)– Event-driven behavior: signals/wires, clocks– Register-transfer level (RTL): boolean logicDiscrete event [VHDL, Verilog]

• System-level design languages (SLDLs)– Software behavior: sequential functionality/programsC-based, event-driven [SpecC, SystemC, SystemVerilog]



• Goals– Executability

• Validation through simulation– Synthesizability

• Implementation in HW and/or SW• Support for IP reuse

– Modularity• Hierarchical composition• Separation of concepts

– Completeness• Support for all concepts found in embedded systems

– Orthogonality• Orthogonal constructs for orthogonal concepts• Minimality

– SimplicitySource: R. Doemer, UC Irvine



BehavioralhierarchyStructuralhierarchy

Concurrency

Synchronization

Exceptionhandling

Timing

StatetransitionsCompositedata types

not supported partially supported supported

• Requirements




• C/C++– ANSI standard programming languages, software design– Traditionally used for system design because of practicality, availability

• SystemC– C++ API and class library– Initially developed at UC Irvine, standard by Open SystemC Initiative (OSCI)

• SpecC– C extension– Developed at UC Irvine, standard by SpecC Technology Open Consortium (STOC)

• SystemVerilog– Verilog with C extensions for testbench development

• Matlab/Simulink– Specification and simulation in engineering, algorithm design

• Unified Modeling Language (UML)– Software specification, graphical, extensible (meta-modeling)– Modeling and Analysis of Real-time and Embedded systems (MARTE) profile

• IP-XACT– XML schema for IP component documentation, standard by SPIRIT consortium

• Rosetta (formerly SLDL)– Formal specification of constraints, requirements

• SDL– Telecommunication area, standard by ITU

• …Source: R. Doemer, UC Irvine


Separation of Concerns

• Fundamental principle in modeling of systems

• Clear separation of concerns

– Address separate issues independently

• System-Level Description Language (SLDL)

– Orthogonal concepts

– Orthogonal constructs

• System-level Modeling

– Computation• encapsulated in modules / behaviors

– Communication• encapsulated in channels



Computation vs. Communication

• Traditional model

– Processes and signals– Mixture of computation and communication– Automatic replacement impossible

s2

s1

s3

P1 P2


• Channel concept (OOP)

• Tasks and channels

• Separation of computation and communication

• Plug-and-play

B2

v2

v1

v3

B1C1


Computation vs. Communication

• Protocol Inlining– Specification model– Exploration model

• Computation in behaviors• Communication in channels

B2

v2

v1

v3

B1C1


• Implementation model

– Channel disappears

– Communication inlined

– Wires exposed

B2B1

v2

v1

v3


IP protocol channel in wrapper

C2

Intellectual Property (IP)

• Communication IP: Channel with wrapper

replacableat any time

Virtual channel

v2

v1

v3

C1

IP


• Protocol inlining with hierarchical channel

B1 B2

v2

v1

before

v2

v1

B1 B2

after

Lecture Outline



• ES modeling


• Languages




Programming Assignment:Digital Camera Specification

JpegEncoder

CCDControl

FileI/O

SoC

pixel bytes

FlashMemory

CCDSensor

JpegEncoder

Read DCT Quant Huff8x8

block8x8

block8x8

blockPixel bytes


Charge-Coupled Device (CCD)

• Special sensor that captures an image

• Light-sensitive silicon solid-state device composed of many cells

When exposed to light, each cell becomes electrically charged. This charge can then be converted to a 8-bit value where 0 represents no exposure while 255 represents very intense exposure of that cell to light.

Some of the columns are covered with a black strip of paint. The light-intensity of these pixels is used for zero-bias adjustments of all the cells.

The electromechanical shutter is activated to expose the cells to light for a brief moment.

The electronic circuitry, when commanded, discharges the cells, activates the electromechanical shutter, and then reads the 8-bit charge value of each cell. These values can be clocked out of the CCD by external logic through a standard parallel bus interface.

Lens area

Pixel columns

Covered columns

Electronic circuitry

Electro-mechanical

shutterP

ixel

ro

ws



Compression

• JPEG (Joint Photographic Experts Group)– Popular standard format for representing digital

images in a compressed form– Provides for a number of different modes of

operation– Mode used in this chapter provides high compression

ratios using DCT (discrete cosine transform)– Image data divided into blocks of 8 x 8 pixels– 3 steps performed on each block

• DCT• Quantization• Huffman encoding



Discrete Cosine Transform (DCT)

• Transforms original 8 x 8 block into a cosine-frequency domain– Upper-left corner values represent low frequency components

• Essence of image

– Lower-right corner values represent finer details• Can reduce precision of these values and retain reasonable image quality

• FDCT (Forward DCT) formula– C(h) = if (h == 0) then 1/sqrt(2) else 1.0

• Auxiliary function used in main function F(u,v)

– F(u,v) = ¼ × C(u) × C(v) Σx=0..7 Σy=0..7 Dxy × cos(π(2u + 1)u/16) × cos(π(2y + 1)v/16)

• Gives encoded pixel at row u, column v

• Dxy is original pixel value at row x, column y



Quantization

• Achieve high compression ratio by reducing image quality– Reduce bit precision of encoded data

• Fewer bits needed for encoding• One way is to divide all values by a factor of 2

– Simple right shifts can do this

– Dequantization would reverse process for decompression

1150 39 -43 -10 26 -83 11 41

-81 -3 115 -73 -6 -2 22 -5

14 -11 1 -42 26 -3 17 -38

2 -61 -13 -12 36 -23 -18 5

44 13 37 -4 10 -21 7 -8

36 -11 -9 -4 20 -28 -21 14

-19 -7 21 -6 3 3 12 -21

-5 -13 -11 -17 -4 -1 7 -4

144 5 -5 -1 3 -10 1 5

-10 0 14 -9 -1 0 3 -1

2 -1 0 -5 3 0 2 -5

0 -8 -2 -2 5 -3 -2 1

6 2 5 -1 1 -3 1 -1

5 -1 -1 -1 3 -4 -3 2

-2 -1 3 -1 0 0 2 -3

-1 -2 -1 -2 -1 0 1 -1

After DCT After quantization

Divide each cell’s value by 8



• Serialize 8 x 8 block of pixels

– Values are converted into single list using zigzag pattern

• Perform Huffman encoding

– More frequently occurring pixels assigned short binary code

– Longer binary codes left for less frequently occurring pixels

• Each pixel in serial list converted to Huffman encoded values

– Much shorter list, thus compression

Huffman Encoding (ZigZag)



Huffman Encoding (2)

• Pixel frequencies on left

– Pixel value –1 occurs 15 times

– Pixel value 14 occurs 1 time

• Build Huffman tree from bottom up

– Create one leaf node for each pixel value and assign frequency as node’s value

– Create an internal node by joining any two nodes whose sum is a minimal value

• This sum is internal nodes value

– Repeat until complete binary tree

• Traverse tree from root to leaf to obtain binary code for leaf’s pixel value

– Append 0 for left traversal, 1 for right traversal

• Huffman encoding is reversible

– No code is a prefix of another code

144

5 3 2

1 0 -2

-1

-10 -5 -3

-4 -8 -9614

1 1

2

1 1

2

1

22

4

3

5

4

65

9

5

10

5

115

14

6

17

8

181

5

29

35

64

1

-1 15x

0 8x

-2 6x

1 5x

2 5x

3 5x

5 5x

-3 4x

-5 3x

-10 2x

144 1x

-9 1x

-8 1x

-4 1x

6 1x

14 1x

-1 00

0 100

-2 110

1 010

2 1110

3 1010

5 0110

-3 11110

-5 10110

-10 01110

144 111111

-9 111110

-8 101111

-4 101110

6 011111

14 011110

Pixel frequency

Huffman treeHuffman

codes


Programming Assignments

1. C model to a concurrent SystemC Process Network model

2. Timing measurement for individual tasks and creation of a timed model

3. Modeling the RTOS scheduling layer to determine performance of SW implementation

4. Modeling a HW-SW solution by moving the DCT to a faster HW module


What will you learn?

• How to model embedded systems?– Models of computations: process and state-based– System-level modeling language (SystemC)– Concurrency, Timing, Scheduling, Communication

• How to predict performance of embedded systems?– ISS-based, measurements and source-level timing analysis

• How to do hardware-software co-design?– Partitioning and mapping of applications– Synthesis of platforms

• How to ensure correctness of embedded systems?– Formal verification and simulation techniques


Summary

• Embedded systems are pervasive, difficult to design, and have a huge market!– Over $90 billion market for embedded processors

– Embedded SW deployed in billions of electronic products

– Embedded SW has become the major cost component in modern cars

• A model-based approach from specification to implementation is essential for success!


coen 691b: embedded system design lecture 1:...

Documents