cpptb command line¶
The complete reference for the cpptb command. For the workflow around it —
registering tests, project layout, structured results — see
Running tests; for the configuration file the command
reads, see cpptb.toml.
Configuration precedence is command-line options first, then cpptb.toml,
then filesystem conventions. Every option below therefore overrides its
cpptb.toml counterpart for one invocation without editing the project.
cpptb --version
cpptb build --help
Commands¶
Command |
Purpose |
|---|---|
|
Resolve the project, generate DUT bindings, and build the simulator executable |
|
Build if needed, then list the compiled test catalog |
|
Build if needed, then run all tests or the named tests serially |
Each test runs in its own fresh simulator process; cpptb test with no
names runs the whole catalog.
Project and build options¶
All three commands accept the same selectors:
Option |
Purpose |
|---|---|
|
Project directory; defaults to the current directory |
|
RTL source, directory, or glob; repeat for multiple inputs |
|
C++ testbench source, directory, or glob; repeat as needed |
|
Select the SystemVerilog DUT top module |
|
Override the generated simulator target name |
|
Build root, relative to the project unless absolute |
|
Simulator backend; currently Verilator |
|
Locate a cpptb checkout, install prefix, or include directory |
|
Override |
|
Override |
|
Build with waveform tracing and dump one wave file per test, landing beside its result as |
|
Request experimental four-state mode after a Verilator semantic capability probe (currently upstream-blocked; see Four-state values) |
|
Ignore the content cache and rebuild |
|
Show normally hidden generation and compiler commands |
This --top selects the HDL DUT and is separate from PeakRDL’s register-map
--top; register generation and its naming options are documented in
Generate a register model.
Per-command options¶
Option |
Command |
Purpose |
|---|---|---|
|
|
Wall-time limit for catalog discovery |
|
|
Wall-time limit, applied independently to each test process |
|
|
Result directory (default: |
The wall-time --timeout is a harness limit on the OS process. It is
separate from the in-simulation watchdog, run.timeout_cycles in
cpptb.toml, which ends a hung test from inside the
simulator with a specific diagnostic.
Exit codes¶
CI can distinguish a red test from broken plumbing:
Code |
Meaning |
|---|---|
|
Every selected test passed (skips and expected failures count as success) |
|
At least one test failed or errored during its run |
|
The run never started: project, configuration, generation, or build error — the diagnostic is on stderr, prefixed |
cpptb-run follows the same convention.
Environment variables¶
There is no --seed option: the seed route is the CPPTB_RANDOM_SEED
environment variable (decimal or 0x-prefixed hex, default 1), which
cpptb test propagates into each simulator process — set it once and every
test in the run replays deterministically. The complete set a built
simulator reads — CPPTB_TEST, CPPTB_LIST_TESTS, CPPTB_RANDOM_SEED,
CPPTB_LOG_LEVEL, CPPTB_RESULT_FILE, CPPTB_WAVE — is tabulated in the
TestContext reference, and
Seeds, streams, and replay covers the
replay workflow.
Lower-level commands¶
Three lower-level entry points exist for custom build systems and harnesses; ordinary projects do not need them:
cpptb-codegendrives generation directly from RTL sources — see Code generation.cpptb-runexposes the runner’s executable protocol — see Running tests.cpptb-rggenimports native RgGen YAML/JSON/TOML register contracts — see Generate a register model.