360 度相機:從 FPGA 原型到能動的矽

一個橫跨九年的東西

這不是一個專案,是一條線。同一顆 360 度相機,我在不同階段站在不同位置:先寫它 FPGA 原型上的影像模組,後來寫進它 ASIC 裡的模組,再後來一個人把回來的晶片跑起來,最後把它整合進別人的產品。

每一段的共同點是:接手的時候,「它應該怎麼運作」都還沒有被完整定義。

第一段:FPGA 上的影像管線

早期平台跑在 Xilinx Artix 級的 FPGA 上。我負責 block 級的 RTL —— ISP 的 RGB binning、WDR 與 HDR 處理區塊,對接既有 DDR 控制器的 DMA 邏輯,暫存器控制訊號與 DDR 介面的跨時脈域處理,DDR3 在低功耗模式轉換時的 auto-refresh,以及五顆鏡頭的同步機制。

其中最完整的一段是 H.264:我被指派把一個十年前寫的模組,從 240×180 延伸到 4K —— 大約 99 倍的像素量。

改完之後模擬過了,FPGA 實測也過了。然後現場開始出現隨機的影像破塊。

戶外才會發生,而且畫面越亮壞得越早。

亮度相關的失效,幾乎一定是資料相依。我把出問題的畫面收集回來,在模擬環境裡重放,追進管線,定位到一個累積像素資料的暫存器在高亮度下溢位。加寬位元寬度,解決。

一般模擬永遠碰不到那個邊界,真實的 4K 陽光碰得到。「模擬過了」講的是你的測試激勵,不是你的設計。

第二段:進到實體矽裡

後期的 UX720V6 相機 ASIC 第一次下線失敗,公司決定開新光罩重做。我在 respin 版本裡設計並加入了影像合成模組,趕在最終 RTL 釋出前完成。

改版的矽真的被製造出來 —— 幾百片工程樣品。晶片回來之後 bring-up 成功,跑起來了。

整顆晶片的架構與流片是團隊推動的,我擁有的是我那個模組。但那個模組現在活在一顆能運作的實體晶片裡。

第三段:一個人把晶片跑起來

幾百片從沒上過電的裸矽送回來。要有人定義「能動」是什麼意思,並且證明它。

這一段是我一個人從頭到尾負責的:決定要做哪些測試、用哪塊板子、怎麼驗,一路到交付。

我改了驗證板的版本。寫了一支考慮電壓變化的 MIPI delay-scan 工具(Python)去找穩定的操作點。寫了一支 DDR sweep 工具(C),整合進開機與模式切換流程,讓每一片晶片動態找到自己的最佳 timing —— 這支工具把大約 20% 原本判為邊緣不穩的樣品救了回來。最後交付一支建在 ASIC 既有硬體控制區塊之上的暫存器級控制驅動,驗證到影像實際存進 DDR。

過程中遇到一個看起來像 DDR 不穩的間歇性失效。那種症狀很容易讓人一頭栽進去調 timing 參數調好幾週。我們沒有鎖定第一個看似合理的嫌犯,而是先分類問題:查 DDR 設定、查時脈與 PLL,然後把示波器接到電源樹上。

異常出現在 PMIC 輸出的漣波。根因是電源設定與行為,DDR 資料路徑是無辜的。

間歇性不等於隨機。它只是代表你還沒找到那個變數。

第四段:裝進別人的產品

最後一段是對外合作的產品線:把我們的相機 ASIC 整合到第三方的 Anyka 處理器上。

從對方提供的 BSP 出發,一路打通到 CPU 能透過 SPI 控制我們的晶片、晶片把 MIPI 資料送回 CPU,做到第一張影像。BSP 是廠商的,整合與 bring-up 是我的。

同一時期我也寫了 IMU 驅動,並且擁有整條電子防手震(EIS)功能 —— 從 IMU 原始資料、經過穩定演算法、到輸出座標,疊加在平台既有的 PTZ 座標系上,交付為可運作的功能。

為什麼這條線值得講

從一段 FPGA 上的影像邏輯開始,到一顆能動的晶片、再到別人產品裡的第一張照片。中間沒有一段是規格書寫好等我實作的 —— 每一段都是先把「還沒被定義的東西」變成可以測量、可以驗證、可以交付的系統。