AM67A Bildverarbeitung: Wo die Latenz zwischen Sensor und Entscheidung entsteht

Einen ISP, eine Engine für optischen Fluss und eine für Stereo-Disparität in der Merkmalsliste eines SoC zu sehen, wirkt beruhigend. Aber allein dass Beschleuniger vorhanden sind, macht die Ende-zu-Ende-Latenz nicht klein. Ausschlaggebend ist nicht, welche Blöcke existieren, sondern wie oft ein Bild in den Speicher geschrieben und wieder gelesen wird, welche Ressource sich wie viele Kameras teilen und an welcher Stelle der Kette eine Kopie entsteht. Dieser Artikel verfolgt ein einzelnes Bild auf dem TI AM67A vom Sensor bis zur Entscheidung und zeigt an jeder Station, wohin die Zeit geht. Grundlage sind das Technical Reference Manual SPRUJB3D (August 2026) und das AM67x-Datenblatt SPRSPA3B. Für diesen Artikel wurden von Spikedge keine eigenen Messungen durchgeführt; alle genannten Zahlen sind veröffentlichte Spitzenwerte.

Der Weg

Sensor → CSI-2 RX (×4) → Video-Stream-MUX → VISS → [SL2] → LDC / MSC
       → DDR ↔ DMPAC (DOF, SDE) → C7x + MMA → Cortex-A53 → R5F

Vier Beschleuniger und mindestens zwei Speicherebenen. Jede Station unten beschreibt, was sie tut und was sie kostet.

Dieser Artikel behandelt das Bildverarbeitungs-Subsystem, nicht den SoC insgesamt; wie die Blöcke im Baustein liegen und welche Varianten sie tragen, steht in unserer AM67A-Architekturanalyse.

1. Vom Sensor zur CSI-2-Schnittstelle

Der AM67A besitzt vier unabhängige CSI-2-Empfänger mit je vier D-PHY-Lanes und bis zu 2,5 Gbit/s je Lane, konform zu MIPI CSI-2 v1.3 und D-PHY 1.2, mit bis zu 16 virtuellen Kanälen je Eingang.

Daraus folgen zwei Entwurfsentscheidungen:

• Lane-Budget. Vier Lanes mit 2,5 Gbit/s ergeben 10 Gbit/s Rohbandbreite. Ein 12-Bit-RAW-Datenstrom mit 1920×1080 bei 60 fps liegt bei etwa 1,5 Gbit/s. Die Lane-Zahl am Sensor auszurichten ist deshalb keine Pedanterie, sondern gesparte Leistung.
• Virtuelle Kanäle oder getrennte Ports? Ein Deserializer kann mehrere Sensoren auf einen Port bündeln — zum Preis geteilter Bandbreite. Vier getrennte Ports trennen die Bandbreite, kosten aber Pins und Fläche.

Ein Errata-Eintrag betrifft genau diese Stelle: i2190 hält fest, dass die CSI-Empfangsschnittstelle nach einem unvollständigen oder CRC-fehlerhaften Bild in einen undefinierten Zustand geraten kann und ein Modul-Reset nötig wird. In einem Mehrkamerasystem unter Vibration ist das ein Wiederherstellungspfad, den man im Treiber vorsehen muss — er zeigt sich, wenn im Feld eine Steckverbindung nachlässt, nicht auf dem Labortisch.

2. Der Video-Stream-MUX: vier Kameras, ein VPAC

Dies ist der wichtigste Abschnitt des Artikels.

Im VPAC-Blockschaltbild des TRM münden vier CSI_RX_IF-Blöcke in einen Video-Stream-MUX, aus dem ein einziges VISS hervorgeht. Das TRM sagt es ausdrücklich:

„The VPAC is designed to support multiple cameras by working in time-multiplexing mode."

Der AM67A hat also vier Kameraeingänge und eine Bildverarbeitungskette, die sich diese Kameras zeitlich teilen. Die Gerätetabellen führen eine VPAC- und eine DMPAC-Instanz.

Das schlägt unmittelbar auf das Zeitbudget durch:

• In einem Vierkamerasystem wird die ISP-Kapazität geteilt, nicht vervielfacht. Die im Datenblatt genannten 600 MP/s sind der Gesamtwert der Kette, nicht ein Wert je Kamera.
• Zeitmultiplex bedeutet Warten. Das Bild der vierten Kamera reiht sich hinter den anderen drei ein. Im Mittel wirkt diese Wartezeit klein, im ungünstigsten Fall nähert sie sich einer Bildperiode.
• Kamerasynchronisation ist eine eigene Aufgabe. Vier gleichzeitig aufgenommene Bilder sind nicht vier gleichzeitig verarbeitete Bilder.

„Unterstützt vier Kameras" ist richtig. „Verarbeitet vier Kameras parallel" nicht. Wenn ein Stereopaar und eine Rundumkamera denselben SoC teilen, gehört das Zeitbudget auf diese Teilung aufgebaut.

3. VISS: vom Rohpixel zum Bild

VISS ist der Teil des VPAC, der die Rohdaten des Sensors verarbeitet. Die im TRM aufgeführten Teilblöcke:

Das Datenblatt bezeichnet diesen Block mit dem Referenznamen VPAC3L und nennt 600 MP/s ISP-Durchsatz, 12-Bit-RGB-IR, RAW-Eingang bis 16 Bit und Zeilenbreite bis 4096. Das TRM spricht schlicht von „VPAC"; die Liste der Teilblöcke existiert nur dort. Ein Block, den man im Datenblatt nicht findet, fehlt nicht zwangsläufig — NSF4V, GLBCE und CAC stehen nicht in der Merkmalsliste des Datenblatts, wohl aber im TRM.

Zwei Fähigkeiten wiegen hier schwerer als der Rest.

RGB-IR. Aus einem Sensor sowohl einen sichtbaren als auch einen Infrarotkanal zu gewinnen und im ISP zu trennen, erspart eine zweite IR-Kamera — und damit Stückkosten wie Ausrichtungsaufwand.

Gleichzeitige HV- und MV-Ausgabe. Das TRM hält fest, dass der VPAC „simultaneous visual (HV) and analytics (MV) output to system memory" erzeugt, und beschreibt das als „saving need for additional read from system memory for HV+MV processing". Mit anderen Worten: Das Bild für die Anzeige und das Bild für die maschinelle Auswertung entstehen in einem Durchgang. In einem Mehrkamerasystem ist die dadurch gesparte Speicherbandbreite erheblich.

Dieses eine Merkmal erklärt einen großen Teil des Unterschieds zwischen einer naiv und einer sauber aufgebauten Kette.

4. SL2 und HTS: die eigentliche Geschichte im VPAC

Wer wissen will, wohin in einer Beschleunigerkette die Zeit geht, liest diesen Abschnitt.

Im VPAC stecken zwei Infrastrukturbausteine:

• SL2 (Shared Level 2) — VPAC-eigener gemeinsamer Speicher. VISS, LDC, MSC und die übrigen Teilmodule tauschen ihre Daten darüber aus; Transfers von und nach DDR/MSMC laufen über die K3-DMA-Architektur.
• HTS (Hardware Thread Scheduler) — führt die Verständigung zwischen den Teilmodulen und der lokalen DMA-Engine (UTC) in Hardware aus.

Die Folge: Übergänge zwischen Blöcken innerhalb des VPAC müssen nicht über DDR laufen. Daten aus VISS erreichen LDC über SL2, und das TRM führt zusätzlich einen Pfad „VISS to LDC direct OTF (on-the-fly) for multi-camera" auf — im Fluss, ganz ohne Speicherzugriff.

Demgegenüber sind LDC und MSC beschrieben als „reads data from memory (DDR or on-chip) to internal SL2 memory". Ruft man diese Blöcke einzeln auf, kommt die Eingabe aus dem Speicher.

Genau hier liegt die Entwurfsentscheidung:

• Wird die Kette verkettet aufgebaut (VISS → LDC im Fluss), entfällt der DDR-Umweg samt seiner Bandbreitenkosten.
• Wird sie blockweise aufgebaut — bei jedem Schritt in den Speicher schreiben, im nächsten wieder lesen — kostet jeder Übergang einen DDR-Schreib- und einen Lesezugriff. In einem Vierkamerasystem wird das auf einem 32-Bit-LPDDR4-Bus schnell sichtbar.

Der Latenzunterschied zwischen zwei Ketten aus denselben Beschleunigern entsteht meist hier, nicht in der Geschwindigkeit der Blöcke.

5. LDC und MSC

