Embedded Systems Hardware/ Software Co-Development

Embedded Systems Design Embedded systems’ hardware and software cannot be designed entirely independently Embedded software often runs on a system-on-chip (SoC) Numerous design challenges Tightly integrated components developed across numerous organizations Strict non-functional and QoS requirements (performance, power consumption, etc.)

Mobile Device Hardware and Software Multiple SoCs Multiple processors and subsystems on each SoC Multiple software stacks Multiple OSs

Example: Qualcomm MSM8960 SoC

Hardware and Software Layers

Example: Android Software Stack “Android” is only the top of the stack Below Android is a Hardware Abstraction Layer (HAL), the Linux kernel, and device drivers

Example: Android Telephony Stack Radio Interface Layer (RIL) abstracts upper software layers from baseband drivers and hardware Baseband runs on an RTOS on a separate processor

Example: Android Network Services

Embedded System Design Starting software development ASAP expedites overall development schedule

Cost to Repair Software Defects

Prototype Requirements Application developers HAL/driver developers System architects Hardware verification engineers HW/SW validation engineers Prototype goals Refine SW requirements and design Refine interfaces and design Trade-off HW and SW; analyze resource usage Precise timing accuracy; model the impact of software Make sure HW and SW works as specified Prototype requirements Early availability; speed over accuracy Early availability; detailed register interfaces; accuracy over speed Early availability; accuracy over speed Accuracy over speed; reuse test benches Balance of speed and accuracy

Embedded System Prototypes Due to the high NRE cost of mask sets for chip development and the significant impact a product delay can have on the return on investment (ROI) for a project, most companies demand the use of prototyping prior to silicon tape-out to ensure first-time-right silicon development. The electronics industry is today using several types of prototypes during the design flow. SDK: app developers Virtual platform: system architects, HW/SW validation engineers, app developers, HAL developers RTL: HW verification engineers

Types of Virtual Prototypes Architectural virtual prototypes For architectural analysis, performance validation Designed to answer very specific questions Will this cache be big enough? Will this interconnect provide enough bandwidth for a specific traffic scenario? Software virtual prototypes For software development, debug, validation, and test Designed to provide logging and visibility for software debugging Architectural:

Example: Android SDK

Prototype Tradeoffs RTL simulation and virtual prototyping for verification engineers Speed and accuracy Emulation/acceleration and virtual prototyping for SW developers and HW/SW validation engineers

Transaction-level Modeling Cycle-accurate (CA) Approximately timed (AT) Loosely timed (LT) TSM: representing transactions flowing within the system instead of individual bus cycles, or specific pins and wires, and thus achieving higher simulation speeds. LT: These transactions include representations of address decoding and control registers for elements such as bus bridges and arbiters. AP: Approximate bus models that add arbitration, pipelining and concurrency details.

Industry Design Chain System OEMs are the actual interface to the consumer, using the network providers like Vodafone and T-Mobile as their channel. Semiconductor houses provide the silicon, including reference design kits, to the system houses. The software programmers are split among semiconductor houses, system houses and ISVs. Programmers in the semiconductor houses and IP providers are traditionally more focused on lower-level drivers and kernel, while the ISVs and system houses actively use middleware and application software as their differentiator.

Scenario-Driven Dynamic Analysis of Distributed Architectures 11/9/2018 Scenario-Driven Dynamic Analysis of Distributed Architectures George Edwards gedwards@usc.edu Sam Malek malek@usc.edu Nenad Medvidovic neno@usc.edu Computer Science Department University of Southern California

Presentation Outline Introduction and Background 11/9/2018 Presentation Outline Introduction and Background Architecture Description Languages Model-Driven Engineering Software Architecture in the MDE Context Extensible Modeling Environments Model Interpreter Frameworks The eXtensible Toolchain for Evaluation of Architectural Models (XTEAM) Discussion of Key Capabilities Remaining Research Challenges November 9, 2018

Background - ADLs Architecture Description Languages (ADLs) 11/9/2018 Background - ADLs Architecture Description Languages (ADLs) Capabilities: Capture crucial design decisions Can be leveraged throughout the software development process Shortcomings: Rely on rigid formalisms Focus on structural elements Lack support for domain-specific extensibility Chart is taken from Medvidovic et al., A Classification and Comparison Framework for Software Architecture Description Languages November 9, 2018

Background - MDE Model-Driven Engineering (MDE) 11/9/2018 Background - MDE Model-Driven Engineering (MDE) Combines domain-specific modeling languages with model analyzers, transformers, and generators Domain-Specific Modeling Languages (DSMLs) Codify domain concepts and relationships as first-class modeling elements Metamodels define elements, relationships, views, and constraints Model interpreters leverage domain-specific models for analysis, generation, and transformation November 9, 2018

11/9/2018 High-Level Approach November 9, 2018

11/9/2018 Extensible Modeling Environment Capturing Domain-Specific Architectures Key Challenges: Development of ADLs is inherently difficult Combining extensibility with formal semantics Solution: Codify ADLs as metamodels ADL composition enables the combination of constructs from multiple ADLs within a single model ADL enhancement allows the definition of new, customized ADL constructs Reuse of existing ADLs maximizes the potential for reuse of the tool infrastructure. Incremental language extensions enable a specific architectural analysis technique. November 9, 2018

