SimpleScalar v3.0 Tutorial

U. of Wisconsin, CS752, Fall 2004

Andrey Litvin

(main source: Austin & Burger)

(also Dana Vantrease’ slides)

Simulator Basics

• What is an architectural simulator?– Tool that reproduces the behavior of a computing

device

• Why use a simulator?– Flexible

• Rapid design space exploration• Tailor abstraction level to need

– Cheap

• Why not use a simulator?– Slow– Correctness?

Functional vs. Performance

• Functional simulators implement the architecture

- Perform the actual execution

- Implement what programmers see

• Performance (or timing) simulators implement the microarchitecture.

- Model system resources/internals

- Measure time

- Implement what programmers do not see

Trace vs. Execution Driven (2)

• Trace+ Easy to Implement- Requires large disk files to store instruction stream- Limited state stored- Speculation? Multiprocessor?

• Execution- Hard to Implement+ Allows access to full state information at any point during

program execution+/- Execution requires inclusion of instruction setemulator and an I/O emulation module

Simplescalar

• Developed by Todd Austin with Doug Burger at UW, ’94-’96

• Execution – driven• Collection of simulators that emulate the

microprocessor at different detail levels (functional, functional + cache / bpred, out-of-order cycle-timer, etc.)

• Tools: – C/Fortran compiler, assembler, linker (for PISA)– DLite: target-machine-level debugger – pipeline trace viewer

Advantages of SimpleScalar

• Fast (given priority over clarity)– 4 MIPS functional, 300 KIPS OOO on 1.5 GHz

host

• Relatively(!) simple - short learning curve• Modular design• Well documented and commented• Popular - support community, extensions• Limitations will be summarized at the end

Sim-Fast

• Bare functional simulator

• Does not account for the behavior of any part of the microarchitecture

• Optimized for speed

Sim-Safe

• Similar to sim-fast (slower)

• Implements some memory op safeguards– Memory alignment– Memory access permission

• Good for debugging sim-fast crashes

Sim-EIO

• External trace/checkpoint generator

• Functional simulator like sim-fast and sim-safe

• Implements checks like sim-safe

Sim-Profile

• Profiles by symbol and address

• Keeps track of and reports (many options)– Dynamic instruction counts– Instruction class counts– Usage of address modes– Profiles of the text & data segment

Sim-Cache/Sim-Bpred

• Functional core drives the detailed model of the cache/branch predictor

• Similar to trace-driven cache/bpred simulation• Fast results for miss/misprediction rates• No timing simulation/performance impact

Cache Implementation

• block size, # of sets, associativity, all customizable

• Replacement policies: random, FIFO, LRU

• 2-level cache hierarchy supported (easily extended)

• Unified/separate I/D L1 and L2 caches

Implemented Predictors

• Specifying branch predictor type-bpred <type>

• Implemented predictors– nottaken always predicts not taken– taken always taken– perfect always right– bimod BTB with 2-bit counters– 2lev 2-level adaptive branch predictor

• Specify level1 size, level 2 size, history size(# bits), XOR PC and history?

• GAg, GAp, PAg, PAp, gshare

– comb combining (meta) predictor

Sim-Outorder

• Detailed performance simulator• Out-of-order execution core• Register renaming, reorder buffer, speculative

execution• 2-level cache hierarchy• Branch prediction

Making a Fast Timing Simulator

• Hardware advantage: parallelism

• Software emulator advantage: free space for auxillary structures

• Functional and detailed performance parts can be decoupled

Simulator RUU vs. Logical RUU

• No consumer -> producer links (tags)

• Rather, producer->consumer links for efficient result broadcast at writeback

• Values not tracked (except address)

• “Completed” bit (ROB and IQ combined)

• Same struct used for LSQ

Other Simulator Structures

• ready_queue– Ready to issue instructions– Used at issue stage– Built at writeback– Limited issue bandwidth– Policy: mul/div, load/store, branch first, then

oldest first

Other Simulator Structures

• fu_pool – functional units– Issue latency vs. operational latency

– Both constant, hard-coded in sim-outorder

– Read port latency more detailed (cache simulation)

– Issue latency – busy counter at FU

– Operational latency – event queue

• event_queue– ordered by cycle

– schedules writeback events

Other Simulator Structures

• create_vector– Register renaming– Maps logical register to RUU entry

(architectural register up to date if entry is null)– Updated at dispatch and writeback– Similar to Qi in Tomasulo– Backed up during dispatch if sim “divines”

misspeculation

Stage Implementation(greater detail in SS hack guide and v2.0

tutorial)• Fetch (at ruu_fetch())

– Fetch ins-s up to cache line boundary– Block on miss – Put in Fetch Queue (FQ)– Probe branch predictor for next cache line to

fetch from

Stage Implementation

• Decode (at ruu_decode())– Fetch from FQ

– Decode

– Rename registers

– Put into RUU and LSQ

– Update RUU dependency lists, renaming table

– Sim (functional core): • Execute instruction, update machine state

• Detect branch misprediction, backup state (checkpoint)

Stage Implementation

• Issue (at ruu_issue() and lsq_refresh())– Ready queue -> Event queue– Order based on policy (see ready_queue slide)– Check and reserve FU’s– Mem. Ops check memory dependences

• No load speculation (“maybe” dependence respected)

Stage Implementation

• Writeback (at ruu_writeback())– Get finished instructions from ready queue– Wake up (put in ready queue) instructions with

ready operands (use dependence list)– Performance core detects misprediction here

and rolls back the state

Stage Implementation

• Commit (at ruu_commit())– Service D-TLB misses– Update register file (logically) and rename table– Retire stores to D-cache– Reclaim RUU/LSQ entries of retirees

Limitations

• I/O and other system calls– Only some limited functional simulation

• Lacks support for arbitrary speculation– Only branches can cause rollback– No speculative loads– Harder problem: Decoupling of functional and

timing cores (for performance) complicates data speculation extensions

Limitations of Memory System

• No causality in memory system– All events are calculated at time of first access

• Simple TLB and virtual memory model– No address translation– TLB miss is a (small) fixed latency parallel with cache access

• Bandwidth, non-blocking– Modeled as n FU’s (read/write ports with fixed issue

delay) • Accurate if memory system is lightly utilized

– SMT extensions?

• Overhaul required for multiprocessor simulation

Extensions

www.simplescalar.com

• trace cache

• value prediction

• SMT

• multiprocessor

• more target ISA / host OS support

Miscellaneous

• Enter “sim-outorder” with no options to get options list and usage examples

• Options database (options.h)– Interface to register an option and check if

entered at initialization

• Stats database (stats.h)– Register new stats– Define secondary stats and track distributions

Miscellaneous