多組 SerDes 配置如何交給整合團隊，Marvell SDC Creator 的三段生成流程

一個 SerDes IP 可以同時支援 Ethernet、PCIe 與測試模式，但放進特定 SoC 後，真正啟用的時脈、資料寬度、頻率和實例位置只占其中一部分。IP 團隊交出一份通用模板有其合理性：同一份材料能服務多個客戶與晶片版本。整合工程師接手後，仍要逐項選出本次模式，刪除未使用的時脈，並把文件中的限制換成可供 synthesis、APR 與 STA 使用的 SDC。

這種工作量會隨介面數、配置與版本一起成長。Marvell 的 Patricia Fong 在 WISH 2024 原始論文中，公開 SDC Creator 的具體方法：以 5 nm SoC 的可配置 56G SerDes 為示範，把 IP 文件、可選模板和晶片配置轉成 SDC，另把已有 SDC 轉成供設計審查使用的文字。這篇研究的工程主題，是 IP 規格如何交到 SoC 整合流程；它也說明生成速度與最終交付速度之間，還隔著哪些工作。

沿圖往下看，兩個團隊提供的資料回答不同問題。IP 文件界定允許的用法，SoC 配置選定這次實際使用的組合；生成工具負責把兩者接起來，實體設計工具則檢查這個組合在目前設計中產生的效果。

通用模板與特定晶片之間，還有一份配置要交付

論文把輸入分成三類。第一類是自然語言文件，包含 user guide、design specification、時脈與接腳表；第二類是可能存在的通用 SDC 模板；第三類是設計資訊，包括時脈配置、階層名稱、接埠數、模式、工作條件和 signoff 所用的 margin。原文第 2–3 頁

資料格式不同，維護責任也不同。規格敘述一個 IP 能做什麼，配置檔敘述這顆晶片選了什麼。工具需要同時知道「此模式最高允許多少頻率」與「本實例設定多少頻率」，才能比較設定是否落在允許範圍。單看文件容易產生過度完整的模板，單看配置又會失去允許範圍與例外條件。

原文的 clock configuration CSV 特別保留所有可能的時脈，以 period 等於零表示本次未使用。這個值在流程中帶有選擇語意：它要求生成器略過該時脈，接收端也應確認最後輸出沒有把它重新建立。對一顆具有多組介面實例的 SoC，這項規則能讓一份 IP 規格搭配多份配置使用，避免每個專案各維護一份已分岔的完整模板。

一條完整的交付路徑可以拆成下表。表中的資料責任是依公開方法推導的參考安排；組織名稱與簽核系統仍由採用團隊自行決定。

這裡也保留了 RTL、功能驗證、DFT 與實體設計的分工。SDC 產生器接入的是約束交接；測試模式是否真的可達、reset 是否正確、scan 與 functional clocks 如何切換，仍要由對應設計與驗證工作提供答案。把測試模式選錯後再產生完整 Tcl，只會更快交出一套不適用的條件。

三段生成把資料選擇和命令撰寫分開

Marvell 公開的平台位於 virtual private cloud，使用 Python、LangChain、向量資料庫、embedding 與模型層。架構圖列出 Chroma 與 Mistral，但沒有給出足以重現全部結果的模型版號、完整參數和文件集合。能直接研究的是資料流及三段呼叫的安排。原文第 4–6 頁

第一段先向 clock configuration 檢索，整理每個有效時脈的名稱、period 和 uncertainty。第二段把這份結果與 design configuration 的檢索內容串接，生成 create_clock 和 create_generated_clock。第三段再沿用第一段的結果，生成 set_clock_uncertainty，最後把第二、三段輸出合併。

第三段有一個容易忽略的特點：原文寫明它沒有再連接 retriever 或向量資料庫，而是透過前段結果與內部提示接續工作。因此，第一段整理出的清單成了共同輸入；如果這裡遺漏某個啟用時脈，後面兩段都可能一起遺漏它。把同一個清單傳給兩個呼叫，能減少各段自行重新選資料造成的分歧，也會讓前段錯誤同時傳播。

這解釋了分段方法的取捨。單次長提示把全部工作交給模型，實作較短，卻難以定位錯誤究竟發生在資料選擇、單位轉換或 Tcl 生成。三段方法留下可檢查的中間結果，但團隊要維護呼叫之間的資料格式、上下文與版本。增加呼叫數量帶來的是可定位性，同時增加延遲、模型費用與一致性工作。

2020 年的 RAG 原始研究把參數化生成模型與外部檢索記憶結合，讓回答可利用模型之外的資料。SDC Creator 延續這種分工，但工程問題更尖銳：文件中一段語意相近的文字，可能屬於另一個 operating mode。相似度檢索能找到相關段落，配置是否適用仍需要另外核對。這項差異使「檢索到」與「可用於本實例」成為兩個要分開測量的結果。

