Category Archives: 建模

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更新裡也加入了此一功能以使我們的軟體用戶也能同享此快速建模法所帶來的好處。

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

Posted on by
1

我們”使必信”公司除了銷售累積多年經驗所開發的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來建模

Posted on by
Reply

前言:

這篇博客文章是為了即將於 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_Resolve及AMI_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: 案例研討

Posted on by
Reply

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: 經濟有效的建模流程

Posted on by
Reply

前言:

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建模流程：研發

Posted on by
Reply

流程構思：

我們設計差分放大器的建模流程時，考慮的是與單端點放大器建模流程的一致性及為因應兩者間不同處所加入的彈性。以前者而言，差分及單端放大器所需走的步驟有很多是相同的︔這是因為差分模型中有一大部份所獨立出來的便是單端放大器（請見上一則貼文）、故自需為其依單端模式建模。對彈性而言，主要的考慮是差分建模過程中，對於靜態和靜態差分電流的建模容或有以人為做取捨的空間。在這篇文章裡，我們就再就中間的細節做更多的探討，並看看在我們的SPIBPro裡是如何兼顧這一致及彈性的。

模型設定：

理論而言，建模者並不需要先對所建放大器為可以單端點方式建模的假性差分(pseudo differential)或半／全(half/true differential)差分來做分別；在官網上的IBIS Cookbook也是如此地陳述。其甚至以一加碼後的spice設計為例來說明在無法得知所為建模的設計內容的情況下，可視一黑盒子而直接以差分建模方式將其做半／全差分設計來處理。直至以series model來表示的差分電流算出來後，再依其是否達到足夠影響另一輸端的大小（亦即藕合的程度）再來決定半／全差分的假設是否正確。

實務上來說，我們認為應反其道而行：也就是先以假性建模方式進行，若模型驗證的結果顯示精確性不夠才再來考慮走半／全差分的流程。之所以如此建議，是因為一般同公司或由公司外包的人才會為其設計建模︔故是否有藕合的情況通常只要問一下晶片設計者就知道了、且如此做也不需要知道晶片設計或運作的內容或細節︔再者，差分放大器的建模需要一些額外的掃描、仿真及計算，故除非絕對必要、能免則免。

相較於為單端放大器建模，為差分建模所需要的設定，多需要知道的只是額外的反相輸入及輸出端點連結在原transistor電路所需連結的端點為何︔再加上差分模型的指定，便足於開始建模的進行:

流程概觀：

差分建模的流程大致總結如下圖所示：和單端放大器建模主要不同點在於走向非線性而可一氣呵成。包括仿真及後處理的步驟都需要前後進行兩次：第一次仿真只需要針對為IV做掃描的PU/PC及C_Die進行即可；注意的是因為兩個輸入互為反相，故並沒有需要做PD/GC的仿真，它們的資料在PU/PC仿真結果裡都有了；第一次後處理的階段需要進行的是將同模電流自PC／GC結果裡萃取出來並分別存成PU/PD/PC/GC各曲線的資料以供第二次後處理所用；而減去此同模電流後的差分靜態電流部份便需以csv表格的格式外存以供用戶用其它如試算表等的工具做檢驗或另作建模所需；其次，C_Comp 及C_Diff的值也需自C-Die的仿真中算出來；與已經算出的靜態差分電流，這兩者需在後處理結束之前以可仿真的模型來呈現。第二次仿真階段只是利用這才產生的模型，將其瞬態電流在VT仿真中自原差分設計後除去；也就是說第二輪的仿真過程只需用到VT的檔案︔在此之後，所有的資料都已具備，故在含第二次後處理的階段之內的建模流程就可繼續線性地走下去、就好比是為單端緩衝器建模一般。

IV資料建模：

雖然PU/PC的仿真是為在DC模式所需的電流所做，但由於很多原始設計裡都有時脈信號的關係，這些仿真並無法真的在DC模式下來進行︔所以走的方式多是＂假DC＂(pseudo-DC)、也就是所有的時變信號都變動得很慢而使得在每一個取樣點附近都可看做是已達準態的情況；如此做的另一考量是很多的設計由於其複雜性，都得透過如all sources ramp up的程序來得到靜態DC的初值，故若真為每點都如此做則仿真所需的時間便會很長。

