single-source approach to the design of hw/sw embedded systems

Eugenio VillarPablo Peñil

University of CantabriaSpain

Schedulablity Analysis

Simulation

Verification

Performance Analysis

Design-Space Exploration

Architectural Mapping

Optimization

Reusability

HWSynthesis

SWSynthesis

Aproximación de Código Único para la mejora del Diseño de Sistemas Embebidos HW/SW

� Motivation

� Modeling of HW/SW Embedded Systems

� Simulation & Performance Analysis

� SW Synthesis

� Verification

� Conclusions

� Who are we?

Agenda

2Seminario de “Metodología de Diseño de SEs HW/SW de código único” TASE, Tres Cantos, July 17, 2014

Microelectronics Engineering Group

Prof. Eugenio Villar

Ing. Pablo Peñil

University of Cantabria4th Spanish University in Research Quality (BBVA-IVIE)

GIM

Who we are


� Design Languages

� Hardware (HDLs)

� VHDL, Verilog,…

� Embedded SW

� ADA, C, C++, ASM (ARM, openrisc, etc…)

� Specification and Design

� SystemC, SystemC-AMS, AADL, UML, MARTE, …

� Interchange format

� IP/XACT

� Hardware Design

� RTL and Behavioral synthesis (Mentor, Synopsys, ISE, Quartus)

� System-Level synthesis: Catapult-C, Gaut, …

� HW/SW Co-Design, Embedded Systems and ESL design

� Development Environments: Quartus, XPS, Eclipse, Papyrus

� RTOS: ELinux, uC-Linux, eCos, uCO-II, xilkernel,

� Embedded processors: ARM, Microblaze, Nios, Leon, Openrisc, …

Main Know-How


� System-Level Specification

� SystemC (HetSC)

� UML/MARTE

� AADL (AADS)

� Verification of Embedded Systems

� Assertion-based verification

� Automatic Test Pattern Generation

� Model-Checking

� System-Level Performance Estimation

� SCoPE→SCoPE+

� VIPPE

� Automatic Implementation

� Automatic SW Generation from SystemC (SWGen) and UML/MARTE (eSSYN)

� HW/SW interfaces

Main research Areas


� Artemis SCALOPES

� ESTEC HWSWCo

� FP7 COMPLEX

� FP7 Pharaon

� Artemis CopCams

� Artemis Crafters

� FP7 Contrex

� Artemis EMC2

Recent and on-going projects


Agenda

7Seminario de “Metodología de Diseño de SEs HW/SW de código único”

� Who are we?

� Motivation



� SW Synthesis

� Verification

� Conclusions

TASE, Tres Cantos, July 17, 2014

Motivation

� Design productivity gap

� Raising the abstraction level

� Multi-Processing &Heterogeneous platforms

� Increasing SW content

� SW-centric design methodologies


� HW/SW platform

OS1

OS2GPU DSP

� Ad/Hoc SW development

� System calls

� Communication functions

� I/O functions & drivers

� Verification & Debug

� Costly fixing of wrong design decisions

� Architectural Design

Usual SW development flow

N2 BN1

M A

� Architectural mapping


� Lack of reusability

� Ad-hoc code

� Partial performance analysis

� Large re-engineering effort

Usual SW development flow

N2 BN1

M A

OS3OS1

OS2GPU DSP


Agenda


� Who are we?

� Motivation



� SW Synthesis

� Verification

� Conclusions


Introduction

� Model-Driven Architecture (MDA)

� High-abstraction level

� Mature SW engineering methodology

� UML language

� Application to embedded systems design


Introduction

� Why UML?

� Natural way to capture system architecture

� Standard way

N2 BN1

M A

N.P N.O


Introduction

� Why UML?

� Natural way to capture system architecture

� Standard way

� UML language

� Semantics lacks

� What is each component?

� What kind or interaction each link actually means?

� Domain-specific profiles

� UML/MARTE


Introduction

� MARTE

� Standard UML profile for real-time embedded systems

� Platform-Independent Model (PIM)

� Platform Description Model (PDM)

� Platform-Specific Model (PSM)

� Rich semantics content

� Single-source approachSchedulablity

AnalysisSimulation

Verification

Performance Analysis

Design-Space Exploration

Architectural Mapping

