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