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: 新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。

IBIS-AMI: 黑箱密技

在IBIS-AMI的建模領域中, 有一些”黑箱密技”值得一究;它們之所以存在,是為了使整個AMI建模的流程不但更順暢且富有彈性而不僵化。在這篇貼文中, 我們會分享並探討最近本司在建立AMI功能中的一些經驗及技巧以供讀者參考。在文章末也會來看看其它公司的AMI模型有些什麼不同的樣式。

黑箱密技所在何處?

相較於系統分析中所會用到的其它元件模型:諸如傳輸線的RLGC Tabular Model、連接器或封裝的S參數、甚或是傳統的IBIS模型而言,AMI模型本身就是個黑箱(Black Box);其為系統及位元相關、由C/C++編譯而成的二進位檔案;在Window裡, 檔名為.dll (dynamic linked library), 而在Unix-like作業系統中為.so (shared object);這檔案裡都是機器碼;另一相關的檔案、即ami檔、雖是人眼可讀的本文檔,但其含有專位這些.dll/.so檔模型所用的資料,故非可以隨意更改或變動。

對於一個AMI模型開發者而言,即便是他/她對C/C++及.dll/.so編程編譯的過程知之甚詳, 這整個流程走起來也是蠻煩瑣且易錯的;舉例來說:即便在Windows上,相同的原碼也需分別以x64及x86 (Win32)的組態來編譯並測試;在Linux上更麻煩:因為Linux 有很多的Distro (Debian-based like Ubuntu, Linux Min, Redhat based etc)且IT所裝起來的環境…至少在所含程式庫上也不盡相同;好比說”boost” 及”gsl”是吾人在工程及科學計算編程上很常用的開源程式庫,但在以production為導向上的linux機器便未必有安裝,而Linux的主要訴求之一是很多的程式庫都放在/usr/lib或/usr/local/lib裡分享, 所以未安裝此程式庫的結果便是原來在開發者機上跑起來沒問題的模型放到這些其它機器上便Load不起來;常用的解決方案是把所有的機碼都以static link的方式放到.so檔裡,再把symbol給strip掉以減小程式大小,最後再把結果放到不同的(虛擬與否)機上做測試以確保相容性;正由於這些麻煩的過程, 在以往AMI建模的市場或領域僅被少數公司所把持或寡佔, 且在專案的計價上動則要美金數千或數萬元。

在之前的貼文裡,我們提到了將AMI檔和仿真器(circuit simulator)相對比的觀念;就仿真器而言,為某種電路所特別打造的(如cache, memory等高重覆性設計的電路)仿真器固然跑起來較快且有其存在價值,但對大多數的電路設計而言, 用MNA (modified nodal analysis)所建成的一般化的(generalized)仿真器如Spice/HSpice便足夠所需;這些仿真器雖為二位元檔,但內建有如R/L/C/I/V等的基本電路元件;就算是複雜的系統元件如傳輸線或S參數等,也可由外部讀入模型檔而不需要為不同的電路重編一仿真器;也是說:仿真器即便是與OS/系統有關也多半是固定的..一年最多更新幾次,就好像HSpice只有一個…不管你的電路為何;而可變動的部份是用Netlist網表的形式來傳給仿真器,這就好像.ami檔是以本文描述的設定可用來傳給實在不需太常被編譯的.dll/.so檔一樣;也就像有Encrypted HSpice檔一樣;當吾人有敏感的資訊需要傳遞又不想被人看破時,便可以加密的形式為之。

從以上的觀點來看,其實AMI建模的”黑箱”不僅可指所編出的.dll/.so檔,也一樣可適用於所需的.ami檔案, 以下就稍做探討:

.dll/.so檔裡的黑箱密技:

在IBIS-AMI API的規格中, 雖然定義了五個API函式;但實際上最重要的是如上所示的AMI_Init, AMI_GetWave兩者;從它們的傳遞參數中,我們可以了解兩個指標(pointer)即AMI_Init裡的impulse_matrix及AMI_GetWave裡的wave同時負有輸入及輸出的責任;也就是說, channel simulator把資料放在這些指標裡傳入吾人所定義的函式中,計算完成後我們的函式需再把結果放到這些指標所指的位置以傳回給上層;這一個流程以電路上來看的話大概像是下圖:

上圖中可看出一個AMI仿真中所沒明說的假設是:下一級的輸入阻抗對AMI來說可說是無限大(好像Rx AMI模型不會因為接上去後就把傳進來的impulse_matrix 或 wave值改掉了,要不然就應有iterative的程序直到真值解出為止), 同理也可套用到Tx的輸出級一樣;也就是說,我們可以想像是有兩個增益為1的電壓控制電壓源一樣, 分別在輸入及輸出端替我們的AMI黑箱和其它電路隔離開來;而我們建模者要做的, 就是專心把這輸入及輸出的關係,透過所編程出的AMI .dll/.so檔來表示出來。

正因為這黑箱是.dll/so檔, 所以裡面如何編寫除了老闆外其它人都看不到, 所以一個沒什管的或求快不求好的建模者便很容易寫出”spaghetti” C/C++碼把什麼都混在一起而降低這黑箱的再次使用性;一個比較好的設計應是看起來如下模組化的:

如果我們同時以Spice .subckt的觀點來看, 它大概是長這樣:

也就是說, 不同的CTLE, DFE, CDR等都已定義在其它的模塊中以供重覆使用;上述兩圖明顯地已將各模塊所需的參數略過不提,值得再說明的是即便是如上看起來很有機制的設計,也內含了幾個假設:1: 這個黑箱只有三個模組(即CTLE, DFE及CDR), 若是我要另加一AGC於前或DSP Filter於其中呢,難道又要重新編程編譯? 2:所有的模組是以cascade方式連成(這假設對SERDES設計來說大致上可成立),且每個模組都是一進一出(未必皆然, 有的有回控電路輸入), 所以看似精心設計過的AMI模可其實都還有改進的空間…因為這兩個假設都未必皆然且和設計有關,所以如果說我們的目的是要把.dll/.so檔的重覆使用性上做到最高, 這些假設都不應hard code到模型裡而應以外在.ami檔案的方在來進行組態(configure).

還有就是在建模過程中,一般的程序是先將實際電路或模組的行為模式(behavior)萃取出來到一個可以用C/C++語言來描述的地步才開始編程;比如說如果我們知道這是個濾波器,則先要拿到其頻率響應, 而後便可用傅利葉反轉到時域再和輸入信號做convolution;但有些時候一些模組的行為並不那麼能精確的描述, 或是其close-form的等式並不存在, 則是否我們可以把如.subckt裡的電路定義放到AMI .dll/.so裡呢, 這當然是可能的;比如說我們SPISim有內建的仿真器及IBIS, S-Parameter 等元件模型,自然就可以以一mini circuit simulator的樣式來做這一級的AMI模型;實務上,這種模組可用於Tx的輸出級或Rx的輸入端來模擬封裝模型的S-參數;而如我們所樣在其它貼文提到的SPISimProxy一樣, 這AMI的某一級其實可以外叫其它的程式或Script來達到特製化的目的。

從上面可以看到, 其實即便是對將會被編譯成二進碼的.dll/.so而言,其C/C++的設計也有很多密技可供使用;之所以如此做的目的,是因為所需編成.dll/.so的步驟煩瑣易錯, 所以我們相信更實用的方式應是盡量把富有完整功能的各模組模型都盡量編到這.dll/.so裡, 再透過外部的.ami來做呼叫使用;就好像把可手寫易編的本文netlist傳給不常變動的spice仿真器一樣。

.ami檔裡的黑箱密技:

一個.ami檔案裡同時含有給channel simulator及(更重要的..)真實.dll/.so模型裡運作所需要的資訊, 如下所示:

圖中, 綠色方塊裡的”Reserved_parameters”的部份是給channel simulator所用, 其所必需含的保留字(reserved keyword)都在IBIS Spec規格裡有詳細定義及規範,如此所有支援IBIS AMI規格的仿真器才能讀入這些設定且加以使用。在實務上, 因為之前所提及的市場寡佔, 我們的確看到過廠家自訂的保留字置於此處以支援其本身的仿真器。

在另一方面,上圖中紅色方塊裡的”Model_Specific”部份則是只跟.dll/.so模型有關而與channel simulator無涉的;也就是說, 吾人建模者有很大的自由度可定義其名稱、數目及格式;也就是在這點自由度上, 我們可以發揮創造力來加入黑箱密技。

在.ami檔裡做文章的觀念我們在去年底的貼文裡有約略提及;很令人高興的意外是:在今年初的DesignCon的一篇文章裡,我們看到了IBM/GlobalFoundaries也做出了類似的運用, 所以多少可以說是英雄所見略同 :-), 此一文章的連結如下:

The AMI_Resolve: A Case Study for 56G PAM4 (http://ibis.org/summits/feb17/)

簡單地說, 我們可以把許多資訊放在.ami裡以傳給實際運作的.dll/so檔案,不同的加密技巧也可同時運用以保護相關的IP 或設計;就我們SPISim而言,我們之所以能把已開發的不同AMI模型以公開免費的方式釋出供大家無償使用正是因為所有產出的AMI模型都需要一個自動產生的license資訊,這一小段機碼雖是本文格式,但必需存在且也和機器上的日期甚至是所含的資料有所連結,所以一旦有所更動或破壞,就會造成.dll/.so檔運作的失敗而產生鎖碼、鎖失效日期或鎖值的功能。

上面所提到IBM的文章所展示的是透過.ami檔來和API裡AMI_Resolve函式來做呼叫的概念,其所欲解析(resolve)的網表或等式也是以加密後的格式傳送,回到.ami所支援的model_specific變數來看, 雖然其也同時定義了諸如table 等的樣式,但在實際運作上不是像如excel一樣地一目瞭然而有實際上有更改操作上的限制; 相較之下, 我們更喜歡(且於SPIPro裡採用的)是直外外連一個檔案:

這外連的檔案可以是如含不同pre-cursor/post-cursor設定的預設值、不同CTLE的頻率響應或其至是如S-參數或網表(netlist)等供之前所提mini-simulator 模組所用; 格式上也可以加密與否的方式進行;由這些討論來看, 這.ami檔雖是本文格式,但實也可富含密技以支援所叫的.dll/.so以達到減少重新編程或編譯的目的。

AMI模型實例研究:

上面所提的黑箱密技拿到實際運用上來檢視又是如何?以下我們看一下同由Altera所產生不同AMI模型的兩個案例:

在這個例子裡, 它們不儘發佈了AMI模型,也同時提供了一個小GUI程式來檢測所用的參數組合是否有效;也就是說, 儘管只有一個.ami檔案,但裡面很多組合的值都有而用戶得自行參閱或事先檢查組合是否有效。

在Altera另一發佈的模型裡,我們看到不同的組態方式,這裡有許多預設的.ami檔案, 猜想用戶仍需先對所要用的設定查索引再來使用正確的.ami檔。

在我們SPISim的執行方式上, 我們允許用戶(建模者或使用者)以一csv的格式來建立可一覽無遺的檔案,每個欄位的表頭都是要提供給內建模組的參數名程,而每一行就代表一個可能的參數組何;對於使用者而言, 他/她只要變換所用的行數ID即可而不用一個一個去改變參數的值或corner.

透過這種方式, 所要用到的表格可以加密與否的方式為之, 建模者可以提供同一份.dll/.so及同一份的.csv/.ens (encrypted csv)給不同的客戶,同時再針對不同客戶的不同需求給不同的row ID可能值即可; 就一.ami檔來看, 其內容是十分簡潔且只要一份即可… 不像要上面第二個Altera範例般要許多的.ami檔案。

而我們所提供的解決方案, 實際上可說是先透過一GUI來做組態上的設定, 而後由GUI所屬的程式產生出含黑箱密技的.ami檔案, 而事先已在不同作業系統及位元編好且測試的黑箱.dll/.so也同時在一秒不到的時間內同時產生; 最後模型使用者只要更動很少的設定就可對不同組態的參數做掃描(sweep)或分析, 這可說是一個極為方便有效的流程。

AMI:測試後再使用

一個有點相關、但相當值得一提的是對所得到(或產出)的AMI模型的測試流程: 不同於以往的一個作業系統只有一個版本, IBIS最近最新版的Golden Checker已是特定於不同系統及位元;之所以如此做, 正是因為AMI的日漸流行且其相較於傳統IBIS的複雜性, 所以必需在不同系統上對.ibs檔做偵測。以下是我們覺得不論是建模者或使用者對一個AMI模型均應有的測試步驟:

  1. 第一步是用golden checker來測試模型相容度, 只要一個.ibs檔內含有Algorithmic部份,其所指向的.ami及.dll檔都會同時一併做測試, 唯這些測試儘止於API函式的存在與否及系統相容性, 而非功能上的運作測試。
  2. 第二步則是用Model Driver來驅動所給的.ami 及.dll/.so;就好比通過golden checker的ibis模型仍需先放到test load來看波形合理與否一樣(而非直接丟到system simulator做channel simulation), 這一步驟可以偵測出許多運作上的問題及對設定參數的了解情形; 在HSpice及Ansys的程式裡,這驅動程式都叫做amicheck.exe且也都要相對應的license才能運作,我們SPISim提供了免費有效且功能更強的程式, SPISimAMI.exe,以供此用。
  3. 最後一步才是把.ibis, .ami及.dll/.so檔案到諸如HSpice, Cadence’s SystemSI 或是Mentor HyperLynx等的channel simulator裡運作, 這些工具程式能對如眼圖, BER及Bath tub Plot等的數據加以計算及產出,可以期待的是我們的SPICPro在今年(2017)稍後也會加如類似的功能。

IBIS-AMi: 經濟有效的建模流程

前言:

IBIS-AMI的建模流程至今為止常被認為具有經濟及技術上的高門坎;一AMI建模人員固然需先對有關AMI的相關流程甚或是LINK分析的知識有所了解, 但據此便要求其也能透過C/C++語法將模型在不同作業系統上編譯成.DLL/.SO的格式、甚或是透過不同的第三方分析(常是所費不貲)也都要能得到相同一致的結果則不免要求過多…或至少也會拖延設計流程不少的時間。有鑑於此,一些公司均有提供由上而下的自動化方案;唯這類”按滑鼠即成”的流程多有一些共通的問題:比如說原始的SERDES架構必需要在相關的IDE環境裡先設計完成, 如此才能透過內建的源碼產生器轉換出相對應的AMI檔;其次,通常昂貴的這類軟體也先需構置且熟悉其使用;再者對於所產出的AMI模型長遠來說的花費(以維謢性、建伸性或是對特定流程所綁定的使用以致無法輕易地改選更佳的方案等)再再都是隱藏未見的開銷。且就算是使用這些特定軟體,其在不同系統上需要另行編譯的步驟仍是無法省略跳過。

我們最近發佈了一些供AMI建模使用的免費工具、也於近日前在相關研討會上發表了有關的一些文章;再加上在本文最後也會提及的開源LINK 分析軟體,我們此時已有足夠的方案來建構一個有別於上述所提及的AMI建模流程。在此所提提議的新流程不僅經濟(不需要事先購買任何軟體)又有效(SERDES設計人員或建模工程師可專注於欲建的模型而非其它編程上的步驟)。

[註:在以下文章內我們交替地用Link Tool及仿真器來代表一將AMI的.dll/.so模型格式加載並呼叫其內建以C語言寫成的API函式]

概念:

用Spice-like仿真器的人都了解我們通常只需要一個在某作業系統上的程式…即仿真器本身;對於不同的設計其網表(netlist)均會以本文的格式來輸入給仿真器進行運算;也就是說我們通常並不需要針對不同的設計就要有不同的仿真器。之所以如此是因為常用的Modified Nodal Analysis (MNA)為基礎的仿真器是根據一些基本的電路原理來設計:如KCL, KVL, 及解電路方程所用的線性代數等等;這些都是和各個設計無關而可通用的。

對於AMI建模來說,現階段的方案常是不同的SERDES設計就有不同的二進位模型需被產出;則我們是否也能由所知的AMI流程中萃取出與個別設計無關的成份以便將因此形成的建模阻礙減到最低呢?當然凡事都有利弊…用C碼有效地寫成做出的模型大概跑得最快;那退而求其次…在建構原始模型(prototype)時若能讓相關人員能最專注在最重要的部份(應不是寫C碼或編DLL吧..),將來若有機會再把這已迅速開發完成的原始模型轉成有效的C模型也將會是獲益良多吧。

我們觀察現階段的AMI應用多在SERDES的設計領域上;這些多是點對點設計的(point-to-point)而非有如DDR般地multi-drop/fly-by;也就是說, SERDES的設計可以看做是一級一級地接續處理的。若我們再仔細看看IBIS-AMI API格式裡所定義的函式原形就更可看出此一特性:

在上圖中,AMI_Init及AMI_GetWave是AMI流程(不管是建模或分析)中最重要的兩個步驟;可以看到的是不同的參數由仿真器透過此一定義的界面格式來傳入AMI的.dll/.so模型裡。由於這些參數..尤其是impulse_matrix及wave等等是傳址輸入的(passed by reference), 所以它們的值需被AMI模型取用、運算後再填回原來的記憶體位址裡來完成此一步驟的運算。而當初呼叫這些函式的仿真器也就接著由原址把值取回繼續接下的流程。

不同的AMI模型由仿真器接獲不同的輸入而在運算後把值傳回;這一流程是一級一級下去的…由上圖所示;由此可見:如果我們能1)把仿真器或/Link Tool來和所叫的AMI模型切開來;2)把AMI模型和實際做運算的部份再切開來, 則這一切的流程很多的步驟都可讓我們以最有效率的方式進行。