Optimization

Reusability

HWSynthesis

SWSynthesis


State-of-the-Art

� Discussion

� System modeling in MARTE

� Methods based on specific MoCs and/or profiles

� Requiring additional semantics

� Non-standard

� SW Synthesis

� Commercial code generation available

� Limited support for heterogeneity

� Limited flexibility for different architectural mappings

� Limited support for the MARTE semantics


PHARAON Single-Source Design Flow



HW/SWPlatform

Architectural

MappingsC/

C++

Scenarios

PIM (App)

HWAccelerators

HWAccelerators

HWAcceleratorsHW

Accelerators

SW stacks

CompilersLinkers

SW Synthesis (eSSYN)

+

M2T Tools

CPUs/DSPs/ASIPs GP-GPUs


PHARAON Modeling Methodology

� Main features

� MDD concepts

� Separation of Concerns

� CBE: Component-Based Engineering approach

� SW centric

� Standard

� MARTE profile


TASE, Tres Cantos, July 17, 2014 20Seminario de “Metodología de Diseño de SEs HW/SW de código único”


� Modeling Methodology� Separation of Concerns

� Bit Arrays

� Arrays


� Data Types for Communication Interfaces

� Primitive Types

� Data Structures



� Functional View

� Classes implement Interfaces and require services

Internal Interfaces

External Interfaces



� Communication & Concurrency View

� System components and their non-functional properties

� Two different kinds of components

� Components with their own execution thread

� Stereotyped with the MARTE::HLAM RtUnit

� Passive components

� Stereotyped with the MARTE::HLAM PpUnit

� Representation� Composite diagrams



� Component model

� Hierarchical functional encapsulation

� Ports

� provided or required

C2

C2.3

C2.1 C2.2



� Component Interfaces

C2

C2.3

C2.1 C2.2



� Component model

� Interfaces

� sequential, guarded or concurrent, Max. threads available

� argument sizes (data splitting), Num. of incoming channels

C2

C2.3

C2.1 C2.2



� Component model

� Channels manage communications

� BlockingFunctionCall, BlockingFunctionReturn, both or none

� Timeout

� Priority

� Buffer Size

� ResMult

C2

C2.3

C2.1 C2.2



� SW Platform

� Declares High-level SW Components

� RTOS, Drivers, HdS

� Class Diagram

� can be shared with HW platform diagram

� Each SW Component

� A UML Component + MARTE stereotype

� RTOS: <<scheduler>>

� Drivers: <<DeviceBroker>>

� HdS: <<HwPLP>>

� Stereotypes for very high-level modeling could be a MARTE improvement



� HW Platform

� Declares HW Components

� Processors, Memories, Buses, IO Peripherals

� Processor: <<HwProcessor>>

� Memory: <<HwMemory>>, <<HwRAM>>, <<HwROM>>

� Bus: <<HwBus>>, etc…



� The Platform Description Model

� HW/SW Components using MARTE stereotypes

� Software Components

� OS, HdS, Drivers, …

� Hardware Components

� Processors, Memories, Buses, Custom HW, I/O



� Platform-Specific Model

� Mapping of functional components

� to memory spaces and/or platform resources

� Memory spaces mapped to platform resources


� Architectural Design


� HW/SW platform


� Code reuse and/or development

� platform independent


� Verification View

� COMPLEX stereotype

� <<VerificationView>>

� Environment component

� Separated from system components

� Homogeneous style

� composite diagram

� Enables extraction of the

test bench SystemC

code (structural code)


verification

<<VerificationView>>


34Seminario de “Metodología de Diseño de SEs HW/SW de código único” 2011-01-19

� Interaction “Behavior”

� between an environment component and the System Component

� A sequence Diagram

� Includes synchronization and communication semantics

� Extraction of code for the behavior of environment component




35Seminario de “Metodología de Diseño de SEs HW/SW de código único” 2011-01-19

� A single sequence diagram can cover the interaction of more than one environment component

� Synthetic description of a “scenario”

� Interaction “Behavior”

� Eventually, a single sequence diagram





Scenario1

<<Scenario>>

2011-01-19

� Scenario: A tuple of interactions covering the interaction of the system with the whole environment

� A package within the Verification View with the <<Scenario>> stereotype

