A General Synthesis Approach for Embedded Systems Design with Applications to Multi-media and Automotive Designs

Transcription

1 A General Synthesis Approach for Embedded Systems Design with Applications to Multi-media and Automotive Designs Alberto Sangiovanni Vincentelli (Qi Zhu and Abhijit Davare)

2 Outline Design Trends and Challenges Semantic-Driven Synthesis Flow Common Modeling Domain Automatic Synthesis Validating the Design Flow Automotive Stability Control Image Processing Future Work 2/34

3 Toyota Autonomous Vehicle Technology Roadmap Source: Toyota Web site 3/34

4 Value from Electronics & Software Electronics, Controls & Software Shifting the Basis of Competition in Vehicles -More functions & features -Less hardware -Faster Potential inflection point. Now! Electric Ignition... Software $ Other $ 2% Electronics $ 9% 13% BCM ABS OnStar OBD II HI Spd Data TCC Mechanical $ Rear aud/vid EGR CDs $ ECUs ACC Rear Vision Passive Entry Side Airbags Head Airbags Hybrid PT Electric Brake Other $ DoD 8% Fuel Cell Wheel Motor Electric Fan 76% 1970s 1980s 1990sAVG. 2000s AVG. 2010s 2020s ABS: Antilock Brake System EGR: Exhaust Gas Vehicle Recirculation. Integration ACC: Adaptive Cruise Control GDI: Gas Direct Injection BCM: Body Control Module System Connection OBD: Onboard Diagnostics DoD: Displacement On Demand TCC: Torque Converter Clutch ECS: Subsystem Electronics, Controls, and & Software Features PT: Powertrain Source: Matt Tsien, GM 1M Lines $1182 (+196%) 50 ECUs (+150%) 100M Lines of Code (+9900%) GDI Mechanical $ 55% Software $ 13% Electronics $ 24% Forefront of Innovation 4/34

5 A Typical Car Architecture (BMW) 5/34

6 Design Trends Complexity of embedded systems Time to market Reliability Flexibility Separation of concerns Design reuse Correct-by-construction Functionality MP3, MPEG-4, Wi-Fi, BT, GPS? Mapping Architecture Cell, MXP series, IXP series, Nexperia 6/34

7 Platform-based Design Application Space Architectural Space Application Instance Platform Instance Platform Mapping Platform Design-Space Export Platform: library of resources defining an abstraction layer Resources do contain virtual components i.e., place holders that will be customized in the implementation phase to meet constraints Very important resources are interconnections and communication protocols 7/34

8 Fractal Nature of Design 8/34

9 The next level of Abstraction IP Block Performance Inter IP Communication Performance Models IP Blocks SDF Wire Load abstract Gate Level Model Capacity Load abstract RTL cluster RTL Clusters SW Models Transistor Model Capacity Load abstract cluster abstract cluster 1970 s 1980 s 1990 s Year /34

10 Challenge Functionality and Architecture are modeled separately Function Model Architecture Model Mismatch Find a common language Different semantics (e.g., synchronous vs. asynchronous) Different abstraction level (e.g. instruction vs. block level) and decide the abstraction level Mapping Mapping could be is automatic, ad-hoc, manual, correct-by-construction error-prone 10/34

11 Outline Design Trends and Challenges Semantic-Driven Synthesis Flow Common Modeling Domain Automatic Synthesis Validating the Design Flow Automotive Stability Control Image Processing Future Work 11/34

12 Technology Mapping Mapped Design Function t 1 t 3 + fgh d+e d e a F f g d e F t 4 f b+h h c b a c b h at 2 +c oai21 g (3) oai21(3) Mapping Covering Architecture nand3(3) inv(1) aoi21 (3) Common language: Boolean logic nand2(2) Primitives: NAND2 gate and inverter inv(1) xor (5) nand2(2) nor(2) and2(3) nand3 (3) F oai22 (4) nor3 (3) 12/34

13 Synthesis Flow Function Model Architecture Model CMD Stage 1 Function Model in CMD Common language Primitives Architecture Model in CMD Covering Stage 2 Further Synthesis Stage 3 13/34

14 Modeling Domain Semantic Domain Modeling domain is based on semantic domain and primitives Q: semantic domain - language (trace-based agent algebra [R. Passerone, PhD thesis]) Q.D: domain of agents building blocks Q.A: master alphabet all signals between blocks Q.α : Q.D -> 2 Q.A, each agent has an alphabet which is a subset of Q.A each block has a set of signals Operators: renaming, projection and parallel composition rules to initialize and compose agents s 3 3 proj({ i1, o2}) ( 1 s2 s = rename ( r)( s ) rename( r)( )) i 1 s 1 s 2 i 1 o 1 o 2 i 1 io 12 io 12 io 12 i 2 o 2 o 2 PN semantics 14/34

