This is a reference page derived from official TI documentation. The version pairings, operator constraints and command flow below are read from the state of the edgeai-tidl-tools repository and the Processor SDK documentation on 5 September 2026. Spikedge has not executed this flow on AM67A hardware. There are no frame rates, latencies or accuracy results on this page, and there will not be any until they are measured — what would have to be measured is listed at the end.

What costs teams time when moving a model onto the AM67A is usually not TIDL itself. It is three things around it: where compilation happens, which tool version pairs with which SDK, and which layer of your model quietly falls back to Arm.

Compilation and inference do not happen on the same machine

This is the most-skipped structural rule of the flow, and it is stated plainly in the repository's own table:

Operation x86 PC TI SoC
Model compilation ✔ ✘
Model inference ✔ ✔
Operation Python API C++ API
Model compilation ✔ ✘
Model inference ✔ ✔

So: compilation runs only on an x86 host, and only through Python. There is no on-target compilation and no C++ compilation path. The board loads and runs artifacts produced on the host. Teams that hit "TIDL compiler not found" on a board are usually attempting something that is not supported rather than something that is broken.

The practical consequence is that your development environment has two halves, and the two halves have to agree on versions. That is where the real trap lives.

Version pairing: the most important table on this page

The edgeai-tidl-tools tag and the Processor SDK version on the board are coupled. The repository publishes which tag was validated against which SDK. For the AM67A / J722S / TDA4AEN row:

edgeai-tidl-tools tag Validated against Processor SDK (Linux / RTOS)
11_02_16_00 11.02.01.03 / 11.02.01.03
11_02_12_00 11.02.00.06 / 11.02.00.10
11_02_04_00 Not validated for AM67A (N/A)
11_01_06_00 11.01.00.03 / 11.01.00.04
11_00_06_00, 11_00_08_00 11.00.00.08 / 11.00.00.06
10_01_00_02 10.01.00.04 / 10.01.00.04
10_00_02_00 10.00.00.08 / 10.00.00.05
09_02_06_00 09.02.00.05 / 09.02.00.05

Three things fall out of that table:

1. 11_02_04_00 is a trap. The repository marks it the default for J721E, J721S2 and J784S4 — and writes N/A on the AM67A/J722S row. The family default is not validated for this part; the corresponding release for the AM67A on that branch is 11_02_12_00.

2. AM67A support starts at 09.02. In the 09.01 and earlier sections of the table the J722S/AM67A row is simply absent, while AM62A, TDA4VM, AM68A and AM69A are present. A plan that targets the AM67A with an older tool version is assuming something the documentation does not carry.

3. The sharpest point appears only when you put this next to the documentation map. The current branch of the repository points the AM67A at Processor SDK Linux/RTOS 11.02.01.03. But that version is published only on the J722S-branded SDK page; the Linux SDK on the AM67A-branded page is still at 11.00.00.08. So a team following ti.com/tool/PROCESSOR-SDK-AM67A is running an SDK that does not pair with the current edgeai-tidl-tools branch, and would have to fall back to the 11_00_06_00 or 11_00_08_00 tag to get a documented pairing. Where that naming split comes from is covered in the AM67A / J722S documentation map.

The repository also notes that for patch releases the firmware and libraries on the SoC have to be updated too; changing the tag on the host alone is not enough.

Runtime versions are fixed by the tag

Choosing a branch or tag also chooses your runtime versions — they are not independently upgradable. On the current branch:

Runtime Version
ONNX Runtime 1.23.0
TFLite Runtime 2.12.0
TVM Runtime 0.18.0
ONNX 1.14.0 (OPSET-21, IR-10)

Artifacts do not plug into every runtime

The runtime you compile with constrains where the artifact can run:

  • An artifact compiled through onnxrt runs only under onnxrt and tidlrt.
  • An artifact compiled through tflitert runs only under tflitert and tidlrt.
  • For tidlrt, artifacts are agnostic of the runtime used at compile time — but only if every node of the model is offloaded.

That last condition matters, and it leads directly into the next section: if a single layer in your model is not offloaded, the artifact is not runtime-agnostic.

The AM67A's own operator constraints

TIDL does not fail on an operator it cannot accelerate — it falls back to the Cortex-A core. The repository says so directly: "any unsupported operator will execute on cortex-A Core as part of the corresponding runtime." The model runs, the output is correct, it is just slower than you expected, and the reason is invisible.

Most constraints in the operator table apply to every device. But four of them name the AM67A (and AM62A) explicitly — limits this part carries that others in the family do not:

Operator Constraint specific to AM62A and AM67A
Conv Kernel size 3×3 with stride 3 is not supported
Conv Padding greater than the input width is not supported
Conv Input width smaller than MAX(PadL, PadR) is not supported
ConvTranspose 16-bit deconvolution is not supported

These are architecture decisions, not compile flags. The last one binds directly on any mixed-precision plan: raising a ConvTranspose layer to 16 bit for accuracy is not an option on the AM67A.

A handful of all-device constraints that bite most often in practice:

  • Conv: depthwise (fully grouped) convolution is supported only for 1×3s1, 3×3s1, 3×3s2, 5×5s1, 5×5s2, 7×7s1 and 7×7s2 filters.
  • ConvTranspose: only 4×4, 3×3 and 2×2 kernels with 2×2 stride. The docs suggest switching to Resize/Upsample where possible, as it is more efficient.
  • Resize: power-of-two scales only, width and height axes only, no scale below 1.
  • GlobalAveragePool: plane size (height × width) cannot exceed 1024.
  • Softmax: only along the width and height axes.
  • Slice/Split: batch size 1 only.

Before porting a model to the AM67A, the first job is to check the architecture against this list at the graph level. Counting fallen layers after compilation is a far more expensive way to learn the same thing.

Quantization decisions

TIDL supports 8-bit, 16-bit and mixed precision. The decision points and their documented settings:

Decision Setting Note
Simple calibration accuracy_level = 0 Per-layer min/max. The repository reports typically under 1% accuracy drop for networks without depthwise convolution (ResNet, SqueezeNet, VGG)
Advanced bias calibration accuracy_level = 1 Clips weights and corrects biases. The docs report a considerable improvement observed at 50 or more calibration images
Histogram-based activation range accuracy_level = 9 + activation_clipping = 1 Removes outliers; helps networks with highly skewed activation distributions
Asymmetric quantization advanced_options:quantization_scale_type = 4 Recommended on devices that support it. Supported on all SoCs except J721E / TDA4VM — so it is available on the AM67A
Pre-quantized ONNX QDQ model advanced_options:prequantized_model = 1 Bypasses TIDL's own calibration
TFLite full-integer model quantization_scale_type = 3 —
Manual mixed precision params_16bit_names_list, output_feature_16bit_names_list —

Two things about mixed precision are stated explicitly in the documentation:

  • Not every layer can change precision. The ones that can: TIDL_ConvolutionLayer, TIDL_BatchNormLayer (Clip, Relu and no-activation only), TIDL_PoolingLayer (excluding max pooling) and TIDL_EltWiseLayer. Every other layer takes its input, output and parameter precision from its producer or consumer — if a Concat output goes to 16 bit, all of its inputs go to 16 bit with it.
  • For layers whose output is already floating point (Softmax, DetectionOutput), raising activation precision has no effect.

The documented command flow

The steps below are the flow published in the edgeai-tidl-tools README itself. Spikedge has not run these commands on AM67A hardware; they are reproduced here to show the shape of the flow and where the version and environment-variable dependencies land. Confirm against the README of the tag matching your own SDK version before applying them.

On the host (x86, Python 3.10):

git clone https://github.com/TexasInstruments/edgeai-tidl-tools.git
cd edgeai-tidl-tools
git checkout <TAG compatible with your SDK version>
./scripts/setup/setup.sh
source ./scripts/setup/setup_env.sh <SOC>

<SOC> is the device-family name from the "Supported Devices" table — for the AM67A that family is J722S, the same naming split showing up one more time. The repository separately warns that missing environment variables are a common cause of errors.

Compilation and inference run as two flags on the same example script:

python3 basic_example.py --config ./config.yaml -r onnxrt --compile
python3 basic_example.py --config ./config.yaml -r onnxrt --infer

Artifacts are written under ./runtimes/examples/model-artifacts/; that is what moves to the board. On the C++ side there is an inference example only — no compilation.

What this page cannot tell you

None of the questions below can be answered from official documentation; all of them require measurement on hardware. Because Spikedge has not made those measurements, no estimate is offered here either:

  • How many frames per second a named model at a stated input resolution actually runs at on the AM67A.
  • What the 4 TOPS peak figure corresponds to on a real network.
  • Which layers fall back to Arm and what that costs end to end.
  • What memory-bandwidth contention between the ISP and the C7x does when both are running.
  • The real accuracy difference between accuracy_level options on a given network.

Every one of these needs a bench, and none of them can be written honestly without one. When these are measured, the results will be published with their conditions (model, input resolution, SDK version, thermal state, whether the ISP was running) under technical proofs. An unconditioned frame-rate number is no more informative than the TOPS marketing it would be replacing.

Related Spikedge pages

Sources