� Several scenarios are possible

� Synthetic: import of sequence diagrams



Scenario2

<<Scenario>>


Agenda


� Who are we?

� Motivation



� SW Synthesis

� Verification

� Conclusions



�HW/SW Embedded Systems Design Flow

UML/MARTEMDA

Functional design

C

VHDLVerilog

SystemC

HW/SW Implementation

RTL Synthesis

Compilation IPReuse

Behavioral Synthesis

HW Platform

Embedded SW

Co- Design

Executable Specification

Requirements

� HW/SW Simulation

� Performance Analysis

• avoiding slow design iterations

� Design Verification

• At the different abstraction levels

ContextContext

� Computing needs Time

� Edward A. Lee

� Communications of the ACM, 52(5):70-79, May 2009

MotivationMotivation

� Computing needs Energy

� Eugenio Villar

� Still to be published


� Motivation

� Why SW performance analysis

� Software Simulation Technologies in Virtual Platforms

� Simulation Technologies at different abstraction levels

� SCoPE: SW performance analysis for DSE

• Native simulation

• After architectural mapping

� SCoPE+: SW performance analysis for DSE

• Compositional Native simulation

• Before architectural mapping

• Direct PSM from the same PIM

� VIPPE: Parallel simulation

AgendaAgenda


� The MPSoC

� Multi-processing platform

• ASIC

• FPGA

• Commercial multi-processing platform

� SW-centric design methodology

• Most of the functionality implemented as Embedded SW

• With ‘some’ application-specific HW

MotivationMotivation



� Embedded SW simulation

Functional Simulation

Native & Trace-based co-simulation

Accurate Computation&Communication estimations

Virtual Models

ISS Discrete-Time Models

HDL Discrete-Event Models

Native & Trace-based code simulation

Fast Computation&Communication estimations

SW Simulation Technologies

42

UML/MARTEMDA

Functional design

C

VHDLVerilog

SystemC

HW/SW Implementation

RTL Synthesis

Compilation IPReuse

Behavioral Synthesis

HW Platform

Embedded SW

Co- Design

Executable Specification

Requirements

Seminario de “Metodología de Diseño de SEs HW/SW de código único”

VHDLVerilog

� HDL simulation

� Very detailed Model

� Very accurate

� Very slowNode i

Application Code

Task n...Task 1

NoC if.

NoC

Other NodesBus

caches …

memory DMAASHW

CPU1

caches

CPUp

HdS API

HdSOS

OS API HdS API

HdSOS

OS APIHDL Model

Embedded System Architecture

Other Nodes

Node i

Bus model

NoC model

NoC if.DMA ASHW memory

Cache models …

CPU1 model

Cache models

CPUp model Compilation



ISSs

� ISS simulation

� Very detailed Model

� Very accurate

� Very slowNode i

HdS API

Application Code

Task n...Task 1

Bus

HdSOS

caches …

NoC

NoC if.memory DMAASHW Other Nodes

CPU1

OS API HdS API

HdSOS

caches

CPUp

OS API

ISS Model

Node i

Bus (TLM/RTL) model

NoC model


Cache models …Cache models

CPU1Instruction

Setmodel

CPUpInstruction

Setmodel Compilation


44


Seminario de “Metodología de Diseño de SEs HW/SW de código único” TASE, Tres Cantos, July 17, 2014

� Virtualization

� Target virtual model on host

Node i

HdS API

Application Code

Task n...Task 1

Bus

HdS

caches …

NoC


CPU1

HdS API

HdSOS

caches

CPUp

OS APINode i

TLM Bus model

NoC model


OS

OS API

Compilation

Binary Binary

…CPUp

virtual modelCPU1

virtual model


45


Virtual Model


� Virtualization (QEMU)

� Detailed model

• High modeling cost

• Late design steps

� Faster than ISS# movl_T0_r1

# ebx = env->regs[1]

mov 0x4(%ebp),%ebx

# addl_T0_im -16 # ebx = ebx -

16 add $0xfffffff0,%ebx #

movl_r1_T0

# env->regs[1] = ebx

mov %ebx,0x4(%ebp)

Intel Core i5 (2.40 GHz)

# r1 = r1 - 16

addi r1,r1,-16

PowerPC (200 MHz)



� Virtualization

