Download VLSI_Lecture01-SW-HW Co

Outline
Lecture 1: Embedded System Design
(HW-SW Co-Verification)
Lecture 2: OpenRISC-Based Embedded
System Design
Introduction to Embedded System and
SoC
System-Level Design Approach
HW-SW Co-Verification
Introduction
Introduction to OpenRISC
OpenIDEA
Practice
(1)
Embedded System Design
(HW-SW Co-Verification)
March. 2007
Dynalith Systems
www.dynalith.com
Embedded system and SoC (1/2)
An embedded system is a specialpurpose system in which the computer is
completely encapsulated by the device it
controls.
Unlike a general-purpose computer, such
as a personal computer, an embedded
system performs one or a few pre-defined
tasks, usually with very specific
requirements.
Characteristcs
Single-functioned: Executes a single
program, repeatedly
Tightly-constrained: Low cost, low power,
small, fast, etc.
Reactive and real-time: Continually reacts
to changes in the system’s environment;
Must computes certain results in real-time
without delay.
Introduction
System-on-a-chip (SoC or SOC) is an idea of
integrating all components of a computer or
other electronic system into a single chip.
It may contain digital, analog, mixed-signal, and
often radio-frequency functions – all on one chip.
A typical application is in the area of embedded
systems.
SoC = A complex IC that integrates the major
functional elements of a complete end-product
into a single or chipset (from ‘Surviving the
SOC revolution’)
Single chip or integrated chipset (designed
together)
Integrates the major functional elements of a
complete end-product (system)
Usually incorporates a programmable processor,
on-chip memory, and accelerating function units
implemented in hardware
Interfaces to peripheral devices and/or the real
world. Often incorporates analog/mixed-signal
(AMS) components
May include opto/microelectronic mechanical
system (O/MEMS) components
(3)
Embedded system and SoC (2/2)
Application
Application
Real-Time Operating System
Special
Function
block
Control
Processor(s)
SoC
Embedded System
Memory
system
Data
processing
Processor(s)
On-chip
Peripherals
network
Peripherals
Introduction
(4)
System-level design approaches
Top-down approach / Application-driven
Orthogonalization of concerns:
Separate Implementation from
conceptual aspects
Separate computation from
communication
Formalization: precise unambiguous
semantics
Abstraction: capture the desired system
details (do not over-specify)
Decomposition: partitioning the system
behavior into simpler behaviors
Successive refinements: refine the
abstraction level down to the
implementation by filling in details and
passing constraints
Introduction
Bottom-up approach / Technology-driven
IP reuse
Platform architecture from pre-existing
library
Meet-at-middle approach
Platform-based
Functional design and architectural
mapping
(5)
Top-down design approach
System
Spec.
HW-SW
Co-Design
HW IP
System
Design
SW IP
HW/SW
Partitioning
Functional
Verification
HW-SW
CoVerification
Software
Verification
HW
Development
SW
Development
HW refinement
(UT->T->RTL)
SW refinement
(RTOS
mapping)
Gate
Final code
Gate-Level
Verification
Introduction
(6)
Bottom-up approach (1/2)
Introduction
(7)
Bottom-up approach (2/2)
Frame or skeleton is a system consisting
of blocks which are required to run a
software.
Platform is a pre-designed architecture
that designers can use to build SoC for a
given range of applications.
Flash
SDRAM
ARM7
ISS
ARM
DMA
Flash
SDRAM
Memory
controller
LCD
controller DCT/IDCT
PIC
RAM
Memory
controller
PIC
AHB-APB
LCD
AHB
AHB
AHB-APB
BFM
CCD
interface
Timer
VLD
DMA
CCD
APB
APB
GPIO
UART
GPIO
USB
Introduction
(8)
Timer
USB
Meet-at-middle approach
Functional design and architectural mapping
FDCT
quantizer
entropy
encoder
entropy
decoder
JPEG
Dequantizer
Source image data
IDCT
Re-constructed image data
MEM
P
On-chip-network
Bluetooth Device
Link
Manager
Test bench
Bluetooth link
controller
Synch
control
Transport
Decode
Behavioral/functional design
ARM7TDMI
(CPU)
Memory
Rate buffer
Video
decode
Rate buffer
Audio
decode/
output
Frame buffer
Video
output
Memory
Set-to box behavior
Architectural design
RTOS
RTOS
Memory
User/Sys
control
Rate buffer
Mapping
Bluetooth link
controller
Shared bus & memroy architecture
uP
Adopted from ‘System-on-a-chip verification’ – P. Rashinkar et.al.
Introduction
Memory
Transport
Decode
Audio
decode/
output
Vidie
decode
Video
output
Adopted from ‘Surviving the SOC revolution’ – H. Change et.al.
(9)
Hardware design in general
Logic (RTL) design
Logic simulation
Logic debugging
RTL code
(Verilog)
Logic synthesis
iPROVE compilation
Placement & routing
iPROVE
RTL code &
FPGA
library
RTL code &
Target
library
Netlist &
Gate delay
(SDF)
GDSII &
Test-vector
Logic synthesis
Placement & routing
FPGA
bit-stream
iNTUITION
Logic synthesis
FPGA
Debugging
Netlist
(EDIF)
Gate-level simulation
Gate-level debugging
Placement & routing
Timing simulation
GDSII
Timing analysis
Semiconductor fabrication
Introduction
( 10 )
How to verify the
hardware in the
context of software?
Software design in general
Develop board
or training
board
JTAG-based
Compiler
Source-level
debugger
Profiler
What if development board is
not available?
Introduction
( 11 )
Hardware/Software Co-Verification
System on Chip (SOC)
Trend toward greater system integration, such as the demand for low-cost, highvolume consumer products
A single chip that includes one or more microprocessors, application specific custom
logic functions, and embedded system software
Hardware/Software co-verification
Addressing one of the most critical steps in the embedded system design process,
the integration of hardware and software
Becoming a verification technique used by more and more engineers
Allowing projects to be completed in shorter time and with greater confidence
Introduction
( 12 )
Commercial Co-Verification Tools
Eaglei  Viewlogic
Eagle Design Automation  Synopsys
System Studio
Synopsys
Seamless CVE
Mentor Graphics
The most successful for the commercial co-verification tools
V-CPU
Cisco Systems
MaxSim
AXYS Design Automation  ARM
ConvergenSC
CoWare
Introduction
( 13 )
Benefits of Co-Verification
Both hardware and software teams benefit from co-verification.
Early access to the hardware design for software engineers
Allowing software that is dependent on hardware to be tested and debugged before a
prototype is available
Additional stimulus for the hardware engineers
The early software test provides an additional test stimulus for the hardware design.
Project Schedule Saving
Traditionally, software engineers suffer because they have no way to execute
the software they are developing if it interacts closely with the hardware design.
Co-verification addresses the problem of software waiting for hardware by
allowing software engineers to start testing code much sooner.
Introduction
( 14 )
Project Schedule Saving
Project schedule without co-verification
Requirements
Architecture
HW Design
HW Build
SW Design
HW/SW Integration
SW waiting for HW
Project schedule with co-verification
Requirements
Architecture
HW Design
HW Build
SW Design
HW/SW Integration
Time Savings
Project Time
Introduction
( 15 )
Benefits of Co-Verification
Providing Visibility
Able to see exactly the correlation between hardware and software
Not only useful for debugging, but even more useful in providing a way to
understand how the microprocessor and the hardware work
Providing information to identify bottlenecks in performance using bus activity or
cache hit rates
Improving Communication
Many companies separate hardware and software teams to the extent that each
does not really care about what the other one is doing, a kind of “not my problem”
attitude.
Co-verification improves communication between the hardware and software teams
Introduction
( 16 )
Hardware/Software co-development environment
Verify hardware using real software.
Verify software in the context of hardware.
Executable image of
the application
software
MEM
BFM
ISS
Processor
model in C
Cross-compiler
Hardware model
Application
program
Target
dependent
library
Simulator
Introduction
( 17 )
ISS program
Cross compilation
Cross compiler is a program in a host
computer and generates executable
codes for the target machine.
Build machine is the machine the toolchain is being built on.
Host machine is the machine the toolchain programs (compiler, linker,
assembler, and so on) will run on.
Target machine is the machine the toolchain builds programs for.
Cross compiler is a compiler that builds
programs for a machine different than the
one the compiler is run on.
It runs the result of cross-compiled program.
Cross
compiler
source
Compiler
User
program
in C
Cross
compiler
Executable code
for target
machine
P
Build machine
Host machine
Introduction
Target machine
( 18 )
ISS: Instruction Set Simulator
Instruction set simulator (ISS) is a
program that runs on a host machine to
executes target machine programs by
simulating the effects of each instruction
on the target machine.
Used for the following areas in the past
As a reference model for processor
design
As a processor model for computer
architecture analysis, such as cache study,
network traffic, and so on.
As a processor model for software
development prior to silicon or board.
ISS is a software program (environment)
which reads microprocessor instructions
and simulates its execution.
Application
ISS
(S/W)
A program
in ARM code
ISS
ARM ISS
in Pentium code
Host
machine
PC Pentium
Windows
Used for hardware-software codesign/co-development at the present
ISS
(S/W)
Introduction
Memory
model
( 19 )
H/W
HDL
simulator
C Simulation
Limited availability of platform
Co-verification using logic simulation requires a logic simulation license for each software
engineer.
Most companies have only one or two such machines that must be shared by verification
engineers and software engineers
C or C++ simulation environment
To eliminate the need for logic simulation
Moreover, C simulation is faster then logic simulation
HDL to C translation
Tool are now available to take the Verilog and VHDL code and turn it into a C model by
translating it into C or SystemC.
It generates cycle-based C code, but it is not clear.
VCS logic simulator
High performance of C model
The only way to gain higher performance of C or SystemC simulation is to raise the abstraction
level of the model.
Engineer can make an abstract model in about 1/10 the time it takes to develop an RTL model
and the model should run 100 or 1000 times faster in a C or SystemC environment.
Introduction
( 20 )
Methods from software programming perspective (1/2)
Memory model
Peripheral model
GDB
ISS
Peripheral model
Peripheral model
Memory model
Peripheral model
GDB
ISS
BFM
Peripheral model
Peripheral model
ISS simulation with SW
debugging
HDL simulator
Memory model
GDB
ISS & HDL simulation with
SW & HW debugging
Processor
model
Peripheral model
Peripheral model
Peripheral model
HDL simulator
HDL simulation with SW & HW
debugging
ISS: Instruction-set simulator
HDL: Hardware description language
GDB: Source-level debugger from GNU
BFM: Bus functional model
Introduction
( 21 )
Methods from software programming perspective (2/2)
GDB
Processor
model
Memory model
Peripheral model
Peripheral model
Peripheral model
HDL simulator
FPGA (iNCITE)
USB 2.0
FPGA & HDL simulation with SW & HW
debugging
GDB
Processor
model
Memory
model
Peripheral
model
Peripheral
model
Peripheral
model
FPGA (iNCITE)
USB 2.0
FPGA prototype with SW debugging
FPGA: Field programmable gate array
USB: Universal serial bus
iNCITE: FPGA board with host interface through USB (Dynalith Systems)
Introduction
( 22 )
Host-Code Mode with Logic Simulation
Modeling
Processor model: Native compiled software
Hardware model: Logic simulator such as HDL simulator or hardware-based simulator
Communication channel between two model
Inter-Process Communication
IPC message passing or shared memory for different host process mapping in a workstation
Socket for different workstation mapping
Abstracted messages for communication
C API and Bus Functional Model
Host Software Debugger
Native
Compiled
Software
C
API
Inter-Process
Communication
(IPC or Socket)
Abstracted messages
(Read, Write, Interrupt)
BFM
Logic Simulation
with
Hardware
Design
Host-code execution with logic simulation
Introduction
( 23 )
ISS with Logic Simulator
Processor Modeling with ISS (target-code mode)
More realistic simulation of target processor architecture such as cache, MMU, exception handler, etc.
Able to understand the context of the bus transactions better
In host-code mode, all bus transactions are considered to a single bus transaction.
Slower than host-code mode
Communication modeling with C API and BFM
Transaction-based Interface
Cannot simulate the details of port signals of processor
Software debugging
Not a host debugger, but rather a debugger that can work with the ISS with cross-compiled target code.
Target Software Debugger
ISS
C
API
Inter-Process
Communication
(IPC or Socket)
Abstracted messages
(Read, Write, Interrupt)
BFM
Logic Simulation
with
Hardware
Design
Host-code execution with logic simulation
Introduction
( 24 )
ISS with Logic Simulator
Cycle-based interface instead of the transaction-based interface
Cycle-accurate simulation of bus transactions
Exchanges pin values between the ISS and logic simulator on every bus clock cycle.
Moving the bus functional model state machine into the ISS
Target Software Debugger
ISS
C
BFM
Inter-Process
Communication
(IPC or Socket)
Bus Signal Values
HDL
Bus
Shell
Logic Simulation
with
Hardware
Design
Host-code execution with logic simulation
Introduction
( 25 )
RTL Model of CPU with Software Debugging
RTL model of processor running on logic simulators
Hard macro
Used without revealing all of the source code of the design
Soft macro
Synthesizable Verilog or VHDL
Offer better flexibility and eliminate portability issues in the physical design and fabrication process
Low simulation speed
All system is totally inside the hardware execution engine.
A simulation environment for a large SoC typically runs less than 100 cycles/sec.
It is not possible to use a software debugger to perform interactive debugging.
Acceleration
Simulation acceleration and emulation systems are capable of running at much higher speeds.
A few hundred KHz up to 1 MHz
Possible to interactively debug software running on the RTL model of processor
Introduction
( 26 )
RTL Model of CPU with Software Debugging
Software debugging
A software debugger must be able to communicate with the CPU RTL.
To debug software programs, a software debugger requires only a few primitive operations to
control execution of a microprocessor.
Read and write registers and memory
Single step and continue execution
Stop, exit
gdb
Gdb provides an interface and specification called the remote protocol interface that
implements a communication channel between the debugger and the target CPU.
Target Software Debugger
( gdb configured for
the target processor )
Application
C code
Inter-Process
Communication
(UART, Socket)
gdb remote protocol
gdb stub
RTL
CPU
Logic Simulation
with
Hardware
Design
gdb connected to the RTL code of the microprocessor
Introduction
( 27 )
Evaluation Board with Logic Simulation
The microprocessor evaluation board can serve a similar purpose as the ISS.
Each is running independently without synchronization or correlation between the two time
domains of the board and the logic simulator
Since most boards have networking support, a socket connection between the board and the
logic simulator can be developed.
It is most appealing to software engineers since the performance of the board is very good.
Needs customization
The drawback is the need to add custom software to the code running on the CPU board to
handle the socket connection to the logic simulator.
Microprocessor
Evaluation
Board
Inter-Process
Communication
(Socket)
Bus Transaction
(read/write)
BFM
Logic Simulation
with
Hardware
Design
Microprocessor evaluation board with logic simulation
Introduction
( 28 )
In-Circuit Emulation
JTAG connection to microprocessors on emulation system
There is a trend for the IP vendors to provide RTL code to the user for the purposes
of simulation and synthesis.
Most cores used in SoC design today support some kind of JTAG interface for
software debugging.
JTAG debugger
and probe
JTAG connection
Serial bitstream
RTL
CPU
core
Emulation System
with
Hardware
Design
JTAG connection to an emulation system
Introduction
( 29 )
In-Circuit Emulation
Microprocessor test chip + emulation system
Useful for hard macro microprocessor IP such as the ARM7TDMI that cannot be mapped into
the emulation system
JTAG debugging can also be done by connecting to the JTAG port on the chip.
CPU core runs at the speed of the emulation system.
Cycle-accurate lock-step simulation
Able to model the system exactly
Able to run faster using emulation technology for long software tests and regression tests
Target Software Debugger
JTAG connection
CPU Chip
on a board
Emulation System
CPU
with
Shell
Hardware
Design
Signal Values
JTAG connection with test chip and emulation system
Introduction
( 30 )
In-Circuit Emulation
Emulation system with PCI speed bridge
Application : verification of a chip that connects to the PCI bus
Software engineers are developing device driver for OS such as Windows or Linux.
Use a PC to test the software
The emulation system provides a PCI board that plugs into the PC.
PCI speed bridge bridges the speed differences between the real speed of the PCI bus in the
PC (33 or 66MHz) and the slower speed of the emulator.
Host Software Debugger
PC running
Windows or
Linux
PCI
speed
bridge
board
Cables
PCI Signal
Values
HDL
PCI
Shell
Emulation System
with
Hardware
Design
PC
Emulator
Test chip and emulation system
Introduction
( 31 )
Co-Verification Metrics
Performance (speed)
Accuracy
Synchronization
Type of software to be verified
Ability to do hardware debugging (visibility)
Ability to do performance analysis
Specific vs. general-purpose solutions
Software only (simulated hardware) vs. hardware methods
Time to create and integrate models: bus interface, cache, peripherals, RTOS
Time to integrate software debug tools
Pre-silicon compared to post-silicon
Introduction
( 32 )
Performance and Accuracy
Performance
The number one objection to co-verification from software engineers
Cycles/sec or instructions/sec
Every vender will say that performance is “design dependent”, but with a good understanding
of co-verification methods it is possible to get a good feel for what kind of performance can be
achieved.
Accuracy
The number one concern of hardware engineers
How is the model verified to guarantee it behaves identically to the device silicon?
Does the model contain complete functionality, including all peripherals?
Is the model cycle accurate?
Are all features of the bus protocol modeled?
Can performance data be gathered to ensure system design meets requirements?
Will the model accurately model hardware and software timing issues?
Introduction
( 33 )
An example SoC development environment
OpenRISC-based SoC/embedded system
development environment
Software development with OpenIDEA
Integrated SoC development environment based on
open source hardware and software
OpenIDEA for software development
GUI-based software studio
iNSPIRE-Lite for iNCITE
SoC hardware generation
environment
Project Management
C/ASM Editing
SW Compiling
Debugging
Hardware development with iNSPIRE-Lite
Building SoC hardware
Exporting synthesis script
Exporting simulation project
Exporting emulation project
Software-hardware
co-simulation/emulation
OpenIDEA for
SW/HW co-simulation
SW/HW co-simulation/co-emulation/prototyping with
OpenIDEA
OpenIDEA for
SW/FPGA coemulation
SW/HW co-simulation using ISS and HDL simulator
SW/HW co-emulation using ISS and iNCITE
Prototyping and SW debugging
HDL simulator
Hardware prototyping board
iNCITE as FPGA and memory board
iNCITE-AVREM as application board
Introduction
( 34 )
FPGA on the
iNCITE
References
Co-verification of Hardware and Software for ARM SoC Design (Embedded
Technology) by Jason Andrews, Newnes
Essential Issues in SOC Design: Designing Complex Systems-on-Chip,
Chapter-7, SOC PROTOTYPING AND VERIFICATION, by Moo-Kyoung Chung,
et al., 2006, Springer.
Enhancing Performance of HW/SW Co-Simulation and Co-Emulation by
Reducing Communication Overhead, IEEE Transactions on Computers, 2006,
Moo-Kyoung Chung, Chong-Min Kyung
“Embedded System Design: A Unified Hardware/Software Introduction”, Frank
Vahid and Tony Givargis, John Wiley & Sons; ISBN: 0471386782. Copyright (c)
2002.
Introduction
( 35 )