LDC (Lens Distortion Correction) führt perspektivische Transformationen und Objektivverzeichnungskorrektur aus, Fischauge eingeschlossen. Bei einem weitwinkligen Sensor und einem Modell, das entzerrte Geometrie erwartet, nimmt diese Korrektur in Hardware den A53-Kernen erhebliche Last ab.

MSC (Multi-Scaler) liest aus dem Speicher in den SL2 und erzeugt aus einem oder zwei Eingängen bis zu zehn skalierte Ausgaben. Diese Zahl ist wichtig: In einer mehrskaligen Inferenzkette — mehrere Modelle in verschiedenen Auflösungen oder ein pyramidenbasierter Ansatz — ist es weit günstiger, alle Maßstäbe in einem Durchgang zu erzeugen, als je Maßstab eine eigene Skalierung zu fahren.

Praktische Folge: Übergeben Sie die Skalierung auf die Eingangsauflösung des Modells dem MSC. Dieselbe Arbeit auf dem A53 oder der GPU kostet Kernzeit und einen Speicherumweg. Wo die Vorverarbeitung stattfindet, ist der am häufigsten übersehene Anteil der gemessenen Latenz.

6. DMPAC: Tiefe und Bewegung

DMPAC unterscheidet den AM67A von den meisten Familienmitgliedern und enthält zwei Engines. Die vom TRM veröffentlichten Grenzen definieren tatsächlich, was der Block leisten kann:

Dense Optical Flow (DOF) nutzt einen eigenen Algorithmus von TI: grob-zu-fein-Blocksuche über Bildpyramiden mit proprietären binären Pixeldeskriptoren. Die Grenze: Flussvektoren reichen bis ±191 Pixel horizontal und ±62 Pixel vertikal. Bewegt sich etwas in der Szene zwischen zwei Bildern weiter, kann DOF es nicht verfolgen. Abhilfe schaffen eine höhere Bildrate oder eine geringere Auflösung — beides schlägt aufs Budget.

Die Stereo Disparity Engine (SDE) unterstützt Suchbereiche von 64, 128 oder 192 und arbeitet über „0 … SR−1" oder „−3 … SR−4". Die Subpixelgenauigkeit liegt bei 1/16 Pixel; die Ausgabe durchläuft einen 2D-Medianfilter und trägt für jeden Disparitätswert eine Vertrauensbewertung in acht Stufen.

Diese Vertrauensbewertung ist aus Sicht des Systementwurfs womöglich die wertvollste Ausgabe des Blocks: Zu wissen, welchen Bereichen der Tiefenkarte nicht zu trauen ist, verhindert, dass Stereo auf texturarmen Flächen stillschweigend falsche Werte liefert.

DOF und SDE teilen sich einen eigenen SL2-Speicher, eine DMA-Engine namens UTC und einen HTS. Die Architektur „ohne Speicherumweg durchreichen" existiert also auch innerhalb des DMPAC.

Was die Grenzen sagen: Eine Obergrenze von 2 MPix und die 1280×720-Grenze im gleichzeitigen Betrieb bedeuten, dass 4K-Stereotiefe nicht das ist, was dieser Block liefert. DMPAC ist ein Helfer, keine unbegrenzte Ressource.

7. C7x + MMA: die Inferenz

An dieser Stelle ist aus dem Bild ein Tensor geworden. Der AM67A trägt zwei Deep-Learning-Beschleuniger, jeder aus einem C7x256V-Vektor-DSP und einem MMA, zusammen mit bis zu 4 TOPS Spitzenwert.

Drei Dinge bestimmen hier die Latenz:

Operatorabdeckung. Schichten, die der Compiler nicht auf den Beschleuniger legen kann, fallen auf die Cortex-A53 zurück. Das ist ein Domänenwechsel mitten in der Kette, und ein Domänenwechsel bedeutet einen Speicherumweg. Ein Modell, das „läuft", und ein Modell, das „beschleunigt wird", sind zweierlei.

Der Ort der Vorverarbeitung. Letterboxing, Normalisierung und Farbkonvertierung gehören zur Kette. Der Unterschied zwischen VPAC und A53 übersteigt in vielen Messungen die Inferenzzeit selbst.