另一個能縮短仿真所需時間的方式是平行處理：如上方我們SPIBPro所產生的test bench電路所示，不同IVPC的檔案間不同的只是輸出N點的電固定電壓，輸出P點則同是做線性-Vcc~2Vcc的掃描︔正因為兩者之間無關聯性，故所有這些spice檔案都可以並行地在同電腦上用多執行緒或是在不同電腦上被仿真；另一流程上所需的考量是因為並非在所有的偏壓點原始設計的仿真都會收歛，故在後處理上需對部份資料的缺少有相當的容忍性。

如前所述，第一次後處理時需做第一個部份是的是將才剛完成的IV仿真做計算，先把同模電流算出來，其次將這同模部份在每一點都減去以剩餘差模的部份、最後再將這些不同仿真的結果總結並輸出在一個CSV檔案裡。當然以這些資料做初始的建模【下段會詳述】是程式需要做的部份，但同時也提供CSV檔也表示如果有需要的話，用戶可以認證這些資料或以其它的程式（如試算表或JMP)等來自行做建模的實驗。

那要如何將此表建出可在第二輪VT仿真裡可用到的模型呢？有下列兩個可能的方式：

  • 曲面反應模型：

在此要做的是將上表的資料以三維的方式呈現，如上圖所示，因為差分放大器P／N兩端的輸出一般是有對稱性的，故吾人可在與同模（紅色直線）相垂直的準差模部份（藍色直線）來看在那軸線上的資料是否可用線性的平面來表示；若然則表示只要用一個電阻放在產出的藕合部份的模型裡即可︔若是以series model 來看便表示只要一個series resistor即可。在驗證上，同戶也可利用產生出來的CSV檔來看P端輸出電流和差分電壓（即V(P) – V(N))是如何變化︔若是其值大部份近似固定值、則此固定值便是模型裡所需的電阻值。

其次，若是軸線上的曲面並非直線，但是是一致的波浪狀，則表示用一非線性電阻仍可以表示這波浪面︔在為VT仿真電路所需的實現上則可用如PWL的被控元件以達到非線性電阻的目的。至此而言，可以說的是一個差分建模流程裡應要有輸出CSV及３D視覺化資料的能力以變對所需要的模型設定很快地有初步的決定。

比較麻煩的是若資料呈現出的是如上圖般的不規則曲面，則需再透過如為＂反應曲面＂來計算或是以Series MOSFET般用多重表格來給與所有取樣點才能得到精確的建模以供VT仿真使用。

以反應曲面設計為例，上圖所示是我們SPIMPro的步驟：選定自變數及應變數後時也需決定自變數的order為何︔一般而言二階應是足夠，而後就用每一取樣點形成的矩陣做SVD解並求得各個階次自變數的係數為何︔同時也把原取樣點的各值代入此等式中再和原輸出值求差值、亦即計算殘餘值(residue):

若是求解成功，依此預算式算出並和真值差的殘值應是很小，若能以視覺化來檢查（如下）則能很快看出所求等式係數的品質：

上圖各紅點是真值，而很靠近原點的灰色部份則是殘值；因殘值極小，故可謂求解成功；接下來要做的便是利用spice 元件裡的E/F/G/H等受控電路再依仿真器所支援的等式格式(如用poly(2)來表示二次式並在其後設定各係數值）來產生模型︔以上的圖形皆由我們SPIMPro所產生︔若所用工具無此功能，則可利用Matlab以＂lsfit＂的函式來進行。

  • Series Model:

若是建模者想直接利用CSV表格建模供VT仿真使用而不想走上述幾個為二維曲面建模的步驟︔在所用仿真器也支援series model的前提下是可以直接進行的︔所要做的便是以合乎IBIS語法的方式來將CSV表單直接轉成series model,如下圖SPIBPro的 series modeling flow所示：

若建模者可事先利用３D視覺化了的資料預先決定只要用簡單R或甚至非線性電阻以series current的方式填入series model，則過程並不複雜；但若是要用可達一百個表格的Series MOSFET來把所有取樣點都加進去，則要手動來做所費的工夫就很不經濟而不如透過如我們的程式來進行也更不易出錯。

C-Diff建模：

與上述類似的步驟（CSV建表及曲面建模）也同樣可套用在差分電容C-Diff的計算上︔話雖如此，由於利用EFGH等受控電源及透過series model的語法對電容的描述有更多的限制（比如說用以描述非線性電阻的series current及series MOSFET就無法套用到需取決於時下端點電壓變化率的電容值CdV/dt)，故一般的做法、也是有所取捨的部份，是在所得反應表面的最高及最低值間取一平均值，而後再加入所生成的模型並在VT瞬態仿真上使用。

