A New Approach to Design

Transcription

1 A New Approach to Design n Formal Specifications n Top Down Design u System Level Design and Rapid Prototyping u Hardware/Software Co-Design u Component Design n Bottom Up Design: IP Use and IP Delivery EE249 1

2 System Specifications EE249 2

3 Closed loop vehicle model Driver Key, Brake, Gas, Transm. Vehicle emissions, external noise, temperature,... force, speed, acceleration, jerk, rpm, fuel consumption,... Engine & Driveline spark advance, injection time, throttle angle Controller EE249 3

4 INP UTS: K - Key G - Gas Pedal T - Clutch Pedal & Gear Stick B - Brake Pedal C - Cruise Control Stop n=0 F G =0 K = Start (n < n min ) (K = O ff) Startup n=. F G =0 (n < n min ) (K=Off) n > n st art up OUTPUT: n - Eng ine Speed F G - Gen e rated Fo rce V G - Vehicle Speed D - Comfort G = 0 IdT le > 0 G > 0 G > 0 Rpm Tracking T>0 & G=0 n=argmin(m fu el ) F G =0 (G>0)&(T>0) G = 0 n=n(g) F G =0 T > 0 T=0. T=0 G>0 t>τ Fast N egative Force Trans ient max D τ < τ max F G =F G (G,T,n) f I (n) = 0 & G=0.. G < G B B=1. G > 0 B = 1 Speed Tracking Force Track ing min f(d, M fuel ) τ < τ max F G =F G (G,T,n) f I (n) = 0 & G=0. G=0 & C=1. G<0 t>τ.. G > G A f I (n,g) > 0 Idle &Trasm On Fast Positive Force Trans ien t min τ M fuel < M ma x ; D>D min F G =F G (G,T,n) T=0 V G = V G (.) n=n(.) T=0 EE249 4

5 Engine Model Air Mngmt Mix Mngmt & Injection Torque Generation Fuel Mngmt Combustion Engine Ignition (Spark) Timing Exhaust Gas Treatment EE249 5

6 Abstraction n n n n n The Plant consists of Engine+Drive-Line Torque Generation Model abstracted from very complex chemical-mechanical-thermo-dynamical process = FSM! Drive Line Dynamics represented as 3rd order linear dynamical system Control variables: spark + fuel injection Abstraction validated by theoretical devices (formal verification) + measurements on actual cars EE249 6

7 Hybrid Systems in Automotive n Driver (Reference) Model n Engine + Drive-line (Plant) Model START ACCEL. FSM DE CONST. DECEL. CT STOP IDLE EE249 7

8 Cut-off Control: the Problem n n n n When accelerator pedal is released, no torque is requested. Intuitive solution: reduce injection to zero immediately! u u minimizes consumption and emissions but, sharp torque variations can cause unpleasant power-train oscillations! Control Problem: Power-train oscillation reduction via injection signal control Present solution: open loop air/fuel modulation u u engine speed transient during gear changes power-train state not taken into account EE249 8

9 Short History n Specifications obtained November 1996 n Hybrid Modeling November-December 1996 n Control Problem partially solved January 1997 n Complete Simulations May 1997 n Implementation and Field Test October 1997 n Planned for production 1998 EE249 9

10 Summary of Results n Hybrid engine+power-train model n Cut-off control as hybrid control n Convergence and Optimality Properties n Experimental results very encouraging: u better performance u for a commercial car, 50% of memory occupation for data and 75% of memory occupation for code, 1% CPU utilization (Motorola 68020) u Approach can be extended to most regions of operations EE249 10

11 Target HW/SW Architecture I/O up/ uc Thread Mem I/F Driver Cust HW Co-P Mem Map Thread Bridge DP MEM Map Driver Periph I/O DSP Thread Mem Bridge I/F IP BLOCK EE249 11

12 Choosing the Architecture Core Processors (ARM, x86, MIPS) DSP Processors (TI320x, Pine, Trimedia) Configurable Hardware (Clay, Xilinx, Atmel) Dedicated Hardware (Fixed, Synthesized) Metrics Programmability Coverage Cost Performance Power EE249 12

