1. UNISIM (UNIted SIMulation Environment) walkthrough
Edited and Presented by
Gage Eads, UC Berkeley

2. Outline PRET simulator needs What UNISIM offers UNISIM
CLM Methodology
Methodology
Repository structure
PTARM_ISS outline
Miscellaneous thoughts
UNISIM code walkthrough
CLM = Cycle-level model, TLM = Transaction-level model

3. PRET Simulator Needs Small learning curve Easily modifiable
Well documented
Distributable
Within PRET, we’d like to be able to add/modify modules (like a DRAM controller) easily. Outside of PRET, we’d like a student or researcher to easily learn and extend the simulator.

4. What UNISIM offers Open Source code (BSD) C++ Language
CLM and TLM models
CLM built on FastSysC engine
TLM built on SystemC 2.0 engine
Includes working ARMv5te simulator* and emulator
Useful tools and services
Easily distributable
*Mostly working
There is a bug in instructions that load R15 (the PC), in which the PC will skip its first instruction after branching.
The simulator is a timing-accurate model, whereas the emulator models only the functionality. Currently, the emulator is used to verify the functionality of the simulator by comparing states at various points in the pipeline.

5. UNISIM: CLM Methodology
Consists of modules, ports, and signals
Modules communicate via ports
Ports transmit signals, such as ‘instr’
Img src: Cycle-level Signal & Module documentation, Sylvain Girbal, UNISIM

6. UNISIM: CLM Methodology
Signal containers have their own class
There are three types of signals
Data
Accept (or reject - for module stalls)
Enable (use of data – when sending to multiple modules)
class instruction
{ uint32_t opcode;
enum operation_t operation;
uint32_t Ra_index, Rb_index, Rd_index;
uint32_t mem_address, branch_address; }

7. UNISIM: CLM Methodology
Modules are parameterized
Three types of parameters:
Core: Relate to the module itself, usually define data structure sizes
Connection: Define port widths, etc.
Behavior: Anything from cache replacement policy to debug verbosity
This allows for design-space exploration and reuse
DRAM module has a full set of parameterized latencies
DRAM latency parameters:

8. UNISIM: CLM Methodology
Modules communicate through ports
Three types of ports:
Clock (input)
Data (inp/out)
Optional data: Optionally enabled, such as a ‘shared’ bit for busses that snoop
Clearly defined interfaces allow you to easily swap modules

9. UNISIM: Methodology CLM vs. TLM - communication level CLM TLM
Img src:
The difference between CLM and TLM can be shown at the communication level. Consider a transfer using bus width of 64 bits, and a cache line size of 256 bits.
CLM: Pass-by-value, 64 bits per bus cycle plus accept and enable signals -> slower, but timing accurate
TLM: Pass-by-reference, all 256 bits of data at once -> much quicker, but not timing accurate

10. UNISIM: Methodology User-level System-level
Focus on the user-space part of the target ISA
Rely on “Syscall” service to translate target OS system calls to host OS system calls
System-level
Simulate the full target OS

11. UNISIM: Methodology Services/Capabilities
Services use client/server interface
Notable services: GDB debugger, ELF loader, data logger

12. UNISIM: Methodology FastSysC: A Fast SystemC Engine
Optimized for speed
Rewritten SystemC engine specifically for CLM communication model
Improved scheduling algorithm
SystemC uses dynamic scheduling
FastSysC uses hybrid static/dynamic algorithm to avoid unnecessary signal wake-ups
see:

13. UNISIM: Repository Structure
Public
Engine Core FastSysC engine
Components Simulator components
Capabilities Services
Cycle-Level Cycle-level components
Packages Modules (memory, cpu, debug)
Simulators Cycle-level simulators
Arm-score 5-stage user-level ARM sim
Benchmarks ARM benchmarks
Full System System-like components (prev. TLM)
Memories Interface and emulator
Processors CPU and ISA definitions
Plugins OS, loader
Tools
Cross compilers Compiler for each target ISA
GenISSLib ISA and decoder generator

14. PTARM_ISS outline Given: Extend: Create: Memory Dispatcher DMA
DRAM (separate memory from controller)
ARM CPU
Register file (resides in CPU module)
Create:
Scratchpad memory
Thread Controller
Memory Wheel
Deadline-related hardware

15. Miscellaneous Thoughts
Adding functionality is made easier by the separation of function and communication
Distribute entire package or simulator only
Fairly easy to extract necessary simulator code
No built-in regression test capabilities
Documentation is spotty
Some ‘README’ files and ‘doc’ folders are empty or incomplete
File descriptions are sometimes missing
UNISIM developer Sylvain (Thales) has been a great asset

16. UNISIM code walkthrough