An Overview of (Electronic) System An Overview of (Electronic) - PowerPoint PPT Presentation

PARADES How to… … How to � How to propagate functionality from top to bottom � How to propagate functionality from top to bottom � How to evaluate the trade offs � How to evaluate the trade offs � How to cope with: � How to cope with: � Design Time Design Time � � Design Reuse Design Reuse � � Design Heterogeneity Design Heterogeneity � � How to abstract with models that can be used to reason � How to abstract with models that can be used to reason about the properties about the properties 18

PARADES Heterogeneity in Electronic Design Heterogeneity in Electronic Design � Heterogeneity in: � Heterogeneity in: � Specification: Specification: � � formal/semi formal/semi- -formal/natural language formal/natural language � � MoC MoC � � Language Language � � Analysis Analysis � � Synthesis: Synthesis: � � Manual/automatic/semi Manual/automatic/semi- -automatic automatic � � Verification Verification � � Methodology Methodology � � Design Process Design Process � 19

PARADES Outline Outline � Embedded System Applications � Embedded System Applications � Platform based design methodology � Platform based design methodology � Electronic System Level Design � Electronic System Level Design � Functions: Functions: MoC MoC, Languages , Languages � � Architectures: Network, Node, Architectures: Network, Node, SoC SoC � � Metropolis � Metropolis � Conclusions � Conclusions 20

PARADES Separation of concerns Separation of concerns � Computation versus Communication � Computation versus Communication � Function versus Architecture � Function versus Architecture � Function versus Time � Function versus Time 21

PARADES Separation of Concerns (1990 Vintage!) Separation of Concerns (1990 Vintage!) Behavior Components Virtual Architectural Components IPs C-Code Buses CPUs Buses Operating Buses Matlab ASCET Systems Analysis System Behavior System Platform Development Process Specification f1 f2 f1 f2 ECU ECU- -1 1 ECU- ECU -2 2 Bus Bus f3 f3 ECU- -3 3 ECU Evaluation of Mapping Architectural Implementation and Performance Partitioning Analysis Calibration Alternatives Refinement After Sales Service 22

Principles of Platform methodology: Principles of Platform methodology: PARADES Meet- -in in- -the the- -Middle Middle Meet � Top Top- -Down: Down: � � Define a set of abstraction layers Define a set of abstraction layers � � From specifications at a given level, select a solution (control From specifications at a given level, select a solution (controls, components) in s, components) in � terms of components (Platforms) of the following layer and propagate terms of components (Platforms) of the following layer and propa gate constraints constraints � Bottom � Bottom- -Up: Up: � Platform components (e.g., micro Platform components (e.g., micro- -controller, RTOS, communication primitives) controller, RTOS, communication primitives) � at a given level are abstracted to a higher level by their functionality and a set of at a given level are abstracted to a higher level by their funct ionality and a set of parameters that help guiding the solution selection process. The selection selection parameters that help guiding the solution selection process. The process is equivalent to a covering problem if a common semantic domain is domain is process is equivalent to a covering problem if a common semantic used. used. 23

PARADES Platform Models for Model Based Development Platform Models for Model Based Development Distributed Distributed Distributed Development Development Development System System System of Distributed of Distributed of Distributed Sign - Off! Sign- -Off! Off! Sign System System System Sub - System(s) Sub- -System(s) System(s) Sub Distributed Integration, Test, Integration, Test, Integration, Test, System and Validation and Validation and Validation Requirements Distributed Virtual Integration of System Sub-System(s) w/ Platform Partitioning Network Protocol, Sub-Systems Model Abstraction Test, and Validation Based Development Sub-System(s) Sub-Systems Implementation Models (s) Sign-Off! Requirements Network Network Network Network Network Network Protocol Protocol Protocol Communication Communication Communication Requirements Requirements Requirements Protocol Sign - Off! Protocol Sign- -Off! Off! Protocol Sign Sub - System(s) Sub- -System(s) System(s) Sub Sign - Off! Sign- -Off! Off! Sign 24

PARADES Meet- -in in- -the the- -middle middle Meet WHAT ? HOW ? � Design Exploration � Design Exploration Partitioning � Partitioning � Scheduling � Scheduling � Estimation � � Estimation � Interface Synthesis � Interface Synthesis Platform (or configuration) (or configuration) Abstraction � Component Synthesis � Component Synthesis (or configuration) (or configuration) 25

PARADES Aspects of the Hw/Sw Sw Design Problem Design Problem Aspects of the Hw/ � � Specification of the system (top Specification of the system (top- -down) down) � Architecture export (bottom � Architecture export (bottom- -up) up) � Abstraction of processor, of communication infrastructure, interface between hardware and software, etc. Abstraction of processor, of communication infrastructure, inter face between hardware and software, etc. � � Partitioning � Partitioning � Partitioning objectives Partitioning objectives � Minimize network load, latency, jitter, Minimize network load, latency, jitter, � � Maximize speedup, extensibility, flexibility � Maximize speedup, extensibility, flexibility � Minimize size, cost, etc. Minimize size, cost, etc. � � � � Partitioning strategies Partitioning strategies � partitioning by hand partitioning by hand � automated partitioning using various techniques, etc. automated partitioning using various techniques, etc. � � � Scheduling � Scheduling � Computation Computation � � Communication Communication � � Different levels: � Different levels: � Transaction/Packet scheduling in communication Transaction/Packet scheduling in communication � Process scheduling in operating systems � � Process scheduling in operating systems Instruction scheduling in compilers � � Instruction scheduling in compilers Operation scheduling in hardware � � Operation scheduling in hardware � Modeling the partitioned system during the design process � Modeling the partitioned system during the design process 26

PARADES Platform- -based Design based Design Platform Tensilica ASICs Xtensa SRAM Application Space RISC CPU Application Instance Sonics Silicon Backplane Platform Speech External Mapping UART Samples Bus Interface Interface Interface System (Software + Hardware) Platform Platform Design-Space Wireless Baseband Flash Processor Export Processor Protocol Bus Platform Instance Architectural Space ADC Xilinx RF FPGA Frontend DAC Intercom Platform (BWRC, 2001) � Platform: library of resources defining an abstraction layer Platform: library of resources defining an abstraction layer � hide unnecessary details hide unnecessary details � � expose only relevant parameters for the next step expose only relevant parameters for the next step � � 27

28 Platform Instance PARADES Architecture Platform constrained composition Library Elements Function Space Closure under (term algebra) Formal Mechanism Formal Mechanism Function

Platform Instance 29 PARADES Semantic Platform Mapped Instance Admissible Refinements Function Space Function Mapping Mapping

PARADES Platform stack & design refinements Platform stack & design refinements Application Space Platform 1 application instance platform i instance Platform i plat.2 Platform 2 Platform instance Mapping Refinement Platform Design-Space plat.3 Export Platform 3 instance Platform i+1 platform i+1 instance implementation instance Platform 4 Implementation Space 30

Automotive Supply Chain: Automotive Supply Chain: PARADES Tier 1 Subsystem Providers Tier 1 Subsystem Providers 1 Transmission ECU 2 Actuation group 3 Engine ECU 4 DBW 5 Active shift display 6/7 Up/Down buttons 8 City mode button 9 Up/Down lever 10 Accelerator pedal position sensor 11 Brake switch � Subsystem Partitioning � Subsystem Integration � Software Design: Control Algorithms, Data Processing � Physical Implementation and Production 31

