PantheonSim / Tenstorrent simulator

A simulated Tenstorrent Blackhole or Wormhole in your browser

PantheonSim, the GPU simulator for CUDA and ROCm, also hosts Tenstorrent Blackhole and Wormhole machines in its playground. You get a Linux terminal with tt-metal installed, write a TT-Metalium program, build it, and run it on ttsim, Tenstorrent’s own open source simulator. It is a functional simulation: programs run and give answers, but there is no performance data of any kind.

What you get

Choose a Tenstorrent machine in the playground and start it. The machine is a container with Ubuntu 24.04, a compiler, CMake, Python and the tt-metal packages. It has no card in it, and no driver for one. Before the shell opens, the machine sources the environment that points tt-metal at the simulator, so the first program you build already sees a device.

Four machines are offered: a Blackhole, a board with two Blackhole chips, a Wormhole, and a board with two Wormhole chips. Each two-chip board is a machine of its own, not two of the single chip; asking for two of a single chip is refused. The second chip of the two-chip Wormhole is reached over Ethernet, so that machine is noticeably slower to run its first program.

These figures were read from the simulator with tt-sim-info (ttsim v1.11.5, tt-metal 0.78.0), not copied from a data sheet. The Tensix grids are smaller than the grids on the data sheets, because the simulator’s descriptors apply harvesting, as real boards have cores fused off. Run tt-sim-info in the terminal to see what your machine reports.

What runs it

The simulator is ttsim, written and published by Tenstorrent. It is not PantheonSim’s simulator and PantheonSim did not change it: the playground installs Tenstorrent’s release and tells tt-metal to load it instead of a device. PantheonSim contributes the machine around it: the container, the editor and terminal in the browser, the limits, and the clean-up when the session ends. PantheonSim is not affiliated with or endorsed by Tenstorrent.

That division matters when something looks wrong. A message about a Tensix core, a NoC transfer or a missing instruction comes from ttsim and is Tenstorrent’s to answer; a machine that will not start or a file that will not save is the playground’s.

Start a machine and run a program

1. Open the playground and choose Tenstorrent Blackhole. The operating system is fixed at Ubuntu 24.04, because that is what the tt-metal packages are built for.
2. Press Start machine. The editor opens with device_info.cpp and a CMakeLists.txt that turns each .cpp file into a program.
3. Press Run. The editor saves the file and types the build and run commands into the terminal.

In the terminal the same thing is:

tt-sim-info
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --target device_info -j2
./build/device_info

tt-sim-info prints the chip or chips, the Tensix grid and the DRAM the way nvidia-smi prints a GPU. The self-test, /opt/tt/selftest <chip>, compiles and runs a small vector add through DRAM and L1 and checks the result on the host. The Tools menu in the playground has both, and a list of the starter programs in /work/examples.

Kernels are compiled when the program runs

A TT-Metalium program has a host part, which CMake builds, and kernels for the Tensix cores. tt-metal compiles the kernels itself the first time a program uses them and keeps the result in a cache under your home directory. The first run of a program is therefore slower than the next one. A playground machine has little CPU, so building kernels takes noticeable time, and the build uses two jobs for the same reason.

What it cannot tell you

• Speed. ttsim has no timing model. A kernel that takes a second here says nothing about how long it takes on a card, and neither do cycle counts or bandwidth figures from a run.
• Hardware behaviour beyond the model. ttsim runs the Tensix and NoC behaviour Tenstorrent implemented. An instruction or feature it lacks fails inside ttsim, and a program that works here can still need a run on a real card.
• Telemetry. The firmware heartbeat does not tick under the simulator, so health and power readings do not behave as they do on a card.
• The network. By default the machine has none, so bring files in with the editor’s Open button.

Like every playground machine it is shut down after a time limit and after a period without input, and its files are deleted with it.

Questions

For NVIDIA and AMD machines in the same playground, see running CUDA without a GPU and running ROCm and HIP without an AMD GPU, or the GPU index.