Simics as a Tool for Embedded Research

1. Simics as a Tool for Embedded Research Andreas Moestedt

2. Background

3. What is Simics? Simics is a high-performance, full systemsimulator used by software developers to simulate large and complex electronic systems. • Simulate any size of target system • Run unmodified binaries • Other use cases as add-ons Any target system Any target system Simics allows you tobreak the rules of embedded systems development

4. Simics History

5. Some Example Simics Users

6. Why Use a Simulator?

7. Common Feedback from Users

8. Compare to Hardware

9. Speed? Really? • Embedded processors slower than server ones • Almost host speed for x86 on x86 (VMP) • Complex systems often boot slowly • Waiting for slow hardware, mandatory timeouts • Clearing memory • Hardware self-tests • Lots of idle time in parallel systems • Simics can fast forward when system is waiting! • Loading SW on real system: • Program flash memory, load over network or USB • Loading SW on Simics: • Load binary directly into target memory in no time • Checkpointing • No need to reboot every time

10. Increasing Value of Simics

11. Complexity Moves, Simics Stays Simics use Mobile Embedded Telecom Servers Server in 1998 - Mobile device today! 2010 1998

12. Simics Features

13. Some Simics Features and Capabilities • High performance • Synchronized System Stop • Save/restore of simulated state • Repeatability • Dynamic reconfiguration • Large systems, hundreds of processors • Runs all software unmodified • Windows, Linux, VxWorks, Hypervisor, etc • Heterogenous systems • Run simulation in reverse • C/C++ debugging • Code coverage • Trace generation • Non-intrusive inspection • Real-world connections • Hardware-in-the-loop • Record/replay of user input • Connections to hardware emulators • Gear shift to cycle accurate models • Host virtualisation for native IA performance • Binary translation for cross target simulation • Synchronize virtual time with external tools • Modeling language for fast development • Models in any language • DML, C/C++, SystemC, Python • Large collection of model interfaces • User developed simulator features • Integrates with external tools • Scripting for automated sessions • Operating System awareness • Process tracking • Instruction and data profiling • Supported, stable, well-documented API • Cache modeling • Advanced memory breakpoints • Distributed simulation • DHCP, DNS, FTP, TFTP services • Connections to remote debuggers • E.g. GDB • IP-XACT import/export • Import of SystemC models • Build kit for system panels • Huge model library

14. Highlight of a Few Features • High performance • Synchronized System Stop • Save/restore of simulated state • Repeatability • Dynamic reconfiguration • Large systems, hundreds of processors • Runs all software unmodified • Windows, Linux, VxWorks, Hypervisor, etc • Heterogenous systems • Run simulation in reverse • C/C++ debugging • Code coverage • Trace generation • Non-intrusive inspection • Real-world connections • Hardware-in-the-loop • Record/replay of user input • Connections to hardware emulators • Gear shift to cycle accurate models • Host virtualisation for native IA performance • Binary translation for cross target simulation • Synchronize virtual time with external tools • Modeling language for fast development • Models in any language • DML, C/C++, SystemC, Python • Large collection of model interfaces • User developed simulator features • Integrates with external tools • Scripting for automated sessions • Operating System awareness • Process tracking • Instruction and data profiling • Supported, stable, well-documented API • Cache modeling • Advanced memory breakpoints • Distributed simulation • DHCP, DNS, FTP, TFTP services • Connections to remote debuggers • E.g. GDB • IP-XACT import/export • Import of SystemC models • Build kit for system panels • Huge model library

15. Identical platforms Synchronized System Stop Chassis and Racks Interfaces: • Backplane • RapidIO • PCI-express • shared memory Network hubs & switches Connection to the World Multicore Boards Mixed Architectures Dedicated Subsystems

16. Identical platforms Without Simics: A Single Component may stop … Chassis and Racks Interfaces: • Backplane • RapidIO • PCI-express • shared memory Network hubs & switches Connection to the World Multicore Boards Mixed Architectures Dedicated Subsystems … but the rest of the system continues to run

17. Identical platforms … or a Single Component Stops … Chassis and Racks Interfaces: • Backplane • RapidIO • PCI-express • shared memory Network hubs & switches Connection to the World Multicore Boards Mixed Architectures Dedicated Subsystems … and the whole system crashes. But where is the bug?

18. Identical platforms Simics: Synchronized System Stop Chassis and Racks Interfaces: • Backplane • RapidIO • PCI-express • shared memory Network hubs & switches Connection to the World Multicore Boards Mixed Architectures Dedicated Subsystems … the whole system freezes in an operational state

19. Identical platforms Taking a Check Point Chassis and Racks Interfaces: • Backplane • RapidIO • PCI-express • shared memory Network hubs & switches Connection to the World Multicore Boards Mixed Architectures Dedicated Subsystems

20. Identical platforms Resume From Same State Later Chassis and Racks Interfaces: • Backplane • RapidIO • PCI-express • shared memory Network hubs & switches Connection to the World Multicore Boards Mixed Architectures Dedicated Subsystems