PARADES Magneti Marelli Power- -train Platform Stack train Platform Stack Magneti Marelli Power Powertrain System Specifications A2 Powertrain System Capture System Functional Behavior Architecture Decomposition Functions Partitioning and Capture Functional Optimization Electrical/Mechanical Network A3 Architecture Operations Operation Refinement and Macro Architecture DESIGN Operational Capture Electronic Architecture (ES) Electronic Architecture A4 Design Mechanical System Components Mapping HW/SW Verify partitioning Performance HW and SW A5 Performance Back- Verify Components Components Components Annotation Implementation Only SW components 32

PARADES Outline Outline � Embedded System Applications � Embedded System Applications � Platform based design methodology � Platform based design methodology � Electronic System Level Design � Electronic System Level Design � Functions: Functions: MoC MoC, Languages , Languages � � Architectures: Network, Node, Architectures: Network, Node, SoC SoC � � Metropolis � Metropolis � Conclusions � Conclusions 33

PARADES Design Formalization Design Formalization � Model of a design with precise unambiguous semantics: � Model of a design with precise unambiguous semantics: � Implicit or explicit relations: inputs, outputs and (possibly) � Implicit or explicit relations: inputs, outputs and (possibly) state variables state variables � Properties � Properties � “ � “Cost Cost” ” functions functions � Constraints � Constraints Formalization of Design + Environment = closed system of equations and inequalities over some algebra. 34

PARADES What: Functional Design What: Functional Design � � A rigorous design of functions requires a mathematical framework A rigorous design of functions requires a mathematical framework � The functional description must be an invariant of the design The functional description must be an invariant of the design � � The mathematical model should be expressive enough to capture ea The mathematical model should be expressive enough to capture easily the functions sily the functions � � The different nature of functions might be better captured by he The different nature of functions might be better captured by heterogeneous model of terogeneous model of � computations (e.g. finite state machine, data flows) computations (e.g. finite state machine, data flows) � The functional design requires the abstraction of � The functional design requires the abstraction of � Time (i.e. un Time (i.e. un- -timed model) timed model) � � Time appears only in constraints that involve interactions with Time appears only in constraints that involve interactions with the environment the environment � � Data type (i.e. infinite precision) Data type (i.e. infinite precision) � � � Any implementation MUST be a refinement of this abstraction (i.e Any implementation MUST be a refinement of this abstraction (i.e. functionality is . functionality is “guaranteed “ guaranteed” ”): ): � E.g. Un E.g. Un- -timed timed - -> logic time > logic time - -> time > time � � E.g. Infinite precision E.g. Infinite precision - -> float > float - -> fixed point > fixed point � 35

PARADES Models of Computation Models of Computation Definition: A mathematical description that A mathematical description that Definition: � � FSMs FSMs has a syntax and rules for computation of has a syntax and rules for computation of the behavior described by the syntax the behavior described by the syntax � Discrete Event Systems Discrete Event Systems � (semantics). Used to specify the semantics (semantics). Used to specify the semantics � CFSMs � CFSMs of computation and concurrency. of computation and concurrency. � Data Flow Models � Data Flow Models � Petri Nets � Petri Nets � The Tagged Signal Model � The Tagged Signal Model � Synchronous Languages and De � Synchronous Languages and De- -synchronization synchronization � Heterogeneous Composition: Hybrid Systems and Languages � Heterogeneous Composition: Hybrid Systems and Languages � Interface Synthesis and Verification � Interface Synthesis and Verification � Trace Algebra, Trace Structure Algebra and Agent Algebra Trace Algebra, Trace Structure Algebra and Agent Algebra � 36

PARADES Usefulness of a Model of Computation Usefulness of a Model of Computation � Expressiveness � Expressiveness � Generality � Generality � Simplicity � Simplicity � Compilability � Compilability/ Synthesizability / Synthesizability � Verifiability � Verifiability The Conclusion The Conclusion One way to get all of these is to mix diverse, simple models of computation, while keeping compilation, synthesis, and verification separate for each MoC. To do that, we need to understand these MoCs relative to one another, and understand their interaction when combined in a single system design. 37

PARADES Reactive Real- -time Systems time Systems Reactive Real � Reactive Real � Reactive Real- -Time Systems Time Systems � “ “React React” ” to external environment to external environment � � Maintain permanent interaction Maintain permanent interaction � � Ideally never terminate Ideally never terminate � � timing constraints (real timing constraints (real- -time) time) � � As opposed to � As opposed to � transformational systems transformational systems � � interactive systems interactive systems � 38

PARADES Models Of Computation for reactive systems Models Of Computation for reactive systems � We need to consider essential aspects of reactive systems: � We need to consider essential aspects of reactive systems: � time/synchronization time/synchronization � � concurrency concurrency � � heterogeneity heterogeneity � � Classify models based on: Classify models based on: � � how specify behavior how specify behavior � � how specify communication how specify communication � � implementability implementability � � composability composability � � availability of tools for validation and synthesis availability of tools for validation and synthesis � 39

Models Of Computation Models Of Computation PARADES for reactive systems for reactive systems � Main Main MOCs MOCs: : � � Communicating Finite State Machines Communicating Finite State Machines � Details � Dataflow Process Networks Dataflow Process Networks � � Petri Nets Petri Nets � � Discrete Event Discrete Event � � (Abstract) Codesign Finite State Machines (Abstract) Codesign Finite State Machines � � Synchronous Reactive Synchronous Reactive � Details � Task Programming Model Task Programming Model � � Main languages: Main languages: � � StateCharts StateCharts � � Esterel Esterel � � Dataflow networks Dataflow networks � � Simulink Simulink � � UML UML � 40

Models Of Computation Models Of Computation PARADES for reactive systems for reactive systems � Main Main MOCs MOCs: : � � Communicating Finite State Machines Communicating Finite State Machines � � Dataflow Process Networks Dataflow Process Networks � � Petri Nets Petri Nets � � Discrete Event Discrete Event � � Codesign Finite State Machines Codesign Finite State Machines � � Synchronous Reactive Synchronous Reactive � � Task Programming Model Task Programming Model � � Main languages Main languages: : � � StateCharts StateCharts � � Esterel Esterel � � Dataflow networks Dataflow networks � � Simulink Simulink � � UML UML � 41

PARADES The Synchronous Programming Model The Synchronous Programming Model � Synchronous programming model * is dealing with � Synchronous programming model * is dealing with concurrency as follows: concurrency as follows: � non overlapping computation and communication phases taking non overlapping computation and communication phases taking � zero- -time and triggered by a global tick time and triggered by a global tick zero � Widely used and supported by several tools: Simulink, � Widely used and supported by several tools: Simulink, SCADE, ESTEREL … … SCADE, ESTEREL � Strong constraints on the final implementation Strong constraints on the final implementation to preserve to preserve � the separation between computation and communication the separation between computation and communication phases phases * A. Benveniste and G. Berry: The synchronous approach to reactive and real-time systems, Proc IEEE, 1991 42