13 Mapping n Associates functional units with architectural units n Performs HW/SW partitioning n Associates functional communication with resources (buffers, busses, serial links, etc.) n Provides estimates of performance of a given function on a given architectural unit EE249 13

14 Behavior-Architecture Binding Up-link Radio Down-link Radio Graphics Voice Pen Meaningful decision making requires fast and educated information on impact of design choices External I/O ASSP Dedicated Processor Bus DSP Processor DSP RAM Control Processor EE249 Audio 14 Decode System RAM

15 Estimation and Modeling Software Path Behavioral Function Hardware Path Model Library Code Generation SW library HW library Mapping Model Library Processor Model ARM8 Network of Modules Combines Behavioral Parameters EE249 and Architectural Models 15

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

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

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

19 Architecture Evaluation Problem System Behavior System Behavior Behavior Refine Refine System Architecture System Architecture Architecture Refine Refine Out of Spec High Cost HDL Time and Money EE249

20 Architecture Evaluation System Behavior Behavior System Architecture System Architecture System Architecture Architecture Refine In Spec Low Cost HDL Time and Money EE249

21 Separate Behavior from Architecture n System Behavior n Implementation Architecture u Functional Specification of System. u Hardware and Software Front End 1 Transport Decode 2 Rate 12 Rate 5 Mem 13 User/Sys Control 3 Synch Control 4 Decode 6 Sensor Frame 7 Output 8 External I/O MPEG Peripheral Processor Bus DSP Processor DSP RAM Control Processor Rate 9 Audio Decode/ Output 10 Audio Decode System RAM Mem 11 EE249

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

23 Architecture Determines Performance Transport Decode Audio Decode/ Output Control Processor Processor Bus Audio Decoder EE249

24 Communication Refinement n Separate Function of blocks from inter-block communication n Substitute lower-level detail for communications behavior IP Block Protocol Down Converter Protocol Up Converter IP Block IP Block With Generic Data Transfer IP Block With Generic Data Transfer EE249

25 Insert Communication Design Transport Decode Audio Decode/ Output EE249

26 Engine Control Unit SW Arch. Transformation RTOS Variable Images controls Actuated Variable Communication P. Sensors Device Driver P. Actuators Device driver Software BIOS Sensors Hardware Actuators Net Net S Hardware A network SW Structure Layer EE249 26

27 Mapping and Performance Estimation n Mapping the system behavior to each ECU architecture n Performance estimation based on CPU and peripheral models: u automatic estimation for untimed behavior running on CPUs u manual estimation for timers and TPUs EE249 27

28 Software IP authoring n Key in providing flexibility n Software is consuming more and more time and resources: u Telecom: 70+% of engineering u Automotive: from 40% to more than 60% u Most of malfunctioning comes from software n Life Threatening Errors n Cost of bug fixing EE249

29 Software Issues n Error free requirements n Architecture of embedded software: u typical of 8-bit architectures u assembly code u mostly obsolete u layered u little, if any, documentation n Almost no re-use n Cost of developing software often not recognized by clients EE249

30 Opportunities for Embedded Software Design n A structured approach geared towards re-use and verification is not impossible, but requires investing in new human resources and tools! n Embedded software has peculiarities that allow effective automatic synthesis and optimization n Operating systems are RT and micro-kernel n Could be synthesized as well.to take advantage of the characteristics of the problem n Validation can be carried out formally if a rigorous approach to modeling is used EE249

31 SW Architecture Guideline n Strong separation between basic software and application software. u Basic software must encapsulate hardware details and sensor/actuator implementation details u Application software should reflect the control algorithm hierarchy with no explicit dependency on hardware architecture. A.Ferrari, M.Antoniotti, and A.S.V. EE249 31

32 System Design Architecture Function Synthesis Mapping Verification HW SW EE249 32

33 Proposed Design Methodology Behavioral Libraries Architecture Libraries Functional Level Capture Behavior Verify Behavior Capture Architecture Verify Architecture Map Behavior to Architecture Verify Performance Mapping Level Performance Back-Annotation Refine HW/SW Architecture Link to HW/SW Implementation EE249 Link to uarchitecture Verification Architectural Level