參考設計可以在第一段之後增加一份結構化清單，每項固定記錄文件版本、時脈名稱、啟用狀態、period 單位、實例路徑，以及尚待工程師回答的欄位。模型適合抽取分散敘述與提出候選關係，精確數值的換算和已知配置規則則交給確定性的程式。這樣能把語言模型的彈性保留在文件理解，把可明確計算的部分變成可重跑的檢查。

六個時脈的示範，能檢查到哪一層

原文配置示範列出六個有效時脈，period 分別包含 10,000、2,000、1,000、20,000 與 500 ps；兩個 10,000 ps 時脈位於不同 side。第 7–8 頁展示時脈及 uncertainty 輸出，第 9–10 頁再展示由 SDC 轉成自然語言的審查路徑。原文第 3、7–10 頁

以單位轉換為例，10,000 ps 是 10 ns，對應 100 MHz；500 ps 是 0.5 ns，對應 2 GHz。這兩個換算只用來檢查配置的量級。SDC 命令中的數字要採目前工具與 library 的時間單位；把 ps 數值直接填到以 ns 解讀的環境，會造成一千倍的差距。可讀的註解與正確 Tcl 語法都攔不住這種錯誤。

另一個檢查是物件對應。文件稱為某個 clock pin，整合後的 netlist 可能把它放進不同的階層。工程師應比對查詢到的物件數、實際 pin 名稱與時脈關係，確認生成器沒有把查無物件的查詢當作成功。這類檢查要連到設計資料，單靠重新閱讀生成的說明文字，容易讓同一項假設在兩種格式中重複出現。

公開的 OpenSTA SDC 命令實作提供可參照的命令處理方式：create_clock、create_generated_clock、uncertainty 與 path exceptions 各自有參數及設計物件處理。它可用來建立開源對照實驗，商用工具的支援集合、library 和 signoff 方法仍按專案核對。團隊可以先檢查 Tcl 與物件，再檢查時脈完整性和 exception 的作用範圍，最後才比較 timing 結果。

反向文字生成的好處，是讓 IP、SoC 與時序工程師能用同一份可讀敘述討論頻率、waveform、margin 和關係。它也能指出文件缺少哪些資訊，讓 IP 團隊補回規格。審查時最好保留原始配置與工具報告作獨立參照，避免生成 SDC 和解釋 SDC 的兩個步驟共享同一個錯誤。

這些檢查可以放進一個具體的變更案例。假設同一顆 SoC 的第二版只改了其中一組 SerDes 的工作模式，原本停用的時脈改成啟用，實例位置也因頂層重構而改名。參考流程先對配置表做差異比較，列出新增的有效時脈及被替換的階層，再讓生成器處理這組實例。接收端會看到一份可預期的變更清單，方便檢查新增時脈是否真的出現、舊路徑是否還殘留在輸出中。

若一律用全文重新生成，沒有變動的其他實例也可能出現格式與命名差異，審查者需要從大量文字中找出實質變更。相反地，完全沿用舊輸出又會漏掉新的模式。按實例與配置保存中間結果，能讓重查工作跟著設計變更移動；代價是平台必須追蹤這份結果使用了哪個文件、哪份配置與哪次設計物件清單。此處是可實作的參考安排，原文只公開生成與審查的主要路徑。

錯誤也可以按發生位置處理。找不到文件中的限制時，先回到規格補資料；找得到規格卻對不上階層時，修正設計配置；命令可載入但時脈關係不符預期時，再由時序工程師處理語意。將這三種問題都丟回模型重新回答，會把原本可定位的問題變成多次隨機修改，也增加工具重跑的成本。平台應讓每次修正都回到負責的資料來源，再產生新的候選版本。

兩分鐘生成之後，審查時間會決定交付收益

論文報告該範例的 SDC 生成少於兩分鐘，並把人工撰寫描述為需要多個小時。這是生成階段的 reported result；要評估團隊是否值得導入，還需把文件整理、配置建立、人工修正與 EDA 工作分別計帳。原文第 6 頁

以下是假設算例，用來看重用次數和審查成本的關係。假設人工每份配置需要 4 小時，包含 2 小時撰寫、1 小時審查及 1 小時工具工作。生成方案先投入 40 小時整理文件與配置格式，每份再花 2 分鐘生成、1.5 小時審查修正和相同的 1 小時工具工作。處理 N 份配置時，總工作量分別為：

人工總時數 = 4 × N
生成方案總時數 = 40 + (2/60 + 1.5 + 1) × N

兩式以人時與工具等待可相加的簡化模型計算，並假設這些工作依序完成。生成方案每份省下約 1.467 小時，到第 28 份配置才開始回收前置投入；10 份時人工約 40 小時、生成方案約 65.33 小時，50 份時則約為 200 與 166.67 小時。若審查時間升到 3 小時，生成方案每份反而約 4.033 小時，再多的重用次數也難以回收這筆前置投入。