PARADES ( * ) MoC ( * ) The Synchronous Reactive (SR) MoC The Synchronous Reactive (SR) � Discrete model of time (global set of totally ordered Discrete model of time (global set of totally ordered “ “time ticks time ticks” ”) ) � � Blocks execute � Blocks execute atomically atomically at every time tick at every time tick � Blocks are computed in � Blocks are computed in causal order causal order (writer before reader) (writer before reader) � State variables ( State variables (MEMs MEMs) are used to break combinatorial paths ) are used to break combinatorial paths � � Combinatorial loops have fixed � Combinatorial loops have fixed- -point semantics point semantics MEM U k = W k-1 Y k U k Y k = G*U k = G*W k-1 G W k = V k +Y k = V k +G*W k-1 W k V k + ( * ) S. A. Edwards and E. A. Lee, “The semantics and execution of a synchronous block-diagram language” , Science of Computer Programming , 48(1):21–42, jul 2003. 43

PARADES The Task Programming Model The Task Programming Model � The Task Programming Model (TPM) � The Task Programming Model (TPM) � A task is a logically grouped sequence of operations A task is a logically grouped sequence of operations � � Each task is released for execution on an event/time reference Each task is released for execution on an event/time reference � � Task execution can be deferred as long as it meets its deadline Task execution can be deferred as long as it meets its deadline � � Task scheduling is priority Task scheduling is priority- -based possibly with preemption based possibly with preemption � � Priorities can be static or dynamic Priorities can be static or dynamic � � Communication between tasks occurs: Communication between tasks occurs: � � Locally: via shared variables Locally: via shared variables � � Globally: via communication network Globally: via communication network � � Output values depend on scheduling Output values depend on scheduling T9 T7 T8 � T10 � Represented by Task Graphs � Represented by Task Graphs T11 T12 T13 T14 44

PARADES Outline Outline � Embedded System Applications � Embedded System Applications � Platform based design methodology � Platform based design methodology � Electronic System Level Design � Electronic System Level Design � Functions: Functions: MoC MoC, Languages , Languages � � Architectures: Network, Node, Architectures: Network, Node, SoC SoC � � Metropolis � Metropolis � Conclusions � Conclusions 45

PARADES (Automotive) V- -Models: Car level Models: Car level (Automotive) V Distributed Development System of Distributed Sign-Off! System Sub-System(s) Integration, Test, and Validation Telematics Soft Real Fail Stop Mobile Communications Navigation Time I nformation Systems MOST Access to MOST DAB Firewire WWW Firewire Fire Wall Functions Theft warning Air Body Body Conditioning Electronics CAN CAN Real Time Door Module Fail Safe Light Module Lin Lin Gate Way ABS Driving and Vehicle Dynamic Functions CAN CAN Shift by Engine TTCAN TTCAN Wire Management System Gate Electronics Way Functional Hard Real Time Fault Steer by Brake Wire by Wire FlexRay FlexRay 46

PARADES Distributed Embedded Embedded Systems: Systems: Architectural Architectural Design Design Distributed The Design Design Components Components at at work work The Functional bus Networks Functions Solution Resources Topologies Patterns Evaluation Mapping and Iteration Solution n+1 47

PARADES Co- -Design Problem Design Problem Co � � From: From: � a model of the functionality (e.g. TPM or SPM) a model of the functionality (e.g. TPM or SPM) � � a model of the platform (abstraction of topology, network protoc a model of the platform (abstraction of topology, network protocol, CPU, Hw/ ol, CPU, Hw/Sw Sw etc) etc) � � Allocate: � Allocate: � The tasks to the nodes The tasks to the nodes � � The communication signals to the network segments The communication signals to the network segments � � Schedule: � Schedule: � The task sets in each node The task sets in each node � � The packets (mapping signals) in each network segment The packets (mapping signals) in each network segment � � Such that: � Such that: � The system is schedulable and the cost is minimized The system is schedulable and the cost is minimized � � Design solutions: � Design solutions: � Architectural constrains Architectural constrains � � Analytical approaches Analytical approaches � � Simulation models Simulation models � 48

PARADES The Time Triggered Approach The Time Triggered Approach � Time Triggered Architecture: Global notion of time Time Triggered Architecture: Global notion of time � � Communication and computation are synchronized and MUST HAPPEN Communication and computation are synchronized and MUST HAPPEN � AND COMPLETE in a given cyclic time time- -division schema division schema AND COMPLETE in a given cyclic � � Time Time- -Triggered Architecture (TTA) Triggered Architecture (TTA) C. C. Scheidler Scheidler, G. , G. Heiner Heiner, R. , R. Sasse Sasse, E. Fuchs, H. , E. Fuchs, H. Kopetz Kopetz � � Find optimal allocation and Find optimal allocation and scheduling of a Time Triggered TPM scheduling of a Time Triggered TPM � � An Improved Scheduling Technique for Time- - An Improved Scheduling Technique for Time Triggered Embedded Systems, Paul Pop, Petru Eles, Triggered Embedded Systems and Zebo Peng � � Extensible and Scalable Time Triggered Scheduling Extensible and Scalable Time Triggered Scheduling , EEWei Zheng, Jike Chong, Claudio Pinello, Sri Kanajan, Alberto L. Sangiovanni-Vincentelli � Models of bus/network speed and topology (Hw) and WCET (Hw/Sw) are needed 49

PARADES The Holistic Scheduling and Analysis The Holistic Scheduling and Analysis � Based on a Time and Event Triggered � Based on a Time and Event Triggered Task Graph Model allocated to a set Task Graph Model allocated to a set of nodes of nodes � Worst Case Execution Time of Tasks and Communication time of eac Worst Case Execution Time of Tasks and Communication time of each h � message are known message are known � Construct a correct static schedule for the TT tasks and ST messages (a schedule which meets all time constraints related to these activities) and conduct a schedulability analysis in order to check that all ET tasks meet their deadlines. Holistic Scheduling and Analysis of Mixed Time/Event-Triggered Distributed Embedded Systems (2002) Traian Pop, Petru Eles, Zebo Peng 50

PARADES Network Calculus Modelings Modelings Network Calculus � Network calculus: � Network calculus: � “Network calculus”, J-Y Le Boudec and P. Thiran, Lecture Notes in Computer Sciences vol. 2050, Springer Verlag 51

52 PARADES Event Models Event Models

PARADES Composition and Analysis Composition and Analysis Px transformation based on: transformation based on: Px • Output event dependency • Output event dependency • • WCET WCET • • BCET BCET Provide: Provide: • Schedulability check check • Schedulability • • Output stream models Output stream models Other strategy to search solutions (allocation and scheduling) 53

PARADES Executable Model: Computation and Communication Executable Model: Computation and Communication out in Task_A Task_B 54

PARADES Communication Refinement: Platform Model Communication Refinement: Platform Model out in Task_A Task_B Value()/Enabled() from Post() from Task_A Task_B Communication Pattern Receiver Sender Device Device NetwLayer DriverNetwLayer Driver RTOS CLib CLib RTOS Memory Memory CPU CPU Access Access CPU CPU Bus Bus Adapter Port Adapter Port Local Local Bus Arbiter Bus Arbiter Bus Bus Slave Slave LLC/MAC LLC/MAC Adapter Adapter Controller Controller Network Network Bus Bus Memory Memory Adapter Adapter Bus Network Bus 55

