IBIS-AMI: 現有AMI流程對DDR非對稱之Rt/Ft適用性之研究

[這篇貼文系為2019 DesignCon IBIS Summit發表的同標題文章做準備, 相關簡報檔及現場錄音(英文)已連結於此文之末。]又:此研究是由本司分在美國及東京的兩位顧問共同準備。

研究動機:

IBIS委員會下有一個工作小組(ATM: Advanced Technology Modeling)在美國這邊每週二中午開會; 若是有空話我都會儘量與會以了解最新的建模趨勢及資訊。自2018年中開始, DDR5於AMI上運用的課題便成為會議討論的焦點。主因在於現今的AMI參考流程係以差分訊號或SERDES為主;舉例來說, SPEC裡談到傳入AMI_GetWave的訊號是由正負0.5間所驅動, 而儘用單一的impulse response來執行AMI_Init似也象徵著Rise time (Rt)及Fall time (Ft)是相同的。現有的AMI流程是否能大致原封不動地套到DDR的單端信號如DQ上便引起了熱烈的討論; 與會的不同EDA廠家對此都有不同的看法, 有些認為問題不大可直接套用, 另有些則認為這裡有根本上的問題而非得砍掉重練不足以應用於DDR5之上。IBIS 規格若要改變向來不是那麼簡單的…覺得規格有不足之處的廠家得以buffer issue resolution document (BIRD)的書面文件表達意見及想倡議的改變; 但如此做則不免要揭露本身的商業秘密或是自曝其短, 所以時至今日並未有如此的倡議產生。對於一建模服務為主的本司而言, 則不免好奇而想像倒底一仿真器能在何種情況下不變現有流程而能直接支援DDR5? 這篇論文便是想出這樣的”一種可能”是如何運作; 實際上大EDA廠可能早已有思慮更稹密的設計而比此處所倡議的更週到,但這麼”一種可能”的存在便應足以取信建模者不需再等待規格的改變而可開始構思DDR的AMI應如何的被建構。

AMI_Init:

通道分析一般有兩種方法: “Statistical” 及 “Bit-by-bit”; 不論是採用何種方法, 流程一開始之初便是仿真器對含類比前端(及IBIS BUFFER)在內的channel進行”calibration/characterization”(以下紅框內所示)。目的是要取得這中間LTI channel部份的突波響應 (impulse response)。對於一SERDES其RT/FT為稱而言, 如此取得在”calibrate”之後的突波便會依序先傳給TX EQ而後再傳給RX EQ, 最終的結果回到仿真器去依機率統計來計算probability density function (PDF), 積分而得 cumulative density function (CDF),再來畫出如浴盆曲線等等的結果。

教科書裡對於突波響應的定義是在無限短的時間內輸入信號由0至1回到0所造成的響應。在實際上, 仿真流程裡最小的時間單位是一個時步, 而含有類比BUFFER的部份是沒有在同一時步內做兩次的信號變換的。所以一般的作法都是改用階波響應而後再加以做一階微分而得到突波。對於一Rt/Ft不同的情況而言,其上升及下降階波並不相同, 也就是說, 如此得到的突波會有兩種形式, 則如果流程不變, 是要把那個突波送進模型裡了?這裡要先提的一點是:暨然是由仿真器對channel來仿真以得到calibrate的波形, 則其可自由地去”probe”不同的節點而有任何它想要知道的資訊。

Asymmetric Rt/Ft:

有的人可能會想:規格裡沒有規定AMI模型在流程裡只可被叫一次, 也就是說理論上而言,仿真器可跑連續兩次流程: 第一次用上升沿算出的突波、第二次再用下降沿算出的突波..分別來運用。如此做不但要花兩倍的時間, 主要的是若在同一個process裡, 一個.dll等的模型被叫兩次..也就是先被叫AMI_Close後又AMI_Init的話,則取決於模型的編程, 很可能會有穩定度的問題。比如說如果第一次叫AMI_Close時記憶體沒清好, 則第二次AMI_Init的呼叫就未必會得到和第一次叫時同樣的結果,如此一來等於仿真器的穩定性就不能保證了。

如上所示, 如果仿真器在Calibrate的時候用的是一個UI很大的方波, 則其響應同時會有上升及下降階波的部份。如果說在這過程中, 仿真器同時去probe TX analog buffer PAD端的話, 上升及下降時對channel的輸入是X1(t)及X2(t), 而其在RX PAD端的響應是Y1(t)及Y2(t), 因為吾人可以導出一轉移函式Xform(t)其在兩輸入信號X1(t), X2(t)之間做轉換,而整個interconnect又是LTI的, 所以Y1(t)及Y2(t)之間存在的也應就是同樣的轉移函式。也就是說, 不論仿真器傳進AMI模型裡的是由上升或下降沿所得的突波, 因其有Xform(t)的資訊, 兩種都Y1(t)及Y2(t)都可在最後透過轉換而取得, 也就是說:一仿真器可透過現有的AMI流程而得到兩個不同的響應。

依據這個想法我們寫了一個簡單的matlab script, 其將不同的輸入訊號inp1 及inp2 之間的轉移函式Xform(t)算了出來, 而後把由當輸入為inp2時的實際輸出out2各由輸入為inp1時透過Xform(t)所重建的理想inp2的輸出out2’來比較, 其可完整的重合在一起, 也就是說驗證了這個理論的可行性。

而一旦我們有分自兩個不同斜率所得的完整響應之後,就分別去建構出兩個不同的眼圖, 再把兩眼圖中分屬於上升沿及下降沿的部份抓出來合成一個眼圖…這就是在非對稱Rt/Ft之下應得的眼圖, 其與SERDES的應會不同…即應會顯示非對稱性。

其次, 對於不同Rt/Ft在PDF的計算上也有點不同, 因其必需考慮到之前位元的值為何而不是在不同位元間相互獨立。比如說在算SERDES的PDF時, 若不考慮到編碼(如8b10b)的話, 每一個位元出現0和1的機率各為50%, 也就是因此吾人能透過不同位元間pdf的相互convolve而得到最終的pdf; 但Rt/Ft不同時,我們要分別就上升沿和下降沿的階波做考量, 如果是cursor用的是上升沿的話, 表示這個位元現值為1且前值(cursor – 1)為0, 同樣的, cursor-2分有0 和1 兩種可能, 若其為1, 則在cursor-1所形成的下降沿波尾部份會和現cursor的部份做重合, 凡此種種, 意即一個仿真器得事先決定要追踪的位元深度,而後就此深度內每一個0或一的可能做如樹狀的記錄, 最後再把這記錄內不同時間點上升沿或下降沿的部份去在cursor的那點做疊加而得到最終波形, 這些工作自不簡單, 但全是仿真器裡可做而與AMI模型無涉的。

AMI_GetWave:

根據SPEC建議的標準流程:在bit-by-bit模式中, 數位位元列傳給TX AMI後, EQ過的TX信號由仿真器和Channel的突波做Convolution再把這信號傳給RX AMI 做末端的EQ, 這期間,不論是TX EQ 或是RX EQ都有可能不是LTI地等化信號, 所以之前倡議的Xform(t)轉移函式在此並不適用。

假設先這樣想: SPEC裡只規定仿真器在此處理的是TX EQ出來及輸入到RX EQ前的信號, 而其方式是與Channel的突波做convolution, 那是否有這建議以外的做法又不動到標準流程呢?

如此的一個例子如上圖上半部:假設仿真器並不是用convolve的方式, 而是把那TX EQ出來的信號透過傳統transient simulation的方式來得到在channel末端的波形, 那所有因不同Rt/Ft所造成的影響也就自動包含在裡面而不需要去做額外處理了;但這樣的做法不僅慢(因為要跑傳統時域分析), 且也和規格建議的做法甚為不同, 所以我懷疑真有仿真器是如此運作。

另一種可能是先把TX EQ的輸出和一個UI的數位信號做de-convolve, 把這UI的方波算在channel的頭上而用仿真器去把channel 對這方波的響應算出來, 這樣一來Rt/Ft的不同儘在這方波裡, 而因為只有一個方波…在做最後Convolve時應會快得多, 那這樣做是否就可解決問題了呢?

實則未然…如上圖所示, 當我們用Rt/Ft不同的方波透過Convolve的方式去合成不同位元的信號波形時, 會造成一些”glitch”,這是因為利用疊加的方法並不能把Rt+Ft變成一個平線, 也就是說若有連續同樣的位元信號如01111或10000時, 用方波Convolve形成的合成波形在都是1或都是0的尾端不會有一static state. 其glitch的程度取決於Rt和Ft有多不同, 也就是說, 在這種情況下, 應用Rise或Fall 的階波去算才能得到理想的效果(接下來細節仍很多, 不再往下探討)

結語:

在這篇文章中, 我們討論了若要將現有IBIS Spec裡的reference flow (參考流程)直接套用到有不同Rt/Ft的如DDR的信號時, 仿真器可能有的做法。結論是這是可行的…但仿真器裡得有更多複雜的計算方法以將不同會造成誤差的可能都能考慮進去。當channel analysis係以”statistical”模式進行時, 因為EDA軟體在characterization/calibration的過程中可對任一設計上的節點做量測, 所以其可以有任何想要的資訊, 其中可利用的是在類比TX及RX PAD上的瞬態波形, 透過上升沿及下降沿的波形, 仿真器可預算出一轉移函式, 這函式因整個流程是LTI的關係而也可套用到接收端的信號而使得不論當初AMI_Init時送進的是什麼(上升或下降)沿的算出的突波, 都能將其結果在事後在相互間轉換, 從而兩種資料以合成出不對稱的眼圖, 其間也要做的包括了用如樹狀的追索以對不同cursor處的不同位元做考量…而不是如二項式分佈般每位元間相互獨立。在bit-by-bit流程中, 因為參考流程的限制較多…中間的計算需以channel的突波以convolve方式為之, 而又因非LTI的關係使得不能透過一線性函式相互轉換, 故而仿真器得另闢磎徑…其最終可能得用上升及下降沿的波形(而非突波)來做計算,否則在不同Rt/Ft的情形下, 在原本應是steady state的地方會有glitch的現象…而其大小取決於Rt/Ft間相異的程度。

相關連結:

簡報檔: [請按這] http://www.spisim.com/support/paperetc/20180202_DesignConSummit_SPISim.pdf

現場錄音(英文): [請按這]

IBIS-AMI: 完整的AMI建模流程

上篇的貼文中, 我談到”IBIS cookbook”提供了IBIS類比部份建模的極佳參考資訊; 可惜在為EQ建模的AMI部份, 就我所知類似的cookbook則付之闕如!  要為AMI建模, EQ的理論部份需先導出其演算法、而後再以C語言將IBIS Spec裡的幾個API寫出來, 最後要把這些程式碼在不同的作業系統上編譯..Windows上是編成dynamic link library (.DLL), Linux上則是編成shared object (.SO), 由於不同的編譯器、不同的建檔程式(如make, cmake等)各個的操作指令又不同, 所以這些大都應歸類到資訊或軟體工程的範圍; 也因此其與此工作本質上的電氣/建模等重合性並不高。這也難怪要找到為這一切都寫有詳盡指示的教材或參考資訊實無異於緣木求魚。

在這篇文章中, 我打算略過這些”編程”的細節部份, 專以整體AMI建模的流程分享一些個人的想法。所有從頭到尾的步驟都希望能有所觸及進而能給讀者一個完整的介紹。大致上來說, 其依序可分為下列步驟:

  • 建立IBIS類比模型
  • 準備相關資料
  • 定義AMI模型架構
  • 實際進行編程建模
  • 對單一模型做掃描測試
  • 將模型置入完整渠道測試
  • 編寫使用手冊

以下就分為各步驟做更深入的分享:

建立IBIS類比模型:

信不信…為AMI建模的第一步是要建出其類比的模型部份(也就是傳統的IBIS模型)。這點對於TX端來說尤其真確! 因為TX的EQ是要為”含有TX類比響應”的部份去做等化的, 也就是說:當連接TX及RX端的channel是pass-through時、且RX是TX的一般操作負載情況時, TX EQ要去做等化的等於是其本身的IBIS響應。 如果不事先知道類比響應為何, 是無法繼續算出EQ的各個參數值的。以下圖為例:

這是一個FFE 的EQ電路, 很明顯的是等化的de-emphasis部份為兩個黃色箭頭線所標示; 而為紅線框住的部份:其包含上升、下降斜率, overshoot/undershoot等信號細節, 以及dc的準位等等在在都是類比模型的結果。所以為類比部份精確地建出模型實為TX AMI建模的第一步! 除了IBIS之外, 最近也有BIRD194的倡議(其用S參數來描述類比行為), 無寧地..兩者都是同樣的意義。

對於RX而言, 問題則簡單得多。因為其IBIS模型大抵為ESD的clamp或是terminator外加差分電阻而已。所以不用在那花太多工夫就可實質進入為AMI建模的階段。凡此種種, 有興趣的讀者可見本司之前許多有關IBIS建模的貼文。

準備相關資料:

AMI建模的原始資料可以來自很多方面:比如說是電路的仿真、實際的量測抑或是datasheet等等。就仿真所得結果而言, 第一步當然是在確認仿真結果無誤之後為各個關鍵參數箤取出相關數據以便日後AMI建出來後做為第一步驗證的依據。

以下圖為例, 這是一個TX在不同EQ設定下的的圖型:

由於silicon設定上要激發出不同EQ的時脈未必相同, 所以得到結果後最好要把它們都對齊在某個時間點以便做批次的處理。利用本司的SPIVPro的話, 可以很快地為不同曲線在5.3ns時的值一下量出來並製表如下:

同樣地, 若是原始資料是lab裡量出來的波型, 則得加上手工的程序去量出不同的EQ值, 這點由於多少會有雜訊的緣故會比由電路仿真的流程更加費工且精確性較低:

有些原始設計的效能部份得在頻域才看得出來, 所以在此情況下上述類似的程序就得在比如說DC, 5G, 10GHz等地方進行:

如果原始資料是元件的datasheet的話, 則建模的自由度較高。比如說不同的極點及零點的位置, 都有可能在同樣的頻率點得到極近似的響應, 則用那組資料就都可以, 也或許就要再參考一些其它的限制條件。

定義AMI模型架構:

有了資料之後,下一步就是依資料的樣式來制定出AMI模型的架構。通當AMI的次要組成模組都得反應出原始設計的功能。比如說如果原來的設計裡有DFE/CDR的功能, 則AMI裡也少不了它們。但也有一些情況下, AMI的架構能有有不同的考量, 以下圖為例:

很明顯的是這裡面一定有一個post-tap的FFE, 但上面由不同顏色框起來的部份, 就可以用不同的方式來建模:如果你覺得這些波型都很進似, 則可以用同一個類比IBIS模型外加一個”縮放模組 Scaler”就可套出不同的振幅, 也可能這之間的斜率相差過大而必需由不同的IBIS來表示; 同樣地TYP/MIN/MAX之間的差異也可能用一個類似的Scaler就可以轉出來等等。對於一個repeater而言, 因為其同時具有RX及TX級, 所以EQ的那些功能放在RX那些放在TX也可以有一些彈性。在不同的使用狀況之下, 也很可能同一模型要以不同架構的形式來呈現才能順利被使用, 這樣的一個例子我也已在之前的貼文裡討論過。

實際進行編程建模:

定義好架構之後, 再來就是實際地編程了。如果這不是第一個專案, 那幸運的話可能之前已有類似的設計其源碼可直接拿來運用, 如果是新寫的話, 要注意的是是否夠模組化以便日後能再輕易地重覆使用。由於同一個AMI模型可能被建構多次(several instances)而同時被仿真, 故若用static variables/function的話就要考慮到會不會在不同的instance (相同的class)之間相互干擾, 對於不同的instance是否會位於同一個記憶體空間這個問題可以說每家仿真器的做法都未必一致。再者, 模型裡不要有hard-coded的數值…我就曾經見過一個模型其只能在某個速率下且每UI有32個取樣點的情況下跑…任何其它不同的設定都會造成有誤的結果甚或是crash, 這表示原建模者沒有把用戶不同的取樣、速率設定考慮進去而在內部做適當的up/down sampling。最後, 軟體工程內的許多標準技巧如unit testing, revision control, dependencies check等等也都要弄好。Dependency的部份在Linux尤其重要, 因為在那作業系統上的很多函式庫都是放在lib\之下共享的。也就是說如果模型源碼裡有用到某個外部函式但在編成.so時又沒有做靜態的連結, 則原來在建模工程師電腦上運作無誤的模型拿到另一使用者的環境下就不能跑了。這種情況下,大部份的時候我們都要準備好幾個電腦(可用虛擬機), 裡面只裝有不同distro的OS最開始裝好的情況(所以所有的函式庫都是最基本的)且是吾人所願意支援的最古老版本, 再在那之上去編譯模型的源碼。

