Diese Seite ist eine aus der offiziellen TI-Dokumentation abgeleitete Referenz. Die Versionszuordnungen, Operator-Einschränkungen und der Ablauf weiter unten sind dem Stand des Repositorys edgeai-tidl-tools und der Processor-SDK-Dokumentation vom 5. September 2026 entnommen. Spikedge hat diesen Ablauf nicht auf AM67A-Hardware ausgeführt. Auf dieser Seite stehen keine Bildraten, Latenzen oder Genauigkeitswerte, und es werden auch keine hinzukommen, solange sie nicht gemessen sind — was dafür zu messen wäre, steht am Ende.

Zeit verliert man beim Portieren eines Modells auf den AM67A selten an der Toolchain selbst. Es sind drei Dinge drumherum: wo konvertiert wird, welche Werkzeugversion zu welchem SDK gehört und welche Schicht des Modells still auf den Arm-Kern zurückfällt.

Was bei int8 tatsächlich passiert — und was es kostet

Festkomma-Inferenz mit 8 oder 16 Bit bringt laut Dokumentation vier Dinge: geringere Latenz, weniger Speicherbandbreite, weniger Leistungsaufnahme und einen kleineren Speicherbedarf. Der Preis ist ein Genauigkeitsverlust, dessen Höhe von der Netzarchitektur und vom Kalibrierverfahren abhängt.

Die Entscheidungspunkte und ihre dokumentierten Einstellungen:

Entscheidung Einstellung Anmerkung
Einfache Kalibrierung accuracy_level = 0 Min/Max je Schicht. Das Repository nennt für Netze ohne Depthwise-Faltung (ResNet, SqueezeNet, VGG) typischerweise unter 1 % Genauigkeitsverlust
Erweiterte Bias-Kalibrierung accuracy_level = 1 Beschneidet Gewichte und korrigiert die Bias-Werte. Ab 50 Kalibrierbildern wird ein deutlicher Zugewinn beobachtet
Histogrammbasierte Aktivierungsbereiche accuracy_level = 9 + activation_clipping = 1 Entfernt Ausreißer; hilft bei Netzen mit stark schiefen Aktivierungsverteilungen
Asymmetrische Quantisierung advanced_options:quantization_scale_type = 4 Empfohlen auf Bausteinen, die sie unterstützen. Unterstützt auf allen SoCs außer J721E / TDA4VM — auf dem AM67A also verfügbar
Bereits quantisiertes ONNX-QDQ-Modell advanced_options:prequantized_model = 1 Umgeht die eigene Kalibrierung
TFLite-Modell in reiner Integer-Form quantization_scale_type = 3 —
Manuelle gemischte Genauigkeit params_16bit_names_list, output_feature_16bit_names_list —

Zur gemischten Genauigkeit sind zwei Punkte ausdrücklich dokumentiert:

  • Nicht jede Schicht darf ihre Genauigkeit ändern. Erlaubt ist es für TIDL_ConvolutionLayer, TIDL_BatchNormLayer (nur Clip, Relu und ohne Aktivierung), TIDL_PoolingLayer (ohne Max-Pooling) und TIDL_EltWiseLayer. Alle übrigen Schichten übernehmen Eingangs-, Ausgangs- und Parametergenauigkeit von ihrem Erzeuger oder Verbraucher — geht der Ausgang eines Concat auf 16 Bit, gehen sämtliche Eingänge mit.
  • Bei Schichten, deren Ausgang ohnehin in Gleitkomma vorliegt (Softmax, DetectionOutput), hat eine höhere Aktivierungsgenauigkeit keine Wirkung.

Nicht unterstützte Operatoren fallen zurück, ohne zu scheitern

Trifft die Toolchain auf einen Operator, den sie nicht beschleunigen kann, bricht sie nicht ab — sie führt ihn auf dem Cortex-A-Kern aus. Das Repository formuliert es unmissverständlich: jeder nicht unterstützte Operator läuft als Teil der jeweiligen Laufzeitumgebung auf dem Cortex-A. Das Modell läuft, das Ergebnis stimmt, es ist nur langsamer als erwartet — und der Grund ist von außen nicht sichtbar.

Die meisten Einschränkungen der Operatorentabelle gelten für alle Bausteine. Vier davon nennen jedoch den AM67A (und den AM62A) namentlich — Grenzen also, die dieses Bauteil trägt und andere der Familie nicht:

Operator Einschränkung speziell für AM62A und AM67A
Conv Kernelgröße 3×3 mit Schrittweite 3 wird nicht unterstützt
Conv Padding größer als die Eingangsbreite wird nicht unterstützt
Conv Eingangsbreite kleiner als MAX(PadL, PadR) wird nicht unterstützt
ConvTranspose 16-Bit-Deconvolution wird nicht unterstützt

Das sind Architekturentscheidungen, keine Schalter beim Übersetzen. Der letzte Punkt bindet unmittelbar jeden Plan zur gemischten Genauigkeit: eine ConvTranspose-Schicht auf dem AM67A zugunsten der Genauigkeit auf 16 Bit zu heben, ist keine Option.

Einige für alle Bausteine geltende Einschränkungen, die in der Praxis am häufigsten zuschlagen:

  • Conv: Depthwise-Faltung (vollständig gruppiert) nur für die Filter 1×3s1, 3×3s1, 3×3s2, 5×5s1, 5×5s2, 7×7s1 und 7×7s2.
  • ConvTranspose: nur 4×4-, 3×3- und 2×2-Kernel mit Schrittweite 2×2. Die Dokumentation empfiehlt, nach Möglichkeit auf Resize/Upsample zu wechseln, da effizienter.
  • Resize: nur Zweierpotenzen als Skalierung, nur Breiten- und Höhenachse, keine Skalierung kleiner als 1.
  • GlobalAveragePool: die Ebenengröße (Höhe × Breite) darf 1024 nicht überschreiten.
  • Softmax: nur entlang Breiten- und Höhenachse.
  • Slice/Split: nur Batch-Größe 1.

Der erste Arbeitsschritt vor einer Portierung ist daher, die Netzarchitektur auf Graphebene gegen diese Liste zu prüfen. Nach der Konvertierung zurückgefallene Schichten zu zählen, ist der deutlich teurere Weg zur selben Erkenntnis.

Konvertierung und Inferenz laufen nicht auf derselben Maschine

Diese strukturelle Regel wird am häufigsten übersehen und steht klar in der Tabelle des Repositorys:

Vorgang x86-PC TI-SoC
Modellkonvertierung ✔ ✘
Inferenz ✔ ✔
Vorgang Python-API C++-API
Modellkonvertierung ✔ ✘
Inferenz ✔ ✔

Also: konvertiert wird ausschließlich auf einem x86-Host und ausschließlich über Python. Auf dem Zielsystem gibt es keine Konvertierung, über die C++-Schnittstelle ebenfalls nicht. Die Platine lädt Artefakte, die auf dem Host entstanden sind. Wer auf einer Platine über einen fehlenden Übersetzer stolpert, versucht meist etwas, das nicht vorgesehen ist.

Daraus folgt: Die Entwicklungsumgebung besteht aus zwei Hälften, und beide Hälften müssen versionsseitig zueinander passen.

Versionszuordnung

Das Tag von edgeai-tidl-tools und die Processor-SDK-Version auf der Platine hängen zusammen. Das Repository veröffentlicht, gegen welches SDK ein Tag validiert wurde. Für die Zeile AM67A / J722S / TDA4AEN:

Tag edgeai-tidl-tools Validiert gegen 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 für AM67A nicht validiert (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

Drei Punkte ergeben sich daraus:

1. 11_02_04_00 ist eine Falle. Das Repository führt es als Standard für J721E, J721S2 und J784S4 — und schreibt in die Zeile AM67A/J722S ein N/A. Der Familienstandard ist für dieses Bauteil nicht validiert; das entsprechende Release auf diesem Zweig heißt für den AM67A 11_02_12_00.

2. Die Unterstützung des AM67A beginnt bei 09.02. In den Abschnitten für 09.01 und früher fehlt die Zeile J722S/AM67A vollständig, während AM62A, TDA4VM, AM68A und AM69A dort stehen. Ein Plan, der den AM67A mit einer älteren Werkzeugversion adressiert, setzt etwas voraus, das die Dokumentation nicht hergibt.

3. Der schärfste Punkt zeigt sich erst zusammen mit der Dokumentenübersicht. Der aktuelle Zweig verweist für den AM67A auf Processor SDK Linux/RTOS 11.02.01.03. Diese Version erscheint aber nur auf der SDK-Seite unter dem Namen J722S; das Linux-SDK auf der AM67A-Seite steht weiterhin bei 11.00.00.08. Ein Team, das ti.com/tool/PROCESSOR-SDK-AM67A verfolgt, arbeitet damit auf einem SDK, das nicht zum aktuellen Zweig passt, und müsste auf das Tag 11_00_06_00 oder 11_00_08_00 zurückgehen, um eine dokumentierte Zuordnung zu erhalten. Woher diese Namensspaltung kommt, steht in der AM67A / J722S Dokumentenübersicht.

Für Patch-Releases weist das Repository zusätzlich darauf hin, dass Firmware und Bibliotheken auf dem SoC ebenfalls aktualisiert werden müssen; das Tag auf dem Host zu wechseln genügt nicht.

Laufzeitversionen sind an das Tag gebunden

Mit dem Zweig oder Tag wählen Sie auch die Laufzeitversionen; einzeln aktualisieren lassen sie sich nicht. Auf dem aktuellen Zweig:

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

Artefakte passen nicht in jede Laufzeitumgebung

Die bei der Konvertierung gewählte Laufzeitumgebung schränkt ein, wo das Artefakt später laufen kann:

  • Ein über onnxrt erzeugtes Artefakt läuft nur unter onnxrt und tidlrt.
  • Ein über tflitert erzeugtes Artefakt läuft nur unter tflitert und tidlrt.
  • Für tidlrt sind Artefakte unabhängig von der bei der Konvertierung verwendeten Laufzeitumgebung — aber nur, wenn sämtliche Knoten des Modells ausgelagert wurden.

Die letzte Bedingung verbindet diesen Abschnitt mit dem Operator-Kapitel oben: Bleibt eine einzige Schicht auf dem Arm-Kern, ist das Artefakt nicht laufzeitunabhängig.

Der dokumentierte Ablauf

Die folgenden Schritte sind der in der README von edgeai-tidl-tools veröffentlichte Ablauf. Spikedge hat diese Befehle nicht auf AM67A-Hardware ausgeführt; sie stehen hier, um die Form des Ablaufs zu zeigen und sichtbar zu machen, wo die Abhängigkeiten von Version und Umgebungsvariablen liegen. Vor der Anwendung bitte gegen die README desjenigen Tags prüfen, das zu Ihrer SDK-Version gehört.

Auf dem Host (x86, Python 3.10):

git clone https://github.com/TexasInstruments/edgeai-tidl-tools.git
cd edgeai-tidl-tools
git checkout <zu Ihrer SDK-Version passendes TAG>
./scripts/setup/setup.sh
source ./scripts/setup/setup_env.sh <SOC>

<SOC> ist der Name der Bausteinfamilie aus der Tabelle „Supported Devices" — für den AM67A ist das J722S, dieselbe Namensspaltung noch einmal. Das Repository weist gesondert darauf hin, dass nicht gesetzte Umgebungsvariablen eine häufige Fehlerursache sind.

Konvertierung und Inferenz laufen als zwei Schalter desselben Beispielskripts:

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

Die Artefakte werden nach ./runtimes/examples/model-artifacts/ geschrieben; das ist, was auf die Platine wandert. Auf der C++-Seite gibt es nur ein Inferenzbeispiel, keine Konvertierung.

Was diese Seite nicht beantworten kann

Keine der folgenden Fragen lässt sich aus offizieller Dokumentation beantworten; alle verlangen eine Messung auf Hardware. Da Spikedge diese Messungen nicht vorgenommen hat, steht hier auch keine Schätzung:

  • Wie viele Bilder pro Sekunde ein benanntes Modell bei einer angegebenen Eingangsauflösung auf dem AM67A tatsächlich erreicht.
  • Wofür der Spitzenwert von 4 TOPS in einem realen Netz steht.
  • Welche Schichten auf den Arm-Kern zurückfallen und was das Ende zu Ende kostet.
  • Wie sich der Wettbewerb um Speicherbandbreite auswirkt, wenn ISP und C7x gleichzeitig arbeiten.
  • Welchen realen Genauigkeitsunterschied die accuracy_level-Optionen an einem konkreten Netz machen.

Jede dieser Fragen braucht einen Messplatz, und keine davon lässt sich ohne einen solchen redlich beantworten. Sobald gemessen wurde, erscheinen die Ergebnisse samt Randbedingungen (Modell, Eingangsauflösung, SDK-Version, thermischer Zustand, ob der ISP mitläuft) unter technische Nachweise. Eine Bildrate ohne Randbedingungen ist nicht aussagekräftiger als die TOPS-Angabe, die sie ersetzen soll.

Weiterführende Spikedge-Seiten

Quellen