AM67A Vision Pipeline: VPAC3L, DMPAC ve C7x Arasında Görüntü Nasıl İşleniyor?

Bir SoC'nin özellik listesinde ISP, optik akış ve stereo derinlik hızlandırıcısı görmek rahatlatıcıdır. Ama hızlandırıcının var olması, uçtan uca gecikmenin düşük olacağı anlamına gelmez. Gecikmeyi belirleyen şey blokların varlığı değil, karenin o bloklar arasında kaç kez belleğe yazılıp okunduğu, hangi kaynağın kaç kamera tarafından paylaşıldığı ve hattın hangi noktasında bir kopya oluştuğudur. Bu yazı, TI AM67A'da bir karenin sensörden karara kadar izlediği yolu adım adım takip ediyor ve her adımda gecikmenin nereye gittiğini gösteriyor. Kaynak, TI'nin teknik referans kılavuzu SPRUJB3D (Ağustos 2026) ve AM67x datasheet SPRSPA3B'dir. Bu yazıda Spikedge tarafından yapılmış bir ölçüm yoktur; verilen bütün rakamlar TI'nin yayımladığı tepe değerlerdir.

Hattın haritası

AM67A'da bir karenin yolu şudur:

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

Bu zincirde dört ayrı hızlandırıcı ve en az iki ayrı bellek katmanı var. Aşağıda her durağı, ne yaptığını ve neyi maliyet olarak eklediğini tek tek ele alıyoruz.

Bu yazı, SoC'nin genel mimarisini değil görü alt sistemini anlatır. Blokların SoC içindeki yerini ve varyantlara göre dağılımını TI AM67A SoC mimarisi yazımızda ele aldık.

1. Sensörden CSI-2'ye

AM67A dört bağımsız CSI-2 alıcısı taşır; her biri 4 şeritli D-PHY, şerit başına 2,5 Gb/s'ye kadar, MIPI CSI-2 v1.3 ve D-PHY 1.2 uyumlu. Girdi başına 16 sanal kanala kadar destek var.

Burada iki tasarım kararı doğuyor:

• Şerit bütçesi. 4 şerit × 2,5 Gb/s = 10 Gb/s ham bant genişliği. 12 bit RAW, 1920×1080, 60 fps bir akış kabaca 1,5 Gb/s eder; şerit sayısını sensöre göre kısmak boşuna değildir, güç tasarrufudur.
• Sanal kanal mı, ayrı port mu? Bir deserializer üzerinden birden çok sensörü tek porta toplayabilirsiniz; bu durumda bant genişliği o portta paylaşılır. Dört ayrı port kullanmak bant genişliğini ayırır ama pin ve kart maliyeti getirir.

Bir errata maddesi bu aşamaya doğrudan dokunur: i2190, eksik veya CRC hatalı bir çerçevenin ardından CSI alıcı arabirimin bilinmeyen bir duruma geçebileceğini bildirir; kurtarma için modülün sıfırlanması gerekir. Çok kameralı, titreşimli bir sistemde bu, sürücü seviyesinde tasarlanması gereken bir kurtarma yoludur — sahada kablo teması bozulduğunda ortaya çıkar.

2. Video Stream MUX: dört kamera, tek VPAC

Bu yazının en önemli bölümü burasıdır.

TRM'in VPAC blok diyagramında dört CSI_RX_IF bloğu bir Video Stream MUX'a girer ve MUX'tan tek bir VISS çıkar. TRM bunu açıkça yazar:

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

Yani AM67A'da dört kamera girişi vardır ama bir tane görüntü işleme hattı vardır ve dört kamera onu zaman paylaşımlı kullanır. Cihaz tablosunda da VPAC örnek sayısı birdir.

Bunun pratik sonucu doğrudan gecikme bütçesine yazılır:

• Dört kameralı bir sistemde ISP kapasitesi kameralar arasında bölünür, çoğalmaz. Datasheet'in verdiği 600 MP/s, hattın toplam kapasitesidir; kamera başına değil.
• Zaman paylaşımı, kameralar arasında sıra beklemesi demektir. Dördüncü kameranın karesi, kendisinden önceki üçü işlendikten sonra sıraya girer. Bu bekleme ortalamada küçük görünür ama en kötü durumda kare süresine yaklaşır.
• Kameraların senkron olması ayrı bir iştir. Aynı anda yakalanmış dört kare, aynı anda işlenmiş dört kare demek değildir.