有了二進位.dll/.so之後, 再來就是寫純文字格式的.ami檔;這裡沒有一定的格式…有很多不同的語法都可以拿來讓用戶設定某個AMI參數的值及範圍。又由於不同EDA的仿真器對呈現這些AMI參數及其選項的方式都不一樣, 所以通常要先選定一個主要支援的EDA軟體再以那為本來編寫。最後, 由於IBIS本身就有TYP/MIN/MAX不同的CORNER, 所以在寫AMI時若其也有類似的CORNER則也要一齊列入考量, 否則用戶選MAX的IBIS來套上MIN的AMI就出錯了, 也就是說它們之間需要能同步”Synchronize”。

模型都準備好之後,再來就是參數的調效, 之前有提到源碼最好能重覆使用, 所以不同設計所會用到的不同參數就不應直接寫在源碼裡而應以外掛的方式讀進來, 在這裡就是建構這外部參數的步驟。有些界面…如PCIe, 其對FFE的不同tap值都有預先定義好了, 則這裡就沒有什麼變化的空間。更多的情況是有的是仿真或測量的結果而建模者需一個一個地去找出相對應的參數, 如果用手動的話可以說是煩瑣且曠日廢時又精確度不高, 記住..這裡可是有可能多達幾百甚至是上千組設定的, 最好的情況應是用如本司軟體的”Auto-Tune”來自動的調效:

基本上本司程式會先把目標波形及時間點量自動出來, 而後透過二分搜尋的方式漸次地調AMI參數使其逼近至目標值至一個範圍內, 而後直接將結果製表。這樣的流程即使是上千組的參數也能在幾分鐘之內完成。

對單一模型做掃描測試:

這裡要進行的是為單一模型驗證的程序。就如同為IBIS建模一樣, 有了AMI模型之後將其和IBIS部份連結起來再來做的就是用Golden Checker進行語法上的驗證; 由於不同的二進位AMI模型在不同的作業系統上載入的方式都不同, 所以這一步驟得分別在不同的作業系統上分別執行:

IBIS官版的golden checker是直到近兩年才有載入AMI模型的能力; 其所做的是先讀且驗證IBIS檔之後, 再看那個IBIS模型有用的AMI的部份而順藤摸瓜去把相對應的AMI模型也讀進來並測試載入, 要強調的是它們只做載入的動作而不會試著去驅動, 所以功能性的測試還是得另外做。無疑地, 尤其是在Linux上的dependency問題在載入的時候就會顯現出來, 所以這個程序在有釋出Linux版本的模型時是少不了的。

再者, 一個AMI檔可能會有好幾個參數, 且每個參數都會有幾個不同的值; 要完整的測試模型本身, 不可或缺的是要把所有參數所有值的不同排列組合都要跑過。本司的做法是先把.ami檔裡的變數”參數化”(如下圖紅框內, 首尾加入%):

而後用像我們的SPIMPro把不同參數不同值完全的排列組合都列出來, 再來就每一個組合把AMI檔內的變數取代填值, 最後生成不同的.AMI檔案。就這個流程而言, 其很像是我們做SI時所用的系統分析法(探討於此篇貼文);而當有了這麼多不同的AMI檔之後,我們就可以對同一AMI模型做不同參數下的驅動。 取決於所用的EDA仿真軟體, 要能快速有效的批次執行這麼多次可能並不簡單, 、即便可能也是要透過腳本(script)的編寫, 所以非得先廢上一番功夫才成。就本司軟體而言, 這些功能都已內建於SPIMProSPIVPro裡, 所以可在一個環境下不寫腳本就成批次完成。此處用途廣泛的SPISimAMI 模型驅動程式也是不可或缺的角色!

當每一個AMI檔都被用來驅動.dll/.so模型之後, 就會又有數百甚至上千的波型檔待分析, 要做的就是一樣批次地把關鍵值量測出來:

而後再與原始資料相減而得出delta的值或比率, 把這些點以圖形呈現出來就可以很快地看出在那些設定下誤差值較大, 如果有明顯的錯誤的話(比如說沒值可比…那就大概表示驅動AMI模型時大概crash了), 就又要回到前幾個步驟找出問題而後重走流程一次…

將模型置入完整渠道測試:

剛剛所提的模型驅動是單就其本身, 當然最後不可少的是也把其它的相關部份帶進來組成一完整的渠道或設計做全面的驗證。這裡有一個重點是AMI的仿真所呈現的結果都是在時域上的(不論是透過statistical或是bit-by-bit的方式進行), 所以對於有些響應是在頻域上的元件(如CTLE)等來說就不是那麼地直觀可驗證。一般的情況下我們會用一個相對應的原始元件(比如說一個S參數, 其Sdd12就是我們CTLE的頻響)來做:蘋果對蘋果的比較, 這樣來看驗證就直觀得多。

另一也不可少的步驟是把建出的模型在不同廠家的EDA軟體上跑過至少一次且確認結果無誤。這點也可能有其難為之處…因為這類的EDA仿真器不在少數, 隨便一算就有ADS, HyperLynx, QCD, SystemSI, HSpice等等, 每一項都花費不貲, 實際上即使是大公司, 也很少有見到會願意或有需要將它們買齊的, 所以就本司而言, 得串連其它的SI顧問相互支援。舉例而言, 同樣的DLL_PATH保留關鍵字有的仿真器傳進來的是絕對路徑、另有些則傳入相對路徑。如果所建模型用到這參數的話, 未對兩者做相同的支援就有可能會跑出不同的結果, 所以不走這步, 所建模型對其它未測廠家仿真器的支援程度便很難說。

編寫使用手冊:

走到這裡, 最後一步就是寫模型操作手冊了。一般來說, 會包括的資訊最先開始的就是類比IBIS模型的部份, 比如說那個針腳接到那個模型, 其AMI的部份為何等等, 最重要的資訊是AMI參數的名稱、值的範圍及描述等等; 對於如果所用仿真器不支援某些保留字時的應變等等也要提及(比如說如果仿真器版本較舊而不支援DLL_PATH/DLL_ID, 則模型是否有其它的AMI關鍵字可用來做相同的設定), 再者, SILICON或量測值與模型跑出的眼圖相較也應置於手冊之中, 最後一項是對主要支援的仿真器、欲使用所建模型的簡易設定為何等等, 凡此種種, 都是一個完整AMI建模專案所不可遺漏的。

結語:

本貼文與讀者分享了本司為AMI建模的一些必經流程。C/C++編程的部份自是AMI建模重點之所在但需另外觸及的..故不在上述之內。不論是AMI API的參數、設定抑或是編程所用的語言(如C/C++)都是一直在與時俱進且不斷演變的, 所以身為一個建模者, 就得時時去汲取相關的新知以便能最有效的建出精確的模型, 而不同軟體、函式庫或是作業系統的限制與運用也在在都是相關的課題。在看過此篇分享之後, 不知讀者是否仍對親自建模而感到興致昂然?…或者覺得乾脆委外於我由本司為您效勞? 祝您建模愉快! 🙂

簡單快速的IBIS建模流程

對於新上手的建模工程師而言, “IBIS CookBook” [連結按此]提供了極佳的入門參考資料;最近的V4.0版本是在十幾年前的2005年出版的, 時至今日, 雖然其中所描述的大部份程序仍屬有效, 但也有許多其它部份或顯得繁瑣或未盡詳述。這些缺點在第四章”差分建模”的部份尤其特別明顯; 更有甚者, 近年來IBIS峰會上發表的文章大多是圍繞著新IBIS科技諸如IBIS-AMI等打轉, 對於傳統IBIS類比模型的部份著墨就相對少得多。在這篇貼文裡, 我打算首先替讀者重溫一下CookBook裡所談到的正式流程, 而後對其間的一些較具挑戰性的部份加以說明, 並以此倡議一個較為簡化又不失精確的建模方案, 最後提出一些正反意見讓讀者參考。

IBIS 模型組成元件:

在IBIS V3.2中所定義的最基本組成元件如上所示; 對於一個輸出BUFFER來說一般至少要有六個資料表: 即IV資料如Pull-up 及Pull-down, 及兩組不同負載情況下的VT資料(Rising/Falling各一); 若是輸入態的IBIS模型, Clamp的IV資料或也要, 而IBIS V5.1又加入了新的IT需求並以ISSO PU/PD及Composite Current等來描述電源供應網路PDN的效應。要為一IBIS模型建模, 一開始便需對這些各別表格所表述的電路部份加以驅動以激發得到相對的響應; 有了仿真的資料後便做後處理以產生出如SPEC規定的表格等的格式才能加以使用。由於一個模型通常也有TYP/MIN/MAX三種組態,所以實際上需要仿真的次數便是上述的六(個表格)再乘以三(種組態)而至少達十八個之多。

我們以下列摘要的方式再對包含於上面圖形但未為即將倡議的新建模流程所觸及到的部分加以簡述:

  • 封裝的寄生元件: IBIS CookBook裡並未談到這個部份, 一般來說buffer的封裝模型(package model)是由諸如HFSS或Q3D等套裝軟體由實際設計透過三維場解來算出來的, 其格式可為S參數或相對應的Spice等效電路; 一個IBIS模型可以用 Lumped R+L+C來對單一的針腳PIN來描述其寄生效應。或者也可把此lump值放在 “Package” 部份來套用到所有的針腳;需要更精確的描述的話則可用如下有樹狀結構的[Package Model]語法來描述。不論如何, 這些都是三維場解軟體所可以生成的而不在一般IBIS建模流程的討論範圍之內。
  • C_Comp: 在IBIS剛制定之初, C_Comp只用一介於PAD及地點間的單一值來描述頻率性的負載; 後來HSPCIE等發明了一些語法來把這單一值打散並分到PAD與各個不同的電源端點間; 又到最近IBIS Spec.便納入了這些語法而成為標準的一部份;話雖如此, 一般建模人員從網上仍可能只會發現單一的C_Comp值是如何算出來的。簡單地說, 其不外乎是透過時域的仿真以RC的充放電常數來得值、抑或是由頻域的虛部電流除以頻率來得到電容值。至於之後如何把這單一值分開來以便更佳描述如下的頻域二維表面則得仍由各人發揮所長(意即:cookbook裡根本沒說)。最後, 這個C_Comp值的效應在建模的過程裡是看不到的, 唯有在信號從另端因阻抗不匹配的緣故反射回來後才能看到這C_Comp值所造成的影響。凡此種種, 我們發現一般上此buffer的IC設計師比透過上述的時域/頻域仿真所算出的C_Comp值了解得更精確, 也就是說常常問他們就可得到大概的估值。
  • Clamp 電流: Power/Ground Clamp的電流和Pull-up/Pull-down的電流都是在穩態下得到的, 在仿真時這四者也是一同拿來做load-line的計算的;所不同處, 因為clamp所表示的是ESD的保護電路故其為總是存在 (always on), 當這兩組表格存在時, 為避免其又被在PU/PD表格裡又再被算一次 (double counting), 在做後處理時需把這部份自後者中移除。若要簡化這個麻煩, 其實一個有IO功能的buffer 在被拿來做輸出buffer使用時便可直接以output type buffer來建模而非io type buffer而可略過此一部份。

 

  • IT 電流(Power aware): 這些是為了描述buffer 在非理想供電或接地情況下的運作而需加入的資料, 其應用則主要用在如DDR DQ的單端點模型裡, 因為它們對PDN的擾動所造成的時間影響最為敏感。對於諸如SERDES的差分模型而言, 因為在P及N點的輸出端會被PDN同樣的影響, 在相減之下效應就抵消了, 所以影響很小而未必有此需要。最後, IT在瞬態的部份其實是和VT一同仿真的, 其只是在PAD端加上一個電流的Probe便可取得相對應的資料, 而且這IT和VT的各點間是需同步的, 所以只要在同一仿真裡就可完成。

完整IBIS建模流程:

本司的BPro軟體已將於上述IBIS cookbook裡所建議的建模程序標準化而總結如下, 其有從0~7的八個步驟:

  • 0, 搜集原始設計相關的資訊: 這包括了(PVT即製程、電壓、溫度)、矽智財、Buffer端點的偏壓及設定等等。一般的buffer設計都會預留許多腳位以便為日後調控所需, 因為一個IBIS的corner有TYP, MIN, MAX三種, 故建模者也得先決定那些組合的腳位設定對映到那種corner;
  • 1, 準備工作的環境: 即工作目錄;
  • 2, 產生仿真的網表: 即驅動不同buffer的組成部件及其仿真時的設定; 如前所述, 以一般的buffer來說, 最少就有十八個網表得在步驟末生成;
  • 3, 進行仿真: 一般可在建模流程軟體內依序地仿真或將所有的網表散到不同的機器上(simulation farm)同時並行;結果出來之後得檢查一下看是否有誤, 若然則得回到一開始的地方檢查看是連接有誤或偏壓不對, 不做修正就繼續往下走就會變成”垃圾進、垃圾出”..產生的模型一定有誤。
  • 4, 產生IBIS模型: 後處理由前一步所產生的仿真資料以產生IBIS模型。這裡面的計算或調整往往就是諸如本司建模軟體的精華所在, 很多步驟是可以用手動或人工去進行、但往往容易出錯又曠日廢時。
  • 5, 語法檢查: 一有了模型之後, 最基本的驗證是用golden checker進行語法檢查, 它也會對dc電位等做基本的測試; 若一模型有根本上的錯誤(比如說vt波型是平的), 在這一步就可以檢查出來;
  • 6, 用模型做仿真上的驗證: 把產出的IBIS模型連到 test load上進行仿真以便第三步由矽智財仿真出的結果相較, 理想的情況下, 除了信號從進去到能見於pad的Tco有別之外, 在波型上應是要能完全重合的;
  • 7, 產生報告: 建模者最後往往需將諸如PU/PD阻抗及slew rate等的模型參數列出來, 以便和data sheet相較或者做為模型報告的一部份。

本司BPro裡的完整建模流程

單端建模資料之轉出:

對於單端點的IBIS建模而言, 上述建模流程的第一個具挑戰性的地方是要能把十八個不同仿真的網表都建出來且順利仿真完成且結果無誤:

這裡面可能出現的問題很多在於DC IV的仿真部份: 很多的IC BUFFER設計裡都有clocking的信號, 這使得真正的dc掃描從-Vcc到2Vcc變得不可能而必需透過如pseudo transient的方式來進行, 其次, 若設計是於佈線後(post layout)的階段轉出來的則各個電路點之間會有一些寄生元件, 另一種情況是雖然我們只針對IO的buffer部份建模, 但電路是他人所設計而不是很容易把前級的部份和只有IO的部份分開來而最後必需一起仿真, 凡此種種, 都會使得仿真的時間變得冗長甚或是有時無法收歛。其結果是上述0~7的流程得從中間往返走上好幾回、每次調參數或除錯而終得費上好一番功夫才能得到所有建模需要的資料。以上雖繁瑣,但由於也就不過是那十八個網表, 所以大致上應該問題都能解決。

差分建模資料之轉出:

差分建模的複雜性就又比單端點的情況多上一個維度了(不只是多了一倍哦, 是多了一個dimension!) 首先, 依據IBIS規格…就像每一個IC的data sheet裡所呈現的一樣… 一個針腳只能連到一個buffer, 而不同針腳之間的連接是有很高的限制; 就差分模型而言, 一個series element能如下所示地用來描述p及n反相針腳間的相互情況。(本段落所用的圖型都出自於ibis cookbook第四章裡, 所以有興趣更深入了解的讀者可以按圖索驥以得到原始的描述)