PARADES Exploring Solutions by Simulation Exploring Solutions by Simulation My_Vehicle_Application P2 P3 Project_Driver Project_Car_v06 Project_Steer_Control_v06 M3 M4 M5 M6 M7 M8 M9 Corrupt Data Double Disconnect Single Disconnect Car_brake Plant_brake Control_steer Vote_steer P1 T Car_steer Plant_steer Interrupt_counter Project_Brake_Control_v06 f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 f11 f12 f13 f14 f15 f16 f17 f18 f19 f20 t1 t2 M1 M2 T1 Vote_brake Driver Control_brake T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 Task_2ms Task_10ms Task_1ms Task_10ms Task_10ms Prc_count Task_2ms Init Init Init SW_IRQ1 Requires a model of the model of the Requires a functionality and and functionality performance models of performance models of CPUs and network CPUs and network protocols protocols Cadence SYSDESIGN It is trace based! It is trace based! 56

PARADES (Automotive) V- -Models: Subsystem Level Models: Subsystem Level (Automotive) V Distributed Development System of Distributed Sign-Off! System Sub-System(s) Integration, Test, Development of and Validation Sub-System Sub-System Sign-Off! Development of Mechanical Part (s) ECU/ Sens./Actrs./Mech. Part(s) Integration, Calibration, and Test ECU Development 57

PARADES Control system design Control system design � � Specifications given at a Specifications given at a high level of abstraction: high level of abstraction: � known input/output relation known input/output relation � (or properties) and constraints (or properties) and constraints on performance indexes on performance indexes � � Control algorithms design Control algorithms design � Mapping to different architectures using performance estimation � Mapping to different architectures using performance estimation techniques and techniques and automatic code generation from models automatic code generation from models � Mechanical/Electronic architecture selected among a set of cand Mechanical/Electronic architecture selected among a set of candidates idates � 58

PARADES HW/SW implementation architecture HW/SW implementation architecture • a set of possible hw/sw implementations is given by – M different hw/sw implementation architectures – for each hw/sw implementation architecture m ∈ { 1,...,M } , • a set of hw/sw implementation parameters z – e.g. CPU clock, task priorities, hardware frequency, etc. • an admissible set X Z of values for z Application Customer Libraries Libraries CCP Speedometer Water temp. Speedometer Tachometer Tachometer --------------- Odometer KWP 2000 Application Transport Specific OSEK Software RTOS OSEK Application Programming Interface COM I/O drivers & handlers Sys. Config . (> 20 configurable modules) Boot Loader μ Controllers Library 59

PARADES The classical and the ideal design approach The classical and the ideal design approach � Classical approach (decoupled � Classical approach (decoupled design design) ) ∈ R, c ∈ X r ∈ R, c ∈ controller structure and parameters ( controller structure and parameters ( r X C ) � � C ) � are selected in order are selected in order to satisfy system specification to satisfy system specifications s � m ∈ ∈ M, z M, z ∈ ∈ X implementation architecture and parameters architecture and parameters ( � implementation ( m X Z ) � Z ) � are are selected in order selected in order to minimize implementation cost to minimize implementation cost � if system specifications are not met, the design cycle is repeated ed if system specifications are not met, the design cycle is repeat � � � Ideal approach Ideal approach � both controller and architecture options ( ) are selected at the are selected at the both controller and architecture options ( r, c, m, z r, c, m, z ) � � same time to to same time � minimize implementation cost minimize implementation cost � � satisfy system specification satisfy system specifications s � too complex!! � too complex!! � 60

PARADES Algorithm Explorations and Control Synthesis Algorithm Explorations and Control Synthesis Powertrain System Specifications A2 •1 •1 •inputEvent_1 •inputEvent_1 •events •events •1 •1 •2 •2 •inputEvent_1 •inputEvent_1 •inputEvent_2 •inputEvent_2 •events •events Powertrain System Capture System •2 •2 •fc_event1 •fc_event1 Functional •inputEvent_2 •inputEvent_2 •3 •3 •inData •inData •InData •InData •function() •function() Behavior Architecture •InData •InData •fc_event_2 •fc_event_2 •5 •5 •InData_2 •InData_2 •OutData •OutData •fc_event1 •fc_event1 •InData_2 •InData_2 Decomposition •InData_2 •InData_2 •3 •3 •inData •inData •SF-SS •SF-SS •FC-SS-1 •FC-SS-1 Functions •InData •InData •function() •function() •InData •InData •5 •5 •fc_event_2 •fc_event_2 •InData_2 •InData_2 •OutData •OutData •InData_2 •InData_2 •InData_2 •InData_2 •function() •function() •Merge •Merge •1 •1 •SF-SS •SF-SS •FC-SS-1 •FC-SS-1 •OutData •OutData •4 •4 •InData1 •InData1 •OutData •OutData •InData_1 •InData_1 •OutData •OutData •InData_1 •InData_1 •MergeOutData •MergeOutData •FC-SS-2 •FC-SS-2 •function() •function() •Merge •Merge •1 •1 •4 •4 •OutData •OutData •InData1 •InData1 •OutData •OutData •InData_1 •InData_1 •OutData •OutData •InData_1 •InData_1 •MergeOutData •MergeOutData •FC-SS-2 •FC-SS-2 Partitioning and Capture Functional Optimization Electrical /Mechanical Network A3 Architecture Operations Operation Refinement DESIGN andMacroArchitecture Operational Capture Electronic Architecture (ES) Architecture Electronic A4 Design Mechanical System Components Mapping HW/SW Verify partitioning Performance HW and SW A5 Verify Components Performance Back - Components Components Annotation Implementation Only SW components 61

PARADES Implementation abstraction layer Implementation abstraction layer � we introduce an � we introduce an implementation abstraction layer implementation abstraction layer which exposes ONLY the implementation non- -idealities that affect the idealities that affect the � which exposes ONLY the implementation non � performance of the controlled plant, e.g. performance of the controlled plant, e.g. control loop delay � quantization error � sample and hold error � computation imprecision � � at the implementation abstraction layer, platform instances � at the implementation abstraction layer, platform instances are described by are described by S different implementation architecture different implementation architectures s � � S ∈ { s ∈ for each implementation architecture s for each implementation architecture { 1,...,S } , , � � 1,...,S } a set of implementation implementation parameters parameters p � a set of p � e.g. latency, quantization interval, computation errors, etc. � � an admissible set X an admissible set P of values of values for for p � X P p 62

Effects of controller implementation in the Effects of controller implementation in the PARADES controlled plant performance controlled plant performance d y u w Plant n w Δ w + Δ u + Controller r Δ r + n u n r � modeling of implementation non � modeling of implementation non- -idealities: idealities: Δ u Δ r Δ w Δ , Δ , Δ time- -domain perturbations domain perturbations � : time � w : u , r , � control control loop delays, sample & hold loop delays, sample & hold , etc. , etc. � value- -domain perturbations domain perturbations : value � � n u , n r , n n w w : n u , n r , � quantization error, computation imprecision quantization error, computation imprecision, etc. , etc. � 63

Algorithm Development Algorithm Development PARADES Control ontrol Algorithm Design Algorithm Design C • Control Algorithm Specification Model and Simulation files • Simulink model • Calibrations data Simulation Results • Time history data Simulink Model •1 •inputEvent_1 •eve nts •2 •inputEvent_2 •fc_event1 •inData •3 •InData •function() •InData •fc_event_2 •5 •InData_2 •OutData •InData_2 •InData_2 •SF-SS •FC-SS-1 •function() •Merge •1 •OutData •4 •InData1 •OutData •InData_1 •OutData •InData_1 •MergeOutData •FC-SS-2 Time History Calibration data 64

