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.

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

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 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

Comparison#