� Functional emulation

� Rough timed simulation

• i.e. 1 cycle per instruction

� Additional effort needed for more accurate modeling

• Execution times

• Power consumption

• Caches

• …

� Requires a specific Virtual Model for each processor

� Commercial tools

� OVP, FastModels, Cadence, Carbon, Synopsys (CoWare), etc.



� Native & Trace-based simulation

� Embedded code directly executed by the host

� Good accuracy

• Native back-annotation

• Trace analysis

� Fast execution time



� Native simulation based on HAL API

� Abstraction of the HW platform

Node i

Bus

caches …

NoC


CPU1

caches

CPUp

Virtual Model

Node i

TLM Bus model

NoC model

NoC if.DMA ASHWOther Nodes memory

HdS API

Application Code

Task n...Task 1

HdSOS

OS API HdS API

HdSOS

OS API

Parsing…Abstract

CPU1 modelAbstract

CPUp model

HAL HAL

Annotation

HdS API

Application Code

Task n...Task 1

HdSOS

OS API HdS API

HdSOS

OS API


49



� Native simulation based on OS API

� Abstraction of the SW platform

Node i

TLM Bus model

NoC model

NoC if.DMA ASHWOther Nodes

Node i

Bus

caches …

NoC


CPU1

caches

CPUp

memory

HdS API

Application Code

Task n...Task 1

OS API HdS API

HdSOS HdSOS

OS API

…

HdS APIOS API HdS API

Abstract model of

OS & CPU

OS API

HdSAbstract model of

OS & CPU

HdSParsing

Annotation

Application Code

Task n...Task 1


50

Embedded System ArchitectureVirtual Model


� Basic code annotation in native simulation

…Overflow = 0;s = 1L;for (i = 0; i < L_subfr; i++) {

Carry = 0; s = L_macNs(s, xn[i], y1[i]);if (Overflow != 0) {

break; }}if (Overflow == 0) {

exp_xy = norm_l(s);

if (exp_xy<=0)xy = round(L_shr (s, -exp_xy));

elsexy = round(L_shl (s, exp_xy)); }

mq_send(queue1, &xy, p, t);…

Global variableint Sim_Time = 0;

Sim_Time += 20;

Sim_Time += 25;

Sim_Time += 15;

Sim_Time += 10;

Sim_Time += 10;

Sim_Time += 10;wait included



ISSs

� Trace-based simulation

� Activity traces from detailed models

Node i

HdS API

Application Code

Task n...Task 1

Bus

HdSOS

caches …

NoC


CPU1

OS API HdS API

HdSOS

caches

CPUp

OS APINode i

Bus (TLM/RTL) model

NoC model



CPU1Instruction

Setmodel

CPUpInstruction

Setmodel Compilation


52



ISSs


Node i

Bus (TLM/RTL) model

NoC model



CPU1Instruction

Setmodel

CPUpInstruction

Setmodel


53

Traces

SimulationTraces



� Difficult scheduling in complex multi-processing systems


54

TracesNode i

TLM Bus model

NoC model


Virtual Model

Scheduler

Application Code

Task n...Task 1


� Basic code execution in trace-based simulation

…Overflow = 0;s = 1L;for (i = 0; i < L_subfr; i++) {

Carry = 0; s = L_macNs(s, xn[i], y1[i]);if (Overflow != 0) {

break; }}if (Overflow == 0) {

exp_xy = norm_l(s);if (exp_xy<=0)

xy = round(L_shr (s, -exp_xy));

elsexy = round(L_shl (s, exp_xy)); }

mq_send(queue1, &xy, p, t);…


55

Traces

T1

T2

T3

T4

T5

T6

Sim_Time += 20;

Sim_Time += 25;

Sim_Time += 15;

Sim_Time += 10;

Sim_Time += 10;

Sim_Time += 10;


� Functional simulation based on code� Fastest but least accurate� Work-load analysis

Node i

Bus

NoC

NoC if.memory DMAASHW Other NodesTLM Bus model

NoC model


Application Code

caches …

CPU1

caches

CPUp


HdSOS HdSOS

OS API

…

Abstract model of OS, HdS & CPU

Modeling API

Abstract model of OS, HdS & CPU

Modeling API

Node i