PARADES (Automotive) V- -Models: ECU level (Hw/ Models: ECU level (Hw/Sw Sw) ) (Automotive) V Distributed Development System of Distributed Sign-Off! System Sub-System(s) Integration, Test, Development of and Validation Sub-System Sub-System Sign-Off! Development of Mechanical Part (s) ECU/ Sens./Actrs./Mech. Part(s) Integration, Calibration, and Test ECU Development ECU Sign-Off! ECU SW ECU HW/SW Development Integration and Test ECU HW ECU HW Development Sign-Off! ECU SW ECU SW Integration Implementation and Test 65

PARADES (Automotive) V- -Models: ECU level (Hw/ Models: ECU level (Hw/Sw Sw) ) (Automotive) V Main design tasks: Distributed Development System � Define ECU Hardware/Software Partitioning of Distributed Sign-Off! System Sub-System(s) � Platform instance structure selection Integration, Test, Development of and Validation Sub-System � Software Implementation Sub-System Sign-Off! Development of � Hardware (SoC) Design and Implementation Mechanical Part (s) ECU/ Sens./Actrs./Mech. Part(s) Integration, Calibration, and Test ECU Development ECU Sign-Off! ECU SW ECU HW/SW Development Integration and Test ECU HW ECU HW Development Sign-Off! ECU SW ECU SW Integration Implementation and Test 66

PARADES Control Algorithm Implementation Strategy Control Algorithm Implementation Strategy � Control algorithms are mapped to the target platform to � Control algorithms are mapped to the target platform to achieve the best performance/cost trade- -off. off. achieve the best performance/cost trade � In most cases the platform can accommodate in software the In most cases the platform can accommodate in software the � control algorithms, if not: control algorithms, if not: � New New platform services platform services might be required or might be required or � � New New hardware components hardware components might be implemented or might be implemented or � � New New control algorithms control algorithms must be explored. must be explored. � 67

PARADES Platform Design Strategy Platform Design Strategy � Minimize software development time � Minimize software development time � Maximize model based software Maximize model based software � � Software generation is possible today from several Software generation is possible today from several MoC MoC and languages: and languages: � � StateCharts, Dataflow, SR, … � Implement the same Implement the same MoC MoC of specification or guarantee the equivalence of specification or guarantee the equivalence � � Fit into the chosen software architecture to maximize reuse at c Fit into the chosen software architecture to maximize reuse at component omponent � level level � E.g. AUTOSAR for automotive � Maximize the reuse of hand Maximize the reuse of hand- -written software component written software component � � Define application and platform software architecture Define application and platform software architecture � � Minimize the change requests for the hardware platform � Minimize the change requests for the hardware platform � Implement as much as possible in software Implement as much as possible in software � 68

PARADES System Platform Definition System Platform Definition •1 •1 •inputEvent_1 •inputEvent_1 •events •events •2 •2 •inputEvent_2 •inputEvent_2 The software •fc_event1 •fc_event1 •3 •3 •inData •inData •InData •InData •function() •function() •InData •InData application is •fc_event_2 •fc_event_2 •5 •5 •InData_2 •InData_2 •OutData •OutData •InData_2 •InData_2 •InData_2 •InData_2 •SF-SS •SF-SS •FC-SS-1 •FC-SS-1 •1 •1 Application Software composed of model- •inputEvent_1 •inputEvent_1 •events •events •function() •function() •M •M erge erge •1 •1 •2 •2 •OutData •OutData •4 •4 •InData1 •InData1 •OutData •OutData •OutData •OutData •InData_1 •InData_1 •inputEvent_2 •inputEvent_2 •InData_1 •InData_1 •M •M ergeOutData ergeOutData based and hand-written •FC-SS-2 •FC-SS-2 •fc_event1 •fc_event1 •3 •3 •inData •inData •InData •InData •function() •function() •InData •InData •fc_event_2 •fc_event_2 •5 •5 •InData_2 •InData_2 •OutData •OutData •InData_2 •InData_2 application-dependent •InData_2 •InData_2 •SF-SS •SF-SS •FC-SS-1 •FC-SS-1 software components •function() •function() •M •M erge erge •1 •1 •OutData •OutData •4 •4 •InData1 •InData1 •OutData •OutData •OutData •OutData •InData_1 •InData_1 •InData_1 •InData_1 •M •M ergeOutData ergeOutData •FC-SS-2 •FC-SS-2 (sources) Sensor/Actuator Layer The software platform is Software Platform Software Platform cross applications and (API services) (API services) cross HW plats and is RTOS RTOS Net Net Device Drivers Device Drivers composed of BIOS BIOS parameterized software CPUs CPUs components (sources) ECU output devices ECU output devices ECU input devices ECU input devices 69

PARADES Software Implementation Flow Software Implementation Flow •1 •1 •inputEvent_1 •inputEvent_1 •events •events •2 •2 •inputEvent_2 •inputEvent_2 The software •fc_event1 •fc_event1 •3 •3 •inData •inData •InData •InData •function() •function() •InData •InData application is •fc_event_2 •fc_event_2 •5 •5 •InData_2 •InData_2 •OutData •OutData •InData_2 •InData_2 •InData_2 •InData_2 •SF-SS •SF-SS •FC-SS-1 •FC-SS-1 •1 •1 Application Software composed of model- •inputEvent_1 •inputEvent_1 •events •events •function() •function() •M •M erge erge •1 •1 •2 •2 •OutData •OutData •4 •4 •InData1 •InData1 •OutData •OutData •OutData •OutData •InData_1 •InData_1 •inputEvent_2 •inputEvent_2 •InData_1 •InData_1 •M •M ergeOutData ergeOutData based and hand-written •FC-SS-2 •FC-SS-2 •fc_event1 •fc_event1 •3 •3 •inData •inData •InData •InData •function() •function() •InData •InData •fc_event_2 •fc_event_2 •5 •5 •InData_2 •InData_2 •OutData •OutData •InData_2 •InData_2 application-dependent •InData_2 •InData_2 •SF-SS •SF-SS •FC-SS-1 •FC-SS-1 software components •function() •function() •M •M erge erge •1 •1 •OutData •OutData •4 •4 •InData1 •InData1 •OutData •OutData •OutData •OutData •InData_1 •InData_1 •InData_1 •InData_1 •M •M ergeOutData ergeOutData •FC-SS-2 •FC-SS-2 (sources) Sensor/Actuator Layer The software platform is Software Platform Software Platform cross applications and (API services) (API services) cross HW plats and is RTOS RTOS Net Net Device Drivers Device Drivers composed of BIOS BIOS parameterized software CPUs CPUs components (sources) ECU output devices ECU output devices ECU input devices ECU input devices 70

PARADES Exampe of Specification of Control Algorithms of Specification of Control Algorithms Exampe � A control algorithm is a (synch or a � A control algorithm is a (synch or a- -synch) composition of synch) composition of extended finite state machines (EFSM). extended finite state machines (EFSM). control-logic data-flow computational blocks •1 •inputEvent_1 •events •2 •inputEvent_2 •fc_event1 •3 •inData •InData •function() •InData •5 •fc_event_2 •InData_2 •OutData •InData_2 •InData_2 •SF-SS •FC-SS-1 •function() •Merge •1 •OutData •4 •InData1 •OutData •OutData •InData_1 •InData_1 •MergeOutData •FC-SS-2 71

