1 / 28

The Essence of Polis/Felix/VCC Project: Virtual Component Co-design

1988:. The Essence of Polis/Felix/VCC Project: Virtual Component Co-design. 1. 2. System Behavior. System Architecture. Describe & verify product behavior Describe product architectures Explore HW/SW design tradeoffs Map behavior to architecture Use performance simulation

afra
Download Presentation

The Essence of Polis/Felix/VCC Project: Virtual Component Co-design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 1988: The Essence of Polis/Felix/VCC Project: Virtual Component Co-design 1 2 System Behavior System Architecture • Describe & verify product behavior • Describe product architectures • Explore HW/SW design tradeoffs • Map behavior to architecture • Use performance simulation • Perform communication refinement • Integrated flow to implementation Behavior Simulation Mapping 3 Performance Simulation Communication Refinement 4 Flow To Implementation

  2. IP Block Performance Inter IP Communication Performance Models IP Blocks SDF Wire Load RTL Clusters SW Models RTL Gate Level Model Capacity Load Transistor Model Capacity Load cluster cluster cluster abstract abstract abstract abstract 1970’s 1980’s 1990’s Year 2000 + The next level of Abstraction …

  3. Architectural Choices Flexibility 1/Efficiency (power, speed)

  4. ARM9 core 16KB I-cache 8KB D-cache 2-way set associative 150 MHz C55x DSP core 16KB I-cache 8KB RAM set 2-way set associative 200 MHz OMAP™ Block Diagram Program Memory SDRAM Memory & Traffic Controller I-MMU D-MMU MMU Internal RAM/ROM I-Cache D-Cache I-Cache DMA RISC Core DSP Core + Appl Coprocessors Peripherals LCD Controller, Interrupt Handlers, Timers, GPIO, UARTs, ...

  5. Hardware Platforms Not Enough! • Hardware platform has to be abstracted • Interface to the application software is the “API” • Software layer performs abstraction: • Programmable cores and memory subsystem “hidden” by RTOS and compilers • I/O subsystem with Device Drivers • Network with Network Communication Software

  6. Platform API Application Software Software Software Platform Hardware Platform Hardware Input devices Output Devices I O network API Network Communication RTOS Device Drivers Compiler BIOS Software Platforms

  7. Nexperia™ -DVP Software Architecture Supports multiple OSs and middleware software Abstracts platform functionality via consistent APIs Nexperia™-DVP Streaming Software Encapsulates implementation of streaming media components (hardware and software) Nexperia™ Platform Software OS independent device drivers for on-chip and off-chip devices Nexperia-DVP Software Applications MiddlewareJavaTV, TVPAK, OpenTV, MHP/Java, proprietary ... Kernel: pSOS, Win-CE, JavaOS Streaming and Platform Software Nexperia Hardware

  8. Application Libraries Speedometer Tachometer Water temp. Speedometer Tachometer Odometer --------------- Sys. Config. Boot Loader HC08 HC12 H8S26 Nec78k MB90 MOSAIC SW Architecture & Components for Automotive Dashboard and Body Control Application Platform layer (@ 10% of total SW) Customer Libraries OSEK RTOS CCP Application Specific Software KWP 2000 Transport SW Platform Reuse > 70% of total SW SW Platform layer (> 60% of total SW) OSEK COM Application Programming Interface I/O drivers & handlers (> 20 configurable modules) mControllers Library HW layer

  9. Application Space Application Instance Platform Specification System Platform Platform Design-Space Exploration Platform Instance Architectural Space Platforms

  10. Platforms • A platform is, in general, an abstraction that covers a number of possible refinements into a lower level. For every platform, there is a view that is used to map the upper layers of abstraction into the platform and a view that is used to define the class of lower level abstractions implied by the platform.

  11. Platforms

  12. Application example: • Automotive Power-Train Control Design: from car manufacturer specs to software design to architecture selection to IC implementation • Project in collaboration with Cadence, Magneti-Marelli, ST Microelectronics, Accent

  13. Power-Train Control System • Electronic device controlling an internal combustion engine and a gearbox • The goal • offer appropriate driving performance (e.g. torque, comfort, safety) • minimize fuel consumption and emissions • Relevant characteristics • strictly coupled with mechanical parts • hard real-time constraints • complex algorithms for controlling fuel injection, spark ignition, throttle position, gear shift … • 135,000 lines of C code with no comments • First Step was to re-design software with methodology to map into different hardware platforms with little effort!

  14. System Specifications

  15. Goal • Develop guaranteed properties control algorithms for all power-train modes • Implement control strategies on embedded controllers “optimally” with respect to production cost, design time, reliability, safety

  16. Manifold (continuous system) Engine sub-system Drive-line (continuous system with changing dynamics) Model of Power-train Simple? Throttle opening angle Manifold pressure Clutch Insertion/Release Gear change Vehicle Speed Spark timing Torque

  17. CTS CTS Engine and Drive-line

  18. Engine and Drive-line

  19. Single Cylinder Hybrid Model

  20. Hybrid Model vs Mean-Value Model • Mean-Value Model: accurate over a longer time window • regulation control problems • low performance transient problems • Hybrid Model: cycle accurate • transient control problems • stability of delay-sensitive control algorithms • high performance control algorithms

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

  22. FLASH FLASH A B Interrupt Based Peripherals ETU CAN SCI IRC ARM7TDMI A XBAR Peripheral Bus Debug Unit PARADES High Speed Peripheral Bus ARM7TDMI B ADC CLB IRC IO sub system RAM A RAM B DMA Based Peripherals Janus-PARADES 2000 Architecture

  23. The Dual-Arm Architecture A symmetric dual processor architecture with a high-bandwidth interconnection network among processors, memory, and I/O sub-systems • 11 Million Tr., 4% more area than single processor solution but twice the performance on application • Most performing architecture for Power-train applications, designed to be re-used over two generations (3-4 years cycles) of system products or more • Entirely designed using the methodology in less than 1 3/4 year from conception (March 99) to first silicon (Jan 01) • In production by 2002, shipments to car manufacturer 2003

  24. Design “Practice”

  25. Design Science: Build upon solid foundations

  26. Design of Function Blocks • Metropolis Infrastructure • Model of computation • Design methodology • - Abstraction levels • - Refinement • Base tools • - Design imports • - Simulation • Metropolis: Analysis • Static timing analysis of reactive systems • Invariant analysis of sequential programs • Refinement verification • Three-valued simulation • Delay estimation using object code • Metropolis: Synthesis/Refinement • Compile-time scheduling of concurrency • Communication-driven hardware synthesis • Protocol interface generation • Latency insensitive protocols ETROPOLIS (20+ from Academia (UCB,CMU) and Industry (Intel, ST,BMW, Cadence)) Design of Architecture Components Design of Communication Media

More Related