Verilog-A建模：

在我們為年底IBIS Summit所遞交的論文裡，另外提出了以Verilog-A/VHDL等為series model建模的可能；其優點在於當用於流程上時，可利用其語言內建的$table_model函式直接運用第一次後處理所產生的CSV表檔︔其次，由於其亦含有更多的運算子（如可以用ddt運學子來算出端點電壓變化速率），故在對C-Diff值的建模上可有更多的彈性及更高的精確度。相關細節待會議發表後再於此更新。

模型完成：

在前一篇的貼文裡，我們已經略述如何利用series element加在P／N兩端的差分腳位上來加進藕合的影響︔另一種可能是純用Verilog/VHDL等語言直接用differential model類別加在腳位所連model下的敍述︔當運用我們所構思的、只運用到series model的Verilog/VHDL模型時，上述兩者其實是可以一同使用的。如下所示：

上圖中，在”[Series Pin Mapping]”下仍描述有另一series model跨接在P／N腳位間並提供藕合的資訊︔然而另一針對此series model所建構的Verilog/VHDL模型透過以series 為model_type的方式用”[External Model]”來加掛於頂層的series model之下。與純series element描述式不同的是因為可用到許多Verilog/VHDL的運算子，靜態差模電流可更方便地被表示︔而C-Diff也可以更精確的模型建構出來。和純differential model 為model_type的作法不同的是，這些Verilog/VHDL的語法只限於描述series model的部份、而且其是可以被comment out掉以增進模型的可攜性的。也就是說，我們可以得用更高階次才能描述的部份放在這裡，而在上層的原來series element裡放入基本的差模IV及單值C-Diff,便可同時達到可攜性及彈性增進精確度的要求。

流程驗證：

欲驗證一差分建模流程的精確性，當然最終的方式是將所建模型仿真的結果和原始設計相比較。但一開始驗證時，其實吾人可以用兩個相同的IBIS單端放大器模型，透過相反相的輸入再加上一任意建構出的藕合電路（比如說內含平行的R與C）、將其連接在兩輸出端來做為測試電路。由於這單端模型已以IBIS模式呈現，且藕合電路的內容也是已知，我們便可很容易地來和所開發的建模流程所產生的結果來相比較。第一次仿真及後處理後，所產生的同模電流放到PU/PD/PC/GC　IV對照表裡且其值需是和原單端IBIS的同表格完全相同的；否則在同模的計算上便有錯誤。差模靜態部份應能完全反推出藕合電路裡的電阻值。。。不論其為線性或得用曲面表示與否；否則便是差模的計算有部份有誤；而C-Die的二維掃描也必需能完全反應出所設定藕合電路裡電容反應的部份。最後當靜態的差分電流及由C-Diff所形成的瞬態差分電流都能完全精確地在VT仿真中被減去的情況下，新建差分模形的VT表格便應和原始單端放大器IBIS模型裡的VT資料幾乎完全相同。

相關資料：

我們已於2016年十一月於IBIS峰會發表此一論文; 其可於 IBIS 官網 或 [這裡]下載. 我們亦於東京場次有現場錄音可[下載]

差分IBIS建模流程：概觀

Posted on by
Reply

我們之前已寫過一些有關IBIS的建模流程的貼文，其中所提重心是針對單端點(single-ended)放大器的建模；主要的原因有下列幾點：

  • 單端點放大器建模流程較簡單直接、在才開始學建模的情形下較易上手；
  • 假性(pseudo)差分放大器是直接可以用兩個單端點放大器組合起來的；
  • 許多半或全差分放大器(half/true differential)即便是用假性差分建模流程來進行結果精確性也未必會較差[參考]；
  • 完全的半／全差分放大器建模牽涉到非能線性進行的步驟而麻煩許多。

上個月在台灣辦的講習裡，有數位同業問到CML(current mode logic)的建模。。。其便是屬於半／全差分放大器的範疇；也由於現在很多的IO界面都是走SERDES（如USB, SAGA, PCIe等等），再加上已介紹過單端放大器建模流程後，也實也應繼續往下走︔故在這篇的貼文裡，我們便要談談差分放大器的建模流程，並在下篇的文章裡，簡介其中分析細節及這些設計理念在我們的建模工具SPIBPro裡是如何體現的。