"Dört kamera destekliyor" cümlesi doğrudur; "dört kamerayı paralel işliyor" cümlesi değildir. Bir stereo çift ile bir çevre kamerası aynı SoC'de koşacaksa, gecikme bütçesi bu zaman paylaşımı üzerinden kurulmalıdır.

3. VISS: ham pikselden görüntüye

VISS (Vision Imaging Sub-System), VPAC'ın ham sensör verisini işleyen çekirdeğidir. TRM'in listelediği alt bloklar:

Datasheet bu bloğu VPAC3L referans adıyla anar ve 600 MP/s ISP verimi, 12 bit RGB-IR desteği, 16 bit'e kadar RAW giriş ve 4096'ya kadar satır genişliği verir. TRM ise yalnızca "VPAC" der; alt blok listesi ancak TRM'de bulunur. Datasheet'te göremediğiniz bir blok yok demek değildir — NSF4V, GLBCE ve CAC datasheet'in özellik listesinde geçmez, TRM'de geçer.

Burada mühendislik açısından iki kritik yetenek var:

RGB-IR. Aynı sensörden hem görünür hem kızılötesi kanal alıp ISP'de ayırabilmek, canlılık tespiti ve düşük ışık uygulamalarında ayrı bir IR kamera koymaktan kurtarır. Kart maliyeti ve hizalama derdi ortadan kalkar.

Eşzamanlı HV + MV çıkışı. TRM, VPAC'ın "simultaneous visual (HV) and analytics (MV) output to system memory" ürettiğini ve bunun "saving need for additional read from system memory for HV+MV processing" anlamına geldiğini yazar. Yani insan için gösterilecek görüntü ile makine için işlenecek görüntü tek geçişte üretilir. Bu, aynı kareyi iki farklı formatta iki kez okumak zorunda kalmamak demektir — çok kameralı bir sistemde kazanılan bellek bant genişliği ciddidir.

Bu tek özellik, hattı naif kuran bir tasarım ile doğru kuran bir tasarım arasındaki farkın büyük kısmını açıklar.

4. SL2 ve HTS: VPAC'ın içindeki asıl hikâye

Hızlandırıcı hattında gecikmenin nereye gittiğini anlamak istiyorsanız bakmanız gereken yer bu bölümdür.

VPAC'ın içinde iki altyapı bileşeni var:

• SL2 (Shared Level 2) — VPAC'a ait dahili paylaşımlı bellek. VISS, LDC, MSC ve diğer alt modüller veriyi buradan alışverişe sokar. DDR/MSMC ile arasındaki taşıma K3 DMA mimarisi üzerinden yapılır.
• HTS (Hardware Thread Scheduler). Alt modüller arasındaki ve yerel DMA motoru (UTC) ile olan haberleşmeyi donanımda yürütür.

Bunun anlamı şudur: VPAC içindeki blok geçişleri DDR'ye uğramak zorunda değildir. VISS'ten çıkan veri SL2 üzerinden LDC'ye gidebilir; TRM ayrıca "VISS to LDC direct OTF (On-the-Fly) for multi-camera" yolunu ayrıca sayar — yani belleğe hiç yazmadan, akış hâlinde.

Buna karşılık LDC ve MSC'nin tanımı "reads data from memory (DDR or on-chip) to internal SL2 memory" biçimindedir. Yani bu blokları bağımsız olarak çağırdığınızda girdi bellekten okunur.

Tasarım kararı buradan doğar:

• Hattı zincirlenmiş kurarsanız (VISS → LDC on-the-fly), DDR turu ve onun bant genişliği maliyeti ortadan kalkar.
• Hattı blok blok kurarsanız (her adımda belleğe yaz, sonraki adımda oku), her geçiş bir DDR yazma + okuma turu ekler. Dört kameralı bir sistemde bu, LPDDR4'ün 32 bitlik yolunda hızla görünür hâle gelir.

Aynı hızlandırıcılarla kurulmuş iki hat arasındaki gecikme farkı çoğunlukla buradan gelir; blokların hızından değil.

