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

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

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.

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.

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

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; }

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: http://unisim.org/site/modules/cycle/network/dram/parameters

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

UNISIM: Methodology CLM vs. TLM - communication level CLM TLM Img src: https://unisim.org/site/speed/start 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

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

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

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: http://unisim.org/site/speed/fastsysc

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

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

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

UNISIM code walkthrough