1 / 27

ASDEN Methodology, Capabilities, and Demonstration

ASDEN Methodology, Capabilities, and Demonstration. 2nd Quarter, 2000 JRS Research Laboratories Motorola. Design Methodology Current Capabilities JRS Fill-in-the-gap Tool Developments Demonstration Scenario. Presentation Overview. ASDEN Design Process. Establish & Evaluate Requirements.

duane
Download Presentation

ASDEN Methodology, Capabilities, and Demonstration

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. ASDEN Methodology, Capabilities, and Demonstration 2nd Quarter, 2000 JRS Research Laboratories Motorola

  2. Design Methodology Current Capabilities JRS Fill-in-the-gap Tool Developments Demonstration Scenario Presentation Overview

  3. ASDEN Design Process Establish & Evaluate Requirements Project Requirements Requirements Planning & Data Tracking Off-line Model Management Building Budgets: cost, Size, Functionality, Reliability System Application Functional Modeling Reusable Software Reactive Data Flow State Algorithm Primitives, Graphs Control Graph Diagram Exploration (application & OS), Capture Capture Capture Test Vectors, Functional Simulation/Debugging, HW-in-the-loop Verification Device Drivers Functional applications, Functional data, Test vectors System Design Data Architecture Selection (HW/SW CoDesign) Sets Trade-Off Assignments Performance Trade-off Data HW/SW Matrix & Mappings Analysis Sets Characterization Data (performance Trade-offs, Cost Estimates Validation formulas: timing, Data Sets power, memory) Assignment list, HW/SW parts, Schedules, OS calls Platform Implementation & Software Driver APIs, RTOS, Bootstrapping Code Generation System Load Modules, Load Scripts, HW Init HW Architectures & Components (boards, chips, Parts list, cores & peripherals) Test vectors, Emulation Calibration Cal. maps HW Mixed-Level Diagnostics Development Simulation & Analysis Kit

  4. ASDEN long-term goals: Support all automotive electronic design arena process flows Support engineers’ tools-of-choice within each domain Support numerous existing platforms (microcontrollers, RTOS’, S/W architectures) Support what if tradeoffs and performance analyses for new platform designs ASDEN Current Targets: Engine Electronic Control Unit design arena Series of tools supporting crucial end-to-end processes Motorola’s best-in-class offerings in HW & OS slated for the automotive sector Precursor to hypothetical designs using performance analysis estimating tool Requirements, experimentation, and test vector management (flow down) Design Methodology Instantiation

  5. Current Tool Set

  6. Cohesive tool launcher Reusable Libraries User workspace and file management Internal semantic models provide tool transitions Tool Integrations -- ASDEN Framework Current Tool List • Integrated System Inc.’s MATRIXx • The MathWorks MATLAB • Software Development Systems (SDS)’ SingleStep Simulator/Debugger • Diab Data’s compilation tool suite • Univ. of Illinois / JRS PERTS performance analyzer • Motorola’s OSEK V2.0 • Motorola’s OSEK Sysgen and Builder • Motorola’s MPC555 EV Board developers kit • Motorola’s PSD I/O Drivers for Ford • JRS peripheral device analyzers (3) • JRS system designs Tradeoff Matrix • JRS Paperless Engineering Notebook (PEN) Libraries • System application models • Hardware cores & peripherals • Real-time operating systems • Design arena domain APIs • I/O Drivers • Platforms • Tools

  7. System performance analyzer (PERTS) Code Generation/Synthesis System (CGS) Paperless Engineering Notebook (PEN) HW peripheral (I/O Devices) analysis packages Devices: QADC64, TPU3, MIOS Tool integrations >> The all-important glue. JRS Fill-in-the-gap Tool Developments • MATRIXx / MATLAB >> generic application description format (ADF) • ADF >> PERTS • ADF >> CGS • ADF >> Peripheral Analyses • ADF >> RTOS Library (OSEK Sysgen) • ADF >> I/O Driver Library • System Libraries >> tools, GUI • PERTS >> Tradeoff Matrix • CGS >> Diab tool suite • CGS >> SDS SingleStep Debugger • SDS >> Motorola EVB • HW test bench >> EVB >> HW test bench • PEN >> MATLAB >> PEN • PEN >> Performance Analysis >> PEN

  8. Intro to ASDEN and PEN features Current tools are mixture of full functional and conceptual capabilities. End-to-end run 6-8 tools to reflect methodology flow Data objects: 4 cylinder ECU spark & fuel strategy Motorola PowerPC for automotive sector (MPC555) Motorola Real-time operating system (OSEKOS) Demonstration Scenario

  9. PEN and ASDEN Scenario Interactions Documentation PEN Requirements Page ASDEN System Modeling Matlab Executable Spec PEN Simulation Page Test Vectors Sim. Results ASDEN Code Synthesis System Wire Harness Report PEN Implementation Page Test Vectors (voltages) ASDEN Target Validation Real-time Results PEN TPU Analysis Page Expected Results Real-time Results

  10. ASDEN Main Panel -- Process Flow

  11. Features -- Library Browsers

  12. Features -- Compiler Options • Compilation Tools for embedded microcontrollers are extremely complex, as a rule. • Diab Data’s compiler, assembler, and linker have over 200 options. • The slightest tweak on a compiler command line can have drastic performance and memory effects. • ASDEN uses 3 separate configurations for I/O drivers, operating system, and application code compilations. • ASDEN provides recommended defaults.

  13. Reusable strategy with ASDEN high level API ASDEN-provided MATLAB and MATRIXx palette of engine control input/output blocks. Enables ease of model development and retargetable code generation. Step 1: Executable Requirements Modeling

  14. Step1: ASDEN Simulink Processing Builds Upon the MATLAB Environment Model Control Block GUI ASDEN m-file Model Manipulation Simulink Library IO Block Library RTW File Test Harness Model ASDEN TLC Standard TLC MDL File Tasking info for CGS target specific code generation RTW C Source for Application functional code

  15. Step1: Modeling Paradigm Helps to Structure Application Designs for Test and Validation • Application model is constructed within a testing harness • A Subsystem is designated by the user to be the application • Surrounding blocks are assumed to be part of the test harness • An ASDEN Model Control Block manages this relationship • All model IO is performed by ASDEN IO blocks • For Simulation, the model is structured such that • Data is passed into the Sensor block inputs as raw ‘voltage’ signals • Actuator block actions may be monitored on their output ports, which pass the data values sent to underlying actuator driver calls • For code generation purposes, sensors and actuators become data sources and sinks • Sensors obtain data directly; their inputs effectively disappear • Actuators do not output values; the driver calls terminate the data flow

  16. Step2: Validate Strategy against Requirements • Utilize JRS Paperless Engineering Notebook • ASDEN example includes pages for: • ECU requirements documentation • Strategy Test Plan • Validation through simulation • Integrated Simulink simulation launch and data extraction • Validation through implementation (EVB execution)

  17. Step 3: System Design Configuration • User’s must configure reusable library elements in order to create new system designs. • Compiler Options • Application Model • Platform Model • System Mapping • Target Definitions provide a basket for all necessary data to get embedded s/w running on target platforms automatically. They support configuration management and requirements traceability.

  18. Analysis Refers to Schedulability of Processing Automotive applications are more generally categorized as Real-Time systems System correctness depends on valid computations, but also that they are done in time, or the system has failed Processors and smart peripherals have processing assigned to them or tasks to perform Many MPC555 peripherals have micro-schedulers and kernels that make them CPUs in their own right The idiosyncrasies of the peripherals require custom analysis The basic issue to analyze is whether the interaction of the core and peripheral tasks will allow them to meet application timing deadlines Step4: Performance Analysis

  19. ASDEN Support of the Spark/Fuel Strategy Identified Core and Peripherals Needs MATRIXx and MATLAB models enhanced to use ASDEN I/O blocks I/O blocks handle sensor inputs and actuator outputs Provides functional processing, e.g. convert sensor voltage to engineering units Provides tie-in to peripherals and SW drivers Mapping to candidate peripherals on the MPC555 QADC64 for analog to digital conversion of inputs TPU3 for event monitoring and actuator control Core processor for functional model execution Generated code divided into angle and time driven tasks RMA based techniques used to form analysis of peripherals and core Step4: Performance Analysis (cont)

  20. Step 4: System Performance Analysis & Estimation

  21. The TPU is a highly programmable peripheral Provides users with a great deal of flexibility At the same time, lots of decisions with little guidance on how to apply or setup the device for an application Two key elements allow ASDEN processing to automatically program the TPU3 Definition of an application SW Architecture or usage model in which to apply the device This provides some of the device settings in the form of SW drivers Worst Case Latency (WCL) based Analysis provides key to determine the rest The remaining device parameters are determined by analyzing the operation of the device from an Rate Monotonic Analysis (RMA) point of view Relationships between the channel processing are set to guarantee meeting application deadline requirements Step 5: TPU3 Peripheral Analysis & Programming

  22. Step 6: Automatic Code & Load Module Synthesis • User must identify the following inputs: • High level behavioral requirements model • High level API implementation • I/O Driver Library • Retargetable platform selection • Platform-specific initializations & optimizations • Compilation options • Output: Production-intent full implementation software load modules.

  23. Code Generation System: Execution Model … Fuel Control OBD ASDEN Angle Event Scheduler Spark Control Tasks High Level API OSEK Scheduler … … Global Variables ECT MAP Set Spark Sync 10 deg 100 ms Events INIT ISRs ECT ISR MAP ISR Low Level API Eng Pos ISR System Timer ISR Configuration Commands Interrupts Hardware peripheral devices: TPU, QADC, ... Sensors Actuators … ECT Sensor MAP Sensor Spark Control Fuel Control Eng Pos Sensor

  24. CGS: Reusable Strategy Key -- High Level API • Removes system designer from microcontroller-dependent implementation details • Independent of microcontroller and peripheral hardware, but dependent on specific sensor/actuator components. • Intended to provide a complete interface between the application functionality and the hardware. • Enables ability to Bridge the Gap automatically • Pure system level design to production-intent implementation • User interface is a predefined library of API function blocks used to build the application model. • Used in same manner as libraries supplied by tool vendor. • Initial implementation is for both MATLAB and MATRIXx; portable to other tools.

  25. CGS: High Level API (continued) • Implementation of API utilizes I/O driver low level API provided by Motorola’s Powertrain Systems Division • JRS created an initial version of a High Level API for use in ASDEN. • Defines functions such as: • float Get_ECT(); /* Get engine coolant temperature in degrees C */ • float Get_TP(); /* Get throttle position as percent of full throttle */ • status Set_Spark(float stop_angle, float dwell, int cyl); /* Set spark */

  26. Step7: Real-Time Verification

  27. What are we going to see? 4-cylinder spark & fuel strategy modeled in both MATRIXx and MATLAB Test vector requirements management and flow down for simulation and implementation Strategy evaluated on several platforms via a Performance Analyzer Automatically generated production-intent implementation Motorola PowerPC 555, OSEK 2.0 operating system Real-time execution of the code on an evaluation board Demonstration Summary

More Related