Model Interpreter Framework Implementing Architectural Analyses 11/9/2018 Model Interpreter Framework Implementing Architectural Analyses Key Challenge: Transforming architectural models into analysis models requires a semantic mapping (interpretation) that is often difficult to define and implement Requires expertise in modeling languages, software architecture, and the relevant domain Solution: Utilize a model interpreter framework Transforms architectural models into executable simulations Provides hook methods that an architect implements to realize an analysis technique i.e., logic that performs analysis calculations and records measurements Hides the details of the semantic mapping from the architect No need to understand how the simulation model is constructed and executed November 9, 2018

Application Simulations 11/9/2018 The XTEAM Tool-chain XTEAM employs a metaprogrammable graphical modeling environment (GME) XTEAM composes existing general-purpose ADLs: xADL Core (structures and types) and FSP (behavior) GME configures a domain-specific modeling environment with the XTEAM ADL Architecture models that conform to the XTEAM ADL are created XTEAM implements a model interpreter framework The XTEAM ADL is enhanced to capture domain-specific information The XTEAM Model Interpreter Framework is utilized to implement simulation generators Application simulations execute in the adevs discrete event simulation engine Simulations operate on the information captured in ADL extensions to perform scenario-driven analysis GME Metamodeling Environment GME Metamodeling Paradigm GME Domain-Specific Modeling Environment XTEAM ADL XTEAM Model Interpreter Framework adevs Simulation Engine XTEAM Simulation Generators Application Simulations XTEAM ADL Metamodel XTEAM Architecture Models xADL Structures and Types Finite State Processes ADL Extensions Application Architectures Energy Consumption Analysis Reliability Analysis End-to-end Latency Analysis Memory Usage Analysis Scenario-driven Analysis Results November 9, 2018

Scenario-Driven Dynamic Analysis 11/9/2018 Scenario-Driven Dynamic Analysis Allows the architect to rapidly investigate the consequences of design decisions in terms of their impact on non- functional properties Results depend heavily on the environmental context (e.g., the load put on the system) May contain elements of randomness and unpredictability (e.g., the timing of client requests) The set of scenarios to be simulated should include high-risk situations and boundary conditions XTEAM Simulation Generators Generator Information Required Analysis Provided Latency task and process execution times for each required interface, the response time for each invocation Reliability failure probabilities and recovery times time and type of failures and an overall component reliability metric Energy consumption computational and communication energy costs energy consumption of each component and host over time Memory usage memory required by each task amount of memory being used on each host over time November 9, 2018

Example: Energy Consumption Estimation 11/9/2018 A computational energy cost is incurred when a component’s interfaces are invoked Interfaces are classified and parameterized according to energy consumption profile A communication energy cost is incurred when data is transmitted over a wireless network Depends on data size, network bandwidth, etc. November 9, 2018

11/9/2018 Key Capabilities XTEAM provides a quantitative means for software architects to… …provide design rationale “Using a peer-to-peer architectural style for System X will result in greater scalability.” …weigh architectural trade-offs “Increasing the reliability of Service Y will incur an increase in latency.” …evaluate off-the-shelf component assemblies “The set of components selected will meet system energy consumption requirements.” …test and validate systems incrementally “The prototype of Component Z is not behaving as expected.” November 9, 2018

Providing Design Rationale 11/9/2018 Providing Design Rationale Client-Server Architecture Architects rely on intuition and experience to make important decisions early in the design phase What architectural style to use How to allocate functionality among subsystems What types of connectors to use XTEAM allows architects to rationalize such decisions with experimental evidence Model confidence level: Low Peer-to-peer Architecture Potential Workload Comparison of latency  P2P achieves greater scalability November 9, 2018

Weighing Architectural Trade-offs 11/9/2018 Weighing Architectural Trade-offs Nearly all architectural decisions come down to trade-offs between multiple desirable properties Emphasis on one system property may yield diminishing returns XTEAM allows architects to evaluate design alternatives in terms of their impact on multiple non-functional properties Model confidence level: Medium Decreases response time Replication of components Consumes more battery power November 9, 2018

Evaluating COTS Assemblies 11/9/2018 Evaluating COTS Assemblies Contemporary large-scale distributed systems contain numerous off-the-shelf components Detailed information about the behaviors and properties of individual components may be known Component assemblies may exhibit unforeseen behavior due to subtle interactions between constituent components XTEAM allows an architect to determine the emergent properties of a composed system Model confidence level: High Determination of emergent properties Off-the-shelf components Highly accurate parameterization November 9, 2018

Incremental System Validation 11/9/2018 Incremental System Validation Individual component implementations may become available in a piecemeal fashion XTEAM allows architects to Immediately incorporate component implementations into a simulated system, increasing the accuracy of analysis results Rapidly test individual components in the context of a wide variety of operational scenarios Model confidence level: High Component implementation available Invoke implementation from behavior model Integrated simulation and test environment November 9, 2018