HardwareSoftware Codesign of Embedded Systems - PowerPoint PPT Presentation

Loading...

PPT – HardwareSoftware Codesign of Embedded Systems PowerPoint presentation | free to download - id: 26aa12-Yzk5N



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

HardwareSoftware Codesign of Embedded Systems

Description:

... Engineering techniques in designing complex HW/SW products ... been widely embraced, while practical solutions have yet to be ... the end application and ... – PowerPoint PPT presentation

Number of Views:348
Avg rating:3.0/5.0
Slides: 50
Provided by: voicu1
Learn more at: http://www.site.uottawa.ca
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: HardwareSoftware Codesign of Embedded Systems


1
Hardware/Software Codesign of Embedded Systems
  • Interface
  • System on Chip
  • Voicu Groza
  • School of Information Technology and Engineering
  • Groza_at_SITE.uOttawa.ca

2
Presentation Outline
  • Hardware-Software Codesign
  • HW-SW Interface
  • System-on-Chip

3
HW/SW CoDesign Utopian View
  • Codesign tools automatically produce an optimized
    design from some initial high level
    specification!!!????
  • Realistic goal to incorporate the support for
    shifting functionality and implementation between
    HW SW, with effective and efficient evaluation.
    The prototype is the output, based on currently
    available platforms (software compilers and
    commercial hardware synthesis tools).
  • Codesign does not aim to reinvent the wheel of
    system design, but the necessary flexibility must
    be effectively incorporated.

4
HW/SW CODESIGN
Classic Design
Applying Concurrent Engineering techniques in
designing complex HW/SW products
HW SW
HW SW
  • Combined
  • Concurrent
  • Cooperative
  • Unification

Design of HW/SW
5
HW/SW INTERFACES
Analysis of Constraints and Requirements
System Specification
Hardware/Software Partitioning
Hardware Description
Software Description
HW Synthesis Config
SW Generation Parameterization
Interface Synthesis
Config. Modules
SW Components
HW/SW Interfaces
HW Components
Hardware/Software Integration and Cosimulation
Integrated System
System Evaluation
Design Verification
6
HW/SW Interface
  • CFSM Events
  • Event Implementation
  • Synthesize Glue Between IPs

7
HW/SW Interface Synthesis
8
Synthesize Glue between IPs
A
B
Concrete IPImplementations
  • At system level, A and B are abstract
  • In implementation, A B are concrete
  • Concrete IP have different interfaces
  • May map to either HW or SW
  • To make IP integration effective, must
    synthesize interface

HW
IP
A
B
OR
SW
A
B
9
Synthesize glue between IPs
Abstract IP
A
B
Concrete IPImplementations
HW
IP
A
B
OR
SW
A
B
10
A Vision for System Design
USB
Proc
Proc
ASIC
System Bus
Wireless
DSP
Memory
11
HW/SW Interface
  • Three classes of partitioned CFSMs
  • SW mapped to software
  • HW mapped to hardware
  • MP mapped to micro-controller peripherals
  • RTOS functions
  • Enable communication between SW-CFSMs and
    SW-CFSMs, HW-CFSMs, MP-CFSMs
  • define emits and detects using
  • memory,
  • I/O ports and
  • interrupts
  • Coordinate SW - CFSMs
  • keep track which SW-CFSMs are ready to execute
    decide which one to execute

12
Events SW to SW
  • For every event, RTOS maintains
  • global values
  • local flags

x
CFSM2
x
emit x( 3 )
detect x
CFSM1
CFSM3
x
3
13
Events SW to SW
  • Implement atomicity by double buffering
  • always read from frozen
  • others always write to live
  • at the beginning of task execution, switch

CFSM
frozen
live
14
Event Implementation
  • SW to HW
  • allocate I/O port bits for value and occurrence
    flag
  • write value to I/O port
  • create a pulse on occurrence flag
  • SW to/from MP
  • use emit, detect functions from the library

15
Events HW to SW
  • Event can be polled or driving an interrupt
  • For polled events
  • allocate I/O port bits for value, occurrence and
    acknowledge flags
  • generate the polling task that acknowledges and
    emits all polled events that have occurred
  • For events driving an interrupt
  • allocate I/O port bits for value,
  • allocate an interrupt vector,
  • create an Interrupt Service Routine that emits an
    event

16
Interfaces among Partitions
  • Automatically generated in both HW and SW (RTOS)
  • Hardware standardized strobe/data protocol
  • (corresponding to the event/value primitive)
  • Allows one to use hand-designed modules
  • (following the interfacing convention)