要說明的是這兩篇的內容也係為年底要在亞洲IBIS Summit發表的文章所準備，相關簡報檔會在會議之後再於此更新並發佈。又這篇簡介裡的內容多係由IBIS cookbook總結而來，其可在IBIS官網上下載。

差分緩衝／放大器之分類：

一般來說差分大器可分為下列幾類：

  • 假性差分 (pseudo differential):　即如下圖中最右所示；這種差分放大器在P及N電路間是完全互相獨立而沒有任何藕合的︔兩個部分的電路可各自獨立運作而不互相影響。
  • 半差分 (half differential):　即如下圖圖中所示；其上拉端為互相獨立，唯下接到地的部份同經過一個電流源，所以輸出電流是共享的而會相互影響。
  • 全差分 (true differential):　即如下圖圖左所示；其不論是上拉或是下接到地的路徑都相互藕合而彼此影響。上接部份用的是電流鏡的設計(current mirror), 下接到地的部份則共享同一電流源。

對於假性差分而言，其可用兩個獨立的單端點放大器來描述︔這兩個放大器可以是不同的模型、也可以是由同一模型的兩個Instances再由反相的輸入所組成。在IBIS建模上、只要單獨將那單端點放大器建模完成後，再在IBIS檔案裡以”[Diff Pin]”的關鍵字表述那兩個針腳有差分關係即可。如下所示：

上面的範例描述的是pin 2 及pin 3互為差分，而pin 6 與pin 5也互為差分信號；當然在IBIS檔案裡的其它地方這四個針腳所接的（單端點）模型也需有所定義及描述。

半／全差分放大器：

對於這兩類的差分放大器、因其P及N輸出端間有程度不同的藕合性，故所需以描述的內容就不單單是上面[Diff Pin]了（仍是需要的），一般來說有下面兩種描述方式：

  • Series: 為了描述P／N輸出間的藕合，在IBIS檔案裡有兩個地方必需加入相關內容。其一是用”[series pin mapping]“來描述在那兩個差分針腳間有藕合的情況︔然後再此藕合電路以Series Model的模型形態來表述：

如上所示：在用[Diff Pin]來描述針腳間互為差分之後，假設某對差分針腳之間有藕合的情況而必需用額外的電路來表述，則另需在[Series Pin Mapping]下來定義。而其模型（以上為例是R_SERIES_100)之model_type必需是series, 且也需依預定的IBIS格式表之。series模型內容非可自定之自由格式，其內容需為R/L/C/Series Current/Series MOSFET任一或更多的元件；至於其數值則是在建模流程間由仿真後處理的結果。Series Current 可以描述的是一維的IV曲線。。也就是非線性電阻；而Series MOSFET則可透過至多有一百個的表格來描述二維的表面取樣點。

  • External Model: 另一種描述差分放大器的方式是在外接模型裡完全自訂。在IBIS標準裡有下列四種模型態式可用以表述差分：

如其右方之說明所示，這些模型的內容需以其它語言：Spice, VHDL-AMS, Verilog-AMS, IBIS Spice Sub-circuits (IBIS ISS)來描述；也因為是用不同的語言，所以裡面倒底包括並沒有另外的限制。。。。建模者想用Spice, VHDL, Verilog等的語言寫什麼都可以。因為如此，IBIS在這裡的角色就只是外包裝(wrapper)而並沒有太大的可攜性的意義（相較於IBIS，不是每個仿真器都支援這些語言的）

如上圖所示，在一個外包裝的模型（名為VHDLAMS-DRV)之下內含有另一個以VHDL描述的差分模型；需強調的是模型內容雖可由建模者自行編寫定義，但其連接的端點(port)則需從在IBIS格式裡預先定義好的兩個或更多個關鍵字裡取用，且定義的順序也必需就是在VHDL/Verilog內等所用相對應的Terminal的順序︔這些VHDL/Verilog/IBIS ISS等檔案是外含而不包括在同一個IBIS檔案裡的。

建模流程：

前面一段所提第二法：即純[External Model]的模型表述因其內容全由建模者決定，故就流程上而言就沒有暨定的方式。在下面所討論的流程、係針對第一種模型表述方式、即Series/Series Model而言的，因為其有固定的格式及內容，故在如何算出這些數值的方法上就有值得深究的需要。