15 Modeling Domain Primitives New agents can be constructed by applying a finite number of operators in sequence on existing agents. Agent Closure C Q (S) contains all the agents that can be constructed from a set of agents S by applying operators in semantic domain Q. Primitives P abstraction level Primitives are agents, P Q. D. No agent in P can be constructed from other agents in P, i.e., p P, there exists no P' P \ { p} s.t. p CQ(P'). {s 1, s 2 } is a set of primitives in PN semantics, {s 1, s 2, s 3 } is not. s 3 s 1 s 2 i 1 io 12 o 2 15/34

16 Modeling Domain Modeling domain M = C Q (P) is the agent closure of a set of primitives P in semantic domain Q. Contains all the agents that can be constructed from P. E.g., C PN ({s 1, s 2 }) contains all the agents that can be constructed from {s 1, s 2 } by applying operators in PN semantics. Semantic domain Q provides a language for modeling. Primitive P defines a sub-space of the entire modeling space of Q. Abstraction level can be explored by choosing different primitives. What is the relation between different modeling domains? What is common modeling domain? 16/34

17 Relation between Modeling Domains Behaviors Γ: 2 Q.A -> 2 T, each alphabet is associated with a set of traces over trace domain T. Each agent s has a set of traces Γ(Q.α(s)), which are called behaviors, denoted as B(s). s 1 B( s ) = Γ( Q. α ( s )) = ( i V ) ( o V ) i 1 o 1 Ancestor-Child relation between modeling domains Ф(M) = {B(s) s C Q (P) }. M 1 = C Q1 (P 1 ) is the ancestor of M 2 = C Q2 (P 2 ) if Ф(M 2 ) Ф(M 1 ), denoted as M 2 M 1. Example: C PN ({s 3 }) C PN ({s 1, s 2 }) Ancestor more expressive, higher modeling complexity Child more specific, lower modeling complexity 17/34

18 Common Modeling Domain A model is an agent in the modeling domain. A modeling domain M is called common modeling domain between function model f and architecture model a if there exists f M and a M such that B(f ) B(f) and B(a ) B(a). Function Model f in Original Modeling Domain Architecture Model a in Original Modeling Domain O C Function Model f in CMD C O Architecture Model a in CMD 18/34

19 CMD Selection Search for CMDs on Modeling Domain Relation Graph Common Ancestor Modeling Domain of F and A D Larger mapping space F Model Transformation C CMD Model Transformation Simpler model A Original Function Modeling Domain Original Architecture Modeling Domain 19/34

20 CMD Selection Two design aspects when selecting CMD C = C Q (P) Semantics decided by semantic domain Q Expressiveness vs. Analyzability. e.g. Dataflow vs. Static dataflow First choose semantic domain for common ancestor domain D, then refine it in C. Abstraction level decided by primitives P Explore different abstraction level by choosing different primitives. Carried out when select C as child domain of D. Utilize ancestor-child relation to explore candidate child domains formally. Trade-off: complexity and size of mapping space 20/34

21 Outline Design Trends and Challenges Semantic-Driven Synthesis Flow Common Modeling Domain Automatic Synthesis Validating the Design Flow Automotive Stability Control Image Processing Future Work 21/34

22 Covering Problem Formulation Symbols: Function primitive instances : Architecture primitive instances : Mapping decision variables : Quantities (power, area, bandwidth ): Costs (special quantities): Constraints: Decision constraints: Each function primitive instance needs to be covered by one and only one architecture primitive instance. l l l Quantity constraints: Ht ( dij, Qijk ) QCt Constraints from architecture platform or design constraints, such as power constraints, bandwidth constraints, etc. Objective function: Cost function: j S i d = 1 ij G ( d l ij, C l ijk ) F = ( f, f2,..., f A = a, a,..., a d ij l Q ijk l C ijk i, 1 i n 1 n ( 1 2 m ) ) 22/34

23 Solve Covering Problem General purpose solvers MILP: CPLEX, MOSEK, GLPK, GP: GGPLAB, YALMIP, Covering Problem j H S i l t d = 1 ij ( d G ( d l ij ij, Q, C l ijk l ijk ) QC ) l t Domain-specific Algorithms Customizable Branch-based framework Other design concerns Scheduling Buffer sizing Comm. bandwidth 23/34

24 Outline Design Trends and Challenges Semantic-Driven Synthesis Flow Common Modeling Domain Automatic Synthesis Validating the Design Flow Automotive Stability Control Image Processing Future Work 24/34

25 Automotive Stability Control Find common language between functionality and architecture by choosing semantic domain Q in CMD C Q (P). Functionality synchronous Simulink model no message loss or duplication Architecture clock drift between distributed ECUs, asynchronous comm. data loss and duplication mismatch 25/34

26 CMD Selection (Stage 1) Find CMD from modeling domain relation graph D = C PN (P D ) Common ancestor domain: Process Networks semantics P 1 =P F U P A C 2 =C SR (P 2 ) C 1 = C LTTA (P 1 ) P 2 =P F U P A F = C SR (P F ) f = f a = a A = C LTTA (P A ) B(f ) B(f) B(a ) B(a) Original Function modeling domain: Synchronous/Reactive semantics Original Architecture modeling domain: Semantics of LTTA (loosely time-triggered architecture) [1] H. Zeng, A. Davare, A. L. Sangiovanni-Vincentelli, et. al, Design Space Exploration of Automotive Platforms in Metropolis, SAE /34

