QUO VADIS, SLD? REASONING ABOUT THE TRENDS AND CHALLENGES OF SYSTEM - - PowerPoint PPT Presentation
1 QUO VADIS, SLD? REASONING ABOUT THE TRENDS AND CHALLENGES OF SYSTEM LEVEL DESIGN Alberto Sangiovanni-Vincentelli Presentation by Michael Zimmer September 21 st , 2010 Current Problems 2 Exponentially rising complexity in circuits and
1
Exponentially rising complexity in circuits and
Functionality Verification Time-to-market Productivity Safety and Reliability
Can traditional design flows (i.e. RTL) continue to
Embedded Systems more intricate
2
Raise level of abstraction
For chips, this means going above RTL
60% productivity increase? (International Technology
New levels of design reuse Need new “design science” for embedded system
System Level Design
3
Heterogeneity and Complexity of the Hardware
Exponential complexity growth
Transistors on a chip Expanding use of embedded systems More networking
Custom hardware implementations costly
Design reuse?
Looks more like a system (integrating predesigned components)
4
Embedded Software Complexity
Reconfigurable and programmable hardware
1+ million lines of code in cell phone 100+ million lines of code in automobiles
Embedded software requirements stricter
Continuously react with environment Safety and reliability
How to verify?
Tens of lines per day
5
Integration Complexity
Top-down approach?
Requires knowledge of entire system for efficient
Integration of predesigned or independently designing
Need some way to standardize integration of components
6
Industrial Supply Chain
Health and efficiency essential System design needs to be supported across entire
Integration of tools and frameworks from separate
Information flow between companies Can more efficiently meets demands (safety, cost, etc)
Who benefits?
7
Application Developers Sell software directly to customer or come bundled with service
provider
Service Providers Access to network infrastructure Device Makers Manufacture cell phones with significant software content and
hardware integration
IP Providers Provide components to design chain Outsourcing Companies Manufacturing, design, etc
8
Boundaries under stress
SIM cards
Cell phone locked to service provider, but cell phone can
Standards
Not locked to one IC provider, IC provider can provide to
Unified methodology and framework favors
9
Car Manufactures (OEMs)
GM, Ford, Toyota Provide final product
Tier 1 Suppliers
Bosch, Contiteves, Siemens Provide subsystems
Tier 2 Suppliers
Chip manufacturers, IP providers
Manufacturing Suppliers
Not as common for safety and liability reasons
10
Sharing IP and standards could improve time-to-
AUTOSAR, world-wide consortium, has this goal in mind
Hard real time software hard to share
Can’t just add tasks and not affect behavior New, strong methodology needed that can guarantee
Would cause restructuring of industry
Plug and play environment results in better solutions Tier 1 suppliers?
11
Design chains should connect seamlessly Boundaries between companies are often not
Misinterpretations result in design errors
Optimization hard beyond one boundary
12
Current approaches address either software or
Software approaches miss time and concurrency Hardware approaches too specific for software Don’t address all challenges
13
Hardware and embedded software design as two
High levels of abstraction for initial design Effective architectural design exploration Detailed implementation by synthesis or manual
Platform
Reuse and facilitating adaptation of a common design
14
IC Domain
Flexible IC where customization is achieved by
FPGA, DSP, MPU, etc Can’t always fully optimize Xilinx Virtex II
FPGA with software programming IPs
Converging?
Semiconductor companies adding FPGA-like blocks FPGA companies adding hard components
15
PC Domain
Standard platforms have enabled quick and efficient
X86 Instruction Set Architecture Fully specified set of busses (USB, PCI, etc) Full specification of I/O devices
Allows hardware/software codesign
16
Systems Domain
Platform allow quick development of new applications Sharing subsystems
Common mechanical features on automobiles like engines,
17
Main Principles
Start at highest level of abstraction Hide unnecessary details of implementation Summarize important parameters of implementation
Limit design space exploration to available
Carry out design as sequence of refinements from
18
Platform
Library of components usable at current level of
Computational and communication blocks Characterized by performance and functionality Can have virtual components Platform Instance
Set of components selected with set parameters
Mapping functionality to architecture
Important to keep separate
19
Meet-in-the-middle process
Top-down: Map functionality into instance of platform
Bottom-up: Build a platform by choosing components
Mapping becomes new functionality
20
21
Partitioning of software and hardware is the
Platforms should restrict design space Establishing number, location, and components of
Precisely defined layers
Better reuse
22
23
Closely resembles Platform-Based Design Model-Driven Architecture
Platform-Independent Model Platform-Specific Models Interface definitions
Separation of function and platform
24
Vanderbilt University group evolved MDD for
Because a single modeling language not suitable for all
But how to define and integrate various models?
Interaction must be mathematically well characterized This allows model transformations
25
Is being adopted Well-defined layers of abstraction help supply
Designers do need to be trained in PBD and have
26
27
Need to capture at high level of abstraction without
Languages for Hardware Design
Attempts to raise abstraction levels SystemC
C lacks concurrency and notion of time Capture particular aspects of hardware Used for simulation (not directly synthesizable or verifiable)
SystemVerilog
Extend Verilog (RTL) to higher abstraction level
28
Languages for Embedded System Design
Want higher productivity and correctness guarantees Synchronous Languages
Strong formal semantics to make verification and code
Esterel, Lustre, Signal Safety-critical domain
29
Models of Computation
In traditional approaches, assumptions about
Want maximum flexibility while capturing design Mathematically sound representations Discrete Time
Flexible model
Finite State Machines
Less flexible, but easier to analyze and synthesize
30
Heterogeneous Models of Computation
Mixing models is not trivial Numerous approaches
LSV Model, Interface Automata Environments for capturing designs
Ptolemy II ForSyDe and SML-Sys Behavior-Interaction Priority Framework Signal Processing Worksystem Simulink LabVIEW
31
Needs to be represented to enable mapping of
Netlist that establishes how a set of components is
Capabilities should be included “Cost” needs to be computed
Time, Power, etc.
32
Software Architecture Description
Unified Modeling Language (UML)
Stresses successive refinement Graphical nature Too general? (difficult to express common programming
Profiles allow redefining for specific applications
SysML, Rational, Rhapsody, Tau
Eclipse
Integrated Development Environment
33
Hardware Architecture Description
Useful when providing model for performance and
Transaction Level Modeling
Levels of abstraction above RTL, can it do better?
Assembly Tools
CoWare, Synopses, Mentor, and ARM all exploring model
creation, integration, simulation, and analysis
Communication Based Design
Design of interconnect infrastructure and IP interfaces Network-on-Chip Global Interconnect becoming dominant
34
Hardware Architecture Description (cont)
Microprocessor Modeling
Embedded systems normally contain software
Tradeoff between speed and accuracy when modeling Examples
Virtual Processor Model C-Source Back Annotation Interpreted Instruction-Set Simulator Compiled Code Instruction-Set Simulator Worst Case Execution Time Estimation
35
Mapping functional description to hardware
Mismatch of models of computation
Asynchronous and synchronous If forced to be the same, restricts design space
Scheduling
For example, concurrent processes onto processor Static vs. dynamic
36
Correct-by-Construction Mapping – Giotto
Solve scheduling problem by forcing models of
Time-triggered architecture Separates platform independent functionality and
37
Automatic Mapping with Heterogeneous Domains
Needs to be a way to automate mapping process
Like logic synthesis
Need common mathematical language between
Tradeoffs in mapping
Granularity vs. Optimality
38
Unified framework for platform-based design Allows for different levels of abstraction and
Metropolis Meta-Model
Most models of computation and formal languages
Can be used to capture and analyze functionality, and
39
Functional Model
Functional netlist of a network of processes
Architectural Model
Architectural netlist is an interconnection of
Mapping
Mapping netlist instantiates both functional and
40
Tool Support
Allows for back-end tools for analysis Simulator
translates to SystemC
Verification Synthesis Easy to incorporate external tools
41
Related Work
None support all the requirements of PBD Polis System
Co-Design Finite State Machines Limitations of target architecture and model of computation
VCC Artemis Workbench Mescal CoFluent Studio Simulink-Based Flows
42
Goal: Map algorithm efficiently onto a
Modeling and Design Space Exploration
Architecture-independent model of JPEG Encoder in
Processor modeled in Metropolis
Design Space Exploration and Results
Tried different mapping scenarios Simulation close to actual implementation
43
Platform-Based Design is a unifying design
Promising achievements so far, but work still to be
Better understand relationships in heterogeneous
More efficient algorithms and tools More models must be developed Industry must embrace new paradigms Academia must develop new curricula
44