17
Example of Interface HW to SW
ack
HW
SW
HWtoSW
x
y
- 1 / 0
(11 0 -) / 0
x
- 0 / 1
y
1
0
ack
1 0 / 1
x ack / y
18
Events Interrupts
R T O S
X
IRQ
X
HW-CFSM
SW-CFSM
  • Two user-selectable choices
  • Minimize blocking for other tasks and ISRs
  • ISR()
  • emit x
  • Minimize latency for this event
  • ISR()
  • emit x
  • execute SW-CFSM

19
HW/SW Interface Architecture
SW
HW
address bus
HW-gtSW intr. event
irq
bus prot. conv.
we
HW-gtSW polled event, value
mC
oe
decoder/mux
SW-gtHW event, value
data bus
20
Micro-controller peripherals
  • Custom HW (fully programmable, expensive)
  • On-chip or off-chip peripheral (partially
    programmable, inexpensive)

A/D
CPU
RAM
Timer
EPROM
I/O ports
21
Peripheral modeling approach
  • Ideally implement specified function using
    peripherals (if possible)
  • Currently use three models
  • Behavioral (Ptolemy) model for co-simulation
  • CFSM model for RTL co-simulation and rapid
    prototyping
  • C model for implementation (programming and
    interfacing with the peripheral)
  • Parameters customize all models simultaneously
  • (plug-in replacement of abstraction levels)
  • Synthesizable CFSM model key to limited
    re-targetability

22
Peripheral modeling approach
  • The user must
  • decide in advance which functions may need to be
    implemented on a library peripheral
  • choose the best fitting model from a library
  • co-simulate to decide implementation
  • (SW, custom HW, peripheral, )
  • The co-design environment takes care of
  • synthesizing in SW or HW
  • extracting peripheral programming SW from library
  • (may be partially micro-controller independent)
  • interfacing transparently

23
Communication synthesis
Mapping of Behavior to Architecture
Behavioral Description
Architectural Description
Functional Prototype
Co-Simulation
24
Communication Infrastructure
  • Designer maps
  • processes to processors and
  • messages to busses/protocols

Message1
Net / Message1
software library
25
System on a Chip
  • Rationale
  • Typical SoC
  • Core-Based Design

26
Systems-on-chip
  • Started with the idea of integrating all
    components in a board into a single chip.
  • In the last 20 years the technologies
    implementing embedded systems evolved from
    microcontrollers and discrete components to fully
    integrated systems-on-chip (SoC)
  • SoCs and related technologies are the engines of
    embedded systems in the foreseeable future.
  • To increase the productivity for future designs,
    the approach of reusable components was adopted
    intellectual property cores (IPs).

27
Why SoC?
  • System architects cannot afford design restarts.
  • HW and SW design teams cannot afford n design
    iterations or to learn all the details about
    every potential IP core.
  • System managers cannot afford to reinvest in
    completely new tools.
  • IC business managers cannot afford missing
    customer market windows or foundry schedules.
  • Industry shifts from ASICs to systems-on-a-chip.

28
SYSTEM-ON-A-CHIP (SOC) Rationale
  • Industry shifts from ASICs to systems-on-a-chip,
  • New concepts, such as design re-use, Intellectual
    Property (IP) utilization, and system-level
    co-design have been widely embraced, while
    practical solutions have yet to be developed.
  • System architects cannot afford design restarts.
  • Hardware and software design teams cannot afford
    endless design iterations or to learn all the
    details about every potential IP core.
  • EDA system managers cannot afford to reinvest in
    completely new tools.
  • IC business managers cannot afford missing
    customer market windows or foundry schedules.

29
SoC Architecture
  • Heterogeneous processors
  • those used to run the end application and
  • those dedicated to execute specific functions
    that could have been designed in hardware.
  • Application-specific Intellectual Property (IP)
    cores
  • Communication interconnect.

30
SOC Design
  • Language-independent methodology for system
    specification
  • Accurately capture a concept into an
    architecture-independent specification
  • Easy definition of blocks and modules
  • Facilitate concurrent execution of blocks
    separate the behavior and communication of those
    blocks.
  • Provides the ability to animate the system
    specification and validate/debug the required
    product functionality prior to costly design
    implementation.
  • The specification allows existing modules, with
    different abstraction levels, to be re-used.
  • A complete test bench, for checking the system,
    is developed at this stage.
  • Open SystemC community recommends to using C and
    C