AMI模型的解構:

根據上述的了解,首先我們可以看資料長得怎樣且是怎麼由仿真器傳給AMI模型的;由於IBIS-AMI流程不同的運作方式..一種是LTI模型以便做Statistical Analysis, 另一種是針對NLTV的模型所需進行的Bit-By-Bit Analysis, 吾人可以想見傳入值對前者而言是channel的impulse response,對後者而言是bit sequence;如果我們能把TX的效應關掉的話(by pass), 則在RX模型端也會看到諸如Channel的單純響應。

以AMI_Init步驟為例,則上述的解構可用我們發佈的SPISimProxy來完成;上圖中是SPISimProxy與現有AMI模型間的運作關係;當仿真器呼叫 proxy時,它會把所傳入的值產出到一個文件,而後也把同值傳給原來的AMI模型做運算;當運算完值由AMI模型傳回來後,SPISimProxy會先把這些值再次寫入文件檔中才傳回上層的仿真器。也就是說, 透SPISimProxy這個中間人,在仿真器及AMI .dll/.so模型間的資料交換便無所遁形而可一覽無遺了。在上圖中,右方上下兩個藍色的方塊代表的是產出的文件檔。中間的紫色方塊代表的是原AMI模形的AMI_Init C函式;左方的灰格則是SPISimProxy. 在此雖是以AMI_Init為例, 其它如AMI_GetWave的呼叫也可相同地被解構。