5. LDC ve MSC

LDC (Lens Distortion Correction) perspektif dönüşümü ve lens distorsiyonu düzeltmesi yapar; balık gözü lensler dâhil. Geniş açılı bir sensör kullanıyorsanız ve modeliniz düz geometri bekliyorsa, bu düzeltmenin donanımda yapılması A53'ten ciddi bir yük alır.

MSC (Multi-Scaler) belleği SL2'ye okur ve bir veya iki girdiden 10'a kadar ölçeklenmiş çıktı üretir. Bu sayı önemlidir: çok ölçekli bir çıkarım hattında (farklı çözünürlükte birden çok model, ya da piramit tabanlı bir yaklaşım) tüm ölçekleri tek geçişte almak, her ölçek için ayrı bir yeniden boyutlandırma turu yapmaktan çok daha ucuzdur.

Pratik karşılığı: modelinizin girdi çözünürlüğüne indirgeme işini MSC'ye verin. Aynı işi A53'te veya GPU'da yapmak, hem çekirdek zamanı hem bellek turu maliyeti demektir. Ön işlemenin nerede yapıldığı, hatta ölçülen gecikmenin en sık gözden kaçan bileşenidir.

6. DMPAC: derinlik ve hareket

DMPAC, AM67A'yı aynı ailenin diğer üyelerinden ayıran bloktur ve iki motor içerir. TRM'in verdiği sınırlar, bu bloğun ne yapabileceğini gerçekten tanımlar:

Dense Optical Flow (DOF), TI'nin kendi algoritmasını kullanır: görüntü piramitleri üzerinde kabadan inceye blok arama, ikili piksel tanımlayıcılarıyla. Sınırı şudur: akış vektörü yatayda ±191, dikeyde ±62 piksele kadar. Bu, sahnenizde iki kare arasında bundan fazla yer değiştiren bir nesne varsa DOF'un onu takip edemeyeceği anlamına gelir. Hızlı hareket eden bir hedef için çözüm ya kare hızını artırmak ya çözünürlüğü düşürmektir — ikisi de bütçeye yazılır.

Stereo Disparity Engine (SDE), 64, 128 veya 192 disparity arama aralığı destekler ve "0 … SR−1" ya da "−3 … SR−4" aralığında çalışabilir. Alt piksel doğruluğu 1/16 piksel; çıkışta 2B medyan filtreleme ve her disparity değeri için 8 seviyeli bir güven skoru üretilir.

Bu güven skoru, sistem tasarımı açısından belki de bloğun en değerli çıktısıdır: derinlik haritasının hangi bölgelerine güvenilmeyeceğini bilmek, düşük dokulu yüzeylerde stereo'nun sessizce yanlış cevap vermesini engeller.

DOF ve SDE de kendi SL2 belleklerini, UTC adlı DMA motorunu ve bir HTS'yi paylaşır. Yani DMPAC'ın içinde de aynı "belleğe uğramadan geç" mimarisi vardır.

Sınır neyi söyler: 2 MPix giriş tavanı ve 1280×720'lik eşzamanlı çalışma sınırı, 4K stereo derinlik gibi bir beklentinin bu blokta karşılanmayacağını söyler. DMPAC bir yardımcıdır, sınırsız bir kaynak değil.

7. C7x + MMA: çıkarım

Bu noktada kare artık bir tensöre dönüşmüştür. AM67A iki derin öğrenme hızlandırıcısı taşır; her biri bir C7x256V vektör DSP ve bir MMA içerir, birlikte 4 TOPS'a kadar tepe kapasite verir.

Gecikme açısından üç şey önemlidir:

Operatör kapsamı. Modelin hızlandırıcıya inmeyen katmanları Cortex-A53'e düşer. Bu, hattın ortasında bir alan değişimi demektir ve alan değişimi bellek turu demektir. Bir modelin "çalışması" ile "hızlanması" farklı şeylerdir.

Ön işlemenin yeri. Letterbox, normalizasyon ve renk dönüşümü hattın parçasıdır. Bunları VPAC'ta yapmak ile A53'te yapmak arasındaki fark, çoğu ölçümde çıkarım süresinin kendisinden büyüktür.