31
Optimal SOC Design-to-Implementation
ProcessTop-Down Design Flow
  • design (capturing and animating the system
    specification),
  • co-design
  • hardware/software partitioning
  • interface design
  • co-simulation
  • co-implementation (design refinement in parallel
    and co-verification)
  • IP re-use.

32
SOC Co-Design
  • Different architectures (such as processor cores
    ARM, DSP) are selected for possible
    implementation, to explore various HW/SW
    partitioning tradeoffs.
  • Select the corresponding communication mechanisms
    (memory mapped I/O, fast interrupt request etc.,)
    for a given target core
  • Generate the corresponding software device
    drivers and the corresponding hardware glue logic
    to allow for quick exploration of different
    partitioning schemes.
  • System verification at different abstraction
    levels.
  • Un-timed models
  • Instruction accurate models
  • Bus cycle accurate models
  • Virtual prototype at the earliest stage of design
    gt faster simulation. Traditional
    hardware-software co-verification with the
    hardware in HDL code running in an RTL simulator

33
SOC Co-Implementation
  • Once the HW/SW partitioning is agreed to, the
    different SW development teams and HW design
    teams work in parallel to further optimize the
    software and gradually refine the hardware while
    constantly remaining consistent with the original
    system specification.
  • Changes in SW are communicated to the HW team and
    resultant changes in the HW are made. The
    converse should be true for HW originated
    changes.
  • The output of the HW portion is synthesizeable
    RTL and the process flow therefore allows
    co-verification of HW and the actual binary code
    of the software running on a model of the
    processor core.
  • IP re-use at all levels (silicon IP, gate level
    IP, RTL IP)

34
SYSTEM-ON-A-CHIP (SOC) Design Forms
  • vendor design
  • partial integration
  • desktop design

SOC Vendor Design
  • An ASIC vendor or a design services group designs
    the core and ASIC to meet a customers functional
    specification.
  • Gives the system designer little or no control
    over the design schedule and may result in a
    longer time to market and less design flexibility
  • Can lead to the lowest production cost per die
  • May result in high engineering costs, to be used
    for high-volume applications.

35
SOC Partial Integration
  • The system designer creates most or all the ASIC
    gates, and the ASIC vendor designs and integrates
    the core with the customers ASIC logic.
  • Provides a more flexible division of labor, and
    the system designer has some control over the
    design schedule.
  • Dominant approach in the past

SOC Desktop Design
  • Gives the system designer the most flexibility
    and enables the fastest time to market
  • The ASIC vendor designs the core, and the system
    designer builds the ASIC logic and integrates the
    core, using a standard ASIC design flow.
  • The ASIC vendor is no longer the design schedule
    gatekeeper.
  • This approach incurs the lowest engineering cost
    and is suitable for lower-volume solutions.

36
Intellectual Property (IP) Cores
  • Hard cores are provided as black boxes, usually
    in layout form in a given technology and with an
    encrypted simulation model. Examples of hard
    cores are microprocessors, phase-locked loops
    mixed signal blocks.
  • Firm cores are provided as a synthesized netlist
    in a hardware-description language (HDL), that
    is, after logic synthesis and technology mapping,
    but without layout information. These cores can
    be simulated and changed if necessary.
  • Soft cores are given as register-transfer level
    HDLs, and the user is responsible for its
    synthesis and layout. Usually along with the soft
    cores, the IP providers also supply synthesis and
    layout scripts and timing assertions.

37
Types of Cores
  • Synthesizable core
  • Soft core
  • Firm core
  • Hard core
  • Comes in a technology-independent high-level
    description language form.
  • The cores lay-out is completely flexible, but
    its speed and density are limited by the
    characteristics of the ASIC cell library in which
    it is implemented.
  • Require ground-up synthesis, test, static timing
    analysis, and user verification.
  • Their flexibility limits their drop-in design
    usability and their ability to leverage
    performance and area optimization characteristics.

38
  • Synthesizable core
  • Soft core
  • Firm core
  • Hard core

Types of Cores
  • Is a technology-dependent gate-level netlist.
  • May include a small amount of high-level
    technology-independent code that a designer can
    use to parameterize the core during synthesis.
  • Because of the cores technology-dependent
    nature, its size and speed are more predictable
    than those of synthesizable cores.
  • The soft cores layout is flexible, but
    floor-planning guidelines may be necessary to
    achieve performance targets.

39
  • Synthesizable core
  • Soft core
  • Firm core
  • Hard core

