To observe relevant aspects of reality Fewer assumptions High computational workload

Transcription

1 On Simulation Jakob Engblom, PhD Virtutech & Uppsala University Simulation: Modeling + Execution Build a model of the system Try various scenarios on this model Experimental, not analytical approach Understand the real system by working with the model More available More inspectable Less dangerous 5 Simulation or Analysis Sufficient Level of Detail Simulation gets closer to real world Maintain sufficient details More details To observe relevant aspects of reality Fewer assumptions High computational workload Analytical models To avoid artifacts of experiment Abstract away unimportant aspects Newtonian vs. quantum physics Efficient predictors Low computational workload... but more removed from world=less accurate Timing vs. function Danger: bad abstractions = bad simulation 6 7

2 Scope versus Abstraction Example: Scope/Detail tradeoff Atom Simulating a single atom, we can use the incredible detail of quantom mechanics and string theory Galaxies Level of abstraction String theory Scope of model To simulate the universe, the units of simulation have to be galaxies The Universe Reasonable to simulate: scope proportional to abstraction GPL Life-like action: Momentum Friction Steering Engine torque Not nuts & bolts of cars Grand-Prix Legends 8 9 Simulation is never perfect Simulating Computers It is never quite the real thing......but it can be very close indeed 10

3 Simulating Computer Systems Simulating Computer Systems We need to decide the level of abstraction More detail = smaller scope Less detail = larger scope Size of systems that can be investigated Number of different systems Measure of scope: speed As number of software instructions per second Processor What do we need to simulate? Peripherals Stimuli Program Detailed Hardware Models Instruction-Set Simulation Transistor-level model Very close to actual implementation Small scope Small piece of HW Small programs Stimuli at bit level Speed: 100s of instructions per second With 25MUSD hardware: KIPS Necessary for hardware development Model computer at instruction set level Stable & defined interface The level where hardware & software meet Stimuli at transaction level Abstractions to increase scope: Keep functionality correct Vary fidelity in timing Simplify some behavior Speed: 10 KIPS to 100 MIPS 700 MIPS Key issue: there can be no software visible difference (including to the OS) 14 15

4 Sufficient Detail of Model Complete from a software perspective All readable values represented All registers of CPU implemented Software=OS, drivers, applications, middleware,... Hardware considered as a set of devices I/O-space or memory mapped Behavior at level seen by device drivers No abstract networks, all concrete Next slide: example of detail required Instruction-Set Simulation Full-System Simulation To run real workloads, you need Hardware: CPU & devices OS and other services Stimuli to feed them Common methods to achieve this Virtutech Simics Full-system simulation Virtualization User-level simulation One physical computer Virtual computer systems of many different types 18 19

5 Not Full-System Simulation Virtualization Full-System Simulation User program Virtualization system Middleware DB Servers Operating system Real OS & Software One physical computer Several virtual computers of the same type CPU RAM Disk Hardware Network GPU Device controller Simulated hardware Not Full-System Simulation Speed User-level simulation CPU User program Middleware DB Servers Operating system Real user program Simulated OS, services, some HW Depends of level of timing detail in model Slowest: cycle-accurate simulation Hardware timing modeled in great detail Fastest: emulation (user-level only) Sweet spot: somewhere inbetween Simics tries to hit this spot RAM Configurable level of detail Hardware 22 23

6 Speed Going up in Scope Detailed hardware sim accuracy cycle-accurate simulator (>10,000x) fast full-system simulation (20-400x) emulator (5x) Virtualization speed 10 KIPS 1000 MIPS Interesting systems are larger than single CPU Multiprocessors Homogeneous like servers Heterogeneous like mobile phones Distributed systems Local-Area Networks Embedded CAN buses Networks-on-chips = Simulated shared memory, networks Distributed Network Simulation Level of simulation Entire packets, not physical layer Simulate the network cards in nodes Spread simulation across multiple machines Necessary increase of speed Still, maintain determinism Synchronize simulated machines One machine stops, all machines stop Global checkpointing & restore Network Simulation Simulated network of simulated machines Interface to real network if needed Real network of physical machines 26 27