為了能建構出這麼一個series model, 就必需分就p及n輸出端點間做二維的dc掃描; 而且兩者的資料精度必需相近..也就是說如果就單端建模的p點iv曲線我們有一百點的資料, 則同樣在n點的維度上, 為了也要能得到一百個取樣點, 我們就得對一百個網表進行仿真;就三個corner來說, 就有三百個仿真要跑。這一dc iv掃描步驟的最終結果是一個能描述p及n點間dc相互關係如下所示的二維曲面; 唯有看到這二維曲面的形狀為何, 我們才能決定那個series element內有那些次組成元件(其可以是一或更多的R, RL, RLC, 非線性電阻或是一整個非線性平面), 而其中要能產生這二維平面所需先進行的處理步驟之一也包括了要能將同模的電流自P及N點間消去, 凡此種種皆算是第一道的難關。

第二道的關卡在於VT的仿真部份, 由上述的曲面建構出series model 之後, 我們要能在VT瞬態仿真時將其消除才能不被算了兩次 (double count); 對於一個spice 仿真器而言, 大部份的情況其都不允許負電阻、負電容等的存在, 也就是說, 它們會把這些負值元件看做是用戶的輸入錯誤而不讓仿真繼續進行, 解決之道, 吾人可以用如本司在2016年Asian IBIS Summit所展演的Verilog-A 電路或是仿真器大都會提供的控制電源來達成這種”負電阻”似的消去目的;即便是如此, 在Verilog-A的解決方案上, look-up table上每個grid的大小係由iv二維描描所決定, 而控制電源的解決方案上, 為了要能算出適當的控制電源參數, 建模者還得利用最佳化的原理才能算出何種組合的參數最能描述上一步算出的反應曲面; 而這些不論是表格或是參數變化間的圓滑性(smoothness), 也都更進一步地決定了仿真的收斂性。凡此種種情況,難怪cook-book裡描述此段的部份(見下圖描述的前兩行)作者只是輕輕一語帶過而不做詳述, 因為真的是說得比做得還簡單啊。

由於這兩大關卡及之間種種藏在細節裡的魔鬼, 我們發現差分的建模對一般的建模者而言不是那麼地簡單。讓我們更有此感悟的情況是: 當本司在提供建模服務時, 很多情況建模的仿真或因IP的考量、或因對原始設計的熟悉情況所限, 往往是由客戶所進行的, 我們雖已盡己所能地把這些該如何設定及其原理為何做最詳盡的描述,但在客戶端仍常常碰到問題或反應意見說要很久的時間才能得到所有需要的資料, 其次, 客戶之所以把建模工作交給本司就是不願去淌這混水…如果很多麻煩的地方仍得自己來過,那建模外包又有何益? 所以就本司而言, 對於去找出更快速有效的建模方式, 其實是都持續不斷地在進行的。如果我們建模的目的是為了能跑Channel Simulation (而非萬能地又做穩能又做時域依真), 也就是說如果了解模型的運用是在某種特於的環境之下, 那是否有更好(尤其是差分)的建模方案呢?

簡單快速的新建模流程:

之前的貼文中, 我們提到了IBIS模型內部的資料在仿真時是如何被運用的; 簡單地說, VT的資料在得到波型一樣的負載情況下, 是做為一個目標(target)的; 在此”目標”之下, IV的部份則會被拿來算出一組時變的切換參數以便使適量的電流能自PAD點輸入或流出, 基於KCL/KVL的考量, 這適量的電流就會造成仿真矩陣運算時節點的適當電壓而終能符於VT的曲線; 其次, 由於分有Pull-up及Pull-down的切換參數要解, 所以就得有在不同負載情況下的VT曲線才能由兩組資料解出兩組未知;這也就是說, 其時IV的資料和算出的切換參數是互為表裡的, 做為表面、看得到的IV部份需由看不到的參數來配合, 如果IV某電壓點的值小些,則用到那電壓點的某個時步上的切換參數值就得大些才能使最終電流維持不變。從這點來看, 待算出的切換參數可以視做是IV曲線的加權或調整參數。

在另一方面, 每一組的VT曲線裡也內含了對IV曲線一些部份的限制, 在這些限制之下, 兩者之間(即VT及IV)必需要相符否則就會有dc mismatch的錯誤情況發生。最後, IV本身的資料限制是只能有最多一百個點且其間必需單調性的遞增或遞減否則就易在仿真時產生不收歛的情況(stuck-at local minimum)。這些都隱喻了模型裡各個資料間的相互關連性。

由上所述, 我們可以推出一個簡單快速的建模法所需的資料產生步驟為:

  • 將原始silicon設計連到相對應的PVT及偏壓情況下後得到VT仿真資料, 而這VT是如此設定的:
    • 就單端點模型而言, 僅用兩組不同的負載情況(test load)
    • 就差分模型而言, 先做一般使用狀況下(比如說是一百Ohms的輸出差分電阻)的仿真, 得到電壓介在V1及V2之間
      • 設V3=(V1+V2)/2, 以V3為VFixture, RFixture=比如說是40及60, 分做兩次仿真並以此為資料VT波型;
      • 或者用RFixture=50, VFixture分為(V3+V1)/2及(V3+V2)/2並進行仿真, 以此為資料波型;
      • 這一步驟的主要目的是要取得能內含正常運作情況下的兩組波型;
  • 由IC設計師那兒得到C_COMP值;
  • 得到不同Corner的電壓及溫度等參數。

就這樣,再透過不足外為人道也的數學運算及解析, 我們就能透過最少的仿真步驟而產生IBIS模型, 且這模型不會有語法錯誤又能在相同負載情況下重現上述所提供的兩組VT資料。

我們雖不能詳述這中間倒底是怎麼做的, 但可以分享的是在我們的BPRO上,如此的流程僅需填值到如下的GUI裡就可在幾秒之內產生出來, 過去這大半年來,我們已用此法建出許多為客戶所用的模型, 跑起來亳無問題!

優缺點及限制:

我們運用此法建模的使用場景主要是含有IBIS-AMI的差分模型且用於channel simulation情況下, 以此來看, 如此倡議的快速建模法會有如下的優缺點:

優點:

  • 只要透過最少的仿真(即兩組VT仿真), 便能得到建模所需的資料;
  • 就數學及電路分析上會絕對正確, 故而不會有如DC mismatch或monotonic等的語法問題, 在驗證時相同負載的VT結果一定能重現原始資料的波型。

缺點:

  • 如果把這IBIS模型拿來做DC仿真/掃描的話結果未必會精確, 因為模型內的IV資料點是用演算法算出來而不是真的一步一腳印透過DC掃出來的;
  • 沒有”disable”或”high-z” 的state, 因為所有的clamp電流都已內含在算出的pu/pd IV曲線中;
  • 不能拿來做Power-Aware的仿真之用, 因為其中並無ISSO_PU/PD, Composite Current等的資料。

結語:

在這篇貼文裡, 我們首先重溫了在官版cookbook裡傳統IBIS的建模方式及流程, 而後談及了這流程中可能會遇到的困難…尤其是差分建模的部份; 以次我們提出了一個”簡單又快速”的建模方式….其運用了數學的演算來人工合成出模型的部份資料, 這倡議的方式僅用最少的仿真便可建出有效無誤的模型。它有些使用場景上的限制…比如說沒有High-Z State且不能拿來做power-aware的DDR仿真等。我們研發此法的主要運用是含有IBIS-AMI的channel analysis, 以過去大半年的使用來看可驗證其有效及方便性, 因此我們在近日的SPIBPro更新裡也加入了此一功能以使我們的軟體用戶也能同享此快速建模法所帶來的好處。

IBIS-AMI: CTLE二三事

前言:

中文翻做”連續時間性線性均衡器”的continuous time linear equalizer (以下簡寫為CTLE), 常在現今通信渠道(communication channel)裡被使用; 當一channel信號損耗較大時, CTLE常被拿來為接收端或下游的鏈路做為減少失真、恢復原始信號的一種方式; 在網上已有許多有關CTLE在理論如何運作的探討, 更深入的設計細節也在大學/研究所程度的教科書裡找得到;在這篇貼文裡, 在簡短介紹CTLE為何之後,我想要以為CTLE 建IBIS-AMI模型的角度談一些實務上的考量;其中雖然一些關鍵處為了業務機密的考量只能點到為止, 但仍希望會對考量建模步驟或流程的讀者有些幫助。

[Credit]: 這篇貼文的一些用圖來自Sam Palermo教授的課程摘要(連結於下), 雖然共事時彼此不認識,但我們之前都同一時期在在Intel工作過…

ECEN 720: High-Speed Links Circuits and Systems

 

什麼是CTLE及為何用它:

上圖為兩個常見的SERDES通道原理圖, 上方者在TX及RX間直接為被動性的channel所連接;而下方者則是透過了位於中央的repeater把上下游兩個Channel連接起來;在很多界面裡(如USB3), 這種串接(cascade)可以連續好幾次, 所以會有兩個或更多的channel相連接;這些通道裡的Rx端或Repeater/Redriver裡就可能會有CTLE;而圖中的”S” 方塊係泛指如封裝、通孔VIA、傳輸線及連接器connector等等被動元件的合成S參數;這些通道元件有些共通的特性..如在頻域上對不同頻率會有不同的耗損/速率改變, 這種現象一般稱為色散(dispersion)

舉例來說, 我們可以把這些以S參數代表的差分輸入/輸出曲線在頻域上畫出來, 就會得到如上圖的不同損耗曲線。

在現今數位通信的傳送的位元信號多是以方波來表示0與1, 我們知道這些波形裡的快速上升或下降轉換過程(rising/falling transition)含有豐富頻率成分的部份;理論上來說,要保持被傳信號不失真,這些不同頻率的成分應被一視同仁地被續傳下去,但現實上這種所謂的unit-gain all pass filter並不存在, 所以各種頻率成份也就或多或少地被放大或縮減了; 如果下圖中的綠框代表我們想要得到的這種理想無失真狀態:

而實際上的通道卻是如紅框所示, 則要為信號加以補償,吾人所需加入的就是如藍框的線性均衡器,而這也就是為什麼均衡器常被使用於有損通道的原因:由於線性關係其在頻域上可和通道的特性曲線直接相乘而得到趨進理想的傳輸特性;這裡有兩點值得注意: 其一是均衡器和所欲補償的耗損是配對的, 也就是說若拿同一均衡器來套到不同損耗的通路,就可能會有補償過度或不足的情形;其二是CTLE只是這裡所示均衡器裡的一種或一個環節。

CTLE 只是linear equalizer裡的一種:

線性均衡器可以用很多方式來設計或呈現;舉例來說, 如下的feed-forward equalizer就被常被用於Tx及DFE端:

這類的均衡器的頻響有部份限制, 但其作用較易於理解且AMI實作上也不難, 比如說如果只有一個tap的話, 其對波峰/波谷在時域上的作用可以很容易地被了解, 適當值也可藉由掃描而後做內/外插:

但本文所談的CTLE則是代表廣義的均衡器,所以我們常用其頻域上的響應來代表其行為作用;也就是說, 為了如之前所提地對不同耗損的通道做信號的補償,吾人就要有許多不同、相對應的CTLE特性曲線如下所示:

那我們要如何才能得到代表這些行為的資料以便建模呢:

建CTLE IBIS-AMI模型的不同資料形態:

雖然到此為止我們只說到頻域的部份,但拿到以AMI為主的鏈路分析上還是要回到時域來和輸入信號做卷積, 這是因為就SPEC規格上的定義來說, 一個AMI模型所會接收到的輸入不是時域的突波(impulse response)就是時域上的位元波; 前者係用於statistical 模式而後者主要用於bit-by-bit模式,這麼一來,我們就有兩種為模型提供資料的可能: 分別是提供頻域或時域上的資料; 前者(頻域)的好處是其可針對要做鏈路分析的脈波速率及取樣頻率當場在模型裡來做傅利葉反轉(iFFT), 後者(時域)的好處則是所提供的資料已事先檢查過而可確認具有適當的品質;雖然實務上這兩者擇一而用即可,但最具延展性、擴充性的實做方式(也就是本司的實作方式:-) )則是對兩者均支援而能減少對AMI模型的改寫、編譯次數。

  • 頻域資料: 取決於原始設計/資料可否使用的程度, 我們可藉由以下不同的方式來獲得頻域上的資料以便為AMI建CTLE的模型:
  1. 極點及零點: 由不同數目及位置的極點及零點, 再加上DC的放大程度, 則吾人可以”合成”出頻域的響應:  比如說如果我們手上所有的資料只是待建模型的資料表(data sheet),則首先可以從上面找出關鍵頻率必需要有的放大程度 上圖的例子是USB3.1, 所以關鍵頻率是和其運作主頻相關的諧波;當對不同數目、位置及DC放大性做掃描之後, 我們就可以很容易地找到幾組符合此data sheet spec的頻率響應:也因為這些曲線係由預訂的線性函式(由那些極零點所組成)所產出, 所以一則為相對穩定、高品質而不會有passive/causality上的問題,再者也從0Hz 到極高頻皆唾手可得。
  2. 由S參數轉出: 另一種可能是由代表此均衡器的S參數來轉出, 適用的場合包括當矽智財為外購而原始設計不可得, 原智財有方只願提供此行為模型時(behavioral model); 從某個方面上來看, 這樣的原始資料代表在後面的correlation驗證階段會更容易…因為這就是要去建AMI模型的golden data/target, 但在另一方面的大部份情況下, 這也代表得先為這些S參數做一些預處理才能得到如上段結果般的頻響曲線。以用本司的SPro功能而言, 下面幾個步驟是不可或缺的: 首先手上的S參數可能是單端點(single ended)且適於某種port ordering的 (如1->3, 2->4), 則先要做port reordering 至1, 2->3, 4, 而後用generalized 2-N port 做differential mode/mixed mode 轉換,而後外插到DC及夠高的頻率(由VNA等所得的頻率通常只有10或20GB…這是遠遠不夠的), 在外插的過程中所有的計算均需使得這個S參數仍能保持適當的物理性(如causal), 最後再把只適用於differential input->differential-output的那個部份從S參數裡extract出來成單一一條頻響曲線(含magnitude及phase)。
  3. 做AC仿真: 如果有原始設計的話,當然直接做AC仿真可能更快更方便些, 雖是如此, 如此得到的曲線仍需先做資料我檢查及驗證(sanity check), 比如說相位是否連續、頻寬是否足夠及在高頻及低頻時, 所有的大小及相位是否趨於平坦等等。
  • 時域資料: 一旦有了上述的頻域資料, 理論上來說我們就可多做一步地把它們都轉到如下所示的時域上;這裡也可以有兩種做法:把原頻響做iFFT或把原始設計在時域上仿真。
    1. 如何做iFFT: 這裡適用的情況可能是您不打算從AMI必需要有的C/C++語言來做iFFT而想藉助如matlab或python等的機制, 雖然這些數值分析的套裝軟體或函式庫已會幫您做很多幕後的工作(如線性等距取樣至2^N點的), 但zero padding或complex conjugate padding至Nyquist rate通常還是得用戶自己做; 同樣地,在做iFFT轉換前的頻率資料是否”乾淨”也是得自己下場檢視的。略過此一步驟則轉出的時域可能就會有很多低頻的噪音或波動。
    2. 做時域仿真: 理論上的突波響應(impulse response)不難理解,但實務上要如何設定仿真? 就算是以階波響應再做事後的差分好了, 階波的上升速度應多快? 其與到時AMI被仿真時的時步(time-step)之間關係為何? 若需要臨場的縮放(scaling)那AMI模型要如何地得到原時時步/設定的資訊? 如此種種都是當事先要轉成時域資料時不可不想到的細節。

建CTLE IBIS-AMI模型時的種種考量:

好不容易終於有可建模的資料了, 下一步是如何把這些資料以C/C++的形態呈現以符會AMI的API 所需, 比如說下面幾點都要想到:

  • 如何決定用那條曲線: 如前所述, CTLE和不同耗損的通道是有相對應的,則當AMI模型用戶在使用此CTLE的AMI模型時, 要怎麼知道該用那個設定呢?