Types of Cores
  • Comes in the form of an encrypted or abstracted
    black box that protects the cores intellectual
    property content.
  • Designers incorporate a firm core into an ASIC
    design (in the same manner as a library element).
  • The ASIC vendor lays out the core, using a
    technology-dependent gate-level netlist. This
    provides flexibility in the chip layout process
    because the core form factor is not fixed.
  • A firm cores size, aspect ratio, and pin
    location can be changed to meet a customers chip
    layout needs, and floor-planning guidelines
    assist the chip designer in making trade-offs.
  • The technology-specific nature of a firm core
    makes it highly predictable in performance and
    area.
  • Because layout uses a gate-level netlist, a firm
    core has the same routability as a soft core.

40
Types of Cores
  • Synthesizable core
  • Soft core
  • Firm core
  • Hard core
  • Is an encrypted or abstracted black box, which
    designers incorporate into an ASIC design in the
    same manner as a standard cell library element.
  • Have a fixed, custom physical layout.
  • The technology-specific layout allows maximum
    optimization in terms of performance and density.
  • Have the most limited vendor portability and
    greatest difficulty of reuse when moving to a new
    process technology.
  • May contain significant routing blockages (poor
    porosity), making the placement of other blocks
    and chip-level routing difficult.

41
IP-Based Design of Implementation
Which Bus? PI? AMBA? Dedicated Bus for DSP?
Which DSP Processor? C50? Can DSP be done
on Microcontroller?
Can I Buy an MPEG2 Processor? Which One?
Which Microcontroller? ARM? HC12?
How fast will my User Interface Software run?
How Much can I fit on my Microcontroller?
Do I need a dedicated Audio Decoder? Can decode
be done on Microcontroller?
42
Issues Limiting SOC Ramp
  • Economics
  • Productivity
  • Process
  • IP Delivery Reuse
  • Tools Methodology
  • Manufacturing

How do we move SoC Design from the pilot line to
production ?
SourceM.Pinto, CTO, Agere
43
Validating Designs
  • By construction
  • property is inherent.
  • By verification
  • property is provable.
  • By simulation
  • check behavior for all inputs.
  • By intuition
  • property is true. I just know it is.
  • By assertion
  • property is true. Wanna make something of it?
  • By intimidation
  • Dont even try to doubt whether it is true
  • It is generally better to be higher in this list

SOURCE Alberto Sangiovanni-Vincentelli,University
of California at Berkeley
44
State-of-the-Practice
  •  DSP Tools develop algorithms by creating and
    simulating block diagrams, and most generate C or
    HDL code Matlab from Mathworks Inc., Signal
    Processing WorkSystem of Cadence Design Systems,
    COSSAP from Synopsys.
  • State Diagram Entry Tools support system-level
    block diagram entry and simulation, Statemate
    Magnum/i-Logix, Stateflow/Mathworks HDL
    Simulators, Verilog-XL Leapfrog VHDL of
    Cadence Design Syst, VCS and VSS from Synopsys,
    MTI from Mentor Graphics.
  • Software Development Tools (IDE) compilers, real
    time operating systems, and various tools used to
    enable simulation and debugging with the
    instruction set simulator of the processor
    (WindRiver, ARM, etc.)
  • Co-Verification Tools of what have been already
    completely designed CoWare N2C, Eaglei from
    Synopsys, Seamless CVE from Mentor Graphics,.  

45
CANADIAN MICROELECTRONICS CORPORATION
Rapid-Prototyping Platform
46
Home Networking
SOURCE Alberto Sangiovanni-Vincentelli,University
of California at Berkeley
47
Conclusions
  • Computer-aided SW/HW Engineering (CASHE)
    framework/tools still under construction
  • Current combination of EDA/CAD tools
  • are too slow gt distributed systems
  • have incompatible formats gt too many translators
  • First integrated EDA environments for dedicated
    SoC applications
  • Codesign will become reality as soon as corporate
    entities recognize its full benefits

48
THE Conclusion
  • HW/SW Codesign for Embedded Systems is a cut
    paste technology
  • To fit these parts in the big picture, one has to
    understand them, i.e., to know
  • Electronics,
  • Logic design,
  • Computer architecture,
  • Software engineering.

49
Problem atomicity of transition
TASK 1 detect x detect y
TASK 2 emit x
TASK 3 if detect x then emit y
  • TASK 1 detects y AND NOT x, which is never true
  • To avoid, need atomic detects
About PowerShow.com