İki hızlandırıcının anlamı. İki blok, tek bir modeli iki kat hızlandırmak için değil, iki bağımsız akışı paralel koşturmak için en net karşılığı bulur. Tek akışlı bir uygulamada ikincisi boş kalabilir.

C7x'e kendi çekirdeğinizi yazma konusunda TI belgeleri arasında çözülmemiş bir çelişki var; ayrıntısını AM67A mimari yazımızda ele aldık.

8. Cortex-A53: uygulama ve son işleme

Çıkarım çıktısı ham tensörlerdir. Kutulara, sınıflara ve izlere dönüşmesi gerekir: decode, eşikleme, NMS, izleyici güncellemesi, iş mantığı.

Bu adım hattın "görünmeyen" maliyetidir. Hızlandırıcıda 20 ms'de biten bir çıkarımın ardından, yanlış seçilmiş bir izleyici tek başına yüzlerce milisaniye ekleyebilir. Son işlemenin karmaşıklığı model karmaşıklığından bağımsızdır ve ayrı ölçülmelidir.

9. Cortex-R5F: gerçek zamanlı tepki

Hattın sonunda bir aktüatör varsa — bir dur komutu, bir servo, bir röle — o tepkinin Linux zamanlamasına bağlı olmaması gerekir. AM67A'nın R5F alanı tam olarak bunun içindir ve karar burada A53'ten alınıp ayrı bir zamanlama sözleşmesine taşınır.

Bu bölüşümün nasıl kurulacağını, iki alan arasındaki köprüyü ve tipik hataları AM67A'da Linux ve Cortex-R5F yazısında ayrıntılandırdık.

Gecikme bütçesi: hızlandırıcı ≠ düşük gecikme

Bu yazının tezi tek bir cümlede toplanabilir: bir hattın gecikmesi, bloklarının hızlarının toplamı değildir.

Toplama giren gerçek kalemler:

1. Sensör pozlama ve okuma süresi (hiçbir hızlandırıcı bunu kısaltmaz).
2. CSI-2 aktarımı.
3. VPAC sırası — dört kamera zaman paylaşımlı kullanıyorsa bekleme.
4. VISS işleme.
5. Blok geçişlerindeki DDR turları (zincirlenmemiş hat kurulduysa).
6. LDC / MSC.
7. DMPAC (kullanılıyorsa).
8. Ön işleme (nerede yapıldığına göre değişir).
9. Çıkarım.
10. Hızlandırıcıya inmeyen katmanların A53 maliyeti.
11. Son işleme ve izleme.
12. Karar ve aktüatöre çıkış.

Bir sistemin "yavaş" olmasının en yaygın sebebi 9. maddedeki modelin ağır olması değil, 5, 8 ve 11. maddelerin toplamıdır. Bunlar da datasheet'te görünmez.

Pipeline Bottleneck Matrix

Belirti → muhtemel sebep → nereye bakılır. Bu tablo, bir hattın neden beklenenden yavaş olduğunu aramak için bir başlangıç haritasıdır.

Vision Pipeline Design Checklist

Bir AM67A görü hattı tasarlarken, kod yazmadan önce cevaplanması gereken sorular.

Kamera ve giriş

1. Kaç sensör var, kaç CSI-2 portuna dağılıyor, kaç şerit kullanıyor?
2. Sensörler senkronize olmak zorunda mı? Zaman paylaşımlı VPAC bunu nasıl etkiler?
3. Kamera başına düşen ISP bütçesi ne? Toplam 600 MP/s'i kaça bölüyorsunuz?
4. CSI arabirim hatasından kurtarma yolu tasarlandı mı?

VPAC 5. Hat zincirlenmiş mi (VISS → LDC on-the-fly), yoksa her adım bellekten mi geçiyor? 6. Ölçekleme MSC'de mi yapılıyor, yoksa A53/GPU'da mı? 7. Model kaç farklı çözünürlük istiyor? MSC'nin çok çıkışlı yeteneği kullanılıyor mu? 8. Hem gösterim hem analitik akış gerekiyorsa eşzamanlı HV+MV çıkışı kullanılıyor mu? 9. RGB-IR gerekiyor mu? Gerekiyorsa ayrı IR kamera planından vazgeçildi mi?