PARADES Code Generation Code Generation � � Mapping a functional model to software platform: Mapping a functional model to software platform: Data refinement � Data refinement � Software platform services mapping (communication and computation) Software platform services mapping (communication and computatio n) � � Time refinement (scheduling) Time refinement (scheduling) � � � Data refinement Data refinement � Float to Fixed Point Translation. � Float to Fixed Point Translation. � � Range, scaling and size setting (by the designer). Range, scaling and size setting (by the designer). � � Worst case analysis for internal variable ranges and scaling. Worst case analysis for internal variable ranges and scaling. � Signals and parameters to C- Signals and parameters to C -variables mapping. variables mapping. � � � Software platform model: Software platform model: � variables and services (naming). � variables and services (naming). � Access variable method are mapped with variable classes. � � Access variable method are mapped with variable classes. execution model: � � execution model: � Multi Multi- -rate subsystems are implemented as multi rate subsystems are implemented as multi- -task software components scheduled by an OSEK/VDX task software components scheduled by an OSEK/VDX � standard RTOS standard RTOS � Time refinement Time refinement � Task scheduling Task scheduling � � 72

PARADES Mapping Control Algorithms to the Platform Mapping Control Algorithms to the Platform •1 •1 •inputEvent_1 •inputEvent_1 •events •events •2 •2 •inputEvent_2 •inputEvent_2 •fc_event1 •fc_event1 •3 •3 •inData •inData •InData •InData •function() •function() •InData •InData •5 •5 •fc_event_2 •fc_event_2 •InData_2 •InData_2 •OutData •OutData •InData_2 •InData_2 Application Software •InData_2 •InData_2 •SF-SS •SF-SS •FC-SS-1 •FC-SS-1 •function() •function() •Merge •Merge •1 •1 •OutData •OutData •4 •4 •InData1 •InData1 •OutData •OutData •OutData •OutData •InData_1 •InData_1 •InData_1 •InData_1 •MergeOutData •MergeOutData •FC-SS-2 •FC-SS-2 Automatic synthesis Sensor/Actuator Layer From high level models: Software Platform Software Platform • Automatic translation to C/C++ code (API services) (API services) RTOS RTOS Net Net • (Semi)-Automatic data refinement for Device Drivers Device Drivers BIOS BIOS computation CPUs CPUs • Automatic refinement of communication ECU output devices ECU output devices ECU input devices ECU input devices services Flow examples: ASCET, Simulink/eRTW/TargetLink, UML Handwritten code 73

PARADES Example: Gasoline Direct Injection Engine Control Modelled % of Model Components SLOC Compiled SLOC Platform Components 26-HandCoded 26500 0% Application 86-AutomCoded 90% Components 13-HandCoded 93600 % of the total memory occupation ROM % RAM % Platform 17.9 2.9 Application 82.1 97.1 74

PARADES Example: Gasoline Direct Injection Engine Control Gasoline Direct Injection Engine Control Example: � Tremendous increase in application � Tremendous increase in application- -software productivity: software productivity: � Up to 4 time faster than in the traditional hand Up to 4 time faster than in the traditional hand- -coding cycle. coding cycle. � � Tremendous decrease in verification effort: � Tremendous decrease in verification effort: � Close to 0 Close to 0 ppm ppm � � Tremendous reuse of modes and source code � Tremendous reuse of modes and source code 75

PARADES Defining the Platform Defining the Platform Application Space (Features) Application Software Application Instances Platform Specification Application Software Platform API System Software Platform Network Communication Platform (no ISA) Network Communication RTOS Network Communication Network Communication Platform Design RTOS Device Drivers Space Exploration RTOS RTOS BIOS Device Drivers DUAL-CORE Hardware Hardware Platform Device Drivers BIOS Device Drivers Input devices Output Devices I O HITACHI Hardware Hardware Platform BIOS BIOS Input devices Output Devices I O network ST10 Hardware Hardware Platform ST10 Platform Instance Input devices Output Devices network I O HITACHI network DUAL-CORE Architectural Space (Performance) 76