Was zwei Beschleuniger bringen. Der Standardmodus von TI führt ein Modell auf einem einzigen Kern aus, unabhängig von der Zahl der vorhandenen; beide zu nutzen ist eine ausdrückliche Option zur Übersetzungszeit. Der klare Ertrag zweier Blöcke sind zwei unabhängige Ströme, nicht ein Modell in doppelter Geschwindigkeit.

Wie ein Modell auf diese Beschleuniger gelangt — Übersetzung, Quantisierung, Artefakte, Rückfall — behandelt unser Leitfaden zum TIDL-Deployment.

8. Cortex-A53: Anwendung und Nachverarbeitung

Die Ausgabe der Inferenz sind rohe Tensoren. Bis daraus Boxen, Klassen und Spuren werden, braucht es Decodierung, Schwellwertbildung, NMS, Tracker-Aktualisierung und Anwendungslogik.

Dieser Schritt ist der unsichtbare Kostenblock der Kette. Nach einer Inferenz, die auf dem Beschleuniger in 20 ms fertig ist, kann ein schlecht gewählter Tracker allein Hunderte Millisekunden hinzufügen. Die Komplexität der Nachverarbeitung ist unabhängig von der Modellkomplexität und muss getrennt gemessen werden.

9. Cortex-R5F: die Echtzeitreaktion

Steht am Ende der Kette ein Aktor — ein Stoppbefehl, ein Servo, ein Relais — sollte diese Reaktion nicht von der Linux-Zeitplanung abhängen. Genau dafür gibt es die R5F-Domäne des AM67A; die Entscheidung wandert dort aus dem A53 in eine andere Zeitzusage.

Wie diese Aufteilung entsteht, wie die Brücke zwischen den Domänen aussieht und welche Fehler typisch sind: Linux und Cortex-R5F auf dem AM67A.

Zeitbudget: Beschleuniger ≠ niedrige Latenz

Die These des Artikels in einem Satz: Die Latenz einer Kette ist nicht die Summe der Geschwindigkeiten ihrer Blöcke.

Was tatsächlich in die Summe eingeht:

1. Belichtung und Auslesen des Sensors (kein Beschleuniger verkürzt das).
2. CSI-2-Übertragung.
3. Warten am VPAC — wenn vier Kameras ihn zeitlich teilen.
4. VISS-Verarbeitung.
5. DDR-Umwege an den Blockübergängen, wenn die Kette nicht verkettet ist.
6. LDC / MSC.
7. DMPAC, falls genutzt.
8. Vorverarbeitung, je nachdem wo sie läuft.
9. Inferenz.
10. Die A53-Kosten der Schichten, die den Beschleuniger nicht erreicht haben.
11. Nachverarbeitung und Tracking.
12. Entscheidung und Ausgabe an den Aktor.

Der häufigste Grund für ein „langsames" System ist nicht ein schweres Modell in Zeile 9, sondern die Summe der Zeilen 5, 8 und 11 — und keine davon steht in einem Datenblatt.

Engpassmatrix der Verarbeitungskette

Symptom → wahrscheinliche Ursache → wo man nachsieht.

Entwurfs-Checkliste für die Bildverarbeitungskette

Fragen, die vor der ersten Zeile Code zu beantworten sind.

Kamera und Eingang

1. Wie viele Sensoren, auf wie viele CSI-2-Ports, mit wie vielen Lanes?
2. Müssen die Sensoren synchronisiert sein? Wie wirkt der zeitmultiplexe VPAC darauf?
3. Wie viel ISP-Budget entfällt auf jede Kamera — durch wie viel teilen Sie die 600 MP/s?
4. Ist ein Wiederherstellungspfad für einen CSI-Fehler vorgesehen?

VPAC 5. Ist die Kette verkettet (VISS → LDC im Fluss) oder läuft jeder Schritt über den Speicher? 6. Wird im MSC skaliert oder auf A53/GPU? 7. Wie viele verschiedene Auflösungen braucht das Modell? Wird die Mehrfachausgabe des MSC genutzt? 8. Wenn Anzeige- und Analysestrom nötig sind: wird die gleichzeitige HV+MV-Ausgabe verwendet? 9. Wird RGB-IR gebraucht? Wenn ja, ist die separate IR-Kamera aus der Planung entfallen?

