1. Embedded Systems Hardware/ Software Co-Development

2. 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.)

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

4. Example: Qualcomm MSM8960 SoC

5. Hardware and Software Layers

6. 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

7. 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

8. Example: Android Network Services

9. Embedded System Design
Starting software development ASAP expedites overall development schedule

10. Cost to Repair Software Defects

11. 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

12. 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

13. 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:

14. Example: Android SDK

15. 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

16. 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.

17. 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.

18. Scenario-Driven Dynamic Analysis of Distributed Architectures
11/9/2018
Scenario-Driven Dynamic Analysis of Distributed Architectures
George Edwards
Sam Malek
Nenad Medvidovic
Computer Science Department
University of Southern California

19. 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

20. 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

21. 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

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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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