當我們了解了這些由原AMI模型所進行的輸入、輸出處理後,接下來就是以最熟悉的語言所寫出的同樣功能程式來將其取代;不同的是現在我們只需要對再平常不過本文檔來進行操作, 步驟如下:

  1. SPISimProxy將仿真器所傳入的值依序寫入一個文件檔
  2. 用戶的matlab, python, perl等script將此文件檔讀入並作運算
  3. 運算完後script再將結果依類似的格式寫到另一文件檔
  4. SPISimProxy把這新檔讀入,轉化或填入原傳來的記憶體位址空間以傳回給最上層的仿真器

由於SPISimProxy提供了多達十五個可針對不同階段客製設定的參數, 所以上述的每一個步驟都可以依不同設計的不同需要來進行;再加上SPISimProxy已事先在不同的作業系統上都編譯完成,所以寫Script的建模工程師等於只要改一些設定而不需要做任何C/C++的編程就可完成AMI的流程。

之前已提及..至今所述的例子雖是以AMI_Init為主, 其它的AMI API函式呼叫也可一體適用。比如說如果模型師不想在流程走完後在硬碟上留下這麼多的中間文件檔,則其可在AMI_Close裡來對這些用完的檔案進行清除。其次, 在API函式傳址的參數裡也有一些是必需在不同(AMI_Init, AMI_GetWave)呼叫中都要用到的…如model pointer (void*), 可行的解決方案是用戶可把所有相關資料以檔案格式來儲存並在稍後讀回; 如此一來, 即便是不同Scripting語言之間也可透過此一相同的SPISimProxy機制來完成AMI模型的開發。

AMI模型與仿真器間的解構:

在前述流程裡,我們看似是仍需要一仿真器或Link Tool以對SPISimProxy加載最終能對其下的用戶Script加以呼叫;實則不然…在我們所提供也是免費的SPISimAMI.exe裡便用同樣的功能可做運用。SPISimAMI.exe也同樣已事先在不同作業系統上編譯完成而可直接使用。對於LTI的模型開發而言, SPISimAMI具有內建的pulse response可加以驅動加載了的模型,且其響應也會以.csv, .raw的格式直接輸出(可用如我們免費的SPILite在內的程式來查驗), 即便是對NLTV模型而言, 吾人也可事先用如我們所提供的SSolver或NGSpice, Berkeley Spice等的軟體產生bit sequence waveform,而後再透過SPISimAMI.exe把這客製的波形導入SPISimProxy最終傳到客戶的script。值得一提的是, SPISimAMI可加載不限於SPISimProxy的AMI API相容格式的模型, 也就是說, 透過這兩個免費工具, 不論是現有仿真器、現有.dll/.so模型, SPISimAMI或是SPISimProxy間的所有運作都已擹在陽光下可供檢視並由用戶的script加以運用。

在SPISimProxy產品網頁的示範視頻裡我們便以用matlab所寫的AMI_Init為例來為上述過程做了示範。

放在Link Tool裡做BER等的測試:

