Tenstorrent System Management Interface (TT-SMI) is a command line utility to interact with all Tenstorrent devices on host.
The main objective of TT-SMI is to provide a simple and easy-to-use interface to display devices, device telemetry, and system information.
TT-SMI is also used to issue board-level resets.
[!IMPORTANT] As of v4.0.0 we are officially using tt-umd as our backend. To use the luwen backend, please use the
--use_luwenflag. Please file any issues you see with theumd-backendlabel
[!IMPORTANT] TT-SMI needs driver version ≥ 2.0.0 to work correctly. Please install the correct version from tt-kmd.
[!CAUTION] As of v3.0.35 we no longer support Grayskull Devices on TT-SMI. Kernel mode driver support for Grayskull was depreciated in ttkmd-2.2.0
[!CAUTION] Reset will not work on ARM systems since PCIe config is set up differently on those systems. Only way to perform a reliable board reset on those systems is to reboot the host.
https://github.com/tenstorrent/tt-smi/
If Rust isn't already installed on your system, you can install it through either of the following methods:
Fedora / EL9
sudo dnf install cargo
Ubuntu / Debian
sudo apt install cargo
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"
tt-smi is available on PyPI. We recommend running it with uvx, which ensures you always run the latest released version.
Install uv if you don't already have it:
curl -LsSf https://astral.sh/uv/install.sh | sh
Then run tt-smi:
uvx tt-smi@latest
Pass tt-smi flags after the package spec, e.g. uvx tt-smi@latest -s.
git clone https://github.com/tenstorrent/tt-smi.git
cd tt-smi
uv sync
This creates a .venv and installs tt-smi in editable mode along with its dependencies. Run the local build with uv run tt-smi, or activate the venv (source .venv/bin/activate) and use tt-smi directly.
Recommended: install the pre-commit hooks so there is auto-formatting for all files on commit.
uv run pre-commit install
tt-smi can be used as a GUI (tt-smi) or CLI (tt-smi -s) to display system information and Tenstorrent device telemetry, and it can be used to reset Tenstorrent devices (tt-smi -r).
tt-smi [-h] [-l] [-v] [-s] [-ls] [-f [snapshot filename]] [-c] [-r [TARGETS ...]] [--snapshot_no_tty] [-glx_reset] [-glx_reset_auto] [-glx_list_tray_to_device] [--no_reinit]
Running tt-smi with the -h, --help flag displays the help text.
$ tt-smi -h
usage: tt-smi [-h] [-l] [-v] [-s] [-ls] [-f [snapshot filename]] [-c] [-r [TARGETS ...]] [--snapshot_no_tty] [-glx_reset] [-glx_reset_auto] [-glx_list_tray_to_device] [--no_reinit] [--use_luwen]
Tenstorrent System Management Interface (TT-SMI) is a command line utility to interact with all Tenstorrent devices on host. The main objective of TT-SMI is to provide a simple and easy-to-use
interface to display devices, device telemetry, and system information. TT-SMI is also used to issue board-level resets.
options:
-h, --help show this help message and exit
-l, --local Run on local chips (Wormhole only)
-v, --version show program's version number and exit
-s, --snapshot Dump snapshot of current tt-smi information to STDOUT
-ls, --list List boards on the host and quit (UMD: UMD Chip ID, PCI BDF, PCI Dev ID, …)
-f [snapshot filename], --filename [snapshot filename]
Write snapshot to a file. Default: ~/tt_smi/<timestamp>_snapshot.json
-c, --compact Run in compact mode, hiding the sidebar and other static elements
-r [TARGETS ...], --reset [TARGETS ...]
Reset targets: UMD logical IDs, PCI BDFs (e.g. 0000:0a:00.0), or /dev/tenstorrent/<id>. Use -ls to list devices. Omit targets or use "all" to reset all devices. Do not mix types in one command.
--snapshot_no_tty Force no-tty behavior in the snapshot to stdout
-glx_reset, --galaxy_6u_trays_reset
Reset all the ASICs on the galaxy host; prefers no PCIe retimer reset (BMC v0.05.22+), falls back to legacy retimer reset
-glx_reset_auto, --galaxy_6u_trays_reset_auto
Reset all ASICs on the galaxy host, but do auto retries up to 3 times if reset fails
-glx_list_tray_to_device, --galaxy_6u_list_tray_to_device
List the mapping of devices to trays on the galaxy
--no_reinit Don't detect devices post reset
--use_luwen Use deprecated Luwen driver instead of UMD (default).
These options will be discussed in more detail in the following sections.
To bring up the tt-smi GUI run
$ tt-smi
This is the default mode where the user can view device information, telemetry, and firmware versions.