7 Simulation Advantages Simulation Advantages Configurability Simulate anything, Independent of available hardware Target architecture System configuration Availability Easy to copy setup, no manufacturing involved Determinism Removes real-world indeterminism Synchronization across machines and networks 29 Simulation Advantages Simulation Advantages Checkpoint & restart Save state of machine to reload later Parallelize & repeat runs Distribute fixed starting points Non-intrusive inspection & tracing Any events or state in the machine Does not affect running system IO events, hardware events Deep inspection of system state Caches, TLBs, registers, device registers, buffers... Sandboxing Completely walled-in No hidden communications Undo state changes Dangerous experiments possible Viruses, worms, buffer overflows, Magic instructions: Allows programs to communicate with outside 30 31

8 Peripherals HW/SW Cosimulation Program Integrated Systems Highly-integrated devices on the rise Develop HW & SW in parallel Simulate hardware and software together in development of entire system Bluetooth GSM Radio LCD driver Data mem CPU DSP Code memory 33 Big Systems & Small Details Transactions vs Pins To achieve speed: reduce level of detail To capture important effects: increase level Solution: model only parts at great detail Finished hardware can be modeled simply Model only what needs to be observed Mostly, no need for RTL-level understanding Transaction-level modeling: Model transactions as a unit Level of model: Memory read / Network packet send /... Only when something is activated Pin-level modeling: Model detailed electronics of a transaction Level of model: Individual pins Clocked pulsing of transmission pins Every clock cycle

9 Clocking vs Blocking Transactions/Events vs Pins/Clock Traditional hardware modeling: One (or two) step per clock cycle Clock to generate evolution of internal state =All devices called each cycle Large overhead for context switching Optimized hardware modeling (blocking): Only call when events (read, writes) occur Evolve internal state several cycles at a time Count the time since last activation Lower context switch overhead Example: device read operations CPU Transaction: Call device model: (op=read, address=0x17) Immediate reply: data=0x42 Pins: Set address pins to Drive clock pin to 1 and then 0... until data ready pin is 1 Then read from data pins CPU Device Device HW/SW Cosimulation: fast HW/SW Cosimulation: detailed Simics Simics VHDL/Verilog Simulator Memory Application (RT)OS Drivers CPU Core Devices Interface: transactions, events, maybe clock cycles Behavioral model Memory Application (RT)OS Drivers CPU Core Devices Interface: pins, clock cycles RTL-level simulation 38 39

10 Device Modeling Large part of work for a platform Processors: few and standardized Devices: (very) many and varied. But simpler. Still pretty fast, at transaction level Modeling devices: C/C++/Python with simulator APIs SystemC VHDL/Verilog Graphical languages (Magic-C) Stimulating a Simulation Stimuli 40 Stimuli Regular Computers Without proper stimuli, model is useless Feed mechanism How to get information into the simulation Data generation What to supply to the simulation Can get tricky Fixed inputs Spec benchmarks: loaded from disk Network Load generation on simulated machines Interface to a real network Interactive use Load generators on real machines Keyboard & mouse Map directly to real device Easy for PC-on-PC-style Interactive user 42 43

11 Non-traditional Computers Physical World Interaction Phones, navigation computers, PDAs, etc. Application development Use GUI to provide interactive sessions with user Keyboard, joystick, touch screen Not radio data etc. Special simulated devices Sensors & actuators Data sources Statistical models of real system behavior Simulation models of physical reality Hardware-in-the-loop simulation Configuration as Stimuli Workload Scaling Stimuli = hardware configuration Booting an operating system Test of OS software vs hardware Reconfigure hardware, alter devices Self-configuring systems Networks & other distributed systems Master election, device discovery, etc. Adding/removing simulated nodes Problem: simulation is slow Especially for detailed architectural simulation Slowdown 10000: 1 minute real time = 7 days simulation time Scale (down) workloads to fit Smaller data sets How to make representative of full runs? Tricky problem in its own right 46 47