DMPAC 10. Werden Tiefe oder Fluss wirklich gebraucht, oder stehen sie aus Gewohnheit auf der Liste? 11. Liegt die Auflösung unter der 2-MPix-Grenze? Bei gleichzeitigem SDE- und DOF-Betrieb: ist die 1-MPix-Grenze bekannt? 12. Passt die größte Bewegung in der Szene in den DOF-Bereich von ±191 / ±62? 13. Fließt die SDE-Vertrauensbewertung in die Systementscheidung ein oder wird sie verworfen?

Inferenz 14. Welche Schichten des Modells landen auf dem Beschleuniger? Wurde der Übersetzungsbericht gelesen? 15. Werden Vor- und Nachverarbeitung getrennt von der Inferenzzeit gemessen? 16. Gibt es wirklich zwei unabhängige Ströme für die beiden Beschleunigerblöcke?

System 17. Wurde ein Ende-zu-Ende-Zeitbudget aufgeschrieben, oder wird nur über Inferenzzeit gesprochen? 18. Hängt die Ausgabe an den Aktor von der Linux-Zeitplanung ab? 19. Wurde das thermische Verhalten unter Dauerlast gemessen? 20. Wurde die Speicherbandbreite gemessen, während KI- und Speicherzugriffe gleichzeitig laufen?

Was gemessen werden muss

Jede Zahl in diesem Artikel ist ein veröffentlichter Spitzenwert. Was eine Kette tatsächlich leistet, sagt nur die Messung. Der Mindestumfang:

• Zeit von der Sensorbelichtung bis zur VISS-Ausgabe, je Kamera.
• Effektiver ISP-Durchsatz je Kamera bei vier aktiven Kameras.
• Der Unterschied zwischen verketteter und blockweiser Kette bei derselben Aufgabe.
• Verteilungen von Vorverarbeitung, Inferenz und Nachverarbeitung getrennt — p95/p99 statt Mittelwert.
• Belastung der Speicherbandbreite mit und ohne DMPAC.
• Ende zu Ende: von der Sensorbelichtung bis zur Entscheidung.
• Wo sich all das unter Dauerlast nach den ersten dreißig Sekunden einpendelt.

Jede veröffentlichte Zahl trägt ihre Randbedingungen mit sich: welcher Aufbau, welche Methode, gemessen von wem.

Fazit

Das Bildverarbeitungs-Subsystem des AM67A ist reichhaltig: ein ISP mit RGB-IR, ein VPAC mit eigenem gemeinsamem Speicher und Hardware-Scheduler, ein Skalierer mit bis zu zehn Ausgängen, eine Stereo-Engine mit Vertrauensbewertung und ein eigener Algorithmus für optischen Fluss.

Doch all diese Blöcke teilen sich eine VPAC- und eine DMPAC-Instanz; vier Kameras laufen im Zeitmultiplex; und ob zwischen den Blöcken der Speicher berührt wird, bleibt Ihnen überlassen. Diese drei Entscheidungen bestimmen die Geschwindigkeit der Kette — nicht die Liste der Blöcke.

Um Aufteilung und Zeitbudget an Ihrer eigenen Kette zu erarbeiten, ist unsere Arbeit an Edge AI und Bildverarbeitung der Ausgangspunkt; den Umfang legen wir in einem Architektur-Audit fest.

Quellen

1. Texas Instruments — J722S/TDA4VEN/TDA4AEN/AM67 Processor Silicon Revision 1.0 Technical Reference Manual, SPRUJB3D, März 2024, überarbeitet August 2026 — https://www.ti.com/lit/zip/sprujb3 (TI stellt dieses Dokument als ZIP bereit, nicht als PDF)
2. Texas Instruments — AM67x Processors datasheet, SPRSPA3B, März 2024, überarbeitet Juni 2026 — https://www.ti.com/lit/ds/symlink/am67a.pdf
3. Texas Instruments — J722S/TDA4VEN/TDA4AEN/AM67 Processor Silicon Revision 1.0 Errata, SPRZ575 Rev. A — https://www.ti.com/lit/pdf/sprz575
4. Texas Instruments — AM6xA ISP Tuning Guide, SPRAD86 Rev. A — https://www.ti.com/lit/pdf/sprad86
5. Texas Instruments — Processor SDK Linux (AM67A) Dokumentation — https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-am67a/latest/exports/docs/index.html

Zugriff auf die Quellen am 5. September 2026. TRM und Datenblatt tragen unterschiedliche Revisionsdaten; für Teilblockdetails gilt das TRM, für elektrische und Variantenangaben das Datenblatt.