常見的方式是在模型使用手冊裡明載而讓用戶依據其自己現有通道的耗損來自行決定, 這就沒什麼學問了; 更進一步的可能是在CTLE的模型裡設有自動調適化的機制(adaptive), 則這就又是另一課題…

簡單來說, 要做可自動調適的CTLE首先必需把能使用的曲線/頻響做一EQ程度的排序, 而後要對模型針對某一輸入信號所均衡出的結果做一效能的定義(figure of merit, or FOM), 則當模型得到一輸入信號時, 先就現有的CTLE設定做信號均衡、而後計算出FOM值, 接著繼續以相鄰的CTLE設定去做同樣的步驟,以結果FOM的正負變化來決定繼續往上或往下”走”, 如此重覆直到FOM已穩定 (locked)於某一設定或達到所有的CTLE的極值(第一條或最後一條頻響)為止, 因為如此步驟的結果應對某個通道的不同信號都適用, 所以在鏈路仿真之初會要有一段時間的training period以便能鎖定到要用的CTLE值之後才不再改變等等。

  • 種種EQ的設定: 當我們有了不同組態的不同設定, 再加上可能不同corner等於多加了一個dimension, 再來要怎麼編程以符合AMI API的要求呢?

這裡開始可能更多的是computer science上的考量而和原始CTLE設計無關了, 總的來說是方便及速度的間的考量: 比如說我們可能想把所有資料的全部頻域/時域資料都以極細頻率/時步的方式提供,但發現這樣一來模型太大且仍不可避免要做內插, 或是如果所給的資料非等步且非2^N(常為FFT/iFFT所需), 又要如何有效的重新取樣? 最後, 這些資料如果直接一同編進DLL/SO二進位檔裡則每次設計更改(design revision)都要重新編譯, 放在外面呢又要如何的加密以確保原始資料的IP等等,這些都是在開始寫CODE編程之前都要先做好的規劃及考量。

  • 如何驗證模型: 好不容易模型做出來了, 如果按照golden data或和原始設計來比的的話, 這個CTLE應能有效地把下圖左的訊號還原至失真小得多的右圖:

現實裡要能一次達標或一試中的機率大概和買樂透中獎的機率差不多, 所以多半的情況模型做出來後接下來的是折磨人的除錯階段; 在AMI模型之外, 要能得到上述結果也不可不考慮到的還包括了IBIS模型的部份(類比前端), 因為這些IBIS裡的parasitic, loading 乃至於 rising/falling waveform 再再都會影響結果, 關於此點我們之前的貼文也有詳述, 其次,仍是點到為止的是IBIS-AMI是有高阻抗假設的, 所以要直接取代(drop-in replacement)手上現有的其它原始模組還要考慮到的是匹配的問題; 最後, 一個設計完善的CTLE AMI模型(或AMI模型)都要有很完善的除錯設計, 如此可指引出所給資料是否在重新取樣後質變、轉成時域後有問題、或是按時步縮放結果恰當與否等等而毋需反覆重新編譯模型搞得不知手上的波形是那一版本的AMI跑出來的結果。

結語:

凡此種種,應可讓有興趣的讀者看出一CTLE雖然理論上不難了解,但一旦要落實到低階的、以C/C++編寫的AMI模型時則又是另一番境地;本司就看過堂堂EDA大廠做出的CTLE模型是如何的便宜行事, 以至於後來原建案的矽智財廠商僅僅為了一些design revision(也僅是要容納更多的頻響選擇)就必需砍掉全部重練的案例, 這當然也是因為其把所有的設定都編進模型了又漫天喊價以至於矽智財廠不甘從此被綁架而找上經濟實惠的本司之故 🙂 。希望本文所提的幾點, 能做為有心直接下海實做AMI模型的諸君一些實務上的考量, 或是能了解其中”眉角”之一二之後決定由經驗如我司者來為您服務更為方便有效率:-)

SERDES通道分析三部曲

前言:

本司日前完成開發測試並釋出了數款可免費使用的網上應用程式以應通道分析的一些步驟所需 (相關資訊請按此) 雖然這些軟體個自的產品網頁對其功能及使用上都有單獨的介紹, 但我們認為若也能在一套流程裡把它們串連起來則使用者就更能有個完整的概念並對背後的設計理念能有更深的了解。所以寫此篇貼文有雙重的目的: 首先我們希望對一般通道分析(channel analysis)的流程做個介紹,其次也希望展示讀者我們的這幾款APP可如何應用於其上。相較之下,一般要開發AMI模型並得到可做此類分析的仿真程式沒有十數萬美金起跳是不可得的, 現在直接從網頁就可免費執行!

概觀:

[Fig. 1, A SERDES system]

  本文係以上圖的SERDES系統做為案例, 至於其它的界面如DDR, 則請見上篇貼文對有關本流程適用性的探討; 上圖中中間的藍色區塊所涵括的部分即為通道的部份(channel), 其主要的構成為被動元件如封裝、傳輸線、導孔、連接器甚至是cable等等,話雖如此, 主動元件如TX及RX端的類比前端也應被包含在內, 這些主動元件的模型一般都是IBIS或與製程或有相關的Spice設計呈現。另一種可能的做法是把這些主動元件排除在藍色塊通道的定義之外, 而將其與TX EQ, RX EQ等連在一起做;這種做法下的通道(藍色部份)即可以一S參數來描述。之所以會這樣做有可能是因為主動元件的IBIS模型不可得或是要得到通道響應的仿真器對手上現有的主動元件模型並不支援, 例如現今網上的免費仿真器以我所知都不直接支援IBIS。而如此因而和TX EQ及 RX EQ相結合的類比前端級就會加上AMI模型設計的複雜度所以可謂是收之桑榆但失之東隅。一般而言,這中間的通道部份的確是會把TX/RX的主動元件所包含內的。

有了透過仿真所得的通道響應之後, 接下來就是對TX EQ 及RX EQ的部份加以建模。最常見的模型格式是IBIS-AMI, 有關這些本司之前的大部份貼文都已有許多探討故在此不再多加著墨。

最後有關通道分析的部份, 首先仿真器會將通道的時域響應或S參數轉為突波響應, 而後取決於所選定的Statistical 或bit-by-bit模式,或者將此直接送入TX EQ也或者先和PRBS的位元列先做卷積再送入, 而後把TX EQ的輸出再送入RX EQ後把最終結果以眼圖或bath tub的形式呈現。之前有談到中間含主動元件的通道部份, 其整體來說雖是有源而非被動, 但在通道分析上仍是以線性非時變(LTI)為假設, 所以當EQ部份也都是LTI時, 光用一個位元波(single bit response)就可以拿來透過各種排列組何來算出所有可能位元序列的機率函式PDF, 從而再積分得到CDF而畫出bath tub曲線並能對不同BER下的眼高或眼寬做一量測。但若是EQ部份為非線性或時變(NLTV), 則就只能乖乖地跑上數萬至數百萬的位元再把如此所得的時域波形疊合起來形成眼圖再依此量測。於此尚未提到、本司釋出軟體也尚未內含的、是抖動(jitter)及噪聲(noise)的部份, 理論上而言也是將其各自的PDF再和現有的PDF做卷積而得到加乘的效果, 至於實務上的考量他日再以專文探討。

由上所述的通道分析流程細節可見於第IBIS規格文件的十章第二節裡。簡單地總結來說,一個通道分析的三部曲包括了1.得到通道響應、2.得到或產出EQ模型、及3.把這些都放到通道仿真器裡得到分析結果。

 

一、 通道響應:

通道分析第一步的是對通道做時域仿真以得到其響應,如前所說我們也把TX/RX的類比前端包括在仿真的原理圖或網表裡,並以全部響應會是LTI為假設。如果現有欲分析的通路是佈線後的結果,則第三方的全波場解程式則為必需, 因為諸如VIA或連接器等都需以全波的形式場解(field solve)才能得到精確的描述;broadband spice也常是需要的, 因其可將場解出的頻域轉成如RLC/EFGH的仿真器內建元件而於時域上使用;若通道是為佈線前的分析, 則這些Via/Connector的模型仍為必需但傳輸線的部份則可以現有元件代替。如果S參數會一同參與仿真的話則這裡沒做更多說明的部份、即藏在魔鬼裡的細節、包括了調適S參數以期為passive, causal, symmetric and asympotic  以及最終將單端的S參數轉成差分的形式。當所有的模型都就緒之後, 則可到我們的[SPISim_IBIS 程式]端並把IBIS 轉成免費仿真器可支援的格式:

再來到Analog Device的官網免費下載LTSpice仿真器或直接用我們的SPILite:

而後或是編輯原理圖或是用網表把所有不含EQ的通道的部份都建出來,再以時域做階波響應的仿真;若是一位元終將會有N個取樣點的話(這個設定值用戶可自行決定,一般是32 或40…以可整除整個bit-time為主,等一下分析設定裡會用到),那階波從0至1的變化就需以在這個取樣點所代表的時間裡完成, 仿真出來的結果(不論是LTSpice或是NGSpice, SSovler等,均為SPISim_IBIS所支援)會是.raw的波形格式而可為本司免費的SPILite來觀看確認。

 

二、 EQ模型:

如果沒有EQ電路參與其中, 則用戶大可直接在上述的輸入裡更改相關的設定或激勵信號以而直接以傳統的SI分析方式在時域做多位元的仿真,再將結果做後處理及分析。但對SERDES或即將到來的DDR規格而言,EQ多為必要才能把眼圖打開, 而通道分析(一般是以StatEye的理論為基礎)之所以成為必要,即是因為其可在短時間內以卷積的方式把大量的位元和EQ模組做運算而得到可分析的結果, 也就是說, EQ模組(Fig.1裡綠色的TX及橙色的RX部份)也必需支援這種(以端點高阻抗High-Z為前提)的運算方式才能一起運作。現今這種EQ的模型多是以IBIS-AMI, Behavioral或是Spice的格式存在, 其中又以AMI為主流因其能為各不同廠家的通道仿真器所接受。所以分析流程的第二個步驟就是要得到或產生相對應的EQ AMI模型。

若是從無到有的話, 一般的做法是要以C/C++的語法透過合乎AMI API的格式來把動態函式庫開發出來, 所需不是三到六個月就是要更久;但用戶現在就可直接到本司的 [SPISim_AMI程式] 直接產生..完全毋需寫CODE及編譯:

把TX端及RX端的EQ參數填入之後,甚至還可以直接在程式裡用內建的PRBS或用戶可提供的波形(唯一的前提是需為固定均時步uniform time step)來對所欲產的的AMI模型加以驅動:

如果結果波形不合所需, 則回到參數設定處加以更改後再度即時測試, 最後按下”Generate” 按鈕相對應的AMI模可就產生了。這個模型不僅是可在本司的軟體上跑,拿到其它廠家的軟體(如ADS, HyperLynx, HSpice等一樣可以操作且結果都應一致;即便是用戶需要其它作業系統的AMI模型格式(如Windows 32, Linux 64)等,也可透過相同免費的SPILite以同樣的GUI操作而得之。

在本段落之初我們有提到很多EQ的其它形式是諸如behavioral或spice等(不論有無編碼加密), 在那種情況下,其很多含有細節的EQ響應(諸如有ringing等等)就無法透過如之前所示的預設AMI模型加以實現,則可以採用的做法是透proxy(代理人介面)的形式, 這點我們的免費SPILite也有支援且設計理代已揭諸於2017年的IBIS峰會中, 其概念是這代理介面AMI(Proxy AMI)會把用戶現有的spice檔案”包起來”, 而在仿真過程中透過用戶現有且指定的時域仿真器把這spice EQ的響應取出來,最後再以AMI API相容的格式傳會原始呼叫的通道仿真器, 以此形式的AMI建模以下圖簡示:

 

三、 通道分析:

當TX EQ, RX EQ及通道時域響應都在前兩步驟取得之後,接下來就可把它們都放入 [SPISim_Link 程式]做通道的Stat-Eye格式仿真了:

基本上就是把各模型及資料填入相關的tab裡, 再設定仿真運算模式(statistical or bit-by-bit)而後直接按”Simulate”加以計算;要注意的是如果所用EQ為非線性或時變(NLTV)如DFE/CDR之類的話,則仿法無法以statistical方式進行。凡此種種的程式詳細操作在其產品網頁已有視頻展示及說明, 故於此不再贅述。仿真數秒之後, 結果就會直接呈現:

其它資訊如bath tub曲線等也會同時產生:

其實直到這裡才做的說明是通道分析的前兩步驟(取得響應及產出AMI模型)都可直接在這個程式裡進行,用處其中之一是可以直接對所要有的EQ參數就其對通道整體的影響直接做更改後再重新仿真, 而不用回頭先以SPISim_AMI產生模型再以本程式跑之; 比如說用戶可以直接透過簡易快速設定頁來更改TX端的TAB加權值:

更改後再次仿真當就可見其在RX輸出端形成的效應:

其次,對一系統設計工程而言,其也把從所用的IC設計商處得到的AMI模型置入本程式加以仿真;而對於IC供應商而言,如此產出的AMI模型即可馬上提供給下游的系統用戶在其所擁有的通道仿真器裡測試使用;本文討論至今,這一切的軟體都可直接透過所連結的網頁取得並使用, 用戶完全不用花一毛錢甚至是提供諸如EMAIL的個人資訊。

以上..一個經濟又快速有效的通道分析流程或可做為您設計流程上的考量, 也歡迎舊雨新知繼續提供本司意見及建議。

IBIS-AMI: 新DDR規格裡EQ的應用

前言:

在月前DesignCon會期同時舉辦的IBIS峰會上, 後半部的會議時間針對EQ (等化)在即將到來DDR5/DDR6上運用的趨勢及可能機制有很多的討論。過去幾年來, IBIS-AMI及Stat-Eye般的通道/鏈路分析在SERDES界面上獲得了很大的迴響及成效,而DDR則直到最近DDR4 3200之後或未來的新規格上才開始漸漸對EQ的應用有所著墨。現有AMI上的EQ之建模及分析機制是否可直接適用到DDR上仍有很大的討論空間,無疑地,其之終將為DDR所用是不可避免的一個趨勢。

在峰會上, 各EDA廠家甚或是DDR生產廠家都對AMI甚或是VHDL的EQ建模方式有所分享,有興趣的讀者可直接到IBIS官網下載相關的簡報檔做為參考;本司在事後也針對AMI於DDR的應用上做了一些分析及研究,僅以此文分享其中的一些所學及經驗。

SERDES及DDR間的一些主要差異:

SERDES及DDR存在一些以下的幾點差異使得其在運用EQ上會有所不同。

  • Point-to-point vs Multi-Drop:

SERDES通道是點對點式的(point-to-point), 信號從最左端的TX透過通道傳到最右的RX;中間的channel包括了所有的被動元件;其次,這個”點對點”通道的定義是廣義的…其未必只有一小段,不同段的類似連結可透過repeater來串接(cascade)起來, 一個repeater本身即含有一個RX在前及TX在後。Repeater的存在是因為一個SERDES通道可以展延很長, 以USB3來說,從控制晶片連到板邊緣的連接口再走CABLE連到最終的接收端, 所以必需透過repeater來補償或加強可能消失中的信號, 也就是說, 一個SERDES通道的本質是長且有損的(Long and Lossy)。

DDR的連結如上所示則有所不同…其為多端點式的(multi-drop), 一個最左的TX可配上好幾個最右的RX端。比如說一個筆電通常會有至少兩個SODIMM模組…或是直接焊在板上或是透過連接器可外插或升級;桌上型或伺服器級的板子上DIMM就更多了…以雙通道/參通道或是四通道來看成對的DIMM會以2/3/4為一組的模式呈現。一般而言,在主板上的晶片控制器與其它記憶體相距不會太遠以免造成通訊上的遲延,正因如此, 一個DDR的通路通常是是短但具反射性的(Short but Reflective), 也就是說因為阻抗於不同分义點間的變化、再加上各RX端不同的termination impedance, 會使得信號不斷反射並形成很多的ISI干擾。

  • 差分 vs 單端點信號, 時脈信號:

SERDES信號無疑是差分為主的, 正因如此, 其對於如Voltage Droop/Ground Bounce等的電源雜訊具有較高的免疫性, 因為同樣的雜訊會同時出現於P及N端則相減之後便互相抵消; 所以如IBIS V5.1開始所提到的Power-aware IBIS很少會運用到SERDES上因並無此需要。但DDR則不然, DQ信號是以單端點為主(single-ended)所以其對於電源雜訊就必需要有特殊的考量。

其次, SERDES和DDR的時脈機制也不盡相同, SERDES的時脈是透過編碼形(如8b/10b)和資料一起走同樣的線路傳過來的,也就是所謂的embedded clocking。 這也就是為什麼CDR對於SERDES之必要…其必需要將內含的時脈解碼出來;而DDR的機制則是source synchronous, 也就是說時脈是另有專線傳送而不和資料混在一起,文中稍後會看到,這一點的不同也就造成對DFE運作的差異。

  • 運作模式:

SERDES基本上只有一種運作模式, 其信號傳輸的方向是單一的…即由最左的TX到最右的RX為止。DDR則有讀/寫模式的不同, 晶片控制器和不同DDR模組間於不同的模型分別扮演TX及RX的角色, 更有甚者, 因為傳統上DDR很多是透過不同的on die termination (ODT)阻抗值來消弭ISI的影響,眾多DDR端的ODT值對正傳送/接收者和IDLE者而言未必相同, 所以這些不同的排列組合情況就造成了DDR在分析上、尤其是要優化EQ的設定值,有更多的掃描或分析要做。

幾種SERDES上常見的EQ在DDR上的應用:

一直到最近幾年之前, SERDES和DDR的SI分析模式大致上是差不多的, 也是說佈線前的各元件(傳輸線,連接器, 導孔等)模型都兜起來後, 或者是從佈線後轉出來後(extract), 透過如SPICE的時域分析來做仿真, 所謂的worst-case pattern或是事先定義也或是就乾脆跑足夠久的時域仿真以便蓋括大部份可能的位元序列, 之後再把仿真波形做後處理來把和SPEC相關的係數提取計算出來以決定通道的效能如何, 之後再做相對應的設計改變或因應。

但由於SERDES速率的快速提升及對低BER的需求,這種SPICE似的時域仿真已不足所需, 相對應的是以high-Z為前提的EQ模型及STAT-EYE般以convolution 為主的仿真之崛起,這也就是為什麼AMI運用愈來愈廣的主因, 而這類的EQ模型,又將如何被套用到DDR4 3200或更新的規格之上呢?

  • FFE: 其運用不同數量的tap及不同的weight 以對傳送(通常用在TX端)信號做加權以期能消減不同UI所形成ISI的影響。正由於DDR的反射性雜訊(reflective noise)較耗損上更嚴重,所以可見的是這種EQ模組應會有很大的效用。實際的考量是FFE的tap及weight通常得事先決定而不能隨時適應調變(non-adaptive), 所以在運作上有些限制。

下圖所示的是同樣的FFE及weight對單端(SE)及差分信號造成的輸出差異。

  • CTLE: 這類的EQ常用在特別加強某一頻率的訊號或對整體的信號加以放大, 比如說USB3的運作頻率是5G左右, 則一個CTLE便可針對這頻帶特別地加強以弭補通道的牦損。CTLE通常位於RX端, 其另一主要功用也常是提供DC boost以使接收的voltage level能放大而達到SPEC的眼圖需求。實務上來看, 以一如下的data sheet而言:

吾人常可會有一組不同組合的頻響曲線於此CTLE中以提供EQ效應:

而由於DDR如之前所述地非以lossy為主, 可預見的是CTLE在DDR上的運用將不較其於SERDES上普遍且廣泛。

  • DFE: 在SERDES裡, DFE和CDR常是一起出現的, 因為DFE需要CDR以便於適當的時脈信號對進入的信號”slice”以便對其所含的tap做適應調變:

由於DFE本質上也是如FFE般是對ISI做消弭的應用, 所以其應可一樣常適用於DDR上, 而與FFE不同之處是DFE的TAP只能消去post-cursor的部份且其weight常是隨時調變(adaptive)的, 也就是說, 在tap的weight達到約略穩定值之前, 此EQ尚未被鎖定(locked)所以輸出的位元應被忽略 (ignoring bits),其次, 由於DFE需針對隨時進入的信號做計算, 所以其為非LTI的特性造成只能在bit-by-bit的模式裡運作, 而非像FFE可同時用於statistical及bit-by-bit流程。

由於FFE及DFE兩者對ISI上相似的特性, 可能兩者擇一使用即可而不需要同時並存, 我們最近跑了一個案例正證實了此一假設, 如下圖所示, 同時使用FFE及DFE開眼圖的效果並未比單獨使用FFE或DFE來得明顯:

如果說此一結論可廣泛地套用到DDR的設計上的話,則接下來的重點則是如何有效地”掃描”以便得到FFE或DFE所應用的tap數量及其加權值(weight).

現有AMI規格欲套用到DDR上不足之處:

至今為止, 現有IBIS-AMI規格要套用到DDR上若未加改變是無法實現的, 這是因為AMI仍是以SERDES為主而未考慮到上述DDR的差異性, 僅就以下來做實際上的探討:

  • Step response/RF response: 在AMI規格裡的”statistical” flow很明確地提到傳到AMI_INIT的波型為通道的突波響應(impulse response),這種響應實際上只在教科書或理論上存在而不易以SPICE仿真器來實現取得, 所以一般上都是以階波響應(step response)來取代,鏈路仿真器(link simulator)事後再將此波形做一階微分以得到突波響應的形式。這一流程的缺陷是如此獲得的波形假設是上升沿(rising transition)及下降沿(falling transition)為對稱的, 也因此眼圖是上下對稱於 0.0 volt, 這個對稱性的假設於單端點的DDR信號未必存在, 也就是說, 現有規格於statistical流程上對DDR的分析會不準確, 有可能的解決之道是直接以bit-by-bit模式取得通道對PRBS的一連串位元信號的響應,再用外插的方法來得到低BER值。
  • Clocking: IBIS 規格裡的另一假設是時脈信號為embedded…此點一樣不適用於DDR, 如下圖Spec裡的AMI_GetWave函式定對所示:

這個clock_time的參數是只用來傳值回仿真器用的, 一個RX EQ模組可決定是否要將從*wave序列的波型把時脈解碼出來(所以說是以SERDES為前提),若然,則透過這由仿真器預先設好的位址把時脈傳回來。

之前有提到,DDR本身的時脈和資料是分開的,但做為一個DFE, 其又必需要有時脈才能適時地把信號slice以決定位準並調應,那時脈又將從何而得? 個人認為這點的解法不會太難:因為目前clock_time的傳址呼叫只是在回傳時脈時派上用場,所以SPEC只要改定義為:當時脈為外顯時, 仿真器會將其透過這clock_time傳入EQ模組即可, 也就是說,當用在SERDES時, 這參數用來回傳時脈,但用到DDR時,其會被用來輸入值到EQ模組。無疑地,這部份的定義更改只是個人意見而尚未實現於AMI現今的規格裡。

  • Signaling: 最後一點是有關差分/單端信號的假設, AMI現今的規格裡的確是只針對差分信號為主, 如下敍述所示…激勵信號只存於-0.5~0.5伏特之間:

根據定義, 一個LTI EQ模型的轉移函數並不會由於輸入信號放大縮小或位移(scaling and shifting)而有所不同, 所以對於輸入信號是單端或差分處理上應無異處, 但就NLTV的EQ如DFE而言, 其就對位準有特別的需求才能決定位元信號並調應, 就好像NRZ或PAM4的編碼也會對其運作造成不同一樣。理論上,一個link simulator應可就其channel characterization的結果自動測知這一通路的信號模型而自動先加以位移, 再於EQ模組處理之後調回原位準, 如此一來現有的很多NLTV EQ模組都毋需重寫而可直接使用, 另一種可能是於AMI規格裡明白寫出此一level shifting為模型的職責, 則建模人員則可於前及後各加一及的位準位移模組而不用去更動中間以差分為主/現已開發的EQ模型。

本司於之前提到的DDR實驗中亦證實了上述流程的運用,上圖所示是一EDA大廠的鏈路仿真器,圖左可見到的是這channel於characterization的過程中顯示出振幅位於0.95~1.35間, 故為單端點信號, 但當我們的AMI模型放到這仿真器裡去跑時,卻發現所接收到的信號已轉為-0.2~0.2間,由於最後由同仿真器所示的眼圖仍然為單端點信號,故吾人可知這大廠的仿真器已”聰明地”自動為位準做轉換以便能合於現有AMI規格的要求卻又可適用於DDR。唯這一運作模型未必為其它EDA廠所採用, 也就是說AMI模型未必可互換流通, 這也就是什麼現今AMI於DDR的解決方案常鎖定於特定的AMI模型及EDA廠家裡(通常是同一家…綁模形也綁軟體)。

其它可能EQ建模方法:

最後值得一提的是, 在IBIS峰會裡, 有別於AMI的VHDL/Verilog-A建模流程也被提出來分享及探討,就那篇研究而言, 其所運用的傳統時域上分析配合這VHDL的EQ模型可和convolution為主的結果相仿, 主要的賣點是如此一來, 毋需曠日費時地對現有的AMI規格加以更動而可直接以[External Model]的方式及現有對Verilog/VHDLh語法上的支援而加以體現…. 也就是說可直接套用到DDR上, 而由相仿的結果來看, 並沒有需要對DDR跑上幾十萬/百萬個位元而仍可沿用傳通的分析流程。

個人認為這樣的結論只存在於那篇研究上而沒有太多延伸的空間,此一看法是立足於VHDL/Verilog做為建模語言上的一些侷限性,稍舉數點略列於下:

  • 函式庫: 欲以C/C++來做數值分析有許多現有的函式庫可供使用, 比如說GSL及LAPACK就是其中兩種,以其為基本並架構於上的分析流程開發起來即省時又省力, 但Verilog/VHDL相對應的函式庫所在何處? 沒有這些做為基礎,欲開發不同的EQ模組可謂事倍功半;而函式庫存在的一個前提也包括了可攜性及簡易性等等, 正如由C/C++所編出的DLL可把上述的數值函式庫全靜態連結到一起, 但在VHDL/Verilog上則未必如此。
  • 智財保護: C/C++編譯出的形式即為機器碼而不能輕易地被反解譯(de-compile),這也就是為什麼AMI被視為具有IP保護的特性,一般上而言本司的客戶都會要求把模型所用參數黑盒化更遑論是模型本身;峰會上的那篇研究作者亦提到對VHDL/Verilog源碼加密或obfuscate的可能, 唯如此一來, 亦只有特定的仿真器能加以解碼及interpret, 則如此喪失了可攜性的EQ模型又有何益?
  • 速度及彈性: Compile的模型跑得比interpret的快應是大多數認可的事實, 即便論點是未必都需要有Compiled 模型所跑速度的必要,其結論所欲採用的建模語言也未必會落到VHDL/Verilog上, 個人認為Python反到是更好的選擇…其有跨平台性且有眾多現存的數值函式庫可供使用(NumPy, SciPy等), 唯現有的IBIS規格對這類的高階語言的支援仍是付之闕如, 再者一旦允許Python,則Perl, Ruby等眾多不同語言勢必跟進, 如此一來又會喪失了模型可攜性的原則。

以上為個人對EQ於DDR上應用的一些看法及所學供讀者作為參考; 就算是形式上未必以AMI的方式體現(個人所知DDR committee裡有些公司會員未必支持AMI),但就內容上而言應仍不出現有通訊理論上所提到的相關EQ原理, 也就是說,不論最終形式為何, 我們終將於現有EQ/仿真理論基礎上繼續往下一里程標而前進。

IBIS-AMI: 在COM流程中使用IBIS-AMI模型

[這篇貼文系為2018 DesignCon IBIS Summit發表的同標題文章做準備, 相關簡報檔及現場錄音(英文)已連結於此文之末。]

研究動機:

AMI模型的主要部份是二進位檔.dll (dynamic link library, on windows) 或 .so (shared object, on linux)的函式庫, 這些檔案本身是非執行檔而無法直接使用;需要先有另一個”驅動程式”把這些函式庫讀進來才能開始運作;EDA公司如新思的HSpice裡就有這麼一個需要License才能用的AMICheck, 其能對讀進來的AMI模型做上升沿/下降沿及單一位元波的試驅動; 本司也提供了類似功能的SPISimAMI.exe但不需License且還可以用戶自定的波形來驅動。這些小驅動程式在簡易快速地測試所得的AMI模型可否使用上頗有助益、但若要拿來測試模型在完整通路/鏈路分析上的實際運作上則有不足之處。在理想情況下, 一個通路分析的仿真器會把TX及RX端的AMI模型都讀進來而後與通路的response運作並將結果做分析。如果一個AMI模型開發者的IDE (integrated development environment)可以讀入這仿真器並有其源碼可編譯, 則不論是在仿真器中欲讀入AMI模型時, 抑或是AMI模型裡, 都可設入break point並在除錯時暫停於此或步步前進(step through)以能完整地分析模型的實際運作。

即便是開發人員沒有仿真器的源碼, 至少理論上IDE也可”attach”到這仿真器的程序(process)而僅對開發中的模型做除錯。這”attach”的動作需在程式一開始還未讀入AMI模型函式庫時便需執行。現實情況則沒想得那麼簡單, 因為現今的EDA軟體多允許用戶透過圖形使用者界面(GUI)來對AMI的參數、分析模式(statistical or bit-by-bit)、擾動參數等等先做設定, 而在按下”Simulate” 或”Run”的按鈕後仿真的動作才正式展開, 在全部運算完後再把結果傳回給前端的GUI顯示。而在按下開始仿真鈕的那一瞬間, 另一個程序(process)是被”生出來的” (spawn, or forked), 所以事先不知道其ID為何, 故而也就連自己有源碼的AMI模型也無法偵錯。Windows下的visual studio也是直到最近才有”自動attach到spawn process”的功能, Linux上的GDB對此則是付之闕如。再者, 當通路裡有TX及RX端一同做優化(optimize)的動作時, 單單只偵看TX或RX端的AMI模型也是不夠的..無法得知優化是如何進行。凡此種種, 皆造成在AMI模型開發上的挑戰。

有鑑於此, 對於那些非EDA公司而無法得到仿真器源碼的模型開發人員而言, 開源的通路分析平台就是一種可能的方向了;至今為止, PyBert 及COM (channel operating margin)就至少是兩種可能的選擇;就我所見,這些平台大都已有基本的TX/RX演算法模組供使用, 故而把這些以AMI的方式來取代或許就可解決我們之前談到的需求且可縮短模型的開發時程上述兩者之中, pyBert己有初步的AMI架構在內, 則這篇文章就為如何在COM流程裡加入同樣的功能來做探討。

關於COM的背景資訊:

COM (Channel Operating Margin)是已確認通過的IEEE802.3規格, 有興趣的讀者可發現連結於下的COM原主要作者(也是我之前在英特爾的同事)Richard 的簡報:[Channel Operating Margin Tutorial], 若郤知更深的技術資訊及所用到的數學式, 則可直接參閱802.3的規格文件、Richard在2013年DesignCon發表的同標題文章甚或是公佈在802.3官網的COM程式原碼。

要在本貼文內短短的兩三段就把COM說清楚顯然是緣木求魚, 所以以下就僅以AMI模型開發者的角度來看COM對AMI的可能運用。

上圖所示即為COM的參考流程。右邊的上半部份講的是through type的inter-symbol-interference (ISI)影響, 右下半的部份則是遠端或近端串擾(cross-talk)的部份, 這兩者之外, 其它可能的系統雜訊、諸如擾動jitter等等也都有列入考慮; COM本身算的即是這廣義的信號/雜訊比, 信號強度是以單一位元脈波, (Single Bit Response, SBR)的最高點來定義;由於COM也已界定了一同傳訊速度/界面下不同參數的內定值, 所以在使用上很直接, 至於等化EQ的部份則用TX端的FFE、RX端的CTLE及DFE也都包含在內。

對一欲提供AMI模型的SERDES設計者而言, interconnect的S參數是如何而來並不是重點..其有興趣的是TX/RX兩端; COM直接能做的是能對所有FFE 不同TAP比重及CTLE DC增益的部份做窮舉式的掃描而回報最佳值,在每個不同EQ參數組合的試運算過程中, 有一個Figure of merit (FOM)值會被算出來以代表這個組合的最佳化程度, 在最佳EQ組合被決定之後, 完整的如BER般的SBR分析流程才會開始進行終於包括DFE及擾動等把所有的結果都算出來。

在通路分析的流程中, 第一步做的是對interconnect “characterize”的工作以便得到其impulse response, 這裡面其實魔鬼的細節很多:單端量測到的S參數要如何轉成差分S參數、不同部份封裝及breakout的部份要如何和主interconnect串接起來、甚至到串接後的S參數要如何先做conditioning以便其為passive, causal等等終能透過IFFT來得到突波響應, 凡此種種都是分析裡的重要環節且詳細研究起來要耗掉不少精力卻又未必與AMI建模正相關,所幸的是這些在COM裡也都有完整周延的考量及列作計算。

對於EQ的等化部份, 在早期(2014左右)的COM分析FFE的部份僅含有一個pre-tap及post-tap, 最近的更新已將其拓展為兩個pre-tap及三個post-tap, 至於CTLE部份, DC的增益是可以被掃的,除此之外的兩個極點及一個零點則用戶可以自定, 然後透過簡單的公司成CTLE的頻域響應再轉到時域來和突波做計算。也由於是突波被使用, 所以是以LTI為前提。接下來的流程就如IBIS規格裡的AMI流程敍述般一樣:interconnect的突波分別給TX及RX端算完後, 再與UI做計算形成SBR, 最後透過DFE完成對這一特定EQ參數組合的FOM計算, 所有的組合的FOM都計算過後擇最佳者做完整的BER-般分析流程。

如前所提, COM裡的EQ計算是窮舉式的, 所以當打開COM的源碼時, 讀者會發現在上圖的行數附近會有多層的迴圈, 黃色方塊裡可見到DC增益及FFE不同的比重在不同的迴圈裡被列舉(iterate)過去, 故而要把它們以AMI取代, 就是在這附近開始著手。

於COM流程中使用AMI:

由於AMI也需要參數, 所以兩個TX/RX在COM Matlab裡的函式要被取代為對AMI模型的讀取及運用, 除此之外, 在流程的更改上有兩種可能的方向:

  • 線性非時變設計: 由於COM對EQ的計算是以突波為主, 所以如果模型是LTI (即運算不必然在GetWave裡做), 則以AMI_Init的部份直接取代相對應matlab 函式即可。

流程上來說, 第一步是把上述的多層迴圈以單一迴圈來取代, 這單一迴圈可以是對可能的EQ參數組合(未必是窮舉)一一列舉過去, 也可以是有一”stopping criteria”的決定式在內的(近)無窮迴圈, 一旦裡面TX/RX或一起的優化過程收歛之後即break而跳出去; 而由於是用自己的AMI模型,所以TX/RX的結構為何也就不受原COM設計所限, 比如說CTLE的部份可以是很多預先決定好的頻響曲線等等, 至於若TX及RX一起做優化, 則原COM 裡FOM的或可繼續拿來用也或可以自定的cost function來取代。

  • 非線性時變設計: 在這情況下, 一類似PRBS的數位訊號需先被產生, 而後與interconnect 的突波convolve成波形後才能依序傳給TX及RX的AMI_GetWave函式; COM裡的DFE或可用也或可不用但FOM則需由用戶來自行對最後波形計算而得。

其次在實做的細節上, 因為COM原碼係以matlab 寫成, 故需以其相對應的讀取並呼叫外部DLL的程序來運作AMI模型, 簡單地說, 第一步是在Matlab的IDE裡用mex -setup來讓其自行找到系統上安裝的C/C++編譯器並做擇, 除此之外, 與C相容的AMI API 表頭檔(.h)也需事先準備(就把編AMI DLL時的header抓出來用即可), 而後依下列步驟進行AMI的操作:

  • Load AMI model using: load(‘XXXXXX.dll’, ‘ami.h’)
  • check libisloaded(‘XXXXXX’) and list functions in the library using libfunctions(XXXXXX’)
  • Call AMI library function using calllib(‘XXXXXX.dll’, ‘ami_init’, htInput, rowSize…)
  • Finally unloadlibrary(‘XXXXXX’)

最後值得一提的是因為我們只是要針對在開發中的AMI模型做偵錯, 並不是要把COM改成一個通用或給其它人也可以用的通路仿真器, 所以未必需要先建一個.ami檔案的parser. 我們可以事先把其會形成的key-value pairs以字串值存在一變數內再行使用即可, 至於PyBert則有其自己的AMI Parser。

實驗結果:

在此案例中, 我們不想要經過窮舉的方式來得到最佳的FFE比重值, 所以開發了一個可自行優化算出比重的FFE AMI模型並把它套到COM裡運動, 這優化的原理很簡單:當我們知道channel的突波之後, 因為所要recover的信號(bit-sequence)也就是一開始所傳, 所以FFE的比重當為何可以用pseudo-inverse及線性代數的技巧直接解出,這算出的結果是in the sense of Minimum Mean-Squared-Error. 我們想要確認做出來的AMI模型可運作無誤且其和透過原COM裡窮舉法得到的結果差不多。

上圖所示為運算結果, 因為CTLE裡的DC增益有十三個值, 而且FFE的比種有24種不同的可能組合, 所以原COM總共要算三百多次, 每一次的FOM在上圖以紅點表示, 可以約略看出從左到右有十三個block, 每一個block內又冇24個值; 相較之下,我們的AMI TX模型只要算十三次(仍要列舉不同的Gdc), 其結果以藍點表示, 可以看到的是從左到右的每一藍點相對應那十三個紅色區塊大都是在最頂點或更高(高表示FOM好, 值可能更高是因為原COM的掃描有FFE GRID點的限制), 由此結果可認證我們的TX模型可操作無誤。另外可能的實驗案例包括做如PyBert般把TX及RX透過”Hula-Hoop”的優化演算法(2016 DesignCon paper)來同步做優化。

結語:

對於這個研究, 我們要先強調的是動機及需求….COM只是一個可能的方案。也就是對於一個模型開發者而言…不論是模型供應商或是被賦與建模任務的SERDES設計師而言, 能有一個完整的通路分析流程可透過IDE來讀取、偵錯開發中模型或與TX/RX同步偵錯是很有價值的,這一需求無法為簡單的驅動程式(AMI dll driver)所取代且也常不可得於一般商用的通路仿真器。

所幸此一需求已可以現有的開源分析平台所滿足, 其中 COM又因其已通過認證、逐漸廣而被使用、有充足的參考文件及最不可或缺的源碼而值得被列入考慮;其原有的TX/RX EQ部份架構簡單, 但要以我們所有或所開發中的模型來取代其實不難。不論是更改成適合LTI的statistical或是NLTV 的bit-by-bit都有可能, 而原COM裡的很多其它模塊或函式則可沿用;這種混合流程一旦建置完成, 將可大大縮短AMI模型開發的時程並增加模型在實際操作時的可信度, 所以很值得一究。

相關連結:

簡報檔: [請按這] http://www.spisim.com/support/paperetc/20180202_DesignConSummit_SPISim.pdf

現場錄音(英文): [請按這]

IBIS-AMI: 模型中之出雙入對暨無三不成禮

我們”使必信”公司除了銷售累積多年經驗所開發的EDA軟體之外, 也常利用自己的軟體為客戶做建模的服務(畢竟, 要有魚吃除了有好魚竿還是不夠的,有的公司跟本沒人或沒意願來親自釣魚);一般來說, 會找我們做案子的多是IC/IP商,他們的客戶…多是用其IC元件的系統廠…會要求他們提供模型以便設計或分析;雖然這些IC廠的元件多只是TX或RX端, 但常常做到最後會會發現很多情況下, 常至少需要成對的模型才能完成原所建模型之驗證。在這篇貼文, 我們就對這幾種IBIS-AMI中所謂”出雙入對“的使用場景做經驗上分享, 以便有興趣的讀者日後在有建模需要時(未必是找我們),能預先有個心理準備及相對應的考量。

Tx 及 Rx:

上示的原理圖大概是做通道分析中最常見的情況; 在TX及RX端,用戶或許會被要求提供對應的IBIS模型資料,但不可或缺的必是其AMI的模型及參數設定; 就中間的Interconnect而言, 這裡所示的是廣意的方塊”S”, 其大可是Tx封裝, 傳輸線/過孔/連接器, Rx封裝等各自以不同的模型表之;也或可是透過串接的方式全部連起來而成一S參數;這Interconnect在通道分析中的假設是passive且線性非時變(LTI), 其目的是為提供一突波響應(impulse response)以便其它的TX及RX AMI模型可在Statistical 或 Bit-by-bit模式下運作;至於運作的步驟則在IBIS規格的10.2章中有詳細描述。看過其內容的讀者可發現, 之中所有的描述、甚或是如下面KeySight提供的網上資訊教程中也都是一樣地..所有的TX及RX AMI 模型皆是成雙成對地出現而缺一不可:

也就是說, 第一個”成雙成對”的現象最常出現於一般分析時之所需。不同的通道仿真器或許要求不同, 有的即便是不要求用戶提供所缺的TX或RX端AMI模型,其內部也可會有內定(default)的模型供使用;但一般而言, 為了符合IBIS規格中所述的分析流程需求, 兩個模型都要有大概是跑不掉的。從這點來看, 和一般傳統spice仿真對Driver/Receiver端的要求就很不同。在後者的情況下, Driver/Receiver各不論是以傳統的IBIS模型、transistor model, 甚或是Verilog-A或線性化的行為模型都是可以用的。

那如果訂購模型的廠家只有TX或RX端AMI 的需求的話要怎麼辦呢? 通常本司都是如”買一送一”般會再加給一個”Pass-thru”的dummy模型;這個模型可放在TX端或RX端而只是把傳入的資訊再送出而不做任何的更改。當再配合一樣pass-thru的interconnect時, 要為所建/訂購的AMI模型做驗證就很直接了, 因為算出來的結果或BER圖就純是這個模型所造成的結果, 一旦其符合EQ規格所需, 再加上實際情況下的interconnect及其它廠家的TX或RX AMI模型就可做真實的分析了。

(所謂的pass-thru模型不過是在AMI_Init或AMI_GetWave中對那些透過傳址呼叫傳進來的資料不做任何更動而已, 如此相同的資料會被再度送出到下級而完成僅僅是pass-through的目的)

Repeater:

IBIS6.0的規格裡加入了對mid-channel repeater的支援, 其來龍去脈可詳見於BIRD156.3文件;而Repeater的運用常見於諸入PCIe或HDMI等含較長的SERDES通道中;而Repeater實又可再細分為以下兩類:

  • Redriver: 其主要目的及功用是要透過EQ而為在上游通道及擾動所造成的信號損失來做補償, “放大後”的”類比”信號則再度被傳到下游通道。
  • Retimer: 除了像Redriver的功用之外,CDR也包含在其中以便透過這時脈對原激勵做”數位”的重建, 再度傳送到下游的正是這重建後的數位信號。

由於一個repeater先要有接收器且再度傳送, 其AMI之”出雙入對”是顯而易見的:

上示意圖中, repeater裡的前端正是接收器RX用以接收上游的信號, 處理過後的資料則再透過後端的發送器TX以傳到下游, 所以兩者可說是缺一不可的。正由於這兩個AMI模型的加入(只有在RX端的.AMI檔裡才能加入Repeater_Type關鍵字的敍述), 所以要為含有一repeater的通道做分析等於是至少要有四個AMI模型才能開始運作; 實際上因為一個通道允許含有一個以上的repeater, 所以有六個、八個或更多的AMI參與其中也都是可能的。至於含有Repeater的通道分析流程, 在IBIS規格的10.7章裡有更詳細的描述。

若僅就做為單一電氣元件的Repeater而言, 其內部RX/TX間的信號情況為何可能毋需為人所知;但在其它的情況下, 都如為光連結(Optical link)以Repeater模式建模的情況下..諸如下圖所示, 則應用情況便變得複雜得多:

本司最近就做了一個像這樣的案子…我們把這實為optical link(可以很長, 因是透過光纖走線)的兩端光發送/接收模組以Repeater的模式來建模; 第一個碰到的不同點是在對”光”信號的描述中(如上圖所示), TX又再置於前端而光接收器RX在Repeater的後端; 所以這裡就很容易在Review時為光模組廠及其用戶系統廠之間搞混, 其次有下列兩種情況要考量:

  1. 因為Repeater內的TX/RX之間很長, 所以可能會有需要對此信號做量測, 再者, 因為其實為光的發送能量為如mili-watt, 所以與一般認知的差分電氣信號不同。
  2. 此一光模組的系統用戶可能只是在上游通道端、只是在下游通道端、或者兩端皆有來做設計, 所以所提供的模型需能適用於各種情況。

上面中的第一點有點麻煩..主要是因為其”非差分”的信號性使然。截至目前為止, 如果看過IBIS規格中的AMI部份的人都會發現, 所有的描述都是針對差分信號。比如說, 激勵的信號區間是-0.5~0.5間等等;這當然是因為AMI至今大多用在SERDES上有關, 但就建模而言, 其實做差分或單端(single-ended)信號是沒什麼大差別的, 不同的地方在於各仿真器內部是怎麼用AMI模型傳回的信號做運算;而這…多是模型用戶無法窺見得知的。也就是說, 當我們提供一個Repeater時, 取決於仿真器的不同, 可能的運作及能對內部量測的程度也就不同。所幸的是, 由於DDR也要開始採用AMI模型做分析了,所以在可預見的將來,通道仿真器應就會很快地加入能支援單端信號的功能了。

而為因應不同光模組之系統用戶的不同使用場景, 我們也同樣利用了”pass-thru”的AMI模型提供下列不同的組合(全包在同樣一個IBIS檔裡)以做支援:

第一種情況中, 所建的TX/RX端就如實地在AMI裡呈現, 這裡的假設是用戶的通道仿真器可以充分支援TX/RX間的非差分信號,故而這樣的安排可以讓用戶對其間的效應做量測或做不同的安排(比如說不同長度的光纖走線)

第二種情況中,我們假設用戶的通道仿真器只支援差分信號,則我們就把原TX/RX端的AMI模型”合”在一塊而置於Repeater的前端, 至於後端則是無味的pass-thru模型。如此一來, 由於進入光模組及其輸出均為電氣性的差分信號,便可以滿足其所用仿真器所需而能適當運作。

第三種情況中,我們假設系統廠的設計及現有模型是針對下游通道的部份, 所以做法上是把TX/RX端的AMI模型”合”在一塊而設計其成一個TX的模樣, 如此一來, 即便用戶沒有上游部份的設計, 其也可像一般沒Repeater時一樣做單一通道的設計。

第四種情況和第三情況類似, 但用戶專注的部份是上游的部份, 所以所”合”在一起的模型是設置成RX的模樣當RX AMI模型來使用。

最後, 在Repeater的”出雙入對”使用場景中, 有兩點值得一提:

  • 除非DFE/CDR有用到,不然所謂的TX或RX AMI模型在使用及定義上其實是很模糊的, 當然一個Repeater只有在其RX端的.ami檔裡才能有Repeater_type的敍述, 但除此之外, 如FFE及CTLE都可能在TX或RX端出現且其多可被看為filter, 所以沒有什麼特別TX或RX的差別, 但若有JITTER的資訊則情況不同, 因為IBIS裡對TX或RX的jitter都有各自的描述而不能混在一起的。
  • 上面針對以Repeater來為光通訊模組建模的四種不同使用場景, 當然其目的是要為了滿足我們客戶所需以便希望來日能有續單, 但就實做上當然也不希望累死三軍來產生不同組合的AMI模型。就此來看, AMI模型不同模組間的架構設計就很重要了。這點我們在之前的貼文便有詳述。就本司而言, 正因為架構設計的得宜, 所以我們可以透過.ami檔便對所需的不同模型做不同的排列組合而完全不需要重寫C/C++ code或重新編譯。

IBIS-AMI及IBIS:

所謂”無三不成禮”…最後一個要提到的出雙入對便是AMI與其IBIS(傳統模型)之間的配對及運作。當我們因其技術門坎較高而專注於AMI建模之時, 不能忘記了其實其類比前端(analog front-end)也對通道分析的結果有舉足輕重的影響。

一般來遻, 在通道仿真的第一步做的是”link characterization”的分析; 常見的做法是透過spice仿真器在時域把所有的Tx, Rx analog frontend及其間的interconnect都連上, 而後在時域上做0至1的階波響應仿真,所得的pad-to-pad結果再以微分的方法得到突波響應而終為TX/RX端的AMI模型所用。也就是說, 不論是LTI的Statistical的convolution運算、抑或透NLTV的bit-by-bit的連續波型計算,這精確的時域突波或脈波響應都是重要的第一步。

上圖中, 同樣的AMI模型與不同情況下轉出的類比前端IBIS模型結合運作, 通道仿真器算出的眼圖就明顯不同, 由於AMI是從.ibs檔裡連出來的,所以可見IBIS模型裡的VT瞬態及IV靜態資料都足於影響眼圖的大小;所以這之間的”出雙入對”也就不能被忽略。

本司做為一個EDA或顧問公司, 規模上當然是比業界先進如Agilent, Cadence或Mathsoft (matlab)小得多, 這些公司在AMI建模的工具上都各自有獨到的見解及支援且要價比我們貴得多;但就傳統IBIS的建模流程上便甚少或多無著墨;其次, 由於AMI很多還是運用在SERDES通道上, 其中的TX/RX很多都運用到了current mode logic (CML)的設計。如果讀者有看過IBIS cookbook第四章中對差分模型的建模流程且親自走過, 應就知道其中牽涉到的計算及工序又比單端IBIS複雜得多, 則當我們要求全面仿真的精確性時, 就不可獨厚於AMI而忽略了IBIS的重要性並將其建模一同列入考量。一個IBIS不準的AMI模型可說是沒什麼太大用處的。關於差分IBIS的建模, 有興趣的讀者可參考我們之前的貼文及2016 Asian IBIS Summit發表的文章。

IBIS-AMI: 使用Script及Spice model來建模

前言:

這篇博客文章是為了即將於 EPEPS (San Jose, Oct/18/2017), 上海 (Nov/13/2017) 及台北 (Nov/15/2017)所舉行的IBIS Summit所準備,我將於這些會場上發表相同主題的文章。相關資料如簡報檔、案例模型以及會場錄音可下載於下:

動機:

許多年前當我剛開始做SI分析時,採用的標準程序是以spice的仿真器在時域上跑上幾百奈秒,之後再做後處理來得到一些分析的數據。那時一般channel的時脈剛過1Gbps。最近幾年由於高速SERDES的發展使得數Gbps的介面無不在,更不用談動轍50~>100Gb的新802.3網通規格。這麼高時脈的傳訊,若要有所本地談到bit-error-rate (BER)能在多少信心(CI, confidence level)之下有多好的表現(比如說有信心99%以上在1E-12BER以下), 則非得跑上數個1E12bit  不可。要跑這麼多bit,若仍想用以往那種Spice, Nodal-based的方式來跑是不太可能的…要花上太多的時間。所以一定要有新的方法來進行SI分析。在約十多年前2003左右, 如StatEye的分析法便被提了出來, 時至今日,這種用統計方法上對高速電路做的SI分析可以說是快形成了主流, 則吾人便不可不對其上大都會用到的Algorithmic Modeling Interface (即AMI, 是IBIS規格下的一環)模型來做個了解。

AMI建模可說是極具挑戰性的, 因為其牽涉到跨領域的知識及概念。舉例來說對C/C++的編程、上述利用統計法上的仿真、以及一些高速電路建構區塊上的應用等等都得有些大概的了解才能開始進行建模的工作。這也就是為什麼其相較於傳統IBIS的建模下要花上數倍時間或精力的原因。一般而言, 兩個對一般工程師來說最麻煩的地方就是一:要以C/C++的語言來編程, 及二:所編程式需與AMI Spec相容且以.dll/.so的格式來呈現。所以在相關討論中我們常會聽到的兩個問題是: 一:我們可否不用C/C++而用我最喜歡的scripting language來建模? 二:我已有Spice model, 可否直接拿來跑link analysis?

本文將對這兩項常見的需求提出一些理論及實作上的探討及示範。

背景知識:

通道分析(Channel Analysis): 現今的通道分析大多牽涉到TX或/及RX端的等化(EQ)。雖然傳統IBIS模型上也有一點和這有關的設定…比如說driver schedule, 但大致上而言早已過時或不合所需;所以這些EQ電路都是在IBIS模型之外的。之所以有需要加入EQ是因為若無其來對ISI (Self-channel interference) 及XTK (Co-channel interference)來做預加重,後加重等的作用,則其眼圖通當是不會開或很小的。也就是說,沒這些EQ電路,以S參數來代表的通道大都過於Noisy而不符通訊標準的要求。

一般而言, 現今有兩種常用的方式來做通道的分析:

  • Statistical: 若電路是線性非時變、及Linear Time Invariant (LTI),則僅僅用一個脈波(pulse or impulse response)即可得到相當多的資訊以供分析所需;這種方法通常是把含passive channel在內以及LTI Tx/Rx端的單一脈波在不同UI上做切割之後,利用和非main cursor之外的pre-cursor或post-cursor來做疊加(superposition or superimpose)而後得到機率上以及期望值上的統計, 從而能積分再得到Cumulative density function以對想要的BER值做一估計。
  • Bit-by-bit: 若是電路具有時變性或非線性, 即Non-linear Time Invariant (NLTV), 則上述的疊加法則不可行,在這性況下,就得乖乖地用時域上bit-by-bit的方式來”跑”, 但有別於和spice, nodal-like地”跑”, 這新的仿真方式是有假設(High-Z, 稍後會提到)且跑得快得多的。進行上是仿真器會把一連串的數位bit sequence傳給NLTV的電路,由其內部做處理後把輸出傳回給仿真器,而後再由仿真器和是LTI的channel來做convolution. 值得一提的是因為要跑上數百萬個bit, 所以仿真器是可以將其打散成不同的bit chunk, 分別傳給TX/RX跑完後再組起來;組合的時候則要將相臨Chunk之間的aliasing考慮進去。

AMI模型對這兩種新而常用的分析模式都有所支援。

AMI Model: 一個AMI 模型通常包含有下列幾個部份:

  • .ibs file: 在含AMI模型的ibis檔案裡,有一個”Algorithmic Model”的關鍵字區塊,其中指向了所用的.dll/.so, 及.ami檔案的路徑所在;其次,是在何作業系統、位元數及用什麼編譯器所編出此AMI檔的亦包含在同行的資訊裡。
  • .dll/.so file: 這是二進位位元檔, 係以純C語言以合乎AMI API的要求所編譯出來而能為業界的link analysis程式來讀進驅動的。
  • .ami file: 這是一個本文檔, 包含要給上面.dll/.so檔所需的組態資訊;如下圖所示, 此檔包含有兩個主要部份:

  1. Reserved Parameters: 即上面藍色方塊內的部份,資訊是給仿真器讀的…被呼叫的AMI模型看不到的。這裡面包含了必需要有的關鍵字如Resolve_exist 或GetWave_Exists等等,根據這些關鍵字所給值的真偽,仿真器再來對所對應的API程式(位於.dll/.so檔內)在呼叫。
  2. Model Specific: 此即上圖左以紅框包住的部份,這些設定是建模者自己定義而仿真器及/AMI SPEC上管不著的。又雖然字面上在AMI檔裡有一大串,但仿真器會加以讀取,並過濾成相對簡化得多的name-value對(上圖右的部份)後再傳給AMI模型的,也就是說, AMI模型所接到的組態就格式而言其實是已經簡化許多了的。其次、雖然在AMI檔裡的樹狀結構設定(以”(“做分枝開端)可以有很多層,但在其最簡單的格式中,AMI模型收到的資料可以是以根為模型名稱(以上例而言是Rx_Model),而其餘所有的name-value對都是樹狀結構裡”葉”子的末端部份。

AMI-API Functions: 以IBIS V6.1的規格來說, 有最多五個API函式可在AMI模型內被定義執行,如下圖所示:

其中AMI_ResolveAMI_Resolve_Close都是有關組態參數的預/後處理,在一般情況下不太會用得到;而AMI_Close 則像是程式結束前的垃圾處理…也就是把所分配出的記憶體”還”給系統。在現今的作業系統上, 即便是我們在此函式內完全不做任何動作,所佔記憶體最後也會被強制歸還(所以現在的windows很少有BSOD了), 所以這個函式也只是次要的了, 真正重量級而需仔細考量的兩者, 即AMI_Init 及AMI_GetWave,已用紅塊表示:其主要的功是參與上述所提”Statistical”或”Bit-by-bit”分析方式的實際運作。也就是說:若是被建模區塊為LTI, 則其必要執行AMI_Init的執行,AMI_GetWave則可有可無。而若是電路為NLTV, 則其必要有AMI_GetWave的執行, AMI_Init的部份則只做初始化的動作。

其次,再對這兩者的的argument而言,如上圖右中紅框的部份,其第一個陣列是同時做輸入及輸出的, 因為是傳址陣列,所以是passed-by-reference, 也就是程式內任何值的改變終將能被上層的仿真器所取回。所以在AMI模型被呼叫之初,這些陣列內所含有的是之前所述的impulse response 及digital bit sequence, 每一個sampling point之間的時步是sampling_interval,而後AMI 模型依據傳入的其它設定來做計算, 算完之後再把算出來的值放回同樣的陣列裡,而最終為仿真器所取用。

AMI 建模流程:

綜上而言, 一般AMI的建模流程有列數步驟:

  1. 先取得欲建電路的行為方式,其來源則可是從算術式中導出、仿真或LAB信號量測所得。後兩者可能最終以look-up table的方式來呈現並建模而非close loop equations.因為我們即將要將此電路的行為模型以計算機語言來表示,所以一定得先知道其作用為何。
  2. 將上述的電路行為進行編程為AMI-API, 這裡又包含兩個部份: 其一是一定要用plain C語言以合乎AMI-API格式來編程的部份;另一個部份則是實際電路依想要的行為模式來運作的部份…後者可用任何語言或方式來產生, 未必要用C, 也就是說, 實際的電路運作程式其實是可以用非C的語法來編寫的, 只要用C編好的API那部份知道怎麼和這部份的程式溝通即可。
  3. 將第二中C的部份以.dll/.so的方式編譯並測試除錯。以WINDOWS上而言,通常只要改一下編譯器的設定以編出32及64位元即可。但在LINUX上而言, 因有眾多版本的不同(debian, red-hat…)甚或是GNU C對C99, C11等不同格式的支援,就要在很多不同的系統上都測試才能得到一致的結果。

以Script來為AMI建模:

有了上述的背景知識之後,我們來看看如何以Script來為AMI建模:

流程:

上圖為示範流程, 大略上來說, 我們先要有一個很”薄”的AMI模型..其為以C寫成,這一薄層模型不做很多其它的事..諸如任何運算; 它的主要功能只是把從仿真器裡接到的資訊以本文的格式寫成一個檔案,而後把這新寫出檔案的路徑傳給用戶的Script, 呼叫的方式則是透過System Call. 而其它相關要傳給Script的變數也可先透過.AMI檔來設定;用戶的Script被呼叫之後進行必要的運算…看其是得支援LTI的對impulse response的convolution或是對NLTV所傳進的bit-sequence做運算等。結果算好之後又把其寫到另一個本文檔;這新(或相同)的檔案路徑是”薄層AMI”所事先知道的;所以在系統呼叫這Script完之後薄層AMI就會把這檔案內容讀入,再把其內的值填入由傳址呼叫的變數記憶體位址內完成回傳給上層仿真器的程序。其次, 若是在AMI_Init, AMI_GetWave兩函式之間Script有要相互溝通的需要, 在以純C/C++編寫的情況下是有一萬用位址(void *)可在記憶體內直接互傳,但在此以Script進行的流程則需以File based的方式為之。綜上所述、簡而言之, 最上層仿真器和薄層的AMI模型中溝通方法和與其它AMI模型間無異,但薄層AMI和其下的Script中溝通法就都是File based, 透過系統呼叫及這種File based的傳資料,用戶是用什麼Script來編寫對薄層AMI來說就無關緊要而都能達成目的。

範例:

上圖所示為一以MATLAB所寫的範例, 其中左邊為薄層AMI的運作,其間的第二步正是呼叫用戶的Script, 而Script裡的第一步是叫parseInput的函式來讀值,接下來透過Matlab conv()的程序來和FFE做運算, 最後再叫storeOutput的函式把值寫到另一檔案裡, 系統呼叫完之後左邊的AMI模型就走第三步把在檔案裡的值讀進來而最後傳回給上層仿真器。

考量:

雖然以Script建模是可行又方便的,但在打算釋出此法建出模型時則有一些值得考量之處:

  • 效能及可發佈性: 因為所有在薄層AMI及用戶Script之間的傳遞都是透過檔案為之, 所以在效能上就不免會打些折扣, 如果要進行運算之處只是在AMI_Init裡的話這就無所謂…因其只會被仿真器呼叫一次; 其次,取決定所用Script的不同, 可發佈性也就有所差異,比如說若這Script是用.m寫的, 則終端模型用戶的電腦裡就也要有matlab才跑得起來,就算是用compiled matlab的用戶也要先裝matlab compiled runtime (MCR)才能跑,若是以perl的話用戶要先裝perl的解譯器…凡此種種都要先考量, 更何況有些語言在license上可能就有散佈上的限制。
  • 考慮使用Python!: 以此AMI建模目的而言, Python應是一很值得考慮的語言, 其一是它有很豐富的開源數值運算函式庫 (SciPy, NumPy等),更重要的是有一Embedded python的機制使得薄層AMI在和python的函式庫一起編譯之後,所有所需的Python編譯器就可連同所需的函式庫一起打包成單一zip檔案來和AMI模型一起發佈…相較其它語言來說(C除外), 等於只多一個用戶的script及此zip檔, 可說是相當簡潔的。最終端模型用戶完全不需要另外安裝python的解譯器。

以Spice subckt 來為AMI建模:

現在暨然我們知道了”薄層AMI”模型可能的妙用,則很自然的下一步想到的就是:是不是可以連寫碼都不用,直接透過nodal-based spice仿真器來進行AMI的建模或運作? 這答案當然是肯定的!

這裡我們要先回頭談到之前所提及的High-Z assumption. 在一般的nodal-based spice仿真器運作上,每一個時步裡其實都牽涉到好幾個牛頓法的求解(Newton-Raphson Method). 每一牛頓迴圈之初,試探性的每節點電壓就會先被設定,而後在不同節點間的元件依這些電壓來做運算,所需採用或輸出的電流再注入這些所連結點裡; 在牛頓迴圈之末,仿真器就做矩陣運算看KCL/KVL是否已達平衡,依此再決定是否需要另一牛頓迴圈或是可進入下一時步。

對於link analysis而言, 要做Bit-by-bit based 時域分析這麼多牛頓迴圈就行不通, 所以其所採的假設之一就是High-Z, 也就是說輸入及輸出阻抗都很高…使得其輸入的電壓不會被此級電路所需流所影響,而且一旦算好輸出電壓, 接下來同一時步內的運算也就不會將其改變。如此一來, 每個時步就只要運算一次!

在此假設之下,我們若欲以spice model來為AMI建模, 要做的就很像是script方式走的程序, 探討如下:

流程:

首先, 一以C寫好的”薄層AMI”模型仍是需要的,其作用儘限於將從仿真器所傳來的輸入波形以一PWL源的方式表之並寫成一網表(netlist), 這網表內會呼叫用戶所提供的spice model, 至於spice 的參數也若有要覆寫的話也可先籨從.ami檔裡設定; 寫好網表之後, 薄層AMI就呼叫所支援的spice仿真器來對產生的網表仿真, 這程序可透過外部仿真器的直接呼叫或內建的API來為之。仿真完後的波形…可能是如.tr0檔案,則再被薄層AMI所讀入、處理並填回初始傳址呼叫變數的位址裡以完成回傳的程序。

值得一提的是傳給用戶spice model的電壓只是兩節點間的電位差, 其並不含有任何有關GND參考電壓的資訊,所以用戶spice model裡自己很可能需要定義此一電壓的GND 參考值在那裡, 也就是說, 用戶的spice model裡需有接地端。

範例:

上圖所示為一可能範例,其中左邊第一步:”薄層AMI”有一內建網表檔案, 這網表的PWL資訊及所呼叫兩輸入、兩輸出端點的spice model為何則在網表寫出時機動產生; 輸出端的probe也都已設定好了, 所以中間那一步就是透過仿真器來對剛產生的網表做仿真,而最後後再後處理其結果並把值填入回傳給上層link tool.

考量:

如與Script建模流程一樣,這裡也有效能、可散佈性等的考量。效能方面因為每一次的spice model呼叫都會牽涉到nodal simulator matrix的初始化、DC的求解、以及每一sampling point時步的運算, 所以不會跑得太快, 同樣的…若是執行的API函式只是AMI_Init,則這點顧慮可以忽略..因為只會被呼叫一次;就算其運作上是AMI_GetWave而要比一般的AMI model花上十數或數十倍時間來跑,但只要跑一次就可得到精確的數據而能供未來旳建模參考之用。其次就可散佈性而言,若是spice mode裡有用到某個mosfet的模型而需要特別的製程或仿真器, 如HSpice,則終端用戶就也要有HSpice才能跑;就這點而言建模者可考慮開源的仿真器如NgSpice, QUCS等,因其不僅可以執行檔的方式進行運作,同時也提供了shared library的模式, 也就是說此一”薄層AMI”雖要做的動作不多, 但其實可和仿真器的shared library連結一起編譯而自成一仿真器, 在此設定之下,用戶完全不用安裝任何其它的仿真器。

結語:

從上面的討論, 我們知道不論是透過Script或是Spice Model來為AMI建模都是可行的, 事實上,這理所談的都不是紙上談兵而都是已實作出案例;即便是有效能或可散佈性上的考量, 這兩種建模的流程都以縮短建模的design cycle或提供日後可能要以C/C++語法做實際建模時的參考數據。而其中所提及的、不可或缺的”薄層AMI”模型, 因其運作上的要求很簡單,只要一次性的花時間做一個就可被重覆使用;事實上本司的SPISimProxy就連這步驟都為讀者省了因為我們已將其公佈供各位免費使用, 凡此都可供讀者做為日後AMI建模的參考。

IBIS-AMI: 案例研討

IBIS-AMI的建模通常是在IP研發快完成時才執行;也就是說, 一般是先有如用Transistor設計的IP出來, 再開發出AMI模型以便一同釋出。模型之所以需要是因為IP智財商一般不會把設計的細節揭露、但其用戶又需要有相對應的模型才能做分析。在實務上, 我們也會看到倒過來的情形:即先有如behavioral之行為模型或加密過的spice模型,甚或是Lab裡量測出來的數據後,再回頭來想做出AMI模型的案例。這種需求之存在大都是因為原智財商或者沒有AMI模型或者索價甚高。當然也有可能是用戶想先用能不同的參數找出在其設計裡最佳化的組合後再回頭來找是否有相對應的元件或向原智財商要求調校等。

在這篇文章中, 我們將就一最近碰到的、上述情況中的後者來做案例研討,我們的目的是要來示範建模的一般流程並以本司的軟體做為示範。下列為討論的大綱:

  • 相關IP資料
  • 建模標準及需求
  • 建模流程
  • 模型之釋出
  • 其它想法

相關IP資料:

對此案例的設計而言, 我們收到的資料是一以此design IP架在一般SERDES的通道的一網表(netlist), 其設計如下:

在TX及RX端都是含有可調參數的加密過後的HSpice, 當我們挑其中一組參數組合來進行仿真時, 可得到有效(即有意義無誤)的波形如下:

由於這是HSpice的網表, 所以我們可以很自由的去probe不同的節點並視需要去改變仿真的形式(如從瞬態改成小信號AC或是轉移函數等)。

建模標準及需求:

客戶自原IP商所拿到的除了上述網表外, 只有一個簡單的檔案約略說明各方塊及參數的意義和範圍。其中, Tx, Rx封裝模型均是spice sub-circuit. 通道(channel)是一S參數。而Tx/Rx都各含有Typ/Min/Max corners。其次, 在TX端有可調振幅電壓的參數, 有一分為7-Bit及6-Bit各可做為振幅乘數及EQ幅度的參數, 也另有一個boost = on/off旳參數來開關EQ的運作。

針對這些設計參數, 我們的建模目標是要產生相對應的AMI模型以對應不同的參數效能, 也就是模型使用者要能透過AMI本文檔的部份來調整模型效能。其次, 由於本司的軟體係做為建模工具, 所以建模者需要能以不透過寫任何C/C++程式或編譯的形式來達成建模的需求。

建模流程:

以此”逆向工程”來建模的案例來看, 原IP使用者大致是沒有最原始IP的設計的。也就是說, 諸大EDA商(如SystemVue, SimuLink)等的Top-down流程在這種案例上可能沒什麼用武之地; 因為沒有原始設計、自然也就沒有可以自動產生AMI C/C++碼的可能;取而代之的,我們得先依仿真結果來倒推出原IP 的設計架構, 再用試誤法來推出在某組效應下應有的AMI參數。這建模細部可又略分如下:

  • 建立Tx/Rx測試設計(test bench)

原廠所附完整通道(full channel)的網表裡含有建模並不需要的部份, 比如說封裝及通道的S參數就是依設計不同而不同的, 所以建模的第一部就是把實際相關的TX/RX部份萃取出來;其次, AMI模型的一項假設是所有模型的輸出入阻抗都是很高的,所以抓出的設計也就不需含有負載的部份而只與其輸入輸出有關。

就TX而言, 其輸入為PRBS而輸出為簡單的50Ohm

跑出的仿真圖形如下:

當我們把TX直接連到RX的輸入時,跑出來的輸入輸出眼圖如下:

由於眼圖中並未看到如DFE般因force zero而產生特有的突降, 故我們可推測RX端約略是由像是CTLE般的boost filter所組成;依此我們可假定RX test bench如下:

依此跑出的頻響如下:

其次, 由於下一步我們需要依現有的輸入來套到我們假設的AMI模型上, 再將其輸出來和由HSpice跑出的輸出來做比較,所以在此準備階段, 我們由透過本司的VPro來把輸入值轉出成單獨的波型檔案。下面會提到的SPISimAMI.exe就要利用到這個檔案來驅動AMI_Init 或是AMI_GetWave函式。由於HSpice是一variable time-step 仿真器, 要在其輸出probe得波形中得到相同時步間隔(fixed time-step)的資料,我們還得加上此一選項敍述:

  • 定義模型架構

有了測試電路, 下一步就是來倒推出可能有的模型架構並看看我司現有的Spec模型可否支援此一設計。

對於利用HSpice進行的TX的仿真結果, 我們可以看到兩個特點:

  1. 有de-emphasis, 其發生點在peak值之後
  2. 振幅和原輸入並不在同一位準:輸入是0~1, TX輸出是-0.5~0.5, 其次, TX的輸出在上升及下降端都有如RC的充放電效應而非方波, 也就是有應是有AFE(類比前端, Analog Front-End)的存在。

對於de-emphasis的部份, 我們利用本司Spec-AMI的what-if功能來看看在不同的pre/post-cursor情況下輸出的效果為何, 我們依次單獨把某一de-emphasis值調-0.1:

再透過即時的測試驅動來看對PRBS的效應:

可得如下比較波形:

由於我們的實際波形de-emphasis是在峰值之後, 且延遲只有一UI, 故和上圖中間者相合, 也就是確定為1 statge FFE with PostCursor 1 only的存在。

而類比前端部份加在前述FFE之後, 在本司模型中, AFE將對上下端的峰值加以箝制, 所以實際波形的峰值也就是我們模型的high/low rail voltage參數;剩下的就是調整RC參數來得到對應的slew rate了:

經過幾次的調整試誤, 我們可以利用FFE+AFE兩級來和某一參數組合的HSpice結果來對對照, 其結果如下 (藍為HSpice, 紅為AMI結果):

RX部份也是同樣的步驟, 我們利用之前已截取的RX輸入信號來驅動CTLE級,並對部份參數做試誤法的調整,即可以很快地得出一相仿的波形:

下圖中綠為HSpice結果,黃為AMI結果。

也就是說,在這一步驟中,我們針對某一特定參數組合下的HSpice仿真結果, 來逆向推出AMI模型應有的架構, 再透過一些試誤及參數的調整,使得現有的AMI模形得以產出和原仿真近似的結果。結論便是:本司現有的AMI模型,是足以供此建模所用的;而接下來的挑戰, 便是如何快速有效地針對不同的參數組合找出其所對應的AMI參數並產生可用的模型供釋出。

由於RX較為簡化(沒那麼多參數組合)且以下的步驟兩者相似, 故下述的討論單以TX端進行。

  • 制定仿真計劃

在制定計劃並進行大量仿真前, 我們也先針對TX端那有6-bit及7-bit旳參數部份單獨做一維掃描,並不需要掃所有的2^7=128及2^6=64個值, 只要挑一些來看看它們是否相互獨立, 結果如下:

可注意到的是slew rate及峰值部份並未因EQ值的設定而改變, 可見其相互獨立性;再者,這些值的間距也似與所設定的BIT值呈線性類比的關係, 這也就揭示了毋需全面sweep而可透過linear interpolation減少工序的可能。

以此例而言,欲為TX部份的五個參數做全域掃描, 所需進行的仿真可達2^6(de-empasis elvel) * 2^7 (swing level) * 3 (corner) * 2 (boost flag) * 3 (voltage rails) ~ 150000個, 由於線性類比可內插性, 我們加大間距而只掃部份的bit組合,依此想法, 我們透過了SPIPro的MPro制定了產生2403個仿真的計劃:

這2403的case是原150000case的近六十分之一, 其次,我們把TX測試電路參數化, 如下所示:

也就是說, 變數可以用%來含括(如%XVPTX%)而在稍後做取代; 上面表格的第一行(header)即為變數名稱, 其下每一行(row)裡都有該變數在那個行所代表組合裡的值;這裡描述的流程有點像是一般SI裡DOE的步驟; 當我們有一樣板化的TX測試電路及這一表格後,MPro即可據以產生相對應的兩千多個spice檔並以HSpice進行批次仿真, 因為只是驅動電路而無channel的存在, 所以仿真跑得很快…一個小時內所有的兩千多個結果就都出來了。接下來的就是要對每一個結果找出對應的AMI參數。

  • 參數的搜尋及調效

之前我們已證明對某一參數組合,我們可以”兜”出其對應的AMI參數以得到和HSpice相仿的結果, 故在這一步驟中, 所要做的便是對已跑出的2403結果裡的每一個都做同樣的動作。其流程如下:

如果是要用人工進行的話,這2403個CASE當然還是太多…得再減少到成只有50~100左右, 若用程式自動化來跑則無此顧慮。從結果來看, 因為即使不同的CASE其輸入的PRBS波形都一樣, 也就是說在輸出端會出現峰值及EQ變化的時間點也都一樣,所以我們大可透過程序來自動進行。

在我們的做法中,我們首先先把之前證明可行的FFE+AFE架構的AMI檔參數化如下:

其次我們觀查某一組EQ及峰值掃描的結果:

決定的做法是:先讀取HSpice仿真值裡的峰值設定, 由此決定了上面樣板化AMI檔裡的%SWING%變數,其次,再以仿真結果的EQ值為目標, 透過二分搜尋法來變化樣板AMI裡的%FFE_PARAM_POS1%變數, 一旦有新的AMI檔後就把最開始抓下的等步輸入來透過SPISimAMI.exe驅動此AMI檔及.so/.dll, 結果自動和仿真值相比直至其差相近或二分法未收歛為止。

我們的SPIProPro有支援類似的自動化步驟,即使沒有SPIProcPro, 這部份的自動化程序用perl, python或matlab來做都遠比寫C/C++的AMI程式碼來得簡單,其結果, 我們能在約一小時內就把所有的2403個結果處理完並找到對應的AMI參數值。

這是SPIProcPro的部份設定:

對於2403個每個CASE, 其後處理之後每個都會有個別的、內含有找出AMI參數的csv及log檔產生,而這些檔案也被程式自動組合成一個含有2403行的CSV檔,最後用MPro把原始輸入參數和此計結果檔左右相結合, 所得到的就是一個不同情況下的輸入及找出AMI對應參數的對照表。

模型之釋出:

上一步驟的CSV檔案結果如下所示:

其中右邊藍框內的參數是本司SPISim AMI模型所需的參數,這些欄位的第一行, 即表頭部份,有著和AMI參數完全相同的名稱; 而之下的每一行就是不同設計參數下由之前步所驟所找出的相對應的AMI參數。

記得在之前定義架構完成後所產生的AMI檔有著我們內建模型所特定的參數如下:

我們所希望釋出的模型能有和原IP同樣的設計參數, 這些參數為上面CSV表格中紅框的部份, 其也為在產生TX兩千多個不同測試檔案中所用到的變數, 而最左邊黑框的部份則是(可有可無)的索引預設(preset)。

我們SPISim內建模型有一個特點: 其可透過此種預設表格的方式來為所需的參數提供資料, 且這設定可很簡單地透過我們AMI的GUI完成:

上圖中用的是PCIe的例子,其TX有十一個預設值定義於spec裡, 所以利用這麼一個表格,用戶可只用PRESET的AMI參數便來為其它的, 模型所必需要有的FEE_PARAM_PRE, FFE_PARAM_POS0等變數來提供數值。

而在這個案例裡,我們要用的不是這Preset值,而是各原始IP的設計參數如下所示:

則做法是把Preset值設為 -1, 而後提供如原始IP等相對應的欄位名(上面AMI檔內紅框所示), 在運作啟始階段,我們的內建模型會把這些變數來在CSV表格內去找出過濾出來的行(row), 然後再把那行裡相對應的內建 AMI模型參數套用進去, 如果這些原IP參數裡有至多兩個數值型(而非字串型)的變數沒有找到, 則模型會把最接近的兩行找出來來做線性內插, 而再把內插出來的值傳給模型使用。

也就是說,我們可利用本司模型裡數客戶自訂參數來找出對應內建AMI參數的功能, 以及至多可做二維線性內插的功能來為產出簡單明瞭的模型供釋出。

由這些步驟所產生的最終結果是一個.ami檔, 一個.csv 檔(內含所有對應表, 此.csv檔可為明文或經SPIPro編碼加密), 及一組早就編譯好的.dll/.so檔案。在上述的過程中,完全毋需寫任何C/C++碼或在不同作業系統上編譯來產生AMI二進位檔;即便是.tr0後處理的階段,用人工做至多五十至一百個參數的搜尋、抑或是用簡單perl/python/matlab來進行和SPIProcPro相似的運作,都仍遠比從頭寫AMI模型及編譯來得簡單。

其它想法:

在此案例中,我們透過的是如”逆向工程”般的方式來產生一對照表(.csv)以便為定義好的AMI架構來供值。由於廠家提供建模用的IP是Spice檔, 另一種可能是透過我們SSolver或NGSpiced來直接對所供的Spice檔來仿真(這仿真引擎是內建在AMI模型裡的)並為AMI_Init或AMI_GetWave提供輸出波形。這樣就不用透過各種掃描(sweep)而可提供更直接的對應。但要能如此做的前提是:原Spice檔未經加密(加密過的網表只有HSpice能讀), 未牽涉到製程檔案(要不然大概仍是非HSpice不行)且其網表的語法能輕易地轉換成SSolver/NGSpice所支援的格式。其次, 在參數搜尋方面, 因為我們只有一個EQ參數需要找值,所以用二分搜尋法就可以很快地收斂。但若是有兩個或二維以上的變量需要搜尋…比如說同時有pre-boost及de-emphasis參數等, 則若二維曲面每一點找值不可行(要仿真的case過多),便要考慮使用如gradient descent等的差分/最小能量似的優化algorithm。