Skip to main content

TT-UMD

User Mode Driver

ttnn logo

Quickstart

Software Dependencies

UMD requires Tenstorrent's kernel-mode driver

Required Ubuntu dependencies:

sudo apt install -y libhwloc-dev cmake ninja-build

UMD currently supports gcc-11 and newer gcc versions, and clang-13 and newer clang versions.

IOMMU and Hugepage requirements

To determine whether your system requires hugepage configuration, run the provided script:

./scripts/iommu_detect.sh

Wormhole and Blackhole

If your system IOMMU is enabled, no hugepage setup is required. If you don't have IOMMU enabled, than hugepages might be required for some of the driver functionality. 1G hugepages are required for shared device/host memory. Techniques for setup:

  • Recommended: add hugepagesz=1G hugepages=N to your kernel boot parameters (where N is the number of hugepages needed), then reboot.
  • Alternative: the tt-system-tools repository contains a .deb package which will configure your system.
  • For experts:
    • Put system IOMMU in passthrough mode or disable it.
    • Allocate 1 or more 1G hugepages via kernel boot parameters or at runtime via /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages.

Install and use UMD

Python bindings

You can just run the following command, and you'll have tt_umd python package available in your environment:

pip install git+https://github.com/tenstorrent/tt-umd.git

Or if you have UMD downloaded locally you can install from local source:

pip install .

Build flow for C++ lib

To build libtt-umd.so:

cmake -B build -G Ninja
cmake --build build

To build all components (some are turned off by default, like tests), you can run these commands:

cmake -B build -G Ninja -DTT_UMD_BUILD_ALL=ON
cmake --build build

To build with GCC, set these environment variables before invoking cmake:

export CC=gcc
export CXX=g++

Build debian dev package

cmake --build build --target package

# Generates umd-dev-x.y.z-Linux.deb

Enabling Logging

UMD uses a two-level logging system with compile-time and runtime controls.

Compile-Time Logging Control

By default, log_debug and log_trace statements are compiled out of release builds for performance. To include them in the binary:

Option 1: Enable logging explicitly

cmake -B build -G Ninja -DTT_UMD_ENABLE_LOGGING=ON
cmake --build build

Option 2: Use Debug build type (enables logging automatically)

cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug
cmake --build build

Runtime Logging Control

At runtime, control the logging level using the TT_LOGGER_LEVEL environment variable:

export TT_LOGGER_LEVEL=debug  # Show debug and above
export TT_LOGGER_LEVEL=trace  # Show all log messages (most verbose)
export TT_LOGGER_LEVEL=info   # Default level

Available log levels (from most to least verbose):

  • trace - Most detailed logging, traces program execution
  • debug - Debugging information useful during development
  • info - General informational messages (default)
  • warn - Warning messages for potentially harmful situations
  • error - Error messages for serious problems
  • critical - Critical errors that may lead to program termination
  • off - Disables all logging

Example: Running with debug logging

# Build with logging enabled
cmake -B build -G Ninja -DTT_UMD_ENABLE_LOGGING=ON
cmake --build build

# Run with debug level
TT_LOGGER_LEVEL=debug ./build/bin/your_program

Tracy Profiling

UMD supports Tracy profiling via the TT_UMD_ENABLE_TRACY build option. When disabled (the default), Tracy has zero footprint — no binary overhead, no runtime cost.

Building with Tracy

cmake -B build -G Ninja -DTT_UMD_ENABLE_TRACY=ON
cmake --build build

Capturing a trace

Launch the Tracy server, start the application you want to profile, then click connect

Integration

UMD can be consumed by downstream projects in multiple ways.

From Source (Python)

You can use tt_umd module by installing it in your current python environment

From Source (CMake)

You can link libtt-umd.so by linking against the umd::tt-umd target.

Using CPM Package Manager

CPMAddPackage(
  NAME umd
  GITHUB_REPOSITORY tenstorrent/tt-umd
  GIT_TAG v0.1.0
  VERSION 0.1.0
)

As a submodule/external project

add_subdirectory(<path to umd>)

From Prebuilt Binaries

Ubuntu

apt install ./umd-dev-x.y.z-Linux.deb

Simulator Integration

You can run UMD tests without silicon by following setup instructions here.

For UMD, sample tests can be found in tests/simulation/test_simulation_device.cpp

Development workflow

For developing tt-umd, you can see the full set of dependencies in docker_install_common.sh

After that you can look at the section defined above Install and use UMD

Pre-commit Hook Integration for Formatting and Linting

As part of maintaining consistent code formatting across the project, we have integrated the pre-commit framework into our workflow. The pre-commit hooks will help automatically check and format code before commits are made, ensuring that we adhere to the project's coding standards.

What is Pre-commit?

Pre-commit is a framework for managing and maintaining multi-language pre-commit hooks. It helps catch common issues early by running a set of hooks before code is committed, automating tasks like:

  • Formatting code (e.g., fixing trailing whitespace, enforcing end-of-file newlines)
  • Running linters (e.g., clang-format, black, flake8)
  • Checking for merge conflicts or other common issues.

For more details on pre-commit, you can visit the official documentation.

How to Set Up Pre-commit Locally

To set up pre-commit on your local machine, follow these steps:

  1. Install Pre-commit: Ensure you have Python installed, then run:
    pip install pre-commit
    
  2. Install the Git Hook Scripts: In your local repository, run the following command to install the pre-commit hooks:
    pre-commit install
    
    This command will configure your local Git to run the defined hooks automatically before each commit.
  3. Run Pre-commit Hooks Manually: You can also run the hooks manually against all files at any time with:
    pre-commit run --all-files
    

Why You Should Use Pre-commit