34 Ptolemy n n n n n E. Lee Project at UC Berkeley Multiple models of computation DSP beginnings: Static Dataflow Many other models: FSM, Discrete Event Mixed model verification EE249

35 A bit of history: the POLIS project 1988: The problem: Climate Control Info System Engine Control Exhaust Control Active Suspensions n The target architecture: Transmission ABS compute air flow air flow throttle position engine speed air temperature air pressure compute injection time look-up table engine temperature injection time drive actuators PWM signals 68HC11 ROM Intfc. EE249 35

36 POLIS Methodology Graphical EFSM ESTEREL... Compilers Sw Synthesis CFSMs Hw Synthesis Sw Estimation Partitioning Hw Estimation Sw Code + RTOS Hw/Sw Co-Simulation Performance/trade-off Evaluation Fomal Verification Physical Prototyping Logic Netlist Aptix Board Consist of micro of choice FPGA s FPIC s EE249 36

37 F ront End 1 Transpo rt Decode 2 Rat e 12 Rat e 9 Rat e 5 Synch Cont rol 4 Mem 13 User/Sys Cont rol 3 Decode 6 Audio Decode / Out put 10 F rame 7 Sens or Out put 8 Design System Software Development Tools Poindexter C Toolset System Behavior Specification SPW,Cossap BONeS Ptolemy Databooks IP Behavior Libraries Architecture Libraries Simulation Estimation Partitioning Transport Front End Decode Bus Memory mcontroller Decode Output Audio Decode/Output System Architecture Evaluation HW/SW Coverification Design Verification SW Compile HW Synthesis EE249

38 Transpo rt Decode 2 Rat e 12 Rat e 9 Rat e 5 Transpo rt Decode 2 Synch Cont rol 4 Mem 13 User/Sys Cont rol 3 Rat e 12 Decode 6 Audio Decode / Out put 10 Rat e 5 Rat e 9 Transpo rt Decode 2 F rame 7 Sens or Synch Cont rol 4 Mem 13 User/Sys Cont rol 3 Decode 6 Audio Decode / Out put 10 Out put 8 Rat e 12 Rat e 9 Rat e 5 F rame 7 Sens or Mem 13 User/Sys Cont rol 3 Out put 8 Synch Cont rol 4 Decode 6 Audio Decode / Out put 10 F rame 7 Sens or Out put 8 F ront End 1 Transpo rt Decode 2 Rat e 12 Rat e 9 Rat e 5 Synch Cont rol 4 Mem 13 User/Sys Cont rol 3 Decode 6 Audio Decode / Out put 10 F rame 7 Sens or Out put 8 Product Design Kit Reference Implementation Architecture External Library I/O Peripheral Peripheral Peripheral Peripheral Bus Interface Processor Bus Control Processor System RAM DSP Processor DSP RAM Product Development Peripheral Selection Application SW Mapping Toolset Peripheral Catalog Decode Decode Decode Decode Simulation Estimation Partitioning External I/O Peripheral Peripheral Peripheral Bus Interface Processor Bus Control System Processor RAM DSP Processor DSP RA M Peripheral Sample Design Library EE249

39 Conclusion n Separate the Behavior from Architecture. n Map between the Behavior and Architecture. n Mapping paradigm extends to communication and refinement. EE249

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

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

42 Where All is Going HW/SW Co-Design Paradigm (Felix) Rowson, ASV VSI Design Paradigm Convergence of Paradigms Chang et al. Analog Top-Down Design Methodology ucreate paradigm shift- not just link methods lnew levels of abstraction to fluidly tradeoff HW/SW, A/D, HF/IF, interfaces, etc- to exploit heterogeneous nature of components llinks already being forged EE249 42

43 Concluding Remarks n The Industry Structure is undergoing a revolutionary change n The Design Problems are changing radically their main characteristics n System Design is becoming more and more the key to success n System implies Major Emphasis on Software n Analog, Sensors, Actuators, RF must be part of design n Deep Submicron makes most of the tools obsolete EE249 43