Task n...Task 1Task n...Task 1


56

Embedded System ArchitectureVirtual Model


� Performance/Error comparison

� Rough approximate figures

TechnologyTime

EstimationTime & Power

Estimation

Performance 5,000 N.A.

Error N.A. N.A.

Performance 1,000 500

Error 1.3 1.4

Performance 200 T.B.M.

Error 1.5 T.B.M.

Performance 10 1

Error 1.1 (DT) 1.1

Performance 1 0.1

Error 1 (DE) 1

Functional

Native

Trace-based

Virtualization

ISS

(cycle-accurate)

HDL



� Key features

� Abstract OS modeling

� Instruction cache modeling

� Data cache modeling

� Level-X memory model

� Bus model

� System power estimation

SCoPE:SW Performance Estimation for DSE


� Novel features

� Physical memory accesses

� Separate memory spaces

� Configurability for Design-Space Exploration

� Dynamic Voltage-Frequency Scaling

� Thermal modeling

� System composition from IP-XACT components

� Win32 API




� Application code• Instruction counting from binary


60

Bus

NoC


Application Code

caches …

CPU1

caches

CPUp


HdSOS HdSOS

OS API

Node i

Task n...Task 1

� OS & HW-dependent SW• Function power estimation

� Caches• Counting memory accesses• Cache misses

� Bus

• Actual bandwidth• Cache misses• DMA accesses• HW accesses

� HW & NoC

• SystemC power models


Node i

TLM Bus model

NoC model


…

HdS API

Application Code

Task n...Task 1

OS API HdS API

Abstract model of

OS & CPU

OS API


OS & CPU

HdS

Node i

TLM Bus model

NoC model


…

HdS API

Application Code

Task n...Task 1

OS API HdS API

Abstract model of

OS & CPU

OS API


OS & CPU

HdS

Node i

TLM Bus model

NoC model


…

HdS API

Application Code

Task n...Task 1

OS API HdS API

Abstract model of

OS & CPU

OS API


OS & CPU

HdS

� Design-Space Exploration� Configurable model

Metrics

Designparameters

Pareto points

Design-Space

Exploration

Tool

(M3Explorer)




Node i

TLM Bus model

NoC model


Node i

Bus

caches …

NoC


CPU1

caches

CPUp

HdS API

Application Code

Task n...Task 1

OS API HdS API

HdSOS HdSOS

OS API

…


Abstract model of

OS & CPU

OS API


OS & CPU

HdSParsing

Application Code

Task n...Task 1

Annotation

T0(F0,V0)E0(F0,V0)

F,VF,V

E/T P

V

V.E E

F

F.T T

20

2

0

00

=

=

=



� Key features

� Abstract OS modeling

� Instruction cache modeling

� Data cache modeling


� Novel features

� Physical memory accesses

� Separate memory spaces

� Configurability for Design-Space Exploration


� Thermal modeling

� System composition from IP-XACT components

� Win32 API



SCoPE+: CompositionalNative Performance Estimation

64

� Implementation-Agnostic Platform Independent Frontend

� CFAM-CM API

� Fulfilling COMPLEX UML/MARTE executive semantics

� System-Level Modeling of Multi-OS execution

� SW/SW-HW/SW-HW/HW communications

� Architectural mapping agnostic

� Taking advantage of the native simulation speed*accuracy


� Macros and functions

� Concurrent Functional Application & Component Model

� Component Based PIM

� CFAM API

� Platform services required by functional code

� Hide RTOS specific calls



� Platform-Dependent Estimations directly on the PIM

� PIM

� PDM

ARM9annotation

ARM9annotation

ARM7annotation

HWannotation

SW/SWSW/SW

HW/SW



VIPPE: Parallel Simulation& Performance Analysis

67

......tbus 1

tbus b

tmem 1

tcore 1 tcore itcore n...

tmem mCluster 0

Target Multi-/Many-core HW platform

Target Real-Time Operating Systems (tRTOS)

� Increasing number of cores� Non-Uniform Memory Access (NUMA) � Heterogeneous: different types of cores,

HW accelerators, …

• 4 x Cortex A15• 4 x Cortex A7• 1 x MALI GPU

Embedded Software

...Embedded system

t-thread 1 t-thread t


......tbus 1

tbus b