一般而言，由於這樣的差分放大器描述方式是利用series模型來專門描述P／N間藕合的情況，而除去這series電路後就必需是可單獨運作而互相獨立的部份，故在流程計算上以分別針對這兩個部份來作區別︔最後再用第一段所談到的幾個關鍵字將其在IBIS檔案裡組合起來。

針對上圖中”Driver”區塊的部分，因其就是等於除去藕合Series電路之後的單端點放大器，所以便如以往所提：所有PU/PD/PC/GC/VT等表格當存在時都依同方式提取出來，差別的地方是必需得在”能分離藕合電路影響”的情況下仿真轉出：

  • PU/PD: 如上圖裡右上方所示，需在P及N點的輸出接上電壓源分別做 -Vcc~2Vcc的掃描︔在後處理的過程中，一個主要的假設是當P／N兩點都在相同電壓時，series電路的部份是沒有任何電流經過的。也就是說：PN相同的電壓時的同模模式(common-mode)下，為掃描所接之電壓源對放大器所提供或取用的任何電流都是只為Driver區塊所用的，由於P／N兩電路的輸入互為反相，故這同模時的上拉及下拉電流也就等於是driver區塊的PU/PD IV對照表內容。由於我們做的是二維的掃描，除了同模的那一直線（對角線）之外都是屬於差模（即P/N輸出點電壓不相同）的情況，而在那些點量出的電流都同時包括了差模及同模的部份。由於我們已將同模的電流算出來了，故差模的電流也就等於是在那點量測值再將同點電壓時的同模電流減去︔對於整個掃出的二維平面而言，隔出的差模電流就等於是將同模電流減去後的垂直位移︔而後再要做的就是看以何種方式來描述這位移後的二維平面以便在做VT仿真時也能將其減去。
  • PC/GC:　在IBIS規格裡，箝位電路的電流並非必需要有的。唯有當放大器裡有這類不能透過輸入信號的高、低位準來將其關閉的部份時，流經這些部份的電流才需以IV的內容形式放在PC／GC的表格裡的。在以前單端點電路時，箝位ESD電路即屬於這部份︔對差分放大器而言，半差分形式放大器裡的上拉電路也是屬於無法被關閉的部份而需將其算入PC／GC的表格裡。仿真的情況則是將緩沖器置於非開非關的High-Z而後如以前方式做P／N同電壓的同模仿真︔而後此同模電流的部份在後處理後就被放在PC／GC表裡。至於差模電流的部份，因其也會被包含在PU／PD的差模電流裡而算在series模型裡。。series則是始終存在而無法被開關的，故也就無需另計分離出來也不會有被double count的顧慮。
  • C_Comp/C_Diff:

C_Die 電容的計算也是差分放大器建模裡較不同的地方；在單端點放大器建模時，C_Comp的值在後處理時算出來再放在IBIS模型裡即可，其並不會在VT之瞬態仿真裡所用到︔但在差分建模裡，C_Diff的部份便得事先算出來，且也加入series模型裡，然後再一起用於VT的仿真以便在瞬態裡的各點都能將series模型的影響來抵消。算出C_Diff的公式如上所示︔其內容可加在series model裡的c series的部份。

  • VT waveform:　差分放大器建模的VT仿真，除了原有被建模的放大器及相關激勵或偏壓的輸入外，也必需要有一個描述藕合情形的series model一起參與仿真︔而且這個加入的部份是為了取消同樣series model在模型裡的影響（以便轉出的VT表格係為獨立的Driver區塊所用），故電流流向需相反；這就是上上圖裡Idiff有負號的原因。如前所述，這個series model裡包括的資訊除了有屬於靜態IV掃描後消去同模電流的差模部份，也必需包括了已事先算出的C_Diff部份以便反應瞬態間series model的影響︔C_Diff部份自可以一電容值表示之，而靜態差分電流部份則可利用下列兩者方式之一來表述：
    • 用E／F／G／H等的受控電壓電流源來表示所建之二維差分電流內容。比如說用最小化MSE(mean squared error)的方式來以一二次式表示此二維表面，而後再用受控源的”Poly”語法來將此二次式的參數表示並以spice元件表示；
    • 決定適用的series element而後建出相對應的series model,此法的前提是仿真器需能支援這裡產生的series model而在VT仿真中運用。

