tigris codegen

Generate backend-specific C source code from a compiled .tgrs plan. The generated harness sets up runtime memory, selects the requested kernel dispatch, and loads the plan from the target’s normal deployment location.

See Operator and Backend Support for the generated native, fallback, and unsupported routes behind each selection.

Usage#

tigris codegen PLAN [OPTIONS]

Options#

Examples#

Generate reference C code:

tigris codegen model.tgrs -o model.c

Generate for ESP-NN backend:

tigris codegen model.tgrs --backend esp-nn -o model_esp.c

Generate for CMSIS-NN backend:

tigris codegen model.tgrs --backend cmsis-nn -o model_cmsis.c

Generate an embeddable deployment core for an existing application:

tigris codegen model.tgrs --backend cmsis-nn --format core \
  -o generated/tigris_codegen_core.c \
  --header generated/tigris_codegen_core.h \
  --name model_codegen

Output formats#

app (default)#

--format app emits a self-contained example harness with an entry point and the backend’s normal plan-location convention. It is the quickest path for a new deployment or for verifying a generated plan.

core#

--format core emits a C source file and public header for embedding in an application that already owns its entry point, flash placement, arena buffers, input source, or telemetry. It is backend-specific but platform-neutral: no hardware target is selected by codegen.

The generated core provides functions to load the supplied plan bytes, initialize runtime memory and the selected backend, reset activations between inferences, obtain its dispatcher, and run inference. The embedding application supplies plan bytes, fast and slow arenas, the tensor-pointer table, and optionally an input-initialization callback. This fits bare-metal firmware, RTOS applications, and custom instrumentation without copying generated runtime setup into application code.

The generated header exports model-specific constants for tensor-table capacity, plan budget, and compressed-weight reserve. Use --name to choose a C-identifier prefix for its functions, types, and macros; this lets multiple generated cores coexist in the same firmware. --header and --name apply only to --format core.

When to Use Codegen vs. Loading .tgrs#

There are two ways to deploy a compiled plan to your device:

Loading .tgrs at runtime#

The plan is stored in a flash partition and loaded at runtime with tigris_plan_load().

Advantages:

• Swap models without recompiling firmware by reflashing the plan partition
• Smaller firmware binary (plan is separate)
• Multiple models can share the same firmware

When to use: Devices with a flash partition table, applications that need model updates in the field, development/iteration workflows.

# Compile the plan
tigris compile model.onnx -m 256K -o model.tgrs

# Flash to partition
scripts/flash_plan.sh model.tgrs

Codegen app harness#

The generated C file contains the runtime setup and backend dispatch glue. The plan remains a .tgrs binary: ESP-IDF builds load it from a flash partition, Cortex-M examples reference linker-provided flash symbols, and POSIX examples read it from a file path.

Advantages:

• Keeps target-specific runtime setup in generated code
• Lets the same .tgrs plan be used with different backend harnesses
• Supports targets with different plan placement conventions

When to use: Firmware projects that want generated runtime glue while keeping the plan as a deployable .tgrs artifact.

# Compile the plan, then generate C code
tigris compile model.onnx -m 256K -o model.tgrs
tigris codegen model.tgrs --backend cmsis-nn -o model.c

# Add model.c to your firmware build and deploy model.tgrs for your target

Use --format core instead when the application must retain control of its entry point, plan placement, memory ownership, or measurement/reporting loop.

Comparison#