tmem 1

tcore 1 tcore itcore n...

tmem mCluster 0

Target Multi-/Many-core HW platform

Target Real-Time Operating Systems (tRTOS)

Embedded Software

...Embedded system

t-thread 1 t-thread t

VIPPE: Parallel Simulation& Performance Analysis

68

Host Computer

Simulation / Virtual Platform

Software

h-thread 1 ... h-thread h

Host SMP Operating System (h-OS)

Multi-core HW Platform

(hcore 1,...,hcore h)

Source-code instrumentation/annotation

• Model embedded RTOS (tRTOS)

• Abstract hardware details

• Parallelization

oT-thread i � h-thread i

Simulation of target cores

• Main techniques

o ISS (Instruction Set Simulation)

o Virtualization (i.e.QEMU)

o SystemC TLM models

• Parallelization

oTcore i � h-thread i


VIPPE: Performance results

69

Host platform: 64 cores with SMP capability at 3.10GHz, 64Gb of RAM and 20Mb of cache.

� Benchmark: Video codec x264

� PARSEC (Princeton Application Repository for Shared-Memory Computers )

� Configurable number of threads

� Native (PC code) execution is 64,7 times faster than VIPPE simulation

� Both provide similar speed up

Speed-up with the number of target threads Speed-up with the number of host cores


VIPPE: Performance results

70

� Benchmark: Video codec x264

� PARSEC (Princeton Application Repository for Shared-Memory Computers )

� Configurable number of threads

Impact of number of target cores in the simulation

Performance analysis result:

Impact of target bus bandwidth on application execution time

Host platform: 64 cores with SMP capability at 3.10GHz, 64Gb of RAM and 20Mb of cache.


Estimation of HW implementations

71

Application C/C++ code… T

hre

ad I

Thre

ad i+

1

….

Thre

ad j

Core i Hw module

Heterogeneous Target

Many-core platform

VIPPE Virtual Platform

… Thre

ad I

(S

W)

Thre

ad i+

1(S

W)

….

Thre

ad j (

HW

)

….

Kern

el p

rocess

�Only 1 thread is allocated in a “hardware module”�Two new HW-oriented estimation techniques have been defined

� Estimation of the minimum execution time: dynamic scheduling� Estimation of the maximum execution time: basic block execution time

�Include HW register and memory management� Similar to SW caches

�Estimate data transfer requirements (bus and memory access estimation)


Extension to networked embedded system simulation

72

Node i

HdS API

Application Code

Task n...Task 1

Bus

HdSOS

caches …

NoC


CPU1

OS API HdS API

HdSOS

caches

CPUp

OS API

Multi/Many core Embedded Systems

Wireless Sensor Network(WSN)

Networked Embedded Systems

Application

RTOS (OS)

HW: CPU,…

RF trans.

Node i

Other Nodes

Wireless channel



73

Network Model

Application

HW Model

70

10

70

70


Node-i ModelNetworked Embedded Systems

Application

HW Model

Node-j Model

VIPPE: WSN Virtual PlatformDeployment information



74

Network Model

Application

HW Model

70

10

70

70



Application

HW Model

Node-j Model

VIPPE: WSN Virtual Platform

•Execution time•Power consumption

� Battery lifetime• Network traffic

� Tx/Rx packets

Estimations


Security evaluation

75

Network Model

Application

HW Model

70

10

70

70


Application

HW Model

Node-j Model

VIPPE: WSN Virtual Platform

Jammer

AttackInterrogation

Attack

• Attack effects:• Power consumption• Battery lifetime• Network traffic

Estimations


Security evaluation example

76

AttackNode 1: HW crypto

+ attack-aware firmwareNode 2: SW crypto

+ insecure firmware

Not Attacked

2.67 mWh

Replication attack

� HW crypto versus SW crypto: Software crypto increase 33% power

consumption compared to the Hardware crypto

� Attack-aware WSN firmware: Insecure firmware increase 132% power

consumption compared to the Attack-aware firmware in case of attack


Safety evaluation

77

Node i

HdS API

Application Code

Task n...Task 1

Bus

HdSOS

caches …

NoC


CPU1

OS API HdS API

HdSOS

caches

CPUp

OS API

Multi/Many core Embedded Systems