之前的IBIS Summit已對上述部份有些範例及研究，比如說［這一篇］發表就很有代表性。

 由上面的探討，吾人可以發現差分放大器建模的流程是非線性的、也就是非可一氣呵成的︔主要的原因是在建立series model以表示靜態及瞬態的差分電流部分有很多可用人為來取捨的空間︔其次，得事先算出靜態I_Diff及C_Diff後才能繼續進行VT仿真也是和之前很不同的地方而必需依序進行的。這篇的貼文旨在描述差分模型的語法表示方式及大致的建模流程及概念︔下篇的貼文裡我們會談到更多的細節並看看這些設計理念如何落實於我們的建模工具SPIBPro裡。

仿真器之研發：建模 (S－參數及Port元件）

Posted on by
Reply

系統上的channel及很多個別元件都是以S－參數來表示，其可能是用三維場解器依實體結構（導孔或連結器等）算出、也有可能是利用我們SPro的工具一級一級串結計算(cascade)而成。再加上LTI (Linear, time invariat即線性非時變）的假設，很多工具便可依channel單一脈衝(pulse)的波形來模擬數以百萬計位元的相疊加而得到如眼圖或BER圖形等的資料；無疑地，不論是單一脈衝波行的計算(在含IBIS情況下，未必都能用IFFT的方式來達成）、抑或是針對一些特定位元樣式(bit pattern)時域響應，一仿真器都應有能支援的能力。除此之外，在很多情況下我們所得到的spice電路是由頻域轉換而來、但其原始頻域資料又已不可得；故也常會有要能重現其原來S－參數資料的需要。這篇貼文裡，我們將簡單談談S－參數及相關的port 元件在SPISim使必信 SSolver裡是如何建模的。

S-Element… S-參數：

近十數年的研討會或學術論文裡，多有許多對S－參數時域建模仿真的研究；在最基本的概念上，S－參數是在不同頻域點的輸出入相關資料，其可被視為一頻域的轉換函式(transfer function)或是濾波器；故可套用數位信號處理的基本應用：在頻域上和輸入做相乘等於是在時域上做捲積(convolution):

一旦轉成時域（如上圖的最底部方程右邊）則等號右邊則可進一步改寫分成兩項：一個是由元件過去的歷史值算出、亦即由-infinity積分至前一步t=n-1的項目；以及在現今時步t=n和當下輸入有關的項目。前者因是歷史值已發生，故可被視為是一常數而在牛頓迴圈裡不再更動；後者則因和當下輸入有關，故需在Solve及Stamp的熱迴圈裡不斷更新。總的來說，這兩者寫在一起便有了諾頓等效電路I = Y * V + J的形式。其中的Y和輸入V是連在一起的而J則可被視為常數不變。這兩者的值算出後便可自系統矩陣內更新來求解。

有興趣的讀者可參考HP多年前所出版的文件，其中對以這種捲積方式求S－參數解的過程及數學有更詳細的解釋：

Integration of Transient S-Parameter Simulation into HSpice

其中的第「18」及「19」式即為上述有關等效電路的部份。

因為捲積的基本理論是在每一時步之末，常數的值都需更新為-infinity to t=n以便為下一時步t=n+1所用，再者捲積是一種IFFT的樣式而在時域上的時步是固定的，這種要求限制了仿真器運行的速度，也就是為何近來有許多研究論文建議以不同方式來進行S－參數時域仿真。

其中的一種可能是利用之前所提、用在傳輸線建模上的的vector fitting技巧：先利用如Pade approximation 般將S－參數頻域資料透過不同極零點的選取而轉成有理式(rational function),而後利用同一種basis function在不同極點頻率對時域的轉換而得到相對應的形式；這過程的一個附加效果是若原有的S－參數資料有non-causal的情況，便可在有理化的過程中得到修正；與為傳輸線建模同樣地：極零點數目的多寡和是否與原始頻域資料相近似、以及轉成時域後的仿真速率都有相關；再加上原始S－參數資料在某些點可能是ill-behaved，故在實務上常得用如pseudo-inverse的方式以minimum-square-error sense的方式來求得近似有理方程式。

P-Element… 埠(port)元件：

系統上許多元件、諸如晶片封裝package, 導孔via，連結器connector等等設計過程都是先有立體設計；而後用三維場解轉出S－參數，最後再用如broadband spice等的工具轉成相對應的spice 基本元件以便能在時域上仿真。對系統完整性分析人員而言，也在很多情況下所得到的元件模型多是這種已透過轉換得到的spice形式而其原始頻域資料並不可得；與其就直接把元件置入channel中來進行分析，較好的做法是先看看其頻域響應為何、頻寬是否足夠及是否有連結性上的問題等等。透過仿真的方式將spice subckt轉出S－參數在此便用應用的空間；而由於S－參數之轉出是植基於小信號頻域分析的，故一旦系統元件的AC模型建構完成，則轉出其S－參數也就近乎水到渠成了。

在此我們談的S－參數轉出是小信號部份，也就是在DC操作點附近的頻域分析，故而步驟上是先在輸入埠元件定義的地方先而對DC求解、加上AC信號後對其它埠測量，而後再進行下一個埠以至所有埠都掃過為止。

一般而言，埠元件(port element)都有幾個參數：DC偏壓、參考負載(reference impedance)、埠序(port order)及埠名(port name)等等;在輸入埠有DC偏壓時，其它的輸出埠都是連到參考負載的；在不同的頻率上求解後，輸入輸出埠間功率的關係可透過對埠的電壓及輸出入電流的量測而算得，而後依S－參數的測量公式：

S-parameter measurements

便可得到輸入埠i對其它埠j的Sij值；重覆這程序掃過所有的i後（不同的輸入埠可能有不同的偏壓）不同頻域點的Sij就都有值了，最後再依之前定義的埠序把資料寫出(至touch-stone format）且在表頭註記埠名則S－參數轉出的程序即算完成了。若是有進一步的需要要將S－參數轉成其它如Y, 或Z參數的形式，則可透過公式（雖是只有雙埠，但若假設S－參數是廣義的2-n port 也可適用）或是如本司SPro的工具達成。

 

回到仿真器的部分：

除了至今所提的各個元件物理模型的建模外，回到仿真器的階層則又有如下列的相關的課題：

  • 記憶區(memory pool)之管理:分配，擴張及清除
  • 多執行緒
  • 模組化外掛架構以支援新元件
  • 其它種種。。

不難想見這清單可很長地列下去，而之中的編程的工作也未必簡單；即便如此，對於系統分析的方法及流程而言，仿真器的完成及支援實有其不可取代的價值：對很多日後的分析，我們都不用（很多情況下也不可能）再得事先導出所有的算式了，我們大可透過直接形成網表後呼叫仿真器後再後處理資料的方式達成。這不僅有助於軟體的模組化，在穩定性（仿真可在另一執行緒或透過simulation farm完成)甚或是可測試性上都很有幫助， 對於一以研發系統EDA的公司如我者而言，是一項值得的投資。

在開源Spice仿真器上使用IBIS模型資料 「問答」

Posted on by
Reply

上週在IBIS summit of 2016 DesignCon會中，我們宣讀並分享了最近開發”Ibis to Spice”流程的經驗，反應相當熱烈；在這篇貼文裡，我們集錄在宣讀末之問答階段所提的問題及討論，以供未能有機會親身參與讀者之參考。

  • 問：免費版仿真器裡有IBIS parser嗎？
    • 答： 沒有。據我所知的免費仿真器裡都沒有IBIS parser, 更有甚者，它們在寫此貼文的同時跟本就不支援IBIS元件。話雖如此， 有興趣的讀者不妨參考也是開源的pyIbis看有否可利用之處；再者，跟據IBIS官網，只要花約美金兩千五就可拿到公版Ibis Parser的源碼來做商品化的使用。我們（使必信科技）本身是有跨平台的IBIS Parser以在程式及此流程裡直接使用。
  • 問：我在Berkeley Spice3f5的手冊裡沒有看到有ASRC元件？
    • 答： 請參考NgSpice; 免費仿真器、諸如NgSpice, EiSpice, LTSpice及TISpice都是由Berkeley Spice的原碼所加以衍伸改進而成，故雖在文件語法上或有些許不同，但我們所舉出的理論應都只要做微幅的語法改變就可在這些仿真器上運作。
  • 問：所提供的範例是否只適用於上升及下降波形為對稱的情形？
    • 答：並不是這樣的。我們所提供的範例之初便有一段是將輸入的類比波形轉換成數位信號的設定。這轉換是透過偵測穿越某一臨界電壓值而達成的；一旦轉成數位信號， 其上升及下降沿的維時便很短， 故與波型是否對稱、或 Duty Cycle是否是50%無關。
  • 問：所提供的範例是否適用於超頻的情況？
    • 答：在IBIS的官方規格文件裡，並未對在超頻情況下仿真器該如何運作來做規範；故在超頻的情況，不同的仿真器就很有可能會有不同的輸出結果。理想上，吾人應設計模型運作使其在超頻的情況下輸入、輸出電流都能保持連續性；也就是造成的節點電壓也會連續而不會有突波的情況發生。我相信這種機制是有可能外加於現有的範例而達到的。。。比如說利用電容來和緩波形等等；在所提供的範例裡，目前並沒有這種機制來支援超頻的情形。
  • 問：如果我對轉出的模型仿真相當長的時間、比如說一微秒，會有問題嗎？
    • 答：在實作做程中，我們發現如果ASRC的變數值很小。。。比如說像我們仿真時時步的ps(1E-12)的程度,則仿真器會將其捨去而造成結果的不正確。這也就是為什麼我們需事先將此值及相對應的切換參數Ku/Kd都予以放大的原因。若以一奈秒1ns為基準，則1ps及1us相對應的值是1E-3及1E3倍。。。都不是太大或太小，仿真器也應就不會將其捨去。所以我想這種情況下、即使進行一微秒的仿真，也應該不會有任何問題。
  • 問：為什麼會需要用到傳輸線？ 仿真器裡不是都有各節點的記錄嗎？
    • 答：的確一般在仿真器的內部，都會有一個陣列來儲存各節點過去幾時步的電壓資料；所以比如說如說編程者決定用Trapezoidal rule來算一階導數的話，也都能在那裡找到前兩時步的資料。但我們這裡的建模完全是使用現有Spice的語法及元件來完成，也就是說，我們無法透過C／C++等來存取仿真器內部的陣列資料。如果有需要前數點的資料的話，料想的做法是用數段無損T-Element 元件串列起來，則在每兩段線中間連接的節點，都可取到幾個時步前的電壓值。就是說：藉由串連兩段傳輸線，吾人應就可找到前一及前二時步的值而加以運用。
  • 問：為什麼會需要微調來避免突波？轉換係數不是應都已達到穩態了嗎？
    • 答：理論上的確是如此。在未超頻的情況下，一般在做另一向的波形變換之前（比如說開始上升或下降），Buffer應都已達到穩態值。也就是說，KU應是達到1.0值而使pull-up branch能全力供應電流而KD於此同時是0.0使得下拉的pull-down是呈開路的情況。我們之所以需有微調的部份完全是因為在此我們是利用Spice現有的元件來組成這模型的，而非是理論上的需要。有興趣的讀者不妨可Comment掉所提供範例裡微調的部份便可發現突波的出現。若有其它更好可濾此突波的方法，也煩請留言告知或分享。
  • 問：您下一步打算做些什麼改進？
    • 答：我們打算繼續向在以免費仿真器上提供系統分析能力的目標前進。以NgSpice為例， 若要在其它加入如IBIS等新元件的支援，一般有三種途徑：
      1. 直接加入仿真器內部做成如R／L／C般之原生元件：這個方法開發者需對仿真器內部的資料結構、運作流程甚至是仿真的原理都有相當的知識；如果成功的話仿真速度將會最快，但也會需要較久的時間來開發。一般是得用C／C++語言來進行編程。
      2. 透過Code-Model的延伸方法來加入：同樣得用C/C++來編程，但因為透過的是XSpice的延伸方式，並不需要去動到基本的仿真器架構及源碼；所開發出來的Code-Model是動態函式庫的模式，故可直接被現有的公版仿真器所使用；唯在開發及偵錯的過程可能較為麻煩。。因得先attach到在進行中的執行緒。不過這是開發者需要傷神。。。使用者則不用去碰到處理這種問題。
      3. 用ASRC元件在仿真器外建模：這就是我們這幾篇貼文所提到的理論及方法；雖是可行，但只能做驗證用，因為仿真起來速度有其限制。

現在公版的NgSpice裡，尚付之闕如的是：IBIS, W-element及S-參數的元件，有了這些元件的支援，吾人便可用其做很多系統上的仿真及分析。我們打算在接下來的時間以上述途徑“2”（Code-Model)的方式來加入對這些元件的原生支援。