Hiring, or looking for work? Employers: post a job on Far Reach, compare proposals, and fund a milestone that is released when you accept the work. Freelancers: join Far Reach and get hired for what you do best. Post a job on Far Reach →Join as a freelancer →
Advertisement
Buy and Sell your new and used items in Nouhata.com
Visit Nouhata.com →
Advertisement
Project and team management with CSMS.work
Visit CSMS.work →

TSystemC 1.0.0 for Windows x64

SystemC, TLM-2.0 and power modeling

A SystemC simulator that implements IEEE 1666-2023 and adds power: domains, DVFS, power gating, power states and the energy of every transaction, from the first architecture model onwards.

Free release

Download

Version: 1.0.0 (Windows x64)

The simulator library for g++ and Visual C++, the tsystemc command line, the host DLL, the programmer guide, and examples from a first counter to a power-aware TLM SoC.

Download TSystemC 1.0.0SHA-256 checksum

Release details

Released 11 October 2026 • 2,410,318 bytes • Windows x64 • Free of charge, including commercial use

SHA-256
1898b870cd2fee702ab17f935380052fe7bd88f0f4e82a72b0ed1bad97eac8ea

Programmer Guide

Ships inside the download as Markdown and HTML, and is readable here as well.

Open the guide

What it covers

The standard, and then power

IEEE 1666-2023 SystemC

Kernel, processes and process control, events, every predefined channel, ports and exports, integer, bit-vector, logic and fixed-point data types, reporting, VCD tracing. Where the standard and the reference implementation differ, TSystemC follows the standard.

TLM-2.0 and TLM-1

Generic payload, base protocol, blocking and non-blocking transport, DMI, debug transport, temporal decoupling, all the tlm_utils sockets and payload event queues, analysis ports and TLM-1 FIFOs.

Power modeling

Power domains with DVFS operating points and power gating; power states with static and dynamic power; transitions with latency and energy; energy per operation and per byte; wake and sleep policies; a DVFS clock; reports and CSV/VCD power traces.

Energy per transaction

Targets and interconnects charge their energy with one call; an initiator that attaches power_extension learns what each transaction cost along its whole path, and sleeping targets add their wake-up latency to it.

Scriptable and hostable

tsystemc runs models, steps them from scripts with run, get, set, expect and power, and serves them over MCP so an AI agent can drive a simulation.

Co-simulation

tsystemc.dll exposes a plain C API, and DPI-C entry points a SystemVerilog test bench imports to run a SystemC model in lock-step with RTL.

Getting started

Quick start

Unzip, put bin on the PATH, and run an example. tsystemc run compiles the model the first time and caches it.

set PATH=C:\tools\tsystemc-1.0.0\bin;%PATH%
cd C:\tools\tsystemc-1.0.0\examples\power_dvfs
tsystemc run power_dvfs.cpp

The end of its output:

fixed:    6.92 uJ, 0 deadline(s) missed
governed: 5.446 uJ, 0 deadline(s) missed
DVFS saves 21.3 % of the energy

To build a model yourself with g++:

g++ -std=c++17 -O2 -IC:\tools\tsystemc-1.0.0\include model.cpp C:\tools\tsystemc-1.0.0\lib\libsysc.a -static -o model.exe

Power modeling

A power model in a dozen lines

States, transitions and operations are described at the domain's nominal voltage and frequency; the model scales them as the domain changes operating point, and integrates energy exactly between events.

#include <sc_power.h>
using namespace sc_power;

struct Core : sc_module {
    power_domain dom{"dom", 1.0, sc_time(10, SC_NS)};   // 1.0 V, 100 MHz
    power_model  power{"power", dom};
    dvfs_clock   clk{"clk", dom};

    SC_CTOR(Core) {
        power.add_state("run", 2e-3, 18e-3)              // leakage, dynamic (W)
             .add_state("idle", 2e-3)
             .add_state("sleep", 0.2e-3)
             .add_transition("sleep", "run", sc_time(2, SC_US), 40e-9)
             .add_operation("instr", 50e-12)              // J per instruction
             .set_wake_state("run")
             .set_idle_policy(sc_time(3, SC_US), "sleep", "idle");
        SC_THREAD(work);
    }
    void work() {
        wait(power.consume("instr", 0, 1000));            // wakes up if asleep
        wait(dom.cycles(1000));
        power.set_state("idle");
    }
};

The report, from the power-aware SoC example:

model       state         power       avg power   energy      static      dynamic     transitions
cpu.power   sleep         225 uW      19.8 mW     1.466 uJ    132.7 nJ    1.315 uJ    18 nJ (5)
bus.power   on            1 mW        1.713 mW    126.8 nJ    74.01 nJ    52.8 nJ     0 J (0)
dram.power  self_refresh  3 mW        13.31 mW    985.4 nJ    519.6 nJ    435.8 nJ    30 nJ (13)
accel.power ready*        0 W         3.719 mW    275.3 nJ    33.84 nJ    241.4 nJ    0 J (6)
total                     4.225 mW    45.71 mW    3.383 uJ  (domain switching 530 nJ)

Known limitations

  • Windows x64 only in this release.
  • The g++ libraries are built with TDM-GCC 10.3.0; other MinGW-w64 GCC builds using MSVCRT should work but are not tested, and a UCRT-based g++ will not link them.
  • Leakage power is linear in voltage and does not depend on temperature; there is no thermal model and no UPF import.
  • Power results are only as accurate as the numbers a model is given; calibrate them against measurements or sign-off tools.

Disclaimer

TSystemC is supplied "AS IS" and "AS AVAILABLE", without express or implied warranties. Although reasonable efforts have been made to develop and test it, it has not been exhaustively tested under all operating conditions, hardware configurations, software environments, or application scenarios.

Users are solely responsible for evaluating, testing, validating, and determining suitability before use. The software is not intended for safety-critical, life-critical, medical, aviation, nuclear, military, emergency-response, or other mission-critical systems unless independently verified and accepted by the user for such purposes.

To the maximum extent permitted by applicable law, chapAI.ai and its authors shall not be liable for direct, indirect, incidental, consequential, or special damages arising from use of, or inability to use, the software.