透過上述流程所完成的AMI原始模型(prototype), 接下來可連同SPISimProxy一起置如pyBert 的開源軟體中加以做更近一步的測試, 因其可對AMI模型做加載並運作, 所以透過SPISimProxy, 用戶的script所寫成的algorithmic block就可以做最有效的測試及除錯。

截至目前為止, 我們所提到的流程中所用的工具都是免費或開源且可直接運用的, 再者, AMI模型開發人員所最習慣用的語言也未因此而受限;最後, 這中間的操作都不是透過繁複的GUI界面.. 也就是說, 不僅不需要有第三方軟體、License的建置考量, 而這一流程又是直接、簡單且可迅速重覆進行的,這也就是所提議經濟又有效的AMI建模流程。

模型的優化及發佈:

最終建構出來的模型要如何發佈呢? 我們提供了幾種可能供參考:

  • 模型發佈商可將寫好的Script加以編碼或加密而後直接發佈; 此舉的優點是不僅IP不外傳, 且模型的精確性也可直接獲得確認及保障;其缺點則有幾點:由於SPISimProxy與Script間的資料交換是透過檔案進行,所以效率未達最佳化。其次,接獲模型要使用的人可能也需要安裝有同的解譯器以便能使用python, perl, matlab 等寫成的程式; 最後, 用戶均需造訪本司網頁以下載使用SPISimProxy因其雖可無償使用,但未經授權的發佈是絕對禁止的。
  • 我們可和您合作提供客製的API以便直接和您的程式進行資料交換而非透過實體檔案。此舉的優點是設計IP及準確性仍可獲得保障, 我們甚至也可在SPISimProxy上加上貴司的公司或更進一步的客製, 缺點是用戶需先安裝相關解譯器的需求並未因此而消失。
  • 我們可將您的AMI模型透過C/C++語言直接轉成AMI API模型的格式, 如此一來, 您只有一個模型檔需要發佈且其運作效率及速度可達最佳化。

綜上所述, 我們在本文中所建議的建模流程也可在您公司內部所採用…未必要用我們已開發完成的工具。我們希望透過這一連串的解構,之前對AMI所有…暨高深又花錢的印象可漸漸解除;取而代之的是SERDES或是模型開發人員可將其大部份的精力專注在與其本職相關的活動中…即algorithmic block的設計及建模… 以加速產品開發的速率; 至於原始模型開發完成後的其它工作(如寫成C/C++, 編成.DLL/.SO等), 就不如交給其它術業的專攻 (* 咳 *) 吧。

IBIS-AMI: 利用Proxy類別來做模型分析

前言:

近幾年來在IBIS-AMI建模討論上常被提到的課題一是透過back channel來對Tx或Rx或兩者同時優化, 目的是要找出一組最佳參數的組合以使channel的效能達到最佳化。至今為止的IBIS Spec並無法對此一流程做出定義及支援, 所以資料的交換僅限於仿真器及各個模型本身、而非模型與模型間。除了這點限制外,建模者也常常會遇到下列一個或多種狀況:1. 仿真器及參與運作的各模型間對Spec.版本的支援並不一致, 2.其IP來源可能是不同的矽智財供應商 3.可能核心部份所編寫的語言也未必一樣, 比如說可能是用matlab的P-code; 在這些情況下, 常因為程式源碼的不可得而必需遷就現有建好的模型或檔案, 則要進行不同模型間的co-optimization也就更困難了;為了克服以上所提到的問題,我們可以利用proxy 類別來進行AMI模型的分析或實驗。

本文係為在2017年DesignCon所欲發表的同名文章準備所寫, 連同發表的簡報檔案及屆時的錄音, 已於此文的底下加入連結以供向隅者下載參考。

AMI流程裡的物件角色:

IBIS Spec.的讀者不難發現:在第十章(Algorithmic Modeling)裡所談到的都是參與AMI流程裡兩個物件角色的分責及應用;這兩個角色分別是1. EDA Tool (常是仿真器), 2.一或更多個參與仿真的AMI模型。AMI應用程式界面裡定義好仿真器需將以.ami為附檔名的參數檔讀進並做範圍及型態上的檢核, 而後將Model Specific的部份以資料對(key-value pair)的格式傳給相對應的模型。在模型與模型之間,並沒有可互相傳遞訊息的機制。

以上述.ami檔的內容為例, EDA軟體得負責讀入此檔, 然後因為”GetWave_Exists”設為True而了解到此模型有AMI_GetWave的函式的存在, 其次因為Use_Init_Output設為False故知在仿真過程中應呼叫AMI_GetWave來做資料上的處理而非透AMI_Init來進行。在此之外的Model_Specific部份則非EDA Tool所需考慮及了解, 而只需將其Parse成資料對傳入模型:

當我們用除錯器在API函式入口設break point後,便可看到由EDA軟體傳進來的值, 其格式已和原.ami裡的不同。這裡要強調的是如果建模者的函式原始宣告與API定義的不符,則EDA軟體是無法對這模型的.dll/.so進行加載而在這break point裡停下來的。

透過最近新加的back-channel interface (BCI)提案, 新的AMI API函式也有所新增及改變以便能支援不同模型間的相互資料交換:

對此有興趣的讀者可至IBIS官網找到BIRD147.1_Draft的相關文件做更深入的了解。簡單言之, 各模型間可利用此新的協定以實體檔案的方式來交換資料。而由於這些AMI參數是新加的, 也就需要為所使用的仿真器支援才能開始運作。

過去幾年來幾間EDA廠商已為這BCI的運作模式進行角力…有興趣的讀者也可在這兩年IBIS Summit的相關發表文章裡找到資訊, 大略言之, 他們對下列幾種情況的見解有異:

  • 如果舊的AMI模可無法重新編譯, 也就是說它們停留在舊版本的話, 則不同廠家所提供的AMI模型要如何一起運作?
  • 對仿真器而言,其是否應主動地介入不同模型間優化的過程, 或是讓模型自己跑就好?
  • 不同模型間優化的協定是否應成為IBIS Spec的一部份或只要參與模型自行設定、相互了解即可?

在此之外, 我們認為下列的情形也構成co-optimization流程的鴻溝:

  • 做為一仿真器的研發人員(就是有仿真器的源碼),我如何用手上現有的AMI模型做co-optimization的測試
  • 做為一AMI建模者而言,我所用的仿真器可能不會每年更新, 那我要如何測試現有的模型以確保其可使用BCI協定無誤?
  • 做為一AMI模型的使用者言,我只能得到仿真器後處理後的結果,但若其有誤, 我如何能檢查仿真器及各模型間相互傳遞的資料以便偵錯?

凡此種種,都可利用Proxy類別的物件來做處理, 以下就為此一構想做更詳細的說明:

Proxy類別:

上圖所示為Proxy的UML, 最上方的虛線代表的是”has a”的關係, 而下方的垂直實線代表的則是”is a”的類別繼承關係,這UML可解讀為:”一個Client有一個或多個的Subject, 每個Subject都有繼承界面並執行DoAction的方法, 其中的一個物件是個Proxy類別, 當Proxy的DoAction被呼叫時, 其又轉而呼叫了RealSubject的DoAction函式

把這種關係套到IBIS-AMI的關係裡, 則可解讀為:”一個EDA軟體可加載一個或更多的.dll/.so, 其每個都有合乎IBIS-AMI API的函式如AMI_Init, AMI_GetWave及AMI_Close等, 其中的一個.dll/so實則為Proxy物件, 當其API函式被呼叫時, 便轉而呼叫RealSubject (即實際運做計算的模型)的AMI-API函式以做資料處理“。

所以Proxy類別或物件可視為一個包在真實模型之外的wrapper, 這個proxy物件雖為EDA軟體所加載, 但它其實只是”中間人”, 而可在其間把要EDA軟體要傳給真實模型間的訊息加以截取、記錄或改變、或甚至是更改運作的流程。對於一接獲訊息的真實模型而言, 其也並不知道呼叫它的實際上並不是EDA軟體本身而是Proxy物件, 所以便有可能做出實際EDA軟體並不支援或尚未支援的工作。在上圖的源碼截圖中,可見到Proxy的AMI_Init函式做的是把真實模型的.dll/.so加載進來, 並轉而呼叫其內含的AMI_Init函式。

透過這種Proxy的類別或物件, 我們可以做一些有用的測試或實驗:

Consistency/Stress測試:

以下的例子所示範的是同一API函式及相同的資料被呼叫了許多次, 其目的是要做兩種測試:

  • Consistency test: 若給與相同的輸入資料, 其傳回的結果也應一致, 尤其如果這個模型是LTI的話(未與歷史記錄有關)
  • Stress test: 模型所用的資源如CPU或記憶體等不應隨著被呼叫次數而一直增加,除非有memory leak等的臭蟲