PARADES Simulation Based (C/C++/SystemC SystemC) Exploration Flow ) Exploration Flow Simulation Based (C/C++/ Different Languages and MoCs Platform non UML idealities ASCET Simulink StateMate Algorithm Analysis Platform Export Generators Exporters Code Generation (Synthesis) Defined MoC C/C++/SystemC Platform Models and Languages Unique Representation Mapping Build C/C++/SystemC C/C++/SystemC Integration Performance Traces Simulation and Simulator Performance Estimation 77

PARADES SystemC and OCP Abstraction Levels and OCP Abstraction Levels SystemC Communication (I/F) Communication (I/F) Abstraction Accuracy Abstraction Accuracy Abstraction Removes Abstraction Removes SystemC OCP Layers SystemC OCP Layers Untimed Functional Functional Token Message (L- -3) 3) Time Resource Untimed Token Message (L Time Resource Sharing Sharing Programmers View (PV) +Address Programmers View (PV) +Address Programmers View + +Transaction time Transaction (L- -2) 2) Clocks, protocols Programmers View + +Transaction time Transaction (L Clocks, protocols Time (PVT) Time (PVT) Bus cycle Accurate (BCA) +Clock cycle Transfer (L- -1) 1) Wire registers Bus cycle Accurate (BCA) +Clock cycle Transfer (L Wire registers Pin Cycle Accurate (PCA) +Pin/clock RTL (L- -0) 0) Gates Pin Cycle Accurate (PCA) +Pin/clock RTL (L Gates Computation Computation Untimed Untimed Functional (UTF) Functional (UTF) Function Function Time Functional (TF) Time Functional (TF) +Computation Time +Computation Time Register Transfer (RT) +Clock cycle Register Transfer (RT) +Clock cycle 78

PARADES Mapping application to platform Mapping application to platform CPU load% IRQ/s 15 2000 10 1000 5 0 0 mapping "zero" mapping "uno" mapping "due" mapping "tre" mapping "zero" mapping "uno" mapping "due" mapping "tre" task switching (attivazioni/s) numero di task 10000 15 10 5000 5 0 0 mapping "zero" mapping "uno" mapping "due" mapping "tre" mapping "zero" mapping "uno" mapping "due" mapping "tre" 79

PARADES SW estimation SW estimation � SW estimation is needed to � SW estimation is needed to � Evaluate HW/SW trade Evaluate HW/SW trade- -offs offs � � Check performance/constraints Check performance/constraints � � Higher reliability Higher reliability � � Reduce system cost Reduce system cost � � Allow slower hardware, smaller size, lower power consumption Allow slower hardware, smaller size, lower power consumption � 80

PARADES SW estimation: Static vs. Dynamic SW estimation: Static vs. Dynamic � � Static estimation Static estimation � Determination of runtime properties at compile time Determination of runtime properties at compile time � � Most of the (interesting) properties are undecidable => use appr Most of the (interesting) properties are undecidable => use approximations oximations � � An approximation program analysis is safe, if its results can al An approximation program analysis is safe, if its results can always be depended on. ways be depended on. � � E.G. WCET, BCET E.G. WCET, BCET � � Quality of the results (precision) should be as good as possible Quality of the results (precision) should be as good as possible � � � Dynamic estimation Dynamic estimation � Determination of properties at runtime Determination of properties at runtime � � DSP Processors DSP Processors � � relatively data independent relatively data independent � � most time spent in hand most time spent in hand- -coded kernels coded kernels � � static data static data- -flow consumes most cycles flow consumes most cycles � � small number of threads, simple interrupts small number of threads, simple interrupts � � Regular processors Regular processors � � arbitrary C, highly data dependent arbitrary C, highly data dependent � � commercial RTOS, many threads commercial RTOS, many threads � � complex interrupts, priorities complex interrupts, priorities � 81

PARADES SW estimation overview SW estimation overview � � Two aspects to be considered Two aspects to be considered � The structure of the code ( The structure of the code (program path analysis program path analysis) ) � � E.g. loops and false paths E.g. loops and false paths � � The system on which the software will run ( The system on which the software will run (micro micro- -architecture modeling architecture modeling) ) � � CPU (ISA, interrupts, etc.), HW (cache, etc.), OS, Compiler CPU (ISA, interrupts, etc.), HW (cache, etc.), OS, Compiler � � Level at which it is done � Level at which it is done � Low Low- -level level � � e.g. gate e.g. gate- -level, assembly level, assembly- -language level language level � � Easy and accurate, but long design iteration time Easy and accurate, but long design iteration time � � High/system High/system- -level level � � Fast: reduces the exploration time of the design space Fast: reduces the exploration time of the design space � � Accurate Accurate “ “enough enough” ”: approximations are required : approximations are required � � Processor model must be cheap Processor model must be cheap � � “what if” my processor did X � future processors not yet developed � evaluation of processor not currently used � Must be convenient to use Must be convenient to use � � no need to compile with cross-compilers and debug on my desktop 82

PARADES SW estimation in VCC SW estimation in VCC Virtual Processor Model (VPM) Virtual Processor Model (VPM) compiled code virtual instruction set simulator compiled code virtual instruction set simulator � An virtual processor functional model with its own ISA estimatin � An virtual processor functional model with its own ISA estimating g computation time based on a table with instruction time computation time based on a table with instruction time information information � Pros: Pros: � � does not require target software development chain (uses host co does not require target software development chain (uses host compiler) mpiler) � � fast simulation model generation and execution fast simulation model generation and execution � � simple and cheap generation of a new processor model simple and cheap generation of a new processor model � � Needed when target processor and compiler not available Needed when target processor and compiler not available � � Cons: Cons: � � hard to model target compiler optimizations (requires hard to model target compiler optimizations (requires “ “best in class best in class” ” Virtual Virtual � Compiler that can also as C- -to to- -C optimization for the target compiler) C optimization for the target compiler) Compiler that can also as C � low precision, especially for data memory accesses low precision, especially for data memory accesses � 83

PARADES SW estimation by ISS SW estimation by ISS Interpreted instruction set simulator (I- -ISS) ISS) Interpreted instruction set simulator (I � A model of the processor interpreting the instruction stream A model of the processor interpreting the instruction stream � and accounting for clock cycle accurate or approximate time and accounting for clock cycle accurate or approximate time evaluation evaluation � Pros: Pros: � � generally available from processor IP provider generally available from processor IP provider � � often integrates fast cache model often integrates fast cache model � � considers target compiler optimizations and real data and code a considers target compiler optimizations and real data and code addresses ddresses � � Cons: Cons: � � requires target software development chain and full application requires target software development chain and full application (boot, RTOS, (boot, RTOS, � Interrupt handling, etc) Interrupt handling, etc) � often low speed often low speed � � different integration problem for every vendor (and often for ev different integration problem for every vendor (and often for every CPU) ery CPU) � � may be difficult to support communication models that require wa may be difficult to support communication models that require waiting to iting to � complete an I/O or synchronization operation complete an I/O or synchronization operation 84

PARADES Accuracy vs vs Performance Performance vs vs Cost Cost Accuracy Accuracy Speed $$$* +++ +- --- Hardware Emulation ++ -- -- Cycle accurate model ++ + - Cycle counting ISS + ++ ++ Dynamic estimation Static spreadsheet - +++ +++ *$$$ = NRE + per model + per design 85

PARADES CoWare Platform Modeling Environment Platform Modeling Environment CoWare � Focus on computation/communication separation � Focus on computation/communication separation � Leverage their LISA platform and � Leverage their LISA platform and SystemC SystemC Transaction Transaction Level Models Level Models 86

PARADES CoWare Support for Multiple Abstraction Levels Support for Multiple Abstraction Levels CoWare � Support successive refinement for both processors and bus models � Support successive refinement for both processors and bus models � Depending on abstraction level, simulation performance of 100 to � Depending on abstraction level, simulation performance of 100 to 200 200 Kcycles Kcycles/sec /sec 87

PARADES Refining the C Control ontrol Algoritm Algoritm Refining the Model based Code based Untimed, host data type Model level Untimed, target data type Timed, target data type Real target TF/RT Platform-in-the-Loop UF Platform-in-the-Loop C Code on platform model C Code on platform model Platform model Platform model 88

PARADES Model Based Control- -Platform Co Platform Co- -Design Design Model Based Control •1 •1 •inputEvent_1 •inputEvent_1 •events •events •2 •2 •1 •1 •inputEvent_2 •inputEvent_2 •inputEvent_1 •inputEvent_1 •events •events •fc_event1 •fc_event1 •2 •2 •1 •1 •3 •3 •inData •inData •inputEvent_2 •inputEvent_2 •InData •InData •function() •function() •inputEvent_1 •inputEvent_1 •events •events •InData •InData •fc_event_2 •fc_event_2 •5 •5 •InData_2 •InData_2 •OutData •OutData •fc_event1 •fc_event1 •InData_2 •InData_2 •2 •2 •InData_2 •InData_2 •inputEvent_2 •inputEvent_2 •3 •3 •inData •inData •SF-SS •SF-SS •FC-SS-1 •FC-SS-1 •InData •InData •function() •function() •InData •InData •fc_event_2 •fc_event_2 •5 •5 •InData_2 •InData_2 •OutData •OutData •fc_event1 •fc_event1 •InData_2 •InData_2 •InData_2 •InData_2 •function() •function() •3 •3 •inData •inData •Merge •Merge •1 •1 •InData •InData •SF-SS •SF-SS •FC-SS-1 •FC-SS-1 •function() •function() •OutData •OutData •4 •4 •InData1 •InData1 •OutData •OutData •InData •InData •OutData •OutData •InData_1 •InData_1 •fc_event_2 •fc_event_2 •5 •5 •InData_2 •InData_2 •OutData •OutData •InData_1 •InData_1 •InData_2 •InData_2 •MergeOutData •MergeOutData •InData_2 •InData_2 •FC-SS-2 •FC-SS-2 Platform •function() •function() •Merge •Merge •1 •1 •SF-SS •SF-SS •FC-SS-1 •FC-SS-1 •OutData •OutData •4 •4 •InData1 •InData1 •OutData •OutData •OutData •OutData •InData_1 •InData_1 •InData_1 •InData_1 •MergeOutData •MergeOutData Abstraction •FC-SS-2 •FC-SS-2 •function() •function() •Merge •Merge •1 •1 •OutData •OutData •4 •4 •InData1 •InData1 •OutData •OutData •OutData •OutData •InData_1 •InData_1 •InData_1 •InData_1 •MergeOutData •MergeOutData Software Platform Software Platform •FC-SS-2 •FC-SS-2 (API services) (API services) Control RTOS RTOS Net Net Specification Device Drivers Device Drivers BIOS BIOS CPUs CPUs ECU output devices ECU output devices ECU input devices ECU input devices void integratutto4_initializer( void ) { /* Initialize machine's broadcast event variable */ _sfEvent_ = CALL_EVENT; _integratutto4MachineNumber_ = sf_debug_initialize_machine("integratutto4","sfun",0,3,0,0,0); sf_debug_set_machine_event_thresholds(_integratutto4MachineNumber_,0,0); sf_debug_set_machine_data_thresholds(_integratutto4MachineNumber_,0); } 89

PARADES Platform Design Platform Design •1 •1 •inputEvent_1 •inputEvent_1 •events •events •2 •2 •inputEvent_2 •inputEvent_2 The software •fc_event1 •fc_event1 •3 •3 •inData •inData •InData •InData •function() •function() •InData •InData application is •fc_event_2 •fc_event_2 •5 •5 •InData_2 •InData_2 •OutData •OutData •InData_2 •InData_2 •InData_2 •InData_2 •SF-SS •SF-SS •FC-SS-1 •FC-SS-1 •1 •1 Application Software composed of model- •inputEvent_1 •inputEvent_1 •events •events •function() •function() •M •M erge erge •1 •1 •2 •2 •OutData •OutData •4 •4 •InData1 •InData1 •OutData •OutData •OutData •OutData •InData_1 •InData_1 •inputEvent_2 •inputEvent_2 •InData_1 •InData_1 •M •M ergeOutData ergeOutData based and hand-written •FC-SS-2 •FC-SS-2 •fc_event1 •fc_event1 •3 •3 •inData •inData •InData •InData •function() •function() •InData •InData •fc_event_2 •fc_event_2 •5 •5 •InData_2 •InData_2 •OutData •OutData •InData_2 •InData_2 application-dependent •InData_2 •InData_2 •SF-SS •SF-SS •FC-SS-1 •FC-SS-1 software components •function() •function() •M •M erge erge •1 •1 •OutData •OutData •4 •4 •InData1 •InData1 •OutData •OutData •OutData •OutData •InData_1 •InData_1 •InData_1 •InData_1 •M •M ergeOutData ergeOutData •FC-SS-2 •FC-SS-2 (sources) Sensor/Actuator Layer The software platform is Software Platform Software Platform cross applications and (API services) (API services) cross HW plats and is RTOS RTOS Net Net Device Drivers Device Drivers composed of BIOS BIOS parameterized software CPUs CPUs components (sources) ECU output devices ECU output devices ECU input devices ECU input devices 90

PARADES Choosing an Implementation Architecture Choosing an Implementation Architecture Application Space (Features) Application Software Application Instances Platform Specification Application Software Platform API System Software Platform Network Communication Platform (no ISA) Network Communication RTOS Network Communication Network Communication Platform Design RTOS Device Drivers Space Exploration RTOS RTOS BIOS Device Drivers DUAL-CORE Hardware Hardware Platform Device Drivers BIOS Device Drivers Input devices Output Devices I O HITACHI Hardware Hardware Platform BIOS BIOS Input devices Output Devices I O network ST10 Hardware Hardware Platform ST10 Platform Instance Input devices Output Devices network I O HITACHI network DUAL-CORE Architectural Space (Performance) 91

PARADES Platform Design and Implementation Platform Design and Implementation � Hardware, computation: � Hardware, computation: � Software, granularity: � Software, granularity: � Cores: Cores: � Set of Processes Set of Processes � � � Core selection Core selection � � Process/Thread Process/Thread � � Core instantiation Core instantiation � � Instruction sequences Instruction sequences � � Coprocessors: Coprocessors: � � Instructions Instructions � � Selection (Peripherals) Selection (Peripherals) � � Software, layers: � Configuration/Synthesis Configuration/Synthesis � Software, layers: � � Instructions: Instructions: � � RTOS RTOS � � ISA definition (VLIW) ISA definition (VLIW) � � HAL HAL � � ISA Extension Flow ISA Extension Flow � � Middle layers Middle layers � � Hardware, communication: � Hardware, communication: � Busses Busses � � Networks Networks � 92

93 PARADES AUTOSAR Software Platform Standardization AUTOSAR Software Platform Standardization

94 PARADES

PARADES Hardware Design Flow Hardware Design Flow � Not a unified approach to explore the different levels of � Not a unified approach to explore the different levels of parallelism parallelism � The macro level architecture must be selected � The macro level architecture must be selected � Implementing function in RTL ( Implementing function in RTL (SystemC SystemC/C++ Flow) /C++ Flow) � � Hardware implementation of RTOS Hardware implementation of RTOS � � Partition the function and implements some parts using a Partition the function and implements some parts using a � dedicated Co- -Processor Processor dedicated Co � Change Core Instruction Set Application (ISA): Change Core Instruction Set Application (ISA): � � Parameterization of a configurable processor Parameterization of a configurable processor � � Custom extension of the ISA Custom extension of the ISA � � Define a new ISA (e.g. VLIW) Define a new ISA (e.g. VLIW) � 95

96 PARADES -Chip Design Flow Chip Design Flow On- -On Traditional System- Traditional System

97 PARADES C/C++ Synthesis Flow C/C++ Synthesis Flow

98 PARADES -Chip Design Flow Chip Design Flow On- -On Evolution of System- Evolution of System

PARADES Implementing Function in RTL Implementing Function in RTL General-purpose CPUs used in General-purpose CPUs used in traditional SOCs are not fast enough for traditional SOCs are not fast enough for data-intensive applications, don’t have data-intensive applications, don’t have Hardwired Logic Hardwired Logic enough I/O or compute bandwidth, lacks enough I/O or compute bandwidth, lacks • High performance due • High performance due efficiency efficiency to parallelism to parallelism • Large number of wires • Large number of wires in/out of the block in/out of the block • Languages/Tools • Languages/Tools ROM General General familiar to many familiar to many A/D Purpose Purpose But … But … 32b CPU 32b CPU RAM • Slow to design and verify • Slow to design and verify • Inflexible after tapeout • Inflexible after tapeout I/O • High re-spin risk and cost • High re-spin risk and cost Hardwired Logic • Slows time to market • Slows time to market PHY Courtesy of Grant Martin, Chief Scientist, Tensilica Courtesy of 99

PARADES SystemC/C /C++ Synthesis Flow ++ Synthesis Flow SystemC High Level Models: High Level Models: TLM/Simulink Simulink TLM/ IR: Control Flow Data Graph IR: Control Flow Data Graph SystemC/C++ Models SystemC /C++ Models Chunks Identification & Chunks Identification & High High- -Level Synthesis Level Synthesis Software Extraction Software Extraction System partitioning System partitioning Hardware Software Hardware Software implementations Compilation implementations Compilation Cost Function Evaluation Cost Function Evaluation Hardware Cost Performance Software Cost Hardware Cost Performance Software Cost Estimation Estimation Estimation Estimation Estimation Estimation Hw/Sw Hw/ Sw Integration Integration Hardware Refinement Hardware Refinement Hw/Sw Hw/ Sw Co Co- -verification verification Software Refinement Software Refinement RTL Level hardware software hardware software 100