Trace-based modeling tool

Clone this repo:


  1. e856704 tbm: add hashes to requirements.txt by Shaked Flur · 9 months ago master
  2. cc5a110 TBM: remove Springbok text by Shaked Flur · 10 months ago
  3. d767b14 open source: add requirements.txt by Shaked Flur · 11 months ago
  4. 9f24eac open source: getting ready to open source TBM by Shaked Flur · 11 months ago
  5. 33c0120 Add gentrace-renode: elaborates Renode traces by Jakub Jatczak · 12 months ago

Trace Based Model (TBM)

What is TBM?

TBM is a performance simulator, designed to get performance measurements very early in the design cycle of processors/accelerators. It provides a way for testing the impact of new design ideas, before any detailed implementation. In order to do hardware-software codesign, it is necessary to have a highly configurable, easily extended performance simulator that gives detailed, actionable feedback to hardware engineers about the bottlenecks of different microarchitectural options; that can give detailed, actionable feedback to software engineers about the performance of the inner loops of their code; and that can be used to evaluate a range of different design microarchitectural decisions. Having a configurable, and extensible, performance simulator enables the software and hardware engineers to have the conversations that are critical to hardware-software codesign and replaces guesswork and hunches with data.

TBMs approach is to use an existing functional simulator to generate a functional trace and to build a “trace based model” (TBM) that models the control/scheduling logic of the microarchitecture but does not need to calculate the result of each instruction. The overall usage of a TBM: a functional simulator simulates execution of a program and generates a functional trace; TBM processes the functional trace using a microarchitectural model and produces information about the performance of the program on the microarchitecture being modeled. TBM is intended to be small and simple. Since it is only concerned with implementing the control/scheduling logic, it is possible to achieve high levels of code reuse and make it highly configurable.

Project structure


To run TBM you will need Python3 and the packages listed in requirements.txt. You can install the packages with pip: pip install --require-hashes -r requirements.txt.

You will also need the flatbuffers compiler flatc. On Debian based distros you can get it with apt: sudo apt install flatbuffers-compiler

The make scripts expect the following environment variables and directory structure:

  • ROOTDIR should be set to the root directory of the shodan source tree.
  • OUT should be set to the directory where build artifacts should be created (e.g. $ROOTDIR/out).
  • To use spike (RISC-V simulator), the spike executable should be in $OUT/host/spike/bin/spike.
  • To update the RISC-V pipe-maps, the riscv-opcodes repo (commit 6c34f60fe290613b7ba1d280b29a41179c399e69) should be checked out at $ROOTDIR/toolchain/riscv-opcodes.


  • tbm/ - reads a Spike trace and reformat it.
  • tbm/ - reads a Renode trace and reformat it.
  • tbm/ - create and update pipe-maps.
  • tbm/ - merges results from multiple runs of TBM.
  • tbm/ - runs a trace in TBM; the main tool here.

Python modules:

NOTE: currently TBM includes a single model for each of the building block units. The intention is that other models will be added in the future to cover uArchs that are not supported by the current models. defines (what we expect to be) the API of the building blocks.

  • tbm/ - defines Queue, FIFO queue model.
  • tbm/ - performance counters.
  • tbm/ - defines CPU, a cpu model (includes instances of FetchUnit, SchedUnit, ExecUnit, and MemorySystem).
  • tbm/ - bits we need to elaborate Spike traces.
  • tbm/ - defines ExecUnit, an execution unit model (includes instances of ScalarPipe, VectorPipe, scoreboard.Preemptive and scoreboard.VecPreemptive).
  • tbm/ - defines FetchUnit.
  • tbm/ - reads a trace (as generated by gentrace-*.py).
  • tbm/ - defines Instruction, a data class representing a single instruction instance in the trace.
  • tbm/ - defines the internal API. This will be more important when we add different models (i.e. implementations) for the various units.
  • tbm/ - defines MemorySystem, a main memory and cache hierarchy model.
  • tbm/ - defines ScalarPipe, a scalar functional unit model.
  • tbm/ - defines SchedUnit, an issue queue model.
  • tbm/ - defines Preemptive and VecPreemptive, scoreboard models.
  • tbm/ - command line parsing for
  • tbm/ - general purpose constructs.
  • tbm/ - defines VectorPipe, a vector functional unit model.

TBM configuration files:

  • config/instruction.fbs - FlatBuffer schema for the Instruction data class (used for saving elaborated traces). The FBInstruction.Instruction module is generated from this file.
  • config/rvv-simple.yaml - a uArch configuration example.
  • config/uarch.schema.json - JSON schema for uArch configuration files.
  • pipe_maps/riscv/*.json - pipe-maps, mapping RISC-V opcodes to functional units.

Build files:

  • Makefile - builds things that are needed for tbm to run.
  • - runs tbm on some ML models.
  • - run tbm on tests from $OUT/springbok/riscv-tests.
  • - runs tbm on tests from $OUT/springbok/rvv_for_tbm/tests.
  • - rules for running tbm.

How to use the make files

Building TBM:

Before running any of the TBM tools you must run make all.

To update the RISC-V pipe-maps in pipe_maps/riscv run make riscv_pipe_maps. This will import missing opcodes from $ROOTDIR/toolchain/riscv-opcodes, and will remove spurious ones. New opcodes are mapped to “UNKNOWN”. You can also update individual RISC-V pipe-maps like this: make pipe_maps/riscv/rv32a.json.

To run a linter on all the Python files in tbm/ run make lint.

To type-check all the Python scripts run make type-check. After running the type checker you can merge inferred types back to the .py files by running make merge-pyi to merge into all .py files, or make merge-pyi-MOD to merge into tbm/

Running tests from shodan

  • make -f integration_tests - most of these tests are actually not very good for integration testing as they take far too long to complete.
  • make -f riscv_tests_isa - run some of the tests from $ROOTDIR/out/springbok/riscv-tests/isa.
  • make -f riscv_tests_benchmarks - run the tests from $ROOTDIR/out/springbok/riscv-tests/benchmarks.
  • make -f riscv_tests - run the two previous targets.
  • make -f benchmarks - runs the above benchmarks and generates the file with all the results.
  • make -f rvv_tests - run the tests from $ROOTDIR/out/springbok/rvv_for_tbm/tests/.