這個模型的用途是找敏感參數。模型每次快一分鐘，在 50 份配置中合計只省約 0.83 小時；每份審查少半小時，則合計省 25 小時。對這組假設，優先改善配置完整性、物件對應與錯誤定位，比繼續壓縮生成延遲更有效。若多個專案能同時審查，工作量與曆時又會分離，需另外計算排隊和人力瓶頸。

三者也可組合使用。規則已穩定的時脈 period 和 hierarchy mapping，適合以程式產生；文件中尚未結構化的條件，才交由檢索與模型提出候選。若導入後多數時間仍耗在重建同一張配置表，把這張表整理成正式輸入，通常比增加更多模型呼叫更有直接效果。

選擇方案時還要計入責任移動。IP 團隊把模板交出去後，可以減少各專案重複詢問，卻需更有紀律地維護模式說明與版本差異；SoC 團隊獲得較快的初稿，同時承擔配置資料的正確性；CAD 團隊則新增檢索、模型與工具銜接的維護工作。生成服務若由外部供應商提供，文件存放位置、模型存取與版本更新也會影響長期維護。採用者應以自己的資料權限與工具環境決定部署方式，原文的私有雲架構只提供一種公開案例。

收益會隨專案成熟度改變。在新 IP 導入初期，文件缺口和模式判讀通常較多，人工審查可能主導總時間；模式逐漸穩定後，結構化配置與模板的重用價值增加。若產品改版持續新增例外，則需重新評估前置整理成本。這使導入評估應涵蓋至少一次真實的規格變更，單次對固定文件產生一份漂亮 SDC，只能量到最窄的一段工作。

與 RapidWright 比較，重用的物件已經不同

先前的 RapidWright 模組交接文章處理已完成局部實體實作的 DCP 與 metadata 重用；官方預先實作流程把局部建庫與系統組合分開。SDC Creator 則從文件和配置產生設計約束。兩者都把重複工程搬到可保存的材料上，但可以固定的內容不同。

RapidWright 保存的局部解已帶著實體條件，重用收益受相容位置、介面與全域連線影響。SDC Creator 保存的是規格到配置的轉換方式，收益受文件完整性、模式數與審查成本影響。一份可讀的 IP 規格，還需要經過配置選擇；一份可用的局部 DCP，還需要通過系統組合。比較兩家公司方法時，應分別衡量這些剩餘工作，才能找到真正可以移用的工程分工。

未來三個月的導入實驗，可固定一組文件與設計版本，比較人工、模板、RAG 三條路在相同配置集合上的總工時。測試集合應包括未啟用時脈、錯誤單位、改名階層、互斥模式，以及少量規格缺漏的案例；保留每次中間清單和人工修正，統計漏掉的有效時脈、誤建時脈、查無物件與不適用例外。如果模型的生成速度提高，人工修正卻持續增加，就應先縮小生成範圍，回到配置與模板的整理。

這條工作線也接回 Marvell 3DIC 實體 signoff：前段需要把 IP 的模式及限制交清楚，後段需要把不同 die 與封裝的實際連接組起來。共同能借鏡的是交付物要攜帶接收端需要的資訊；從文件抽取到實體連接，各階段仍使用不同的檢查方法。下一個具體問題，是規格變更後如何找出真正受影響的時脈與配置，讓重查範圍跟著變更內容縮小。

證據範圍

• Marvell 主要來源為 Patricia Fong（Marvell）等人的 WISH 2024 十頁論文，頁面日期為 2024-10-23。它提供 5 nm／56G SerDes 示範、三段呼叫與輸出畫面；沒有公開完整程式、全部文件、模型版號、測試母體或整體量產導入規模。
• 少於兩分鐘與人工多小時是原文對生成階段的描述；本文沒有把它換算成已證實的整體專案加速倍數、良率提升或首次投片成功率，也沒有執行商用 EDA、STA 或 PPA 實驗。
• 結構化中間清單、獨立檢查與導入實驗屬參考設計；40 小時前置投入及各項審查工時是假設。附程式只重算成本模型，沒有驗證生成 SDC 的電路正確性。
• OpenSTA 為公開命令處理方式的對照，不能替代專案指定的商用工具、library、工作條件及 signoff 規則。自然語言反向說明也不能獨立證明原始 SDC 完整或正確。
• 圖一依原文資料流整理，圖二的獨立核對部分是參考安排；兩張圖都不代表 Marvell 已公開的完整內部平台。

References

1. Patricia Fong（Marvell）等，2024-10-23，SDC Constraint Automation for Interface IP using Generative AI。第 2–3 頁輸入與配置，第 4–6 頁架構及串接，第 7–10 頁輸出與審查。
2. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，2020 年原始研究；用於說明生成與外部檢索資料的分工。
3. AMD Research，A Pre-implemented Module Flow。比較資料重用的物件與剩餘整合工作。
4. Parallax Software，OpenSTA Sdc.tcl，固定 commit 的命令處理實作。
5. 可重跑成本算例與計算結果，僅為假設模型。