12 Using Simulation Software Development Low-level software development Supervisor-level (OS) & interrupt code debug Inspection of system state Device access tracing & breakpoints Debugging unfinished operating systems Developing drivers High-level software development Powerful debugger, with checkpointing 49 Hardware Replacement Hardware Development Embedded HW Model hardware in development Cheaper, more convenient, available, stable Test components before physical prototype Often USD development platforms Virtual platform for early software dev Boards under development AMD64 (Hammer, Opteron, Athlon 64) Saved months for the Linux/AMD64 ports Next-gen UltraSparcs,... Stimulate HW with real workloads Requires ability to run operating systems HW/SW cosimulation At various levels of detail Shortens time to market dramatically 50 51

13 Parallelization of Development Network Software Board design Board prototype Handoff to the software team, when working hardware exists Develop network stacks & protocols Software development Easy to instrument the network, trace traffic Easy to inject packets Board prototype No interference from other traffic Board design & build simulator Simulator = reference Synchronous breaks at important events Try network configurations Handoff to the software team, using a simulation of the hardware platform Software development Large networks Pathological topologies Performance Tuning Faults and Boundary Cases Performance tuning of software Fault injection Trace & statistics on performance events Repeatable, no physical damage necessary Cache misses, TLB misses, disk accesses Fault tolerant systems, safety critical systems Memory access patterns Get first-order estimates from event counts Absolute performance measurements Examples: next slide Boundary case testing Extremely small or large configurations Requires very detailed models Intense bursts of interrupts Not a design goal of large-scale simulators Communications latencies and intensity 54 55

14 Fault Injection Examples Fault Injection & Checkpointing Corrupt register values CPU Corrupt measurements Sensor Boot system SW Position workload Run 1 Check results Restore checkpoint 56 Permanent bit errors Unplug a device RAM Device Transient errors in xmit Kill entire subsystem Bridge Device Network Corrupt network packets; unplug 57 Take checkpoint Check results CKP injected fault Restore checkpoint Run 2 Did the fault affect the result? Check results Teaching Enable hands-on experience Computer architecture Embedded systems programming Operating systems Debug half-finished systems Same setup for all students, easy handins System management Easy to restore system state No risk to real machines and networks Simulate with Care 58

15 Obtaining Significant Results Wisconsin Experiments Computer architecture research 90% or more done in simulation Measure of success: effect of modification to a reference machine What is a significant result? -5%?+10%? How real is the machine modified? SimpleScalar is not a real processor = need for quite extensive modeling Mark Hill et al, IEEE Computer Feb 2003 Investigating potential pitfalls of simulation Detailed microarchitectural modeling Pipeline, caches, reordering, the works Randomized L2 miss time (80-89 cycles) Several runs with same workload Variable results! Wisconsin Experiments Wisconsin Experiments Cycles Per Trans. (millions) ROB Size WCR (16,32) = 18% ( Wrong Conclusion Ratio ) WCR (16,64) = 7.5% WCR (32,64) = 26% max avg min Cycles Per Trans. (millions) Sample Size (number of runs)

16 Wisconsin Experiments Conclusions: Simulation no different from runs on real HW Use standard statistics Non-overlapping confidence intervals Danger of determinism in simulation Testing a single path of a program Induce variability by randomization Implementations 64 Full-System Simulators Integrated full-system simulators Virtutech Simics (better at abstraction) Virtio Virtio (more on the pin-level) Frameworks for combining discrete simulators Combine ISS with VHDL and Verilog simulators Mentor Graphics Seamless Cadence Incisive Virtualization environments VmWare VmWare (fast PC-on-PC) Connectix/Microsoft VirtualPC (fast PC-on-PC) Almost done... 66

17 Cost of Simulation Photo courtesy of The Computer Museum History Center Sim in 1977: on DEC VAX-11/ ,000 USD (1977 dollars) 1 VAX MIPS simulation technology ~200 cost for simulated server hour: 4,000 USD Linux on Itanium VxWorks on PowerPC Windows NT on x86 Photo courtesy of Intel Sim in 2002: on Dell PC (P4 2.2 GHz) 1,500 USD approx 3100 VAX MIPS simulation technology ~40 cost for simulated server hour: 2 USD a factor of 2000 in 25 years! Solaris on Sun SunFire Linux on x86 All running on a Linux host Windows XP/64 on AMD Hammer 68 Demo Time! Booting Linux Lifting checkpoints of Windows and Solaris Kernel debugging IO access history Configuration file syntax... and more.. Thank You info@virtutech.com 70