21. Systems Take Time to Boot • Windows 7 boots in about 1 minute on Simics • Windows 7 is restored from a checkpoint in about 1 second • Some of our customers’ systems takes almost 30 minutes to boot (on real hardware). • Add to this, loading application, running to interesting points etc…

22. RepeatabilityTraditional Hardware Run 1 • Physical systems are not wholly predictable or controllable • The system will usually follow a slightly different path from start to finish • Some runs will hit bugs, others will not.

23. RepeatabilityTraditional Hardware Run 2 • Physical systems are not wholly predictable or controllable • The system will usually follow a slightly different path from start to finish • Some runs will hit bugs, others will not.

24. RepeatabilityTraditional Hardware Run 3 • Physical systems are not wholly predictable or controllable • The system will usually follow a slightly different path from start to finish • Some runs will hit bugs, others will not.

25. RepeatabilityVirtual Platform Run 1 • Simics virtual platforms are predictable and controllable • The system will follow exactly the same path from start to finish • Every developer will precisely duplicate every execution step

26. RepeatabilityVirtual Platform Run 2 • Simics virtual platforms are predictable and controllable • The system will follow exactly the same path from start to finish • Every developer will precisely duplicate every execution step

27. RepeatabilityVirtual Platform Run 3 • Simics virtual platforms are predictable and controllable • The system will follow exactly the same path from start to finish • Every developer will precisely duplicate every execution step

28. RepeatabilityVirtual Platform Run 4 (new stimuli) • New stimuli can be injected to ensure different paths • Random paths can be generated

29. Non-Intrusive Inspection • Processor and device registers • Internal hardware state • Software on the target

30. OS Awareness & Non-Intrusive Inspection

31. Simics Use Cases

32. Develop SW Before HW is Ready • Most typical Simics use • Lots of success stories • But far from the only use case • SW team can work in parallel with HW team • System bring up in days instead of months Customer: “Software bring up on real hardware was ready three months earlier than in previous projects”

33. Always Have Working Software • Start with a Simics model of the old system • Replace one part at a time • Adapt OS and drivers to each replaced part • Gradually transform model into new system • Requires good coordination between teams!

34. Easily Reconfigurable Hardware • Easy to reconfigure and replicate hardware • Vary the number of disks, processors, etc • PCI boards in different slots • Network topology • Memory configurations (min, max) • Test software with all hardware configurations • Run in parallel on server farms • Everything scriptable • Save time it takes to configure real hardware

35. Easily Reconfigurable Hardware • Test large expensive configurations • Keep configurations for regression testing Customer: cluster of 200+ networked storage systems, more than the test group had access to

36. Develop SW for Fault Tolerance • Inject errors in the model • Lost network connections • Corrupt packets • Disks that stop responding • Memory errors • Simple to script and control in Simics • Can be very difficult to test on real hardware • Easy to track down issues once triggered in Simics

37. Post Silicon OS Development • Example: Multi-pro support added to RTOS • Scripts in Simics that verify proper locking without changing the target software • Driver development • Simics devices tell developers what is happening • Real devices are silent • Port of OSes to new hardware Customer: “All development now on Simics. Real hardware only used for release testing.”

38. Catch Hard-to-Find Bugs • Use simulator unique features to find bugs • Non-intrusive insight in complete system • Repeatability • Unmodified software • Reverse execution • Combine with standard debug features • Source level debugging • OS awareness

39. Verify Correct Programming of HW • Model can warn when software misbehaves • Drivers ported to new revisions of hardware • But still accesses removed or changed registers • “Undefined” may be defined in next revision • Example: Overlapping MMU mappings

40. Hybrid Simulation • Integrate a detailed model with Simics • Timing • Power & thermal • Run real workload on fast Simics model • Switch to detailed for interesting part • Only replace units of interest • Requires model specific work

41. Controlled Environment • Examine viruses, Trojans, cyber attack software • Run unmodified software • Full inspection capabilities • Sandboxed multi-machine environment

42. Simics in Academia

43. Background • Computer architecture research • Cache and memory hierarchies in MP systems • Add-ons • UW-Madison Multifacet GEMS • OOO processor models, memory hierarchies • CMU SimFlex • Timing-accurate processor, memory and interconnect • UIUC FeS2 • Timing-first multiprocessor x86 simulator

44. Academic Use • http://blogs.windriver.com/engblom/ • Blog posts about Simics • Information on Wind River academic program • Interviews with Simics users • Projects by interviewed researchers • Improved HW support for virtualization • Multicore partitioning for avionic systems • Fault injection in reliable embedded systems

45. Current Availability • Always been available at low or no cost • Wind River academic program • Simics 4.2, soon Simics 4.4 • ARM, PPC, SPARC V8, SPARC V9, X86 • Intel 440BX with several different processors • 486sx, Pentium II, Pentium 4, one x86-64 CPU

46. Simics from Intel • Will soon launch an academic Simics program • Simics 4.6, the most recent version • Intel based models • Intel X58/ICH10 system • Core i7 • Intel Tunnel Creek • Atom E600 SoC • ETA Late spring 2012 • More models to come