By setting up pre-commit locally, you can help maintain the quality of the codebase and ensure that commits consistently meet the project's formatting standards. This saves time during code reviews and reduces the likelihood of code formatting issues slipping into the repository.

Since the hooks run automatically before each commit, you don't need to remember to manually format or check your code, making it easier to maintain consistency.

We strongly encourage all developers to integrate pre-commit into their workflow.

Formatting C++ code

Installing clang-format

If you're using an IRD docker, clang-format should be already available. If you don't have clang-format in your working environment, follow the instructions on llvm website for installing it.

Formatting files

If working with VSCode, you can copy the provided default settings:

cp .vscode/default.settings.json .vscode/settings.json

From now on, c++ files will be formatted on save (given that clang-format is available).

Note that if you setup pre-commit hook, the files will be automatically formatted when you commit changes. You can also manually auto format the whole repo using mentioned pre-commit:

   pre-commit run --all-files

Bumping the UMD version

There is an automated workflow for creating releases. It is triggered by merging a PR to main which changes the VERSION file.

You can change the VERSION as part of another PR or as an isolated PR. Please also update the CHANGELOG with the exact version you are changeing to.

Once the PR is merged, a draft Release will be created with the generated changelog and artifacts. Please review it and publish it using the tag which exactly matches the version of the release.

Metadata

Release files for tt-umd 0.9.4.260325

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Built distributions (wheels)

Table of built distributions (wheels) for tt-umd 0.9.4.260325
File
tt_umd-0.9.4.260325-cp313-cp313-manylinux_2_28_x86_64.whl CPython 3.13 CPython 3.13 Linux glibc 2.28+ x86-64 Details
tt_umd-0.9.4.260325-cp312-cp312-manylinux_2_28_x86_64.whl CPython 3.12 CPython 3.12 Linux glibc 2.28+ x86-64 Details
tt_umd-0.9.4.260325-cp311-cp311-manylinux_2_28_x86_64.whl CPython 3.11 CPython 3.11 Linux glibc 2.28+ x86-64 Details
tt_umd-0.9.4.260325-cp310-cp310-manylinux_2_28_x86_64.whl CPython 3.10 CPython 3.10 Linux glibc 2.28+ x86-64 Details
tt_umd-0.9.4.260325-cp39-cp39-manylinux_2_28_x86_64.whl CPython 3.9 CPython 3.9 Linux glibc 2.28+ x86-64 Details

Total release size: 11.9 MB

Release files / tt_umd-0.9.4.260325-cp313-cp313-manylinux_2_28_x86_64.whl

Download URL tt_umd-0.9.4.260325-cp313-cp313-manylinux_2_28_x86_64.whl
Size 2.4 MB
Tags CPython 3.13 Linux glibc 2.28+ x86-64
SHA-256 checksum
How to use checksums
608766f6024866c0545a77871c43e44d765d3b7f1ecf18cf53fa1e67741ab0bc
BLAKE2b-256 checksum
How to use checksums
cecba345d4f2a12e50688e3ff9f4e7b690223032c56f72f5abd69ebde7cb576e
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.7

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Mar 25, 2026.

Transparency log

Release files / tt_umd-0.9.4.260325-cp312-cp312-manylinux_2_28_x86_64.whl

Download URL tt_umd-0.9.4.260325-cp312-cp312-manylinux_2_28_x86_64.whl
Size 2.4 MB
Tags CPython 3.12 Linux glibc 2.28+ x86-64
SHA-256 checksum
How to use checksums
ff1cddd8c9457050234ab53615803a9bc4e29d00050b04c2d58c623352e85af8
BLAKE2b-256 checksum
How to use checksums
dab34fea2aa7357a58bfd0de219ead7cd053e3431bce4afa524bbc3ef09ecd7c
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.7

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Mar 25, 2026.

Transparency log

Release files / tt_umd-0.9.4.260325-cp311-cp311-manylinux_2_28_x86_64.whl

Download URL tt_umd-0.9.4.260325-cp311-cp311-manylinux_2_28_x86_64.whl
Size 2.4 MB
Tags CPython 3.11 Linux glibc 2.28+ x86-64
SHA-256 checksum
How to use checksums
a2695538b3236c336454bb75c8d471a3be74fc91800a2de6cf9e7df0a78a5a50
BLAKE2b-256 checksum
How to use checksums
35a88eb2e8934bb02ffa75a363b8b9d76b6693a9062e0ae28b45f9f95afcc79b
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.7

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Mar 25, 2026.

Transparency log

Release files / tt_umd-0.9.4.260325-cp310-cp310-manylinux_2_28_x86_64.whl

Download URL tt_umd-0.9.4.260325-cp310-cp310-manylinux_2_28_x86_64.whl
Size 2.4 MB
Tags CPython 3.10 Linux glibc 2.28+ x86-64
SHA-256 checksum
How to use checksums
207fc90556d0d2abd06c5440c9471da4ba1bdae8de5526e4f00106fc6c91b717
BLAKE2b-256 checksum
How to use checksums
fd4fb92ffb228a44044f24b069986408c36124843591c633b796b5b15de14a75
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.7

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Mar 25, 2026.

Transparency log

Release files / tt_umd-0.9.4.260325-cp39-cp39-manylinux_2_28_x86_64.whl

Download URL tt_umd-0.9.4.260325-cp39-cp39-manylinux_2_28_x86_64.whl
Size 2.4 MB
Tags CPython 3.9 Linux glibc 2.28+ x86-64
SHA-256 checksum
How to use checksums
a9d13a5d32de98e316189e860ad80fd02981c44afeddc34ece76b983b75ae9df
BLAKE2b-256 checksum
How to use checksums
2fb01fccb5d7eea6093ec7a65bb6414f37d66c0e61e828a40b2d7dd7d66abc3b
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.7

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Mar 25, 2026.

Transparency log
Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page