DMPAC 10. Derinlik veya akış gerçekten gerekli mi, yoksa alışkanlıktan mı listede? 11. Çözünürlük 2 MPix tavanının altında mı? Eşzamanlı SDE+DOF ise 1 MPix sınırı biliniyor mu? 12. Sahnedeki azami hareket, DOF'un ±191/±62 vektör aralığına sığıyor mu? 13. SDE güven skoru sistem kararında kullanılıyor mu, yoksa atılıyor mu?

Çıkarım 14. Modelin hangi katmanları hızlandırıcıya iniyor? Derleme raporu okundu mu? 15. Ön işleme ve son işleme, çıkarım süresinden ayrı ölçülüyor mu? 16. İki hızlandırıcı bloğu için gerçekten iki bağımsız akış var mı?

Sistem 17. Uçtan uca gecikme bütçesi yazıldı mı, yoksa yalnızca çıkarım süresi mi konuşuluyor? 18. Kararın aktüatöre gitmesi Linux zamanlamasına mı bağlı? 19. Sürekli yük altında termal davranış ölçüldü mü? 20. Bellek bant genişliği, AI ve depolama trafiği aynı anda çalışırken ölçüldü mü?

Ne ölçülmeli?

Bu yazıda verilen bütün rakamlar TI'nin yayımladığı tepe değerleridir. Bir hattın gerçekte ne yaptığını yalnızca ölçüm söyler. Asgari küme:

• Kamera başına, sensör pozlamasından VISS çıkışına kadar süre.
• Dört kamera aktifken kamera başına düşen etkin ISP verimi.
• Zincirlenmiş hat ile blok blok kurulmuş hat arasındaki fark — aynı görevde.
• Ön işleme, çıkarım ve son işleme sürelerinin ayrı ayrı dağılımı (ortalama değil, p95/p99).
• DMPAC açıkken ve kapalıyken bellek bant genişliği baskısı.
• Uçtan uca: sensör pozlamasından karara.
• Sürekli yük altında bu değerlerin ilk otuz saniyeden sonra nereye oturduğu.

Ölçüm disiplinimizi somut bir örnekle EtherCAT ölçüm metodolojisi yazısında anlattık; aynı disiplin bir görü hattı için de geçerlidir: hangi kurulumda, hangi yöntemle, kim ölçtü.

Sonuç

AM67A'nın görü alt sistemi zengindir: RGB-IR yeteneğine sahip bir ISP, kendi paylaşımlı belleği ve donanım zamanlayıcısı olan bir VPAC, 10 çıkışlı bir ölçekleyici, güven skoru üreten bir stereo motoru ve TI'nin kendi optik akış algoritması.

Ama bu blokların hepsi tek bir VPAC örneğini ve tek bir DMPAC'ı paylaşır; dört kamera zaman paylaşımlı çalışır; ve blokların arasında belleğe uğrayıp uğramamak size bırakılmıştır. Hattın hızını belirleyen şey bu üç karardır, blokların listesi değil.

Kendi görü hattınızda bu bölüşümü ve gecikme bütçesini çıkarmak için Edge AI ve görüntü işleme yetkinliğimiz uygun bir başlangıçtır; kapsamı birlikte belirlemek için gömülü sistem mimari denetimi planlayabilirsiniz.

Kaynaklar

1. Texas Instruments — J722S/TDA4VEN/TDA4AEN/AM67 Processor Silicon Revision 1.0 Technical Reference Manual, SPRUJB3D, Mart 2024, Ağustos 2026 revizyonu — https://www.ti.com/lit/zip/sprujb3 (TI bu belgeyi PDF olarak değil, ZIP içinde dağıtır)
2. Texas Instruments — AM67x Processors datasheet, SPRSPA3B, Mart 2024, Haziran 2026 revizyonu — 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 — Processor SDK Linux (AM67A) dokümantasyonu — https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-am67a/latest/exports/docs/index.html

Kaynaklara erişim tarihi: 5 Eylül 2026. TRM ve datasheet farklı revizyon tarihleri taşır; alt blok ayrıntıları için TRM, elektriksel ve varyant bilgisi için datasheet esas alınmalıdır.