All GUI keyboard shortcuts can be found in the help menu that user can bring up by pressing the h key or clicking the help button on the footer.

The GUI has five tabs. Each row is one device (except the Processes tab, which lists host processes using Tenstorrent devices, and the GDDR Telemetry tab, which lists one row per GDDR channel). Several Telemetry values are shown as current / limit when a firmware limit is available.
| Field | Description |
|---|---|
# | Logical device index used by TT-SMI for this session (same numbering as UMD Chip ID with the default backend). |
| Bus ID | PCI bus/device/function (BDF) address of the device, for example 0000:01:00.0. |
| Board Type | Product / board series identifier (for example p150a, n300, tt-galaxy-bh). An R suffix means the chip is a remote (non-PCIe host) chip on a multi-chip board. |
| Board ID | Unique board serial / board ID string read from the device. |
| Coords | Ethernet mesh coordinates for Wormhole multi-chip systems, shown as (x, y, rack, shelf). Shown as N/A on Blackhole. |
| DRAM Trained | Whether on-board DRAM/GDDR completed training successfully (Yes / No). On Blackhole, one harvested GDDR channel is still a pass (7 of 8 trained + BIST). |
| DRAM Speed | Trained DRAM/GDDR data rate (for example 16G). |
| Link Speed | Current PCIe link generation negotiated with the host (for example Gen4 / Gen5). |
| Link Width | Current PCIe link width in lanes (for example 8 or 16). |
Live device metrics updated about every 100 ms. Where a limit applies, values appear as measured / limit.
| Field | Description |
|---|---|
# | Logical device index for this row. |
| Core Voltage (V) | ASIC core (VCORE) supply voltage in volts. Shown with the configured maximum VDD limit. |
| Core Current (A) | ASIC core current draw in amperes. Shown with the thermal design current (TDC) limit. |
| AICLK (MHz) | AI clock frequency in megahertz — the main compute clock. Shown with the maximum allowed AICLK. |
| Core Power (W) | ASIC core power draw in watts. Shown with the thermal design power (TDP) limit. |
| Board Power (W) | Total board input power from the host power supply, in watts. Shown with the board power limit. May be N/A if the firmware does not report input power. |
| Core Temp (°C) | ASIC temperature in degrees Celsius. Shown with the thermal throttle / temperature limit. |
| Fan Speed (RPM) | Cooling fan speed in revolutions per minute. Shown as N/A when the board has no controllable fan or fan telemetry is unavailable. |
| Heartbeat | Animated indicator that firmware is alive and updating. The spinner advances while the on-device firmware heartbeat counter is increasing. |
Live per-channel GDDR metrics updated about every 100 ms. Blackhole reports temperatures, EDC error counts, training, and BIST for up to 8 channels. Wormhole reports training status for 6 channels; other fields show N/A. Harvested channels are marked Harvested = Y with the remaining fields shown as -.
| Field | Description |
|---|---|
# | Logical device index for this row. |
| Ch | GDDR channel index on that device (0–7 on Blackhole, 0–5 on Wormhole). |
| Harvested | Whether this GDDR channel was harvested (Y / N). A harvested row shows - for the remaining fields. |
| Enabled | Whether the channel is present and enabled (Y / N). |
| Training | Channel training result (Pass / Fail / N/A). |
| BIST | Built-in self-test result after training (Pass / Fail / N/A). Shown as N/A on firmware older than 19.7 and on Wormhole. |
| Speed | Trained GDDR data rate per channel (for example 16G). Harvested, disabled, or failed-training channels show N/A. |
| Top (°C) | Top DRAM die temperature in degrees Celsius. |
| Bot (°C) | Bottom DRAM die temperature in degrees Celsius. |
| Corr RD | Correctable EDC errors on read since reset (saturates at 255). Highlighted when non-zero. |
| Corr WR | Correctable EDC errors on write since reset (saturates at 255). Highlighted when non-zero. |
| Uncorr RD | Uncorrectable EDC error flag on read (0 / 1). Highlighted when set. |
| Uncorr WR | Uncorrectable EDC error flag on write (0 / 1). Highlighted when set. |
| Field | Description |
|---|---|
# | Logical device index for this row. |
| FW Bundle Version | Version of the full firmware package flashed to the board (the bundle that contains the component firmwares below). |
| CM FW Version | Chip Management (CM / ARC) firmware version — the primary on-chip management firmware. |
| ETH FW Version | Ethernet firmware version used for chip-to-chip and fabric Ethernet links. |
| DM App Version | Device Management (DM) application firmware version — board management microcontroller application software. |
| GDDR FW Version | GDDR memory controller firmware version (Blackhole). Shown as N/A on boards that do not report it. |
Host processes currently holding open Tenstorrent device handles. Updated about every 100 ms.
| Field | Description |
|---|---|
| PID | Host process ID using the device. |
| User | Username that owns the process. |
| Device | Logical device index the process is using. |
| Command | Process command line (or executable name) as reported by the host. |
The sidebar box lists the version of each component in the Tenstorrent software
stack that we have validated. These are not each project's newest release.
They come from golden.json in the latest tt-sw-manifest
release: the set of versions that CI installs and exercises together as one
stack. Renovate opens a PR there as components publish new releases, and a pin
only moves once the full validation suite passes on the combination, so the
newest release of a component and its tested version can differ. This is the
same set that tt-installer installs by default.
Where TT-SMI can determine what is installed on the host (tt-kmd through sysfs, tt-smi and tt-flash through their CLIs), the row is marked:
| Marker | Meaning |
|---|---|
✓ | Matches the tested version. |
↑ | Older than the tested version, shown as installed → tested. |
▲ | Newer than the tested version. Not an error: the host is running ahead of the validated stack, so this particular combination has not been tested together. |
Rows with no marker are informational, since TT-SMI has no way to tell what is installed for them.
Run tt-smi --offline to skip the fetch and hide the box.
Use tt-smi -ls or tt-smi --list to print a table of Tenstorrent devices and exit (no GUI). This is the easiest way to see UMD Chip ID, PCI BDF, and /dev/tenstorrent/<n> (shown as PCI Dev ID) for each board—use these values with tt-smi -r as described in Resets.
With the UMD backend (default), output includes two tables:
tt-smi -r.Column meanings:
| Column | Meaning |
|---|---|
| UMD Chip ID | Logical device index used for tt-smi -r 0, tt-smi -r 1, … |
| PCI BDF | PCI bus/device/function, e.g. 0000:01:00.0 — use with tt-smi -r 0000:01:00.0 |
| PCI Dev ID | Kernel device node path, e.g. /dev/tenstorrent/19 — use with tt-smi -r /dev/tenstorrent/19 |
| Board Type | e.g. Blackhole, Wormhole |
| Device Series | Board SKU / series string |
| Board Number | Board serial identifier |
On large hosts (e.g. Galaxy), UMD Chip ID and /dev/tenstorrent/<n> are not always the same number—always use -ls to pick the correct target.
During discovery, tt-umd may print log lines (for example Ethernet heartbeat checks on Galaxy). Those messages are from the driver; the tables below still list the boards.
Abbreviated output from a 32-board Galaxy system; your PCI BDFs and /dev/tenstorrent/<n> assignments will differ.
$ tt-smi -ls
… UMD may log info/warning lines during topology discovery …
Gathering Information ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
All available boards on host (UMD):
┏━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━┓
┃ UMD Chip ID ┃ PCI BDF ┃ PCI Dev ID ┃ Board Type ┃ Device Series ┃ Board Number ┃
┡━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━┩
│ 0 │ 0000:01:00.0 │ /dev/tenstorrent/19 │ Blackhole │ tt-galaxy-bh │ 0000047131831011 │
│ 1 │ 0000:02:00.0 │ /dev/tenstorrent/18 │ Blackhole │ tt-galaxy-bh │ 0000047131831011 │
│ 2 │ 0000:03:00.0 │ /dev/tenstorrent/25 │ Blackhole │ tt-galaxy-bh │ 0000047131831011 │
│ … │ … │ … │ … │ … │ … │
│ 31 │ 0000:c8:00.0 │ /dev/tenstorrent/6 │ Blackhole │ tt-galaxy-bh │ 0000047131831011 │
└─────────────┴──────────────┴─────────────────────┴────────────┴───────────────┴──────────────────┘
Boards that can be reset (UMD):
┏━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━┓
┃ UMD Chip ID ┃ PCI BDF ┃ PCI Dev ID ┃ Board Type ┃ Device Series ┃ Board Number ┃
┡━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━┩
│ 0 │ 0000:01:00.0 │ /dev/tenstorrent/19 │ Blackhole │ tt-galaxy-bh │ 0000047131831011 │
│ … │ … │ … │ … │ … │ … │
└─────────────┴──────────────┴─────────────────────┴────────────┴───────────────┴──────────────────┘
With --use_luwen, the table layout differs (no UMD Chip ID column); use PCI BDF and /dev/tenstorrent/<n> for tt-smi -r when using Luwen.
Another feature of tt-smi is performing resets on Blackhole and Wormhole PCIe cards and galaxy machines, using the -r / --reset argument.
Reset targets are parsed as one type per invocation (do not mix UMD logical IDs, PCI BDFs, and /dev/tenstorrent/<id> paths in the same command).
With the UMD backend (default, no --use_luwen), -r accepts four kinds of input:
all — reset every detected device (tt-smi -r or tt-smi -r all).0, 1, 2 (same numbering as UMD device enumeration).0000:0a:00.0 (comma-separated for multiple devices)./dev/tenstorrent/<id> — device node index, e.g. /dev/tenstorrent/0.--use_luwen)With the Luwen backend, -r accepts three kinds of input:
all — reset all devices discovered via Luwen./dev/tenstorrent/<id> — as above.Note: A bare integer (e.g. 0) is not a valid Luwen reset target. Use the /dev/tenstorrent/0 form instead.
tt-smi -r 0 --use_luwentt-smi -r /dev/tenstorrent/0 --use_luwentt-smi -r 0000:0a:00.0,0000:0b:00.0
tt-smi -r /dev/tenstorrent/0,/dev/tenstorrent/2,/dev/tenstorrent/3
tt-smi -r 0,1,2 # UMD logical IDs (UMD / default backend only)
tt-smi -r # or: tt-smi -r all
Use tt-smi -ls (or tt-smi --list) to list boards; see Listing devices for UMD Chip ID, PCI BDF, and /dev/tenstorrent/<id> columns.
By default, the reset command will re-initialize the boards after reset. Use the --no_reinit arg to skip this.
There are several options available for resetting Galaxy 6U trays.
-r/--reset argument and treat it like any other pcie card. Warning - Needs CPLD FW v1.16 or higher.tt-smi -glx_reset
Resetting WH Galaxy trays with reset command...
Executing command: sudo ipmitool raw 0x30 0x8B 0xF 0xFF 0x3 0xF
Waiting for 30 seconds: 30
Driver loaded
Re-initializing boards after reset....
Detected Chips: 32
Re-initialized 32 boards after reset. Exiting...
This prefers ipmitool raw 0x30 0x8B 0xF 0xFF 0x3 0xF (no PCIe retimer reset). If that command fails — including older BMCs that reject it with rsp=0xc9 (Parameter out of range) — tt-smi prints an error and falls back to the legacy 0x0 retimer reset so the trays still reset. BMC firmware v0.05.22 or later is required for the no-retimer path.
To identify the correct tray number for resetting specific devices, users can run tt-smi -glx_list_tray_to_device / --galaxy_6u_list_tray_to_device. This command displays a mapping table that shows the relationship between tray numbers, tray bus IDs, and the corresponding PCI device IDs, making it easier to target the appropriate devices for reset operations. Note that this command should not be run in a virtual machine (VM) environment as it requires direct hardware access to the Galaxy system.
$ tt-sml -glx_list_tray_to_device
Gathering Information ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
Mapping of trays to devices on the galaxy:
┏━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Tray Number ┃ Tray Bus ID ┃ PCI Dev ID ┃
┡━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ 1 │ 0xc0 │ 0,1,2,3,4,5,6,7 │
│ 2 │ 0x80 │ 8,9,10,11,12,13,14,15 │
│ 3 │ 0x00 │ 16,17,18,19,20,21,22,23 │
│ 4 │ 0x40 │ 24,25,26,27,28,29,30,31 │
└─────────────┴─────────────┴─────────────────────────┘
TT-SMI provides an easy way to get all the information that is displayed on the GUI in a json format using the -s / --snapshot argument. This prints the snapshot info directly to STDOUT.
Use the -f option to save the output to a file. By default the file is named and stored as ~/tt_smi/<timestamp>_snapshot.json, but users can also provide their own filename if desired.
Example usage:
$ tt-smi -f tt_smi_example.json
Gathering Information ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
Saved tt-smi log to: tt_smi_example.json
$ tt-smi -s
Gathering Information ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
{
"time": "2025-02-04T13:04:50.313105",
"host_info": {
"OS": "Linux",
"Distro": "Ubuntu 20.04.6 LTS",
"Kernel": "5.15.0-130-generic",
.........
Apache 2.0 - https://www.apache.org/licenses/LICENSE-2.0.txt
Python
99.2%
Tenstorrent System Management Interface (TT-SMI) is a command line utility to interact with all Tenstorrent devices on host.
The main objective of TT-SMI is to provide a simple and easy-to-use interface to display devices, device telemetry, and system information.
TT-SMI is also used to issue board-level resets.
[!IMPORTANT] As of v4.0.0 we are officially using tt-umd as our backend. To use the luwen backend, please use the
--use_luwenflag. Please file any issues you see with theumd-backendlabel
[!IMPORTANT] TT-SMI needs driver version ≥ 2.0.0 to work correctly. Please install the correct version from tt-kmd.
[!CAUTION] As of v3.0.35 we no longer support Grayskull Devices on TT-SMI. Kernel mode driver support for Grayskull was depreciated in ttkmd-2.2.0
[!CAUTION] Reset will not work on ARM systems since PCIe config is set up differently on those systems. Only way to perform a reliable board reset on those systems is to reboot the host.
https://github.com/tenstorrent/tt-smi/
If Rust isn't already installed on your system, you can install it through either of the following methods:
Fedora / EL9
sudo dnf install cargo
Ubuntu / Debian
sudo apt install cargo
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"
tt-smi is available on PyPI. We recommend running it with uvx, which ensures you always run the latest released version.
Install uv if you don't already have it:
curl -LsSf https://astral.sh/uv/install.sh | sh
Then run tt-smi:
uvx tt-smi@latest
Pass tt-smi flags after the package spec, e.g. uvx tt-smi@latest -s.
git clone https://github.com/tenstorrent/tt-smi.git
cd tt-smi
uv sync
This creates a .venv and installs tt-smi in editable mode along with its dependencies. Run the local build with uv run tt-smi, or activate the venv (source .venv/bin/activate) and use tt-smi directly.
Recommended: install the pre-commit hooks so there is auto-formatting for all files on commit.
uv run pre-commit install
tt-smi can be used as a GUI (tt-smi) or CLI (tt-smi -s) to display system information and Tenstorrent device telemetry, and it can be used to reset Tenstorrent devices (tt-smi -r).
tt-smi [-h] [-l] [-v] [-s] [-ls] [-f [snapshot filename]] [-c] [-r [TARGETS ...]] [--snapshot_no_tty] [-glx_reset] [-glx_reset_auto] [-glx_list_tray_to_device] [--no_reinit]
Running tt-smi with the -h, --help flag displays the help text.
$ tt-smi -h
usage: tt-smi [-h] [-l] [-v] [-s] [-ls] [-f [snapshot filename]] [-c] [-r [TARGETS ...]] [--snapshot_no_tty] [-glx_reset] [-glx_reset_auto] [-glx_list_tray_to_device] [--no_reinit] [--use_luwen]
Tenstorrent System Management Interface (TT-SMI) is a command line utility to interact with all Tenstorrent devices on host. The main objective of TT-SMI is to provide a simple and easy-to-use
interface to display devices, device telemetry, and system information. TT-SMI is also used to issue board-level resets.
options:
-h, --help show this help message and exit
-l, --local Run on local chips (Wormhole only)
-v, --version show program's version number and exit
-s, --snapshot Dump snapshot of current tt-smi information to STDOUT
-ls, --list List boards on the host and quit (UMD: UMD Chip ID, PCI BDF, PCI Dev ID, …)
-f [snapshot filename], --filename [snapshot filename]
Write snapshot to a file. Default: ~/tt_smi/<timestamp>_snapshot.json
-c, --compact Run in compact mode, hiding the sidebar and other static elements
-r [TARGETS ...], --reset [TARGETS ...]
Reset targets: UMD logical IDs, PCI BDFs (e.g. 0000:0a:00.0), or /dev/tenstorrent/<id>. Use -ls to list devices. Omit targets or use "all" to reset all devices. Do not mix types in one command.
--snapshot_no_tty Force no-tty behavior in the snapshot to stdout
-glx_reset, --galaxy_6u_trays_reset
Reset all the ASICs on the galaxy host; prefers no PCIe retimer reset (BMC v0.05.22+), falls back to legacy retimer reset
-glx_reset_auto, --galaxy_6u_trays_reset_auto
Reset all ASICs on the galaxy host, but do auto retries up to 3 times if reset fails
-glx_list_tray_to_device, --galaxy_6u_list_tray_to_device
List the mapping of devices to trays on the galaxy
--no_reinit Don't detect devices post reset
--use_luwen Use deprecated Luwen driver instead of UMD (default).
These options will be discussed in more detail in the following sections.
To bring up the tt-smi GUI run
$ tt-smi
This is the default mode where the user can view device information, telemetry, and firmware versions.

All GUI keyboard shortcuts can be found in the help menu that user can bring up by pressing the h key or clicking the help button on the footer.

The GUI has five tabs. Each row is one device (except the Processes tab, which lists host processes using Tenstorrent devices, and the GDDR Telemetry tab, which lists one row per GDDR channel). Several Telemetry values are shown as current / limit when a firmware limit is available.
| Field | Description |
|---|---|
# | Logical device index used by TT-SMI for this session (same numbering as UMD Chip ID with the default backend). |
| Bus ID | PCI bus/device/function (BDF) address of the device, for example 0000:01:00.0. |
| Board Type | Product / board series identifier (for example p150a, n300, tt-galaxy-bh). An R suffix means the chip is a remote (non-PCIe host) chip on a multi-chip board. |
| Board ID | Unique board serial / board ID string read from the device. |
| Coords | Ethernet mesh coordinates for Wormhole multi-chip systems, shown as (x, y, rack, shelf). Shown as N/A on Blackhole. |
| DRAM Trained | Whether on-board DRAM/GDDR completed training successfully (Yes / No). On Blackhole, one harvested GDDR channel is still a pass (7 of 8 trained + BIST). |
| DRAM Speed | Trained DRAM/GDDR data rate (for example 16G). |
| Link Speed | Current PCIe link generation negotiated with the host (for example Gen4 / Gen5). |
| Link Width | Current PCIe link width in lanes (for example 8 or 16). |
Live device metrics updated about every 100 ms. Where a limit applies, values appear as measured / limit.
| Field | Description |
|---|---|
# | Logical device index for this row. |
| Core Voltage (V) | ASIC core (VCORE) supply voltage in volts. Shown with the configured maximum VDD limit. |
| Core Current (A) | ASIC core current draw in amperes. Shown with the thermal design current (TDC) limit. |
| AICLK (MHz) | AI clock frequency in megahertz — the main compute clock. Shown with the maximum allowed AICLK. |
| Core Power (W) | ASIC core power draw in watts. Shown with the thermal design power (TDP) limit. |
| Board Power (W) | Total board input power from the host power supply, in watts. Shown with the board power limit. May be N/A if the firmware does not report input power. |
| Core Temp (°C) | ASIC temperature in degrees Celsius. Shown with the thermal throttle / temperature limit. |
| Fan Speed (RPM) | Cooling fan speed in revolutions per minute. Shown as N/A when the board has no controllable fan or fan telemetry is unavailable. |
| Heartbeat | Animated indicator that firmware is alive and updating. The spinner advances while the on-device firmware heartbeat counter is increasing. |
Live per-channel GDDR metrics updated about every 100 ms. Blackhole reports temperatures, EDC error counts, training, and BIST for up to 8 channels. Wormhole reports training status for 6 channels; other fields show N/A. Harvested channels are marked Harvested = Y with the remaining fields shown as -.
| Field | Description |
|---|---|
# | Logical device index for this row. |
| Ch | GDDR channel index on that device (0–7 on Blackhole, 0–5 on Wormhole). |
| Harvested | Whether this GDDR channel was harvested (Y / N). A harvested row shows - for the remaining fields. |
| Enabled | Whether the channel is present and enabled (Y / N). |
| Training | Channel training result (Pass / Fail / N/A). |
| BIST | Built-in self-test result after training (Pass / Fail / N/A). Shown as N/A on firmware older than 19.7 and on Wormhole. |
| Speed | Trained GDDR data rate per channel (for example 16G). Harvested, disabled, or failed-training channels show N/A. |
| Top (°C) | Top DRAM die temperature in degrees Celsius. |
| Bot (°C) | Bottom DRAM die temperature in degrees Celsius. |
| Corr RD | Correctable EDC errors on read since reset (saturates at 255). Highlighted when non-zero. |
| Corr WR | Correctable EDC errors on write since reset (saturates at 255). Highlighted when non-zero. |
| Uncorr RD | Uncorrectable EDC error flag on read (0 / 1). Highlighted when set. |
| Uncorr WR | Uncorrectable EDC error flag on write (0 / 1). Highlighted when set. |
| Field | Description |
|---|---|
# | Logical device index for this row. |
| FW Bundle Version | Version of the full firmware package flashed to the board (the bundle that contains the component firmwares below). |
| CM FW Version | Chip Management (CM / ARC) firmware version — the primary on-chip management firmware. |
| ETH FW Version | Ethernet firmware version used for chip-to-chip and fabric Ethernet links. |
| DM App Version | Device Management (DM) application firmware version — board management microcontroller application software. |
| GDDR FW Version | GDDR memory controller firmware version (Blackhole). Shown as N/A on boards that do not report it. |
Host processes currently holding open Tenstorrent device handles. Updated about every 100 ms.
| Field | Description |
|---|---|
| PID | Host process ID using the device. |
| User | Username that owns the process. |
| Device | Logical device index the process is using. |
| Command | Process command line (or executable name) as reported by the host. |
The sidebar box lists the version of each component in the Tenstorrent software
stack that we have validated. These are not each project's newest release.
They come from golden.json in the latest tt-sw-manifest
release: the set of versions that CI installs and exercises together as one
stack. Renovate opens a PR there as components publish new releases, and a pin
only moves once the full validation suite passes on the combination, so the
newest release of a component and its tested version can differ. This is the
same set that tt-installer installs by default.
Where TT-SMI can determine what is installed on the host (tt-kmd through sysfs, tt-smi and tt-flash through their CLIs), the row is marked:
| Marker | Meaning |
|---|---|
✓ | Matches the tested version. |
↑ | Older than the tested version, shown as installed → tested. |
▲ | Newer than the tested version. Not an error: the host is running ahead of the validated stack, so this particular combination has not been tested together. |
Rows with no marker are informational, since TT-SMI has no way to tell what is installed for them.
Run tt-smi --offline to skip the fetch and hide the box.
Use tt-smi -ls or tt-smi --list to print a table of Tenstorrent devices and exit (no GUI). This is the easiest way to see UMD Chip ID, PCI BDF, and /dev/tenstorrent/<n> (shown as PCI Dev ID) for each board—use these values with tt-smi -r as described in Resets.
With the UMD backend (default), output includes two tables:
tt-smi -r.Column meanings:
| Column | Meaning |
|---|---|
| UMD Chip ID | Logical device index used for tt-smi -r 0, tt-smi -r 1, … |
| PCI BDF | PCI bus/device/function, e.g. 0000:01:00.0 — use with tt-smi -r 0000:01:00.0 |
| PCI Dev ID | Kernel device node path, e.g. /dev/tenstorrent/19 — use with tt-smi -r /dev/tenstorrent/19 |
| Board Type | e.g. Blackhole, Wormhole |
| Device Series | Board SKU / series string |
| Board Number | Board serial identifier |
On large hosts (e.g. Galaxy), UMD Chip ID and /dev/tenstorrent/<n> are not always the same number—always use -ls to pick the correct target.
During discovery, tt-umd may print log lines (for example Ethernet heartbeat checks on Galaxy). Those messages are from the driver; the tables below still list the boards.
Abbreviated output from a 32-board Galaxy system; your PCI BDFs and /dev/tenstorrent/<n> assignments will differ.
$ tt-smi -ls
… UMD may log info/warning lines during topology discovery …
Gathering Information ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
All available boards on host (UMD):
┏━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━┓
┃ UMD Chip ID ┃ PCI BDF ┃ PCI Dev ID ┃ Board Type ┃ Device Series ┃ Board Number ┃
┡━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━┩
│ 0 │ 0000:01:00.0 │ /dev/tenstorrent/19 │ Blackhole │ tt-galaxy-bh │ 0000047131831011 │
│ 1 │ 0000:02:00.0 │ /dev/tenstorrent/18 │ Blackhole │ tt-galaxy-bh │ 0000047131831011 │
│ 2 │ 0000:03:00.0 │ /dev/tenstorrent/25 │ Blackhole │ tt-galaxy-bh │ 0000047131831011 │
│ … │ … │ … │ … │ … │ … │
│ 31 │ 0000:c8:00.0 │ /dev/tenstorrent/6 │ Blackhole │ tt-galaxy-bh │ 0000047131831011 │
└─────────────┴──────────────┴─────────────────────┴────────────┴───────────────┴──────────────────┘
Boards that can be reset (UMD):
┏━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━┓
┃ UMD Chip ID ┃ PCI BDF ┃ PCI Dev ID ┃ Board Type ┃ Device Series ┃ Board Number ┃
┡━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━┩
│ 0 │ 0000:01:00.0 │ /dev/tenstorrent/19 │ Blackhole │ tt-galaxy-bh │ 0000047131831011 │
│ … │ … │ … │ … │ … │ … │
└─────────────┴──────────────┴─────────────────────┴────────────┴───────────────┴──────────────────┘
With --use_luwen, the table layout differs (no UMD Chip ID column); use PCI BDF and /dev/tenstorrent/<n> for tt-smi -r when using Luwen.
Another feature of tt-smi is performing resets on Blackhole and Wormhole PCIe cards and galaxy machines, using the -r / --reset argument.
Reset targets are parsed as one type per invocation (do not mix UMD logical IDs, PCI BDFs, and /dev/tenstorrent/<id> paths in the same command).
With the UMD backend (default, no --use_luwen), -r accepts four kinds of input:
all — reset every detected device (tt-smi -r or tt-smi -r all).0, 1, 2 (same numbering as UMD device enumeration).0000:0a:00.0 (comma-separated for multiple devices)./dev/tenstorrent/<id> — device node index, e.g. /dev/tenstorrent/0.--use_luwen)With the Luwen backend, -r accepts three kinds of input:
all — reset all devices discovered via Luwen./dev/tenstorrent/<id> — as above.Note: A bare integer (e.g. 0) is not a valid Luwen reset target. Use the /dev/tenstorrent/0 form instead.
tt-smi -r 0 --use_luwentt-smi -r /dev/tenstorrent/0 --use_luwentt-smi -r 0000:0a:00.0,0000:0b:00.0
tt-smi -r /dev/tenstorrent/0,/dev/tenstorrent/2,/dev/tenstorrent/3
tt-smi -r 0,1,2 # UMD logical IDs (UMD / default backend only)
tt-smi -r # or: tt-smi -r all
Use tt-smi -ls (or tt-smi --list) to list boards; see Listing devices for UMD Chip ID, PCI BDF, and /dev/tenstorrent/<id> columns.
By default, the reset command will re-initialize the boards after reset. Use the --no_reinit arg to skip this.
There are several options available for resetting Galaxy 6U trays.
-r/--reset argument and treat it like any other pcie card. Warning - Needs CPLD FW v1.16 or higher.tt-smi -glx_reset
Resetting WH Galaxy trays with reset command...
Executing command: sudo ipmitool raw 0x30 0x8B 0xF 0xFF 0x3 0xF
Waiting for 30 seconds: 30
Driver loaded
Re-initializing boards after reset....
Detected Chips: 32
Re-initialized 32 boards after reset. Exiting...
This prefers ipmitool raw 0x30 0x8B 0xF 0xFF 0x3 0xF (no PCIe retimer reset). If that command fails — including older BMCs that reject it with rsp=0xc9 (Parameter out of range) — tt-smi prints an error and falls back to the legacy 0x0 retimer reset so the trays still reset. BMC firmware v0.05.22 or later is required for the no-retimer path.
To identify the correct tray number for resetting specific devices, users can run tt-smi -glx_list_tray_to_device / --galaxy_6u_list_tray_to_device. This command displays a mapping table that shows the relationship between tray numbers, tray bus IDs, and the corresponding PCI device IDs, making it easier to target the appropriate devices for reset operations. Note that this command should not be run in a virtual machine (VM) environment as it requires direct hardware access to the Galaxy system.
$ tt-sml -glx_list_tray_to_device
Gathering Information ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
Mapping of trays to devices on the galaxy:
┏━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Tray Number ┃ Tray Bus ID ┃ PCI Dev ID ┃
┡━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ 1 │ 0xc0 │ 0,1,2,3,4,5,6,7 │
│ 2 │ 0x80 │ 8,9,10,11,12,13,14,15 │
│ 3 │ 0x00 │ 16,17,18,19,20,21,22,23 │
│ 4 │ 0x40 │ 24,25,26,27,28,29,30,31 │
└─────────────┴─────────────┴─────────────────────────┘
TT-SMI provides an easy way to get all the information that is displayed on the GUI in a json format using the -s / --snapshot argument. This prints the snapshot info directly to STDOUT.
Use the -f option to save the output to a file. By default the file is named and stored as ~/tt_smi/<timestamp>_snapshot.json, but users can also provide their own filename if desired.
Example usage:
$ tt-smi -f tt_smi_example.json
Gathering Information ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
Saved tt-smi log to: tt_smi_example.json
$ tt-smi -s
Gathering Information ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
{
"time": "2025-02-04T13:04:50.313105",
"host_info": {
"OS": "Linux",
"Distro": "Ubuntu 20.04.6 LTS",
"Kernel": "5.15.0-130-generic",
.........
Apache 2.0 - https://www.apache.org/licenses/LICENSE-2.0.txt
Python
99.2%