Fault effects:• Functionality• Execution time• Power consumption

Estimations

Virtual Platform: VIPPE

Safety Certification

Fault Injection

* Hardware faults- Memory faults- Cache Faults- Bus faults


Agenda


� Who are we?

� Motivation



� SW Synthesis

� Verification

� Conclusions


Reusability


Texas Instruments OMAP Evolution Time

Freescale IMX Evolution Time

Stereovision

N2 BN1

M A

Application Evolution Time

N2’ B’N1’

M’ A’



HW/SWPlatform

Architectural

MappingsC/

C++

Scenarios

PIM (App)

HWAccelerators

HWAccelerators

HWAcceleratorsHW

Accelerators

SW stacks

CompilersLinkers

SW Synthesis (eSSYN)

+

M2T Tools

CPUs/DSPs/ASIPs GP-GPUs


SW Synthesis

� System heterogeneity

� Full support for

� any architectural mapping decided for each component

� any specific processing resource selected

� any processing resource type

� any memory space

� any OS used by the processing resource

� any communication infrastructure


SW Synthesis

� Functional synthesis

� One executable per memory-space

� Platform-Independent (C/C++) code

� Highest reusability

� Non-recommended explicit calls to platform services

� communication, concurrency, etc.

� Platform services should derived from the UML/MARTE model

� POSIX and/or OpenMP as alternatives

� Static execution flows

� <<SwSchedulableResource>>


SW Synthesis


� Platform-Specific code

� Optimized C code for DSPs

� OpenCL/GL for GPUs

� C/C++ & OpenMP for SMPs… C3

DSP optimized

C code

OpenCL/GL code for

GPU

Platform-Independent

C code

Communication Infrastructure

Memory Space

OSGPU

SMPnode

DSP

83

Configuration Original Optimized Code

ARM 908.28 sec 572.92 sec

ARM-NEON 325.81 sec 255.28 sec

ARM+DSPblocking call

206.01 sec 193.45 sec

ARM+DSPnon-blocking call

895.98 sec 431.68 sec

ARM-NEON+DSPnon-blocking call

247.93 sec 215.96 sec


� Communication synthesis


� Same memory space

� Same OS

� Different processing nodes

� Benefits / Drawbacks

� Communication Speed

� Memory protection

� Memory/cache use

� Scheduling

� Parallelism…

SW Synthesis



� 3 Layers automatically inserted in service calls� Layer 1: communication semantics

� Allocation independent

� Layer 2: management for allocation-dependent communications� Thread generation, data splitting, synchronization

� Layer 3: Low-level communications� Inter-thread, Inter-process, distributed communication

SW Synthesis


� Communication synthesis� Layer1: Independent of architectural mapping

� Channel properties� RPC

SW Synthesis

T M Ta

M

Tb

BlockingFunctionCall (T)BlockingFunctionReturn (T)

Ta

Tb



� Channel properties� Pipeline

SW Synthesis

Ta

M

Tb

T M

BlockingFunctionCall (F)BlockingFunctionReturn (T)

Ta

Tb



� Channel properties� Pipeline & Parallel

SW Synthesis

Ta

MTb

T M

BlockingFunctionCall (F)BlockingFunctionReturn (F)

Ta

Tb



� Interface properties� Data splitting

SW Synthesis

Ta

M1Tb

M2

T M

Ta

Tb



� Interface properties� Data splitting

SW Synthesis

Ta

Tb

T M

Ta

Tb

M1 M2


� Implementation alternatives

� Channel semantics can be implemented in multiple ways

� Different OS services

� shared memory

� message queue

� Socket

� file...

� Different middleware APIs

� Performance is highly dependent on platform and OS

� Synthesis enables fast exploration

� optimal channel implementation for specific platform and code

SW Synthesis


� MultiCore Association APIs

� Standard APIs for communication and synchronization

� Closely distributed embedded systems

� MCAPI - communication

� MRAPI - synchronization

� MTAPI - task generation

� Independence from OS

� OS-agnostic channel implementation

� Components treated as MCAPI nodes

� Ports treated as MCAPI endpoints

SW Synthesis


93

� Platform Inputs & Outputs� Drivers associated to environmental components

SW Synthesis

Communication Infrastructure

OS1

PLCSMPNode