之所以要做這些測試, 是因為在IBIS Spec裡有特別提到, 當EDA軟體或仿真器欲對一長串的位元資料(比如說數百萬位元)做計算時, 其可以把這長串的資料分隔成不同的區塊再依次對同一AMI_GetWave函式做呼叫計算。也就是說, 一個良好的AMI模型應要能通過這兩種初步測試。

Co-Optimization(程序內):

第二個的實驗是把Tx及Rx的模型綁在一起以便一起做如優化的工作 (巡迴直至某種組合的參數能讓整體的功效最佳化)

首先, 從IBIS Spec或是上圖中可見, EDA軟體會以輸入1或4做來先對Tx傳值並在模型裡做響應計算, 之後再把結果和Channel做Convolution而最終傳值給Rx模型的GetWave做計算。這些計算主要是Convolution, 而Tx端大都是LTI的如FFE功能模組。

因為Convolution是具可交換性的,也就是說先後次序並不重要:

所以如果我們在Tx端以一Proxy物件直接做Delta響應的計算, 也就是直接回傳EDA軟體所送進的資料而不做改變, 就可以在Rx端的Proxy物件裡把這Tx與Rx綁在一起做計算也不會改變最終結果。

如上所示, 在Rx端的Proxy物件裡我們改變了原來運作的流程, 也就是透過可直接操弄兩者模型的記憶體位址來對內含參數做改變, 再加上一個外包的迴圈且於迴圈內不斷地做優化直致收歛為止。對於上層仿真器或EDA軟體來說, 它並不知道它呼叫了一個模型的GetWave函式後在這裡面竟進行了這麼多的工作, 也就是說:透過了Proxy物件, 我們可以把EDA軟體及AMI模型間的藕合給打斷而隔開來了。這也證明了Proxy類別可拿來為運作流程做客製化的改變。

Co-Optimization(程序外):

以上的兩個例子裡, proxy裡的運作仍是在同一個執行緒及process裡進行的,其實若是在其它的process裡進行, 不管是在本機或網路上的其它機器,這種Proxy也一樣可以讓原仿真流程繼續進行無誤, 以下圖為例:

我們想要利用EDA軟體的後處理能力來得到某組設定參數的效能結果, 可以讓右邊的這個程序反覆地進行,但因為呼叫的是Proxy物件,這proxy可透過某種通訊方式來向遠端的(即左方的)真實模型來送及取值, 則左邊這process便可一直長駐(persistent, 如server般), 每次右方的Proxy送值後, 它就做運算且把結果傳回去,而後等待EDA軟體做完後處理後把結果讀進來並為下一次右邊Proxy再次呼叫做準備, 如此便達到了仿真器和真實模型的所在相隔的效用;之前所提到的兩程式間的通訊可以是透過共享記憶位址(shared memory)、波包傳送(socket communication)或是程序間呼叫(IPC, inter process communication)等來進行, 而所謂的server端, 也並不需要有一個如仿真器的程式來載入proxy物件, 只要有個如SPISimAMI, AMICheck等的模型驅動程式來對.ami檔案做前處理並載入proxy的.dll/.so即可。

上圖源碼截圖中間的部份即是透過socket通訊的方式來與不在同一process的模型做連結, 呼叫這proxy的仿真器並不知道模型的運作不在同一process裡。

其它Proxy類別的應用:

除了以上所提及的幾種實驗外, proxy類別的AMI模型也可做為下列的運用:

  • 可做為一wrapper以便對由其它程式語言所實作出的模型做支援, 也就是說, 實際SERDES的運作部份可以是用matlab, p-code, perl,或其它執行檔所寫成而透過這proxy來和上層的EDA軟體做AMI流程的連結;
  • 可拿來當做一Server以集中管理所要支援的SERDES AMI模型智財,這server可以比如說是在IC智財商的公司裡, 如此便可保持模型的隨時更新及資安上的安全因為模型並沒有發佈出去, 客戶端所用的只是PROXY而已
  • 可以拿來支援舊版的模型, 很多現有的模型也就不需要重新編譯, 只要透過這Proxy把要新增的功能加上去再轉譯成原有模可也可了解的參數即可, 或是將新功能即時地在本地proxy處理後回傳而不透過原有模型, 兩者都可以達到新加功能的效果。

我們在AMI的專案中用了不少這種proxy的軟體設計技巧來做分析且發現其甚為有用;隨著AMI模型運用愈來愈廣, 我們也相信這種proxy類別可在更多的情況下為更多的新加的spec及通訊協定來與現有模型做連結。

相關資料:

[按此]下載當日於會場有關此簡報的錄音。

請[按此]或到IBIS官網下載有關此簡報的PDF檔。