27 Transformation of architecture model CMD uses synchronous/reactive semantics Function model does not need to be changed Architecture primitives P A should be transformed to P A in CMD to support synchronous/reactive semantics Protocol to avoid data loss [1] Constraints on process periods Requires clock drift to be within a certain range Clock synchronization to restrict the clock drift [2] Alternating bit to avoid data duplication B(a ) B(a), but correct behaviors can be assured when function model f is mapped to architecture model a [1] A. Benveniste, P. Caspi, P. Le Guernic, H. Marchand, J.P. Talpin and Stavros Tripakis, A Protocol for Loosely Time-Triggered Architectures, EMSOFT '02 [2] M. Gergeleit and H. Streich, Implementing a Distributed High-Resolution Real-Time Clock using the CAN-Bus, 1st International CAN-Conference 27/34

28 Automatic Synthesis (Stage 2&3) Covering problem Function primitives instance f i : tasks and messages Architecture primitives instance a j : ECUs and buses Quantity constraints : maximum workload on ECU Objective function: minimize inter-ecu communication and balance computation load across ECUs Utilize the Scotch [1] package Function model graph and architecture graph Partition-based algorithm solves the covering problem Further synthesis Task priorities based on pre-assigned message priorities Task periods Adjusted to satisfy end-to-end latency requirements Task periods need to satisfy the protocol to ensure the correctness of semantics [1] Scotch, 28/34

29 Experimental Results 14 tasks, 48 messages 6 ECUs, 1 bus Automatic synthesized design vs. 6 manual designs Simulated in Metropolis framework Design Total delay (ms) Bus utilization Max ECU utilization Manual % 60% Manual % 72% Automatic % 48% 29/34

30 Image Processing Explore abstraction level of the design by choosing primitives P in CMD C Q (P). Functionality Architecture Data-driven application Can be used in MPEG-2, Motion-JPEG, MPEG-4, etc. Highly parallel heterogeneous platform Designed for image application 8 image signal processors (ISPs) 5 processing elements (PEs) in each ISP 30/34

31 CMD Selection (Stage 1) Dataflow semantics Choose proper abstraction level (granularity) Too coarse inefficient usage of highly parallel platform Too fine scheduling difficulties and model complexity Explored four CMDs Block level Coarse sub-block level Fine sub-block level Instruction level Instruction fine sub-block coarse sub-block F block A 31/34

32 Function Model at Different CMDs Block level CMD CSC Shift DCT Quantization Huffman child Coarse sub-block level CMD ZigZag Multi 1D-DCT 1D-DCT Transpose Transpose RLE Lookup Fine sub-block level CMD Add4 Add2 Sub2 Mult1 ancestor Sub4 Mult2 32/34

33 Architecture Model Architecture model has the same abstraction level in all CMDs for this case study. PEs, global registers, memories are architecture primitives in all CMDs. Abstraction levels of mapped designs in this case study are dictated by the functional abstraction levels. No single PE can support DCT block so block level CMD is not suitable. Complexity is too high so instruction level CMD is not suitable. Important to find a CMD at proper abstraction level 33/34

34 Automatic Synthesis (Stage 2&3) Mapping at coarse and fine sub-block level CMDs. Function primitive instances f i : function blocks and channels Architecture primitive instances a j : PEs, GRs and memory Quantity 1400 Coarse sub-block level constraints : maximum # of registers Objective 1200 function: throughput 1000 Fine sub-block level Compare # of cycles to perform DCT for a 8x8 block (simulated in Metropolis, 800 accuracy within 1% [1]) Cycles F-automatic F-manual-1 F-manual-2 C-automatic Mappings Choosing a CMD at proper abstraction level can greatly affect [1] A. Davare, Q. Zhu, J. Moondanos and A. L. Sangiovanni-Vincentelli, JPEG Encoding on the the MXP5800: performance A Platform-based of the mapping. Design Case Study, EstiMedia /34

35 Outline Design Trends and Challenges Semantic-Driven Synthesis Flow Common Modeling Domain Automatic Synthesis Validating the Design Flow Automotive Stability Control Image Processing Future Work 35/34

36 Future Work Ongoing projects: Task allocation and priority assignment for automotive systems stage 2 Period synthesis for automotive systems stage 3 Future work: Complete synthesis flow for automotive domain Multimedia domain case study H.264 Synthesis from synchronous models to general multiprocessor platform Automotive Multimedia Sync. synthesis 01/ Months 36/34

37 Contributions A synthesis flow in which semantics and abstraction level are formally determined, and automatic algorithms can be applied. The method was validated by industrial case studies with different focus. Automotive stability control: choose semantics Image processing: explore abstraction level Regardless of the focus, applications from different domains can be solved in the same way by our flow. 37/34