Environment Model

P1

System Model

P2

Memory Space

PLCTest-Bench

code

CameraTest-Bench

codePLC

driverCamera 1

driver

Camera 2driver


Agenda


� Who are we?

� Motivation



� SW Synthesis

� Verification

� Conclusions


Verification: Main research lines

� Test Framework definition

� Test Methodology for embedded systems

� Extension of commonly used software test framework

� Google Test

� Test models are integrated in the MARTE model

� Automatic test generation

� Model checking

� Improve test set

� Coverage and SIL (safety) improvement, Security validation

� Checking non-functional parameters with VIPPE

� WCET determination


Test Framework

This tree will be modelled in UML MARTE

Test Program

Test case (“TC1”)

Test

Assertions

Test 1 (T1) Test

Test case i

Assertions Assertions Assertions

Test Project

TEST(TC1,T1) {EXPECT_EQ(1, Function_under_test(1));

}

� A test project integrates all theembedded system test

� A test program verifies a unit(function/class/component) or a system(integration test). It could have differenttest cases.

� Each test case can be composed ofmany different tests.

� Each test can be composed of differentconditions to be checked (assertions).


Testing view in UML MARTE

Test case 1

Assertion 1

Test 1

Assertion 2


� Test types:

� Functional test

� Based on Google TestRandom Test� Insert random values in test unit inputs.

� Boundary Test

� Use as inputs the maximum and minimum inputs values

� Automatically generated test (directed test)

� Use an UC ATPG (“Forest”) to generate tests that comply an specific requirement (forexample, cover a condition for code coverage improvement).

� Assertion types

� Tests could verify functional parameters (e.g. function results) or

� non-functional parameters (e.g. execution time limit or power consumption)

� Test results

� Failed tests

� Code coverage


Verification methodology

Verification methodology

SYSTEM REQUIREMENTS

UML/MARTE

PIM PDM

PSM

XML GENERATOR

xml platformfile

xml mapping& concurrency

files

User source code functions

(c/c++)

Applicationcode (c/c++)

CONCURRENCY SWGENERATOR

TESTINGFRAMEWORK (i.e. Google test)

CODE TESTGENERATOR

xml testconfiguration

SIMULATIONFRAMEWORK (i.e. VIPPE)

Test Model


Automatic Test Generation

� FOREST

� FramewORk for Embedded System VerificaTion

� FOREST

� SMT (Satisfiability Modulo Theory) checker to verify properties

FOREST

C/C++ code

Property

Test thatverify the property


� Code coverage improvement

� Generate additional test to cover code that has not been covered by functional/random/boundary tests

� Safety certification

� Generate tests that improve SIL (Safety Integrity Level)

� i.e. improving MC/DC coverage (Modified Condition/Decision coverage)

� Checking non-functional parameters

� Identify the input sequence that requires the maximum execution time (WCET)


FOREST applications

FOREST applications

� Security validation

� Verification of concurrent program

� i.e. identify an input sequence that produces deadlock

FOREST generates a testthat overflows “password_buffer”array and accesses the system.The test (*argv=111111111110)does not verify the password condition.


Agenda


� Who are we?

� Motivation



� SW Synthesis

� Verification

� Conclusions


� UML/MARTE

� Powerful modeling methodology

� Single-Source approach

� Reusability

� MDD concepts� Separation of Concerns

� CBE: Component-Based Engineering approach

� SW centric

� DSE-oriented

� M2T generation of simulation & verification models

� SW synthesis

Conclusions


� SW simulation and performance analysis

� Essential Design Technology

� HW/SW Embedded Systems

� At different design steps

� Different modeling and simulation technologies

� Various performance*accuracy products

� Native simulation� Optimum performance*accuracy for system-level DSE

Conclusions


� SW Synthesis

� Functional modeling



� Platform Inputs & Outputs

� Reusability support

� www.essyn.com

Conclusions


� Verification

� extension of Goggle-test for ES verification

� Integration of the test framework inside UML/MARTE

� Automatic test-pattern generation based on SMT

� Forest

Conclusions


single-source approach to the design of hw/sw embedded systems

Documents

ses hwsw

cdigo nico tase

tres cantos

hwsw codesign

cdigo nico para

systems design

design systemc

embedded sw ada