4. 4
Debugging Challenges
• Limited visibility into hardware
• Single debug port, multiple processors
• High-speed, concurrent execution
• Timing-sensitive chaotic behavior
• Small changes in timing can radically alter
system behavior
• Hardware variations can impact software
behavior
• Lack of determinism
• Re-running a program with different results
• Hard to reproduce bugs
• “Heisenbugs”
• Altered behavior when inserting probes to trace
behavior
• System keeps running even if one core stops
5. 5
• Instrumented code
changes behavior too
much
• Multi-core bugs are
sensitive to timing
changes so may be
difficult to recreate
• It is hard to get at
internal hardware
structures
Traditional Debug
Approaches Don’t Work
Well
6. 6
• Parallelism required to gain performance
• Parallel hardware “Easy” to design
• Parallel software hard to write
• Fundamentally hard to grasp true concurrency
• Complex software environments
• Legacy software assumes single-processor
• Might break in new and interesting ways
• Multitasking not guaranteed to run on
multiprocessor
• Difficult issues for software developers
• Additional tool support required
• Early access physical hardware often not the best
development platform
Migration Issues
7. 7
Imagine If You Could…
Reduce your
time-to-market by 66%.
Reduce your debug
time by 35%.
Reduce your development
target costs by 45%.
• Have target hardware for
every team member.
• Try out several hardware
options before you
committed to one.
• Equip sales, marketing, and
tech support with
inexpensive targets.
• Debug software before
hardware existed
• Explore new silicon choices
before silicon existed.
• Integrate and test your
system before the system
existed.
• Enable agile and iterative
development
• Easily manage large
systems-of-systems.
• Easily debug large
systems-of-systems.
9. 9
What is Wind River Simics?
Wind River Simics is a full system simulator used
by software developers to simulate the hardware of
large and complex electronic systems.
• Simulate any size
of target system
• Run unmodified
target binaries
Simics allows you to break the rules of embedded product development.
Wind River
SimicsAny
Target
System
10. 10
Simulate Any Size Embedded System
Processor
and Memory
SoC Devices Complete Boards Complete Systems
and Networks
Devices,
Racks of Boards,
and Backplanes
System Complexity
CustomerValue
11. 11
Simics Transforms the Product Life Cycle
System
Definition
Platform
Customization
and
Stabilization
Deploy
and
Maintain
Application
Development
System
Integration
and Test
Time-to-Market
TCO
CapEx
OpEx
Reusable Assets Enable Agile
and Iterative Development
• Use virtual target for architectural analysis
• Pre-silicon architecture analysis using actual target software
• Legacy system upgrade analysis using actual target software
• Eliminate hardware availability and flaw issues
• Hardware and software co-development
• Develop target software before hardware is available
• Utilize virtual target instead of host-based development
• Advanced target hardware for everyone
• Easy collaboration among entire team
• Eliminate system availability issues
• Iterative and incremental integration and test
• Debugging at the system level
• Utilize virtual platform even after development is complete
• Maintenance of legacy products for five, 10, 20+ years
• Support of many different customer configurations
12. Simics Impact on Time to Market & Risk
• Simics shifts schedules left
• Enables agile & iterative development by parallelizing work
• Replace big-bang integration with incremental integrations
• Management & debugging of system of systems
12
13. REALITY: Everything Often Gated By Hardware
13
Pre-Silicon
Activities
Hardware
Prototypes
Production,
Manufacture
Start
Application
Development
End User
Documentation
& Translation
System
Integration
System
Test
Hardware
Development
Software
Development
Product
Requirements
Marketing /
Feature
Validation
Prototype H/W
Specifications
14. Simics Enables Agility
14
DevelopDefine Deploy
Systems
Integration
• Documents
• Demos
• Training
• Support
To
Ecosystem &
Customers
Multiple
Design
Spins
Architectural
Investigation
Firmware
• Boot code
• Diagnostics
• Drivers
BSP
Application
Development
Final Rev
HWArchitecture
Design
Product
Spec.
HW
Spec.
• Customers
• Partners
• Sales
• Support
• Marketing
SW
Spec.
15. 15
Simics Impact on Consolidation
Simics Model of
Legacy System
Simics Model of
Multi-core Design
OS
Firmware
OS
Firmware
Hypervisor
• Expedites consolidation
• Replace paper analysis with real software on both designs
• Reduce risks of moving to a new technology
• Evaluate impact on complete system
Application
Software
Application
Software
16. 16
Simics Impact on Costs
• Reduces CapEx, OpEx, and developmental costs
• Replace expensive labs with virtual labs
• Replicate, assemble, and configure large systems of COTS components
• Configure new systems-of-systems faster
Simics
17. 17
• Systems on every Engineer’s Desk
• Replace expensive system hardware with virtual systems
• Debug more efficiently at system-of-systems level
• Reduce number of iterations of physical prototypes needed
Simics Impact on Availability
Simics
18. Simics in Short
• Complete target simulation
• Runs OS, drivers, all other
software
• Models any system
• Processor, SoCs, FPGA, ASICs
• Multicore processors
• Multiple boards
• Multiple Networks
• Targets
• From single-core aerospace
systems
• ... to multicore network
processors
• ... to massive multiprocessor
servers
18
SimicsSimics
User application code
Host hardwareHost hardware
Host operating systemHost operating system
Virtual target hardware
Target operating system (s)
Middleware and libraries
20. System-Level Features
20
Checkpoint and restore Multicore, processor, board Real-world connections
Repeatable fault injection on
any system component
Scripting Mixed endianness, word
sizes, heterogeneity
con0.wait-for-string "$“
con0.record-start
con0.input "./ptest.elf 5n"
con0.wait-for-string "."
$r = con0.record-stop
if ($r == "fail.”) {
echo ”test failed”
}
21. Transporting bugs with Checkpoints
Virtual
platform
PP
D
The software user finds a
bug and needs to report it
to the developer.
A developer D creates a
piece of software and
passes it on for testing
and use
The developer and
software user are both
using the same virtual
platform to run software
The software user the virtual platform’s
checkpointing to pass the bug to the
developer. This ensures perfect
reproduction of the bug, as well as
complete communication of the target
state.
21
checkpoint
hardware configuration or reconfiguration
software package, load, or configuration
22. Session Comments and Recording
22
Comments in the timeline can
also be used to navigate to
that time when using reverse
execution
Starting a recording from
Eclipse – it can also be done
from scripts and the CLI
23. Fault Injection
• Examples
• Dropping packets on networks
• Injecting bad checksums
• Network partitioning
• Delaying hardware replies
• Transient memory corruption
• Permanent memory corruption
• Transient register corruption
• Permanent register corruption
• Data bus transmission errors
• Address bus transmission errors
• Triggering spurious interrupts
• Permanent subsystem failures
(disconnecting from system)
• Processor crash
• Temperature sensor reporting
overheating
• Error reporting registers flagged
23
• Simics target control
• Access any part of target
• Change any part of target state or
configuration
• Scripting for precise targeting and
replay of faults
• No permanent damage to target
• Purpose
• Test system-level fault handling
• Test fault low-level fault detection
• Model failing hardware
24. Scripting
• Simics command-line interface (CLI)
• Easy and powerful for the most common tasks
• Object-oriented, hierarchical naming of target components
• Supports loops, conditionals, and parallel script branches
• User can define custom commands using Python
• Simics integrated Python interpreter
• Access to Simics API, Python library, and host OS
• Full object-oriented programming environment
• Device models can be written in Python
• CLI and Python are fully integrated
24
26. Simics System Editor
• System editor
• Inspect
• Change
• Configure
• Reconfigure simulation
as it is running
• Add and remove
hardware units
• Connect and disconnect
units
• Shows hierarchical
system structure
26
27. Simics Device Register Viewer
• Inspect devices
• Registers
• Register banks
• Bit fields in registers
• Current value
• Documentation and
description strings
27
28. Hardware unit front panel
Simics System Panel
28
Simulation models
Simulation feature control
Target system state
Showing parts of state
now shown on physical
system front panel
Control panel for
simulation extensions and
features not directly part
of a hardware unit
Modeling lights and
displays and buttons
found on the front
(typically) of a real system
Showing parts of state now shown on physical
system front panel
30. Simics Debugging Features
30
Synchronous stop
for the entire system
Ultimate repeatability Reverse debugging
Unlimited and powerful
breakpoints
Trace everything Insight into all devices
break –x 0x0000 length 0x1F00
break-io uart0
break-exception int13
break-log “spec violation”
31. 31
Repeatability and Reverse Debugging
• Repeat any run trivially
• No need to re-run and hope for bug to reoccur
• Stop and go back in time
• No re-running program from start
• Breakpoints and watchpoints backward in time
• Investigation of exactly what happens each time
This control and
reliable
repeatability is
very powerful for
parallel code.
Discover Bug
Re-run: Bug Doesn’t Show Up
Re-Run: Bug Doesn’t Show Up
Rerun: Different Bug
Re-run: Initial Bug Occurs
Discover Bug
Reverse Execute and Find
Source of Bug
On virtual hardware, debugging is much easier.On hardware, only some runs reproduce an error.
32. Simulation executes forward from the state
Reverse execution in Simics
• Take periodic checkpoints of system state as we execute
• To go back to a point in time
• Go back to the closest checkpoint and execute forward
32
Simulation executes forward
Execute forward
Checkpoint
Logical time
Simulation time
Reverse
Execute forward
Restore to
checkpoint,
simulate
forward
33. Unparalleled Breakpoints
• Breakpoints are
unintrusive and do not
affect target state
• Code execution
• Data access
• No limits
• Virtual addresses
• Physical addresses
• Arbitrarily large areas
• Any number of breakpoints
• Processor exceptions
• Control register access
• Devices access
• Time
• Console output
• Network activity
• Task switches
• OS calls
• System event (haps)
• TLB, device action, …
• Simulation log message
33
34. Code is not just about CPUs
34
On a modern SoC, the processor
cores are just one part of the
system
Much application functionality is
implemented by using special
accelerators... and you need to debug
their interaction with the processors &
software
Simics can trace, log, and break on all
hardware activities. Devices can report
suspicious software actions and
violations of hardware programming
rules. Breakpoints on exceptions makes
debugging drivers and operating systems
much easier.
35. Fully-Featured Eclipse Debugger
35
Symbol browser lets you manage
debug symbols and search for
specific symbol names in the
debug information
Stop log shows you how you arrived
at the current point in time,
including actions performed and the
time change they resulted in
36. Debug at System Level
• Debug multiple target boards and
machines using a single debug
connection
• Synchronized system
• Global stop of target system
• Single-step any code, any where
• Reverse entire system
• Relative speeds of targets modeled
• Debug heterogeneous targets
• Different processor architectures
• Different operating systems
• Hypervisor, SMP, AMP, single-core
• Attach multiple debuggers to system
• Debug code through all layers of the
software stack, down to hardware
• Trace and log without effects caused
by instrumented code
36
37. Simics Analyzer
Demonstrating two different
ways to handle a hardware
device. The red alternative is
using a regular Linux device
driver and spends most of its
time in the kernel
The green alternative is
accessing the hardware directly
from user space using an
mmap() setup, leading to very
little kernel time (and better
latency).
Looking at different aspects of
the target system state, such as
hardware registers, device state,
and software threads running.
37
41. Evolve and Iterate the Virtual Platform
• Start with a virtual reference board or bare-bones system or QSP
• Change virtual platform contents as hardware design evolves
• Create new hardware versions faster & in less time
Virtual board
Virtual model of new SoC
CPU
Timer
PIC
UART
CPU
RAM
Virtual board
Virtual model of new SoC
CPU
Pattern
Matching
Timer
PIC
UART
Ethernet
Ethernet
CPU CPU
RAM
Flow control
Virtual board
Virtual model of new SoC
CPU
Pattern
Matching
Timer
PIC MC
UART
Ethernet
Ethernet
CPU
Crypto
Buffer
Memory
TCP
Offload
Buffer
Memory
CPU
RTC
RAM FLASH
Flow control
41
42. System
Simics follows Real-World Structure
• Simics models are built using the
same logical hierarchy of
components as the physical
system
• Fully supports systems of
systems, and multiple levels of
system packaging
• Easy for end users to manipulate
Board 1
Flash
Ethernet
PHY
SoC 1
DDR RAM
FPGA
PHY
CPU
CPU Eth Eth
PIC Time
Ser PCI
Board 2
Flash
PHY
SoC 2
DDR RAM
SCSI
CPU
Eth
Acc
PIC Time
Ser
PCI
HDD
System
Board 1 Ethernet Board 2
FPGA
Flash
DDRRAM
SoC 1
Eth link
PHY PHY
CPU complex
CPU CPU PIC
EthEth TimeSer PCI
etc…
42
43. Boards,
Networks,
Software loads
Systems,
Networks
Chips,
Subsystems,
IP blocks,
Memory maps
Devices,
Cores,
Interconnects,
Memories
System Configuration Levels
43
Rack 2
Board 1 Backplane Board 2
FPGA
Flash
DDRRAM
SoC 1
Eth link
PHY
CPU
complex
CPU CPU PIC EthUSB TimeSer PCI
Rack 1 Wide-area
network
System
DML, SystemC, C,
C++, ISS tools,
etc.
Simics components
Software Software
Simics scripts, Simics
scripts calling Simics
scripts
Simics components ,
Simics scripts
creating components,
Simics scripts adding
software
44. Modeling Support in Eclipse
44
DML editor
Execute model
unit tests
Browse and access
example code and
model skeletons
50. Simics API
• Wind River Simics 4.8 C++ Device API Programming Guide
• Wind River Simics 4.8 Model Builder User’s Guide
• Wind River Simics 4.8 Model Builder DML 1.2 Reference Manual
• Wind River Simics 4.8 Reference Manual
• Wind River Simics 4.8 Target API Application Note
• Wind River Simics 4.8 Extension Builder User’s Guide
• Wind River Simics 4.8 Hindsight User’s Guide
51
Simics exports two well-defined application programming interfaces (APIs)
based on C available in C/C++. One for device modeling, the Device API
and one for extending the simulator, the Simulator API. Almost all functions
in the C APIs are also available in Python, and there is a small Python-only
API in addition. There is also a Simics Eclipse API providing basic control of
a simulator session.
51. Simics CLI (Simics’ console)
The Simics Command Line Interface (CLI), provided as part of Simics
Hindsight, is an text based user interface with built-in help system,
context sensitive tab-completion (on both commands and arguments),
and scripting support which provides access to the Simics API using
Python.
The user interface of a Simics module consists of three parts: its
attributes, its interfaces, and the commands it adds to the Simics CLI.
The Simulation can also pass output to the CLI.
load-module is used to add a components’ commands to the CLI
52
• Wind River Simics 4.8 Hindsight User’s Guide
• Wind River Simics 4.8 Model Builder User’s Guide
• Wind River Simics 4.8 P502x0 Reference Manual (complete list of all CLI commands
defined by this package)
52. Simics Scripting
Simics has a built-in Python 2.6 interpreter that can be used for both
simple and more advanced scripting. The command line interface (CLI)
also supports writing simple scripts. Scripts can be triggered by events
in the simulated machine, called haps.
Scripts provide for –
• Definition and manipulation
• Print command return values to CLI console
• Control flow
• Integer conversion
• Accessing configuration attributes
• Script branching
Wind River Simics 4.8 Hindsight User’s Guide
Wind River Simics 4.8 Reference Manual
53