Monthly Archives: December 2018

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

Posted on by
Reply

[這篇貼文系為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建模流程

Posted on by
Reply

在上篇的貼文中, 我談到”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)的編寫, 所以非得先廢上一番功夫才成。就本司軟體而言, 這些功能都已內建於SPIMPro及SPIVPro裡, 所以可在一個環境下不寫腳本就成批次完成。此處用途廣泛的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建模流程

Posted on by
1

對於新上手的建模工程師而言, “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更新裡也加入了此一功能以使我們的軟體用戶也能同享此快速建模法所帶來的好處。