IBIS-AMI: 模型架構分析

前言:

在前篇貼文, 我們大致探討了有關IBIS-AMI模型的幾種相關角色及其所需要的考量;在這篇文章中,我們以建模工程人員的角度來研究幾種可能的建模流程及其利幣。先申明的是本文中所提到的幾種其它商用程式範例均以在網上可合法公開取得的資料為準, 所參考到的文章已列於本文之末。

IBIS-AMI模型:

不論欲建為其建模的SERDES設計是多麼的精巧複雜,最終要做的事仍是要以C語言將其以合乎AMI API的三到五個函式(取決於要支援的IBIS SPEC.)寫出來並以編譯器在相對應的系統上做出.dll/.so的格式。要先說明的是API雖必需以C語言寫出,但其中的運作(即函式叫進來後是怎麼算出SERDES結果的)並不以C語言為限。比如說用戶可以用matlab寫出其中的計算並以p-code, 可執行碼或函式庫的形式與外包的C語言進行資料交換。不論如何,這套程序所要進行的工作仍然是如何能將SERDES的運作轉成相對應的源碼(source codes), 在此之上,另要考量的則是如何做才能使得產出的程式跑得快、算得準、容易維護又延伸性佳。

IBIS-AMI應用程式界面

為達此目的,一種相對簡單的建模流程是利用程式自原始設計自動地將源碼產生, 也就是所謂由上而下(Top-down)的設計流程。

由上而下的建模流程:

一般硬體的設計流程都是由上而下的:一開始是做佈線規畫(floor planing),然後必需有的各功能以方塊圖的方示表之,在此階段,各方塊圖內的細節先不是重點,要求的是各功能區塊間的行為互動、資料交換標準、及時域或譟聲的預算或容忍值等等。在這之後各設計人員或團隊才分開並針對每一個功能區塊做實體上的設計。最後把所有的設計整合起來做最後的整體分析或仿真。以此設計流程而言, 一般會有可編輯原理圖(schematic)的軟體讓設計人員把現有函式庫或樣版(template)編輯並接連起來, 而每一個區塊也常是各自有其階層性(hierarchical), C/C++源碼產生是由軟體將每一層的設計逐層逐級地產生。

要將設計轉成源碼, 如果順利的話一般是設計人員先右擊各功能區塊且設定要外顯(expose)的參數及名稱或變數範圍, 然後透過一程式產生模組來將設計轉出對應的C/C++源碼。就IBIS-AMI而言因其不僅有功能上的要求,在API函式的名稱及參數上也有規範, 故常還要另外有一個AMI專門的外掛來進行這些動作。

就這種程序而言, 用戶只要專注在SERDES的設計就可以了而毋需去考慮產出軟體的內容細節及品質。因為這兩家公司在業界也算有名,所以一般可相信以這些源碼做出的模型在實際運作後也能產生和原設計幾乎近似的結果。

電腦產生的源碼:

由電腦或程式自動產生的源碼, 可以看到軟體”很忠實”地如原理圖般一階一階地把它們串起來了,但坦白而言, 可讀性、維護性及延展性可能都不高,其次,不論如何為這些程式做更動或調整, 下回當再次將設計右擊滑鼠產出源碼時,所更改的這些部份又都將被覆寫而白作工了。也就是說,這種由上而下的建模方式在下端(即已產出的AMI模型)做的改變更動大概都無法回溯置回原始(上方)的設計裡。

我對這種由上而下的AMI建模方式的看法是:

  • 適合給有所有原始設計、且又不想管CODE的工程師用
  • 由這些程式自動轉出的程式:
    • 應能算出準確的結果,(如果不是的話就麻煩大了… 因為不會有最原始的程式碼可供查驗偵錯)
    • 運作起來跑不快, 至少以目前所見的情形都會是如此
    • 結果源碼可讀性不高…無法強制依某種coding guideline來產出, 所以並不容易維護及做長久性的支援
    • 由上而下是單向式的, 改變的源碼無法回頭標註在原始設計中,所以下回再次產生源碼時可能就又被覆寫過去了。

由下而上的建模流程:

若是以軟體架構的眼光來看AMI建模的需求,又會做如何的設計流程呢?猜想應是會和由SERDES工師師來做不同, 一般而言, 可能會做如下般:由下而上(bottom-up)式的規劃:

  1. 首先, 先定義出AMI建模中常會用到的幾種功能區塊, 諸如
    • FFE: Feed-forward equalizer, LTI, Time or frequency domain
    • LPF: Low pass filter, LTI, freqeuncy domain
      • CTLE, Bassel, filter based IIR/FIR etc
    • DFE: Decision feedback equalizer, NLTV/digial, time domain only
    • CDR: Clock data recovery, NLTV/digital, time domain only
    • Coder: various coding page
      • 64b66b, 8b10b etc
    • PRBS: Pseudo random bit stream, PRBS7, 10, 15 etc
    • AFE: analog front end to convert pulse to shape with Rt/Ft/Swing etc
  2. 其次, 就這些區塊為透過OO的要求針對AMI來做設計:先定義出軟體界面、基礎類別及要以虛擬函式來執行的相關運作等。
  3. 而後,針對不同的區塊進行實作, 並在上層要連結起來的階層以”更優雅”一點的方式整合
  4. 這點可算做加分題:可順便考量更進階的外加功能(諸如加密, 為不同CTLE或FFE組態做切換的設定等等)可如何地透過.ami檔來進行等

因為這些源碼是手動寫出來的…而非機器程式一貫作業產生的, 所以在可除錯性、程式易讀及可維護性、以及可延伸性上應都有更好的結果,再加上適當的說明文件, 這些模型可視為是公司軟體智財的一部份而有其價值且可長久使用。

在運作準確性的要求上:

  • 這些源碼應儘量不要是為單一設計而做, 所以不應有hard coded數字的情況發生,所有設定應儘量參數化以供自動優化用
  • 可透過sweep, lest-squared-error based fit, 或其它的優化方法以取得一組能和原始硬體設計效能最近似的參數供模型使用, 也就是說, 以此法得出的模型,不能假設其必然準確,而需另下功夫才能達到這要求。

我對這種由下而上的AMI建模方式的看法是:

  • 適合給懂得OO又對軟體編程有興趣的工程師使用
  • 因為大都是人手工寫出的軟體:
    • 需另下功夫以先確保軟體品質,而後再求精確性
    • (做得對的話),應會跑得更有效率
    • (做得對的話),會更易維護並延伸
    • 可重覆使用性高(軟體的本質),長久而言應更具經濟效益。

資料表單式的AMI建模:

綜上所述, 兩種AMI建模的流程都各有利幣,難道不能有兩全其美的方法嗎?

當然是可能的…但並不相對簡單, 究竟即便是工程師也各有分工專業,這也就是為什麼提到AMI建模時需要軟硬體相關知識,再加上DSP, 科學或工程計算等等的跨領域背景要求了。

大致上來說, 我認為如果能將兩種不同流程裡的短處減至最少,則就有近似兩全其美的條件;比如說, 當我有機會找到其它EDA廠商的AMI元件庫時,很高興地發現其實它們的設計也都如bottom-up或軟體模組的思維一般是很有完整性的, 之所以會在由上而下流程走過後產生令人不敢恭維的源碼是因為SystemVue(Simulink大概也一樣)這套軟體給一般設計使用(就像CPU一樣, 什麼都能做),也就是說, 它們的設計理念是:我們可將任何設計轉出相對應的源碼, 轉出後的品質等是其次的考量。

既然要改變大公司現有軟體應用領域大不易,則從另一方面來思考, 我們也可從現有的很多(開源等)DSP或濾波器函式庫來做運用而非重新發明輪子般地從頭做起, 在這些已經過較多測試函式庫上再以軟體工程的思維(而非廣義的自動軟體產出)來做AMI的建模應是更易著手的方案。所幸的是這類的開源函式庫很多,其實就連上述兩套體體裡也處處可見運用這類公用函式連的踪跡。更有甚者, 很多的AMI功能其實都可先編譯出來, 再事後透過外顯的.ami檔案來將各功能加以組合, 從這觀點來看, 就像是以datasheet/spec來將已做好的AMI模型透過.AMI來自動產出一樣。

最近其它先進所發表的一些文章, 及以諸如我等較小EDA公司所訂出的AMI建模方案都是朝這個方向進行, 也因此更能證明這個折衷方案是能得兼由上而下及由下而上兩不同流程優點的一可行方式。

參考文件:

2015 DesignCon paper: [HERE]
2016 IBIS Summit paper: [HERE]
2016 DesignCon paper: [HERE]

IBIS-AMI: 使用場景

IBIS-AMI: 相關角色及使用場景

近年來以SERDES為主的相關介面:諸如PCIe, USB及SATA等早已是無處不在;有別於傳統以Spice為主的時態SI分析, 因為這些界面要求低BER, 所以總是要跑上幾百萬個Bit才能得到較準確的分析結果,所以在分析方法上就不能以傳統的IBIS或Transistor模型等來進行。而為了與業界EDA工具或其它IP來源模型一起運作的相容性考量,其它的行為模型如Verilog-A等也未必適合;在此考量下, IBIS-AMI已成為近年來最通用的SERDES模型格式。在使用及建模程序上, IBIS-AMI都較傳統的IBIS要求更高的技術門檻及更跨領域的相關知識。本貼文就與IBIS-AMI模型相關的幾種角色來做相關議題的討論。分的相關角色有:1.終端AMI模型的使用者, 2.AMI建模工程師及3.供應AMI模型的公司人員等。

以AMI模型使用者的角色言:

這是最常見的使用情況, 究竟大部份的人都只需要知道怎麼用模型就可以了。但做為模型使用者而言, 一般標準程序上在對全設計進行相對冗長的仿真分析前, 都應先對所要使用的模型做相關的測試及審核..以免垃圾進垃圾出。以傳統IBIS為例,較謹慎的用戶不會全然相信一般常以模型名字來標出的阻抗值(尤其是用的不是TYP corner時), 所以都應以軟體、手算DC準位的相關阻抗並連以簡單的測試電路(test fixture)進行快速的時態仿真以確認手上的IBIS模型無誤。

以下圖為例,我們用BPro的Performance Measurement 對相關的IBIS模型量測準態阻抗值,發現其與模型檔名所標示值相差不多,便可繼續進行下一步分析。實務上我們常發現的是MIN, MAX corner與TYP值相差甚多, 故在做SI分析時就得把阻抗的不匹配列如考量之一。

同樣的想法套用到AMI的模型上就有更多一點的考量。首先AMI模型是二位元機器檔(非本文檔), 所以外人無法一窺究竟…非得透過其它程式才行;其次此二位元檔不僅是和作業系統windows/linux有關, 也和系統的位元(32/64bit)有關,AMI模型無法在不相同的程式上運作。雖說模型檔案一般也會有相關位元的資訊(比如說TX_Win32.dll), 但最好仍是先做相關測試。其次, AMI應用程式界面(API)中所規定必需包括的函式隨著模型用法(statistical or bit-by-bit)及介面Spec的版本也有所不同, 所以使用上也需先進行了解。最後, 即便是至今最新版的IBIS golden checker也只查驗.ami檔案及AMI必含程序的有無來做檢測, 並不進一步地對這些程序加以驅動並查看其輸入、輸出結果, 換句話說, 模型用戶至今為止仍必需透過第三方(常是較複雜且昂貴)的EDA軟體才能對模型做進一步的檢測。凡此種種皆拉高了初步測試的門檻。

業界常用的仿真軟體HSpice有內帶一簡單的AMICheck程式,唯其需要正式版的license才能跑。EDA公司諸如SiSoft及Cadence也都有提供類似的程式, 但我們在使用過後仍覺得有更多改進的空間, 更不用說它們仍需要用戶在不同系統及位元上先做編譯的工作(因為是以DesignKit的型式提供), 所以在實務上,要直接用這些程式仍有多不便之處。

為此, 本司開發了免費的SPISimAMI程式並供業界下載使用(毋需註冊或License),為免為德不卒,我們也已在不同系統及位元上編譯好以便可直接呼叫使用。這個程式會針對用戶提供的.ami, .dll(s)/.so(s)做下列的檢測:

  • 若呼叫的程式與模型系統及位元不符, 比如說用Win64版叫Win32的AMI模型, 則會顯示錯誤資訊。
  • 會針對必有的AMI函式, 如AMI_Init 及 AMI_close做檢測, 其次會依.ami裡GetWave_Exists的必有設定來對AMI_GetWave做檢測, 所謂檢測在此儘是查檢函式在模型裡的有無。至此以上兩點功能大致和最新版的golden checker相同。
  • 程式下一步會對這些檢測出有的函式進行驅動, 驅動模式有二:
    • 用戶可提供自已的輸入波型, 波型格式可以是.tr0, .raw, 或.csv任一, 其中的.raw是開源Berkeley Spice的內定格式。
    • 若無用戶的波型, 程式內建有rise step, fall step及pulse response以對程AMI_Init及AMI_GetWave加以驅動。
  • 驅動結果的輸出波型會直接存成.csv及.raw格式, 用戶可用如excel, 我們所提供免費的SPILite或其它程式來觀圖。

以下顯示此免費程式的使用說明:

舉例而言, 吾人可能拿到了一個TX的AMI模型且被告知其等化(EQ)的位準, 則就可以簡單的利用一串的脈波信號透過此程式輸入並查驗其輸出以確認所提供資訊無誤。

不論用戶所用的軟體及程序為何, 我們要強調的是AMI用戶對AMI模型就如其它的系統模型(IBIS, S-parameter, RLGC model)一樣, 在進行全分析前都應先進行初步的確認, 而這也應列入SI分析標準程序SOP裡的一個步驟。

以AMI建模人員的角色言:

之前提及AMI建模人員需要有跨更多領域的相關知識及經驗。比如說他/她先要知道AMI模型是什麼、格式有那些、運作模式有那兩種等等(關係到AMI_GetWave的有無), 其次要能將SERDES的相關運作及設計以C/C++的語法合乎AMI API的格式來寫出, 當然程式的相關規範如OO(物件導向)及效能也都要考量到。再來這些程式要用編譯器如Visual Studio或gcc/g++等編譯成.dll/.so的格式;這中間的過程當然也包換了數位信號處理DSP的相關技巧如低通濾波器及傅利葉轉換等等。最後, 所建模出來的模型架構應是可輕易維護且延伸性佳。這是因為同一公司不同SERDES間或不同設計版本間的相似性常是很高的, 所以好的設計可避免每次都重起爐灶重頭來過。凡此種種考量可了解對身為一位AMI建模者而言要了解及學習的知識實在很多。也因此就不難想見AMI建模要不就得花大錢外包或得有專職的工程師負責才能確保模型品質及長久的維護。

以資訊人員的想法從下而上的建模例子

在分工甚細的情況下,幾家EDA公司也就為此順勢推出了AMI建模的解決方案,其大都功能強大且各有風騷。它們的強處都在於這兩者在AMI流行之都早已是系統設計裡從上而下(top-down)流程的首選…尤其是在RF設計上, 所以也早就有很多的Library可供選擇使用。再者, 它們也早都有將流程轉成C/C++語法的外掛, 所以只再加一步..將轉出的源碼配合AMI API的要求即是水到渠成。然而, 就如我們下篇會再探討一般,我們也相信一個AMI建模者不應全然使用這些軟體就直接釋出模型給用戶。因為問題可能在模型釋出後才開始發生…試看這些軟體所轉出來的C/C++源碼:

SystemVue常用長度為1的buffer..

隨便把這給一個軟體工程師看他/她可能頭上都會有三條線, 軟體直接轉出的碼不僅維護不易而且也跑不快。至少以上圖所示.. 重覆地new/delete長度為1的buffer大概就足以讓專職軟體人員丟掉工作。就更不用提到什麼延伸性的的考量了。

如前所述, 其實在一個公司內的SERDES設計或不同版本之間其實差異不會太大, 再者一個SERDES裡所常用的功能區塊也大概就是那麼幾種, 則如為長久考量, 一AMI建模者實在是應該下基本功(Bite the bullet)一步一步地把模型架構建起來, 若設計得當的話很多的模組其實重覆使用性都很高。最後,一旦對架構有第一手(而非透過其它軟體)的掌控後就能加上一些其它”特異功能”, 比如說對部份設定加以加密, 容許特定用戶使用不同的模型設定等等, 而所設計出的模型也可參數化並有特定的GUI以便設計組態,甚至是只要編譯一次的AMI檔案而可將所有其它的設定透過.AMI檔案來做功能上的切換。凡此種種考量一旦建製完成,都可視為公司一IP及無形的資產。

最後值得一提的是在建模過程中將無可避免的需用編譯器來對開發中的模型進行除錯及測試, 則上述的SPISimAMI程式也可在此時派上用場。AMI模型是.dll/.so檔而無法直接執行,再者不論是仿真器或如SPISimAMI, AMICheck這類的驅動程式都需負責讀入並解析.ami檔案以便將相關參數再傳入給模型本身。所以若無這種輕巧的驅動程式的話,建模人員就得利用全仿真器(且得佔一個License)才能對手上的AMI模型讀入驅動且除錯。

以發佈AMI模型的公司角色言:

對一發佈AMI模型的公司,其所釋出的模型不僅代表產品的原有矽智財,其對此模型的效能報告及支援也間接影響公司的聲譽;一般在有AMI模型後最常見的問題是:用戶所用的仿真器或軟體和公司內部所用的不同, 則結果跑出來可能也就不一樣或甚至有錯,那要如何才能迅速有效地對這模型提供支援呢?

如果到各大有釋出AMI軟體的大公司相關網頁看(比如Xilinx), 都可發現他們都強調結果是在某特定軟體上測試, 言下之意,用戶若使用不同軟體則後果自負!?

我們認為模型發佈者及使用者之間的共同立足點(以交換資料)應是以最簡易形式為之, 這樣子就沒有在模型及使用工具上對問題互踢皮球的可能;舉例而言, 用戶可將模型輸入及輸出端的波形轉出來,再加上使用的參數檔.ami,應就足以做為提供給模型發佈商的測試資料(Test Case)供除錯用。關於這個應用,除了之前所提及SPISimAMI之類的驅動程式可供使用外, 可再配合如Proxy class等的設計(下下篇貼文會探討)就可使輸入輸出至某一AMI模型的資料達到透明化的結果,而這也就利於供應商對這模型的支援及維護。

差分IBIS建模流程:研發

流程構思:

我們設計差分放大器的建模流程時,考慮的是與單端點放大器建模流程的一致性及為因應兩者間不同處所加入的彈性。以前者而言,差分及單端放大器所需走的步驟有很多是相同的︔這是因為差分模型中有一大部份所獨立出來的便是單端放大器(請見上一則貼文)、故自需為其依單端模式建模。對彈性而言,主要的考慮是差分建模過程中,對於靜態和靜態差分電流的建模容或有以人為做取捨的空間。在這篇文章裡,我們就再就中間的細節做更多的探討,並看看在我們的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及3D視覺化資料的能力以變對所需要的模型設定很快地有初步的決定。

比較麻煩的是若資料呈現出的是如上圖般的不規則曲面,則需再透過如為"反應曲面"來計算或是以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所示:

若建模者可事先利用3D視覺化了的資料預先決定只要用簡單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建模流程:概觀

我們之前已寫過一些有關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裡。

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

上週在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)的方式來加入對這些元件的原生支援。

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

備註:

對此貼文有興趣的讀者或可繼續在 [Part 1] 得到更多相關資訊,並至 [Free Web App] 使用此一模型轉換流程的免費工具。

這篇貼文將探討如何把IBIS資料裡的瞬態資料Waveform轉出以便在免費Spice裡仿真;「前一篇貼文」討論的是我們開發此流程的動機及如何轉出以IBIS裡Ramp資料為主的Spice模型。

由IBIS裡的Waveform資訊做IBIS to Spice的模型轉出:

在使用IBIS模型時,一般我們都會利用其Waveform資料;故若欲由IBIS原始資料產出一相容於免費Spice的模型且得到與一般使用上近似的結果,則此Spice模型也必需能利用到瞬態Waveform的資料。

在IBIS模型裡,不論是輸出點的電壓或電流,在瞬態都是點對點相對應且和時間有關的。比如說在IBIS V3.2或更新的模型裡,一般都會含有兩個或更多個在不同負載情況下所得的Waveform表格;即便是只有一個表格,一般在仿真器內部也可透過Ramp資料來產生另一組時序的資料。而在IBIS V5.1或更新的模型裡,也含有如[ISSO] 及[Composite Current]等的電流表格。後者的電流資料和前述的電壓表格雖在模型裡放在不同的地方,但在時序上是每點都相對應的。在此所說的“時序”並不是指仿真過程中每一點的絕對時間,而是指在輸入切換信後延續至今的相對應時間(Elapsed time)。在原理上,一般會產生兩組切換係數Ku(t)與Kd(t);分別對應於PU及PD電流分支。其作用在於產生一漸漸“開”或“關”的機制而使信號漸達穩態。這兩組係是是由兩組Waveform資料在不同時間點所算出。當模型接上相同負載時,它應會產生如Waveform 及Composite Current表單裡所列出完全一樣的電壓及電流響應。而當負載不同時,它們也會相對應地縮放輸出的強度。關於這些運作細節,請見我們之前的貼文

一旦我們能算出這輸入後才開始的相對時間值(Elapsed time),我們就可透過許多有關論文及規格所示地IBIS結構透過ASRC元件以Spice格式組出來。也就是說,當我們完成欲將IBIS裡Waveform資料轉出Spice模型後,在原理圖及表單上所顯現的便是如下所示的原始IBIS建構區塊組合:

要達到這個目標,也就是說要組出如原始IBIS區塊一樣的Spice模型,有下列問題先需被克服:

  • 在仿真過程中算出信號切換後已延續至今的時間;
  • 由兩組Waveform算出Ku及Kd的切換係數;
  • 將所有區塊組合起來且如IBIS原始構造般為仿真器所使用。

以下我們就將對這些問題提供解決的方案。

在仿真過程中算出信號切換後已延續至今的時間:

以NgSpice為例,我們可在免費Spice裡的ASRC (Arbitrary SouRCe,即任意源元件)使用函式;而函式的係數之一可以是已開始仿真後至今的絕對時間”time”:

藉由這個時間變數及一些附加元件,我們可以下列步驟算出信號切換後的相對時間:

  1. 首先,我們要能分別出信號的上升(0->1)及下降(1->0)緣,這是因為Ku及Kd在在高態及低態中是不同的。在將緩沖器輸入端的類比信號轉成極短上升/下降時間的數位信號後,我們可用一階微分dv/dt來分出上升下降緣。在此,我們利用一傳輸線來達成微分的目的。其它的選擇包括用Laplace函式在控制源中達成相似的延遲效應。傳輸線的長度是仿真的一個TimeStep且在遠端連有和線相同之特性阻抗以免造成反射。在每一瞬態仿真的TimeStep中,我們可算出傳輸線遠近兩端、在不同時步所造成的電壓差,這便是一階微分。由下圖可見,不同的上升下降緣的信號已可透過此方法加以分別。
  2. 其次,我們在這一階微分後的短暫脈衝乘上ASRC所支援的時間參數,其結果是漸次上升的脈衝。再利用另一傳輸線做為信號閂,我們可做出如“取樣與保持”的效果。做法是在傳輸線的近端輸入遠端當時的信號,因為現在輸入的近端信號在一時步之後(Time Step)也將再度達到遠端,故在循環不息下此一電壓可被保持。當然傳輸線的長度需與仿真中所用的一時步相同且在遠端需連有和線特性阻抗相同的負載以免信號反射。在下圖的上半部中,紅色信號是“取樣與保持”後的結果,當我們以另一時間參數(黃色信號)與紅色信號相減,其結果便是如下半部的信號。。。也就是我們想要得到的結果。這組最終信號在每次輸入信號切換時就會歸零重新計算,而其斜率是一(為橫縱軸都是時間)。要再說明的是因為免費Spice會捨去極小的值,而我們在仿真時的時步大多是1ps即1E-12左右的大小,故欲免其被仿真器所捨去,我們需將其乘上一放大值。此一放大值在下面計算Ku及Kd時需一併列入考慮。

由兩組Waveform算出Ku及Kd的切換係數:

解決算出信號切換後的延續時間之後,我們便可接著算出Ku及Kd以便運用此時間值。這部分的資料已非常多,於下簡列兩則供參考。不論是透過原始IBIS裡的Waveform資料做計算來導出此二切換參數(參考一)抑或是透過其它仿真器來量測此參數(參考二)都可得出結果:

  1. Extraction of Transient Behavioral Model of Digital I/O Buffers from IBIS, Peivand Tehrani et. al, 1996 Electronic Components and Technology Conference.
  2. General K-table Extraction w/ Spice, Bob Ross, IBIS Summit, DesignCon 2015

一般而言,Ku及Kd是兩個未知數,故我們需要有兩組Waveform資料才能在每時間點對其估值。這部分的計算是在離線情況下事先算好的,然後再將結果放在轉出的Spice模型裡。實做的部份四組IV表格參數,即PU/PD/PC/GC均以ASRC透過每兩點間算出的PWL線性直線來做電流輸出;唯因PU/PD有切換系數的關係,它們有較PC/GC更多一點的輸入,即下面的NKUX/NKDX:

NKUX/NKDX的值即是事先算好的KU/KD值,端點1及2即是在第一步驟裡算出的信號切換後的延續時間:

也就是說,我們用這延續時間t來算出相對應的切換系數,而後再乘以原始的PU/PD分支電流。下面的端點5即含有切換係數值:

將所有區塊組合起來且如IBIS原始構造般為仿真器所使用:

有了這些區塊之後,雖然要透過Spice格式將其連起來形成表單是一簡單的工作,但實際操作之後,我們卻發現以此模型仿真的結果在輸入信號切換始末的時間點在輸出端都有很大的雜訊而使得模型無法使用。

細究之下,發現魔鬼藏在細節裡。。。一如我們之前貼文所述,在信號切換的過程中Ku/Kd切換係數也有一“交接”的動作:

也就是說,在低入高態的過程中,PU/PD使用的是上升緣的切換係數,而一旦信號由高轉入低態,它們則改用下降緣的切換係數;這之間一點點的時間誤差,即應當開始使用新係數第一時間點的數值時,若仍在使用上一係數的最後時間點,則雜訊便會產生而使得產出之模型無法使用。在詳細觀察每一信號間的切換順序之後,我們最終能做出一過濾的語法、運用在相同的ASRC裡而得到理想的效果。與商用仿真器對相同IBIS及負載的結果相較之下如下所示:

由圖可見:不論是在輸出端點的電壓、抑或是供電源電流的使用,兩者均極為近似。也就是說,以我們流程所轉出的Spice模型也可供做SSN雜訊分析。兩者信號間些許的遲延並不影響相較的結果,因為此一遲延是一常數且對所有Cycle均相同,故在信號量測或最終眼圖上並不會有任何影響。

在仿真速度上,因為我們加入了兩個長度僅為一時步的傳輸線來做一階微分及取樣保持電路,其亦限制了在實際仿真時的速度,故相較於能直接使用原始IBIS的商用仿真器之下,速度慢得多。當用在佈線後網表的仿真上,變慢的程度則不顯得那麼嚴重。這是因為在佈線後的網表中, 也含有許多傳輸線元件,其中延遲最短者亦一視同仁地對所有仿真器造成時步取用上的限制,當這限制不比一時步長許多時,則由轉出Spice模型所形成的時步限制則顯得更能被接受。

另外一點值得一提的是:以上所示雖只談到電壓Waveform波形的運用,對以IBIS V5.1以上、含Composite Current電源資料的部份其運作情形也是相同的:另一組縮放係數需由ISSO  PU/PD資料事先被計算,而後乘上原始的Composite Current電流再以ASRC的元件以相同的Elapsed Time參數自供電端拉出額外的電流;相同的Elapse Time 分在電壓及電源ASRC中被使用以便達成點對點之間相同的對應關係。

藉由此開發完成的Ibis to Spice轉換流程, 我們可依實際運用需要而將原IBIS模型裡的Ramp或Waveform資料轉出與免費Spice仿真器相容的格式而做分析之用;這個流程已如下所示地內建於我們的SPIBPro模組之中:

 

這篇貼文係為於DesignCon 2016同時舉行之Ibis Summit所準備;我們在這會中宣讀並展示此研究結果。讀者可於下參閱下載相關簡報範例,或至IBIS官網直接下載。

會中所宣讀簡報: [按此] 於外部開啟

相關範例: [請按此下載]

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

備註:

對此貼文有興趣的讀者或可繼續在 [Part 2] 得到更多相關資訊,並至 [Free Web App] 使用此一模型轉換流程的免費工具。

IBIS to Spice:

系統完整性分析中,大部份的建模流程都專注於由原始設計(Transistor)透過Spice網表格式轉成為IBIS模型。但基於以下數點的考量,我們也常發現相反的建模流程、即從IBIS轉成相對應Spice的函式庫格式 (Subckt library)亦有其存在的價值:

  • 支援開源或免費的仿真器: 網上有數款開源或免費的Spice仿真器, 如 Berkeley 3f5, eispice, ngspice, LTspice 等等。這些仿真器多將重點放在晶片上的BSIM模型或廠家所出產的元件, 如LTSpice的穩壓器(Voltage Regulator)等等;當用在系統分析上時,雖然它們對傳輸線大多也都有相當程度的支援,但對於輸出入用的緩沖器(常以IBIS模型資料形式出線)的支援則是付之闕如。在沒有原始設計的Transistor網表、又不能使用相對應的IBIS模型情況下,這些免費的仿真器就只能束之高閣了。當然若有足夠的經驗及能力,吾人也可編程而直接在這些開源軟體裡加入對IBIS等的直接支援, 但這過程是需要相當時日才能完成的。比起若能直接透過某種流程而能將現有IBIS資料轉成這些Spice也能直接使用的模型而言,後者的所需的工程便小得多。而且若這流程是建於Spice之外,則當工程師有需要快速地做些完整性仿真時,便可運用手上任何一款的相容仿真器而不用另外使用特別編譯的軟體。
  • 讓模型供應商能提供公用的參考資料:IBIS本身雖是業界公用的格式,但其在仿真器內的實際體現則依不同廠家而有不同。在理想情況下,不同的仿真器對同一IBIS模型的運作應會生成近似的結果。為了達成這個目標,IBIS制定委員會也定出了”Golden Waveform”的資料格式以便模型使用者能對所用的仿真器的精確性能有所初步的檢定。實際上,這個”Golden Waveform”並非強制性地需在IBIS模型內提供而許多模型也都對此付之闕如;故而有些模型供應商 、如美光半導體,便轉而提供編碼過的Hspice原始設計網表以做為仿真的參考。如此一來,它的模型使用者便必需要有Hspice才能仿真編碼過的設計。我們認為若能在現有IBIS模型之外,更提供一未編碼Spice網表而且它可透過人人可免費得到的開源Spice來仿真進而得到與IBIS極近似的結果,反而更能體現IBIS在業界是公用格式的精神。
  • 外顯地實現IBIS的運作原理及流程更具教育性及參考價值:網上隨便一找都可以發現很多談到IBIS內部運作原體的論文及簡報。這些內容或可以供大致了解模型運作的過程所需,但魔鬼多藏在細節理,模型實際上多以C/C++編程、實現且運作於仿真器內而非外人所知;我們認為, 若能將這些原理以外顯的方式實際以Spice的格式呈現出來,進而能透過仿真而產出和其它商用軟體極近似的結果,則更富教育意義且具參考價值。
  • 開發流程的考量:仿真器是系統整合分析流程裡重要而不可或缺的一環 (場解器亦如是);做為一分析工具供應商,我們有以下數種選擇以便能在開發的流程裡有仿真器可做運用:1.與市面上已具規模的仿真器供應商合作而要求我們的客戶都必需要有一分License; 2.內部從無到有自行研發; 3.使用現有的開源且有聲望的仿真器。上述選項各有其優缺點且不互斥。對於一新創公司如我們而言,需要在有限的時間及資源內為客戶提供最高CP值的工具,則第三個選項、即使用開源版本並再加以改良、便成為最具吸引力的選擇。

市面上已有數家公司提供Ibis2Spice的流程。它們之中免費的版本多提供到IBIS Ver 2.1的轉換支援。即便是付費的版本也只支援到Ver 3.2。再者,它們所轉出的Spice模型多不能直接在開源Spice上所使用。我們開發的目標是要能支援到Ver 5.1的電流資訊、亦即[ISSO] 及 [Composite Current]等資料的運用以能做SSN的雜訊分析。在含此文第二部分的這兩篇貼文裡,我們將對本公司所開發的Ibis to Spice流程做一簡介。首先會談及的是如何運用IBIS裡的Ramp Rate來轉換出相對應的Spice模型,而後要談及的是更精確的、即運用Waveform data來建立模型。兩者我們都會佐以和其它商用仿真器對同一IBIS模型仿真的結果來證明此流程的可行及結果的精確性。

流程開發的目標:

  • 轉出的模型能直接在開源仿真器、 如Spice3f5 及NgSpice上運作
  • 支援電壓部份的Waveform data (Ver 3.2 andup)及電流部份的Composite current (Ver 5.1  and up)
  • 能與其它的業界所常用仿真器產生極近似的結果。

由IBIS裡的RAMP資訊做IBIS to Spice的模型轉出:

首先我們來看一下現有以RAMP為主的Spice模型轉換,因市面上其它工具所轉出的模型不能在免費Spice上直接使用,在我們的免費工具SPILite裡,我們也已加入類似的功能以便能直接使用NgSpice。這部份的流程主要是將原IBIS模型裡的RAMP資料取出並用於瞬態仿真時。靜態電流部份、即PowerClamp, GroundClamp, PullUp及PullDown的資料則是用免費Spice裡支援的ASRC有源元件來實現。這部份在下一貼裡所將提及的:用IBIS裡的Waveform來轉出Spice模型裡,將做更多的應用。

在網上搜尋Ibis to spice則會找出一篇貼文:IBIS to Spice Translation (part 1), 在此文中,原作者討論了市面上其它工具做Spice模型轉出的工作原理、及他所試圖改進的設計及結果。他也提供了一Awk程序以便能將原始Spice模型在當時的免費Spice裡使用。由於這篇貼文是十多年前所寫,當時很多的觀察在今日均已不再適用。比如說:現今公版的NgSpice已可直接讀入如X+-3.2的語法而毋需再將其轉成X-3.2, 故其Awk程序似已無用武之地。無疑的,由於文中所提之商用工具最後更新似是在1998年,原理圖至今仍未做更動,故就研究其運作原理而言,原貼文還是有其參考價值。

上述貼文的第二部份是如何將利用Ramp資料來運作的原理圖。在網上要找到原文恐怕比第一部份難得多,我便將其重貼於下以省讀者的時間:

原理圖中的主要原件是四個靜態電流元件,即XPWRCLAMP, XGNDCLAMP, XPULLUP 與 XPULLDOWN, 它們是利用Spice裡的ASRC(Arbitrary SouRCe, 即任意源元件)來實現。在Spice的使用手冊裡,我們可看到其語法及功能:

由於Power Clamp(PC)及Ground Clamp(GC)是屬於ESD電路的一部份而始終是有在作用的,故其資料可直接被使用。在實作上是將IBIS裡的IV對應表先轉成每兩點間的線性直線(Piecewise Linear)方程而後輸出電流。以PC為例, 由下圖中可看出端點1,2間的電壓被拿來做查表內插而將算出的電流由端點3,4間來供應。

對於Pull up (PU)及Pull down (PD)分支而言,由於它們是在輸入信號切切換後才漸漸開或關的,故在以原理圖中是以在左上部份的C1及RB3所供應的RC充放電常數來完成此開或關的目的。在瞬態仿真中,此RC參數先被RAMP的值設定於分母的部份, 而後將乘上由PU等所提供的原始值,最後再以G控制源元件(VCCS,電壓控制電流源)來將電流輸出。

在原貼文裡,原作者也提及他曾試著直接以其它方式來取代以此RC來做PU/PD電流切換的方式但效果不彰。我們認為其中可能的原因是因為PU/PD供應電流值是有瞬態時間因素的,即它們不是馬上就如PC或GC般全開或全關的,故若少了這“漸漸打開/關閉”的運作,則輸出電壓會很不平滑而可能造成仿真不收歛。而且就算收歛,結果也不會準確。也就是說,一般輸出緩沖器裡場效體(MOSFET)通道裡的載子有其一定的速度,故其開或關的時序不會在瞬間完成。

透過這種由RC方式的開關模擬,來仿真由IBIS轉出的Spice模型,再與其它商用仿真器對同一IBIS模型在相同負載情況下仿真結果相比較,我們可看出其結果算是相當接近的。但這相近僅止於PAD或PIN點的電壓部份。當測量其對供應電壓源所使用的電流,則可發現兩者相去甚遠。也就是說:這種Spice模型只能做理想供壓情況下的信號完整性分析而不能拿來將SSN列入考量。其次,上升/下降的曲線會呈現出如RC充放電般的曲線而非直線性。對於仿真速度而言,因為這種實作的設計相對簡單,故可很快地完成仿真。。與直接使用IBIS的商用仿真器相較之下並不會慢太多。最後要再說明的是:不像IBIS模型裡各種Typ/Min/Max的資料都在同一表格內;當要將某一IBIS裡的模型轉出做Spice仿真時,欲使用之不同的Typ/Min/Max Corner均需分別地各自先被做轉換。

這篇貼文係為於DesignCon 2016同時舉行之Ibis Summit所準備;我們在這會中宣讀並展示此研究結果。讀者請繼續參閱「之二」之貼文並可在那下載相關文檔及範例。

IBIS模型: IBIS AMI之建模

截至目前,我們所談有關緩沖器的模型均侷限於其類比前端、直接連到通信渠道的部份;這篇文章我們則將談談其前級、有關TX/RX等化電路部份之建模。這些設計在業界現常以IBIS AMI (以下簡稱AMI, 即”Algorithmic Modeling Interface”理論建模界面之縮寫)來實現。
IBIS AMI模型範圍:
IBISAMI_Block

上圖所示為一端自最首至最末的通信渠道;其中綠色的部份佔渠道的大部份,是以如傳輸線模形所表示的PCB繞線、及用S參數所表示的導孔或連接器等組成的被動渠道部份;其兩端、以粉紅色區塊表示的部份即以IBIS表示的類比前端;這些前端部份直接与渠道連接;除這兩者之外,在TX的最前級、及RX的最後面則是各種等化電路。這些電路現常以AMI模型來描述。之前所述的幾個部份組合在一起,則可用以描述通信渠道整體並加以仿真或分析。由此可見,AMI實則是和IBIS的部份一起運作以提供等化模型的(也就是說,若無等化電路,則無使用AMI模型的需要)。實務上來說,在一會與AMI共同運作的IBIS模型裡,會看到如下圖所示之數行描述,即會指向所使用的幾個AMI模型成分:含各類模型參數、以純文字檔表示的.ami檔案、編譯出來的二進位檔.dll(on windows)或.so(on linux),以及編譯此二進位檔所使用的編譯環境等等。

IBISAMI_Include
為什麼需要使用AMI:

對於系統整合性的分析,若欲為結果做一量化的描述,一般最常用的是眼圖裡的眼高及眼寬、以及依此所能推算出來的位元誤率(Bit Error Rate, or BER)或bath tub curve,要能形成眼圖,則需有很多的位元信號響應在時域上圍著週期中心重疊起來。在分析完整的通信渠道時,不論是以原Transistor之緩沖器設計抑或是其IBIS模型,在時域上要仿真數以百萬計的位元信號(才能得到想要的低BER)都是要需時甚久的。即便如此,得到的BER數據也極其有限而常需要以外插的方式來推算實際值。除了以仿真為手段為,另一種能得到波形以形成眼圖的方式是直接合成。。速度遠比進行仿真快得多。IBIS模型因其設計上的限制並無法讓我們如此做。除了能在極短時間內算出許多位元波形的速率考量外,下列數者也是發展AMI的原因:

  • 業界標準:純欲以高速在短時間內得到很多位元波形的目的而言,也是有其它商家特有的高階語言(如Matlab)可滿足這需求的;但如此一來建模工程師便等同限制了使用其模形客戶的分析工具;除此之外,這樣建出的模型也無法用其它仿真器來加以驗證。為了能讓IC及EDA業者均有能交換使用的模型標準,如AMI的模型規格實有其必要。
  • 分析速率:如之前所述,需要一能在短時間內得到數以百萬計位元響應的方法及模型。
  • 擴充彈性:其實在AMI之前,IBIS委員會也曾經用Bus Hold或Driver Schedule等的關鍵字來試圖在IBIS內加入等化器的有關描述。甚至在IBIS V4.0中,也有用以Verilog-A為代表的高階語言來擴充以關鍵字為主的IBIS模型的彈性。但執行起來,前述兩關鍵字的使用極其僵化,而Verilog-A又是直譯的語言,遠比不上用C/C++來編譯的語言彈性更高且能保護智財,因而有AMI之倡議。
  • 智財保護:等化器設計電路常是IC公司極欲保護的智財,故一以編譯(編來的檔案是二進位檔)為主、不易被反向導出原設計的建模即有存在的必要。

 

什麼是IBIS AMI:

在談過AMI的模型範圍及其需求背景之後,我們來談談倒底什麼是AMI及其組成部份:

  • 對IBIS AMI建模者的角度而言: IBIS AMI即三個您需提供實際執行的函式定義表頭 (header .h file),這三個函式即Init, GetWave 及Close:
    • AMI_Init: 這個函式必需有實際執行碼,它的功能就好比物件導向語言裡Constructor的角色。若輸入AMI模型的是長串的位元輸入,則AMI規格允許它們被分成好幾小段分別被作為輸入並執行。也就是說,程式碼裡有很多資料結構可能重覆地(在不同的位元輸入段落)裡被使用,故Init函式提供一可在一開始之初便初始化這些資料結構的地方。其次,若通信渠道為線性且非時變(Linear, Time-Invariant or LTI),則在Init函式裡便可對仿真器所提供的渠道突波響應(Impulse Response)做直接的計算而可略過GetWave函式的實際執行。
    • AMI_Close: 這個函式必需有實際執行碼,它的功能就好比物件導向語言裡Destructor的角色。其功能是在仿真結束之際,為之前已分配的資料結構之記憶空間釋放回底層的作業系統。
    • AMI_GetWave: 這個函式的執行可有可無。若含EQ在內的通信渠道為非線性或具時變性,則將無法透這一個突變響應便用波形疊加(Superposition)的方式直接合成並算出BER,在這種情況下,則必需執行GetWave,一長串的位元信號會依序或分段地傳進模型,而後GetWave便一段段地將其做計算並輸出結果波形,仿真器最後才將這些波形再組合起來以組成時域波形並進行疊合(Folding)以產生眼圖。
  • 對IBIS AMI使用者的角度而言:IBIS AMI是由以下三個檔案組成的模型:
      • IBIS file: 這即類比前端的部份,且需有一”[Algorithmic Model]”的描述以指向下面兩個檔案, 即.ami及.dll/.so檔。
      • .ami file: 這是一純文字敍述的參數檔案。建模者將模形參數外顯供用戶調整的部份均在此處。例如下圖中即示出一含有四個tap的等化器設定;可以看到各個tap的比重參數均以數字實際標示出來,且用戶也可加以更改。除此之外,其它的模型參數、諸如是否有GetWave函式的支持等等也包括在此檔。仿真器一旦透過最上層的IBIS檔案讀到這.ami檔後,其便知將如何跟最底層的二位元檔(.so/.dll)進行資料交換。

    IBISAMI_AMIParam

    • .dll/.so file:這即編譯出來的檔案,要注意的是這兩者也跟用戶作業系統是32或64位元有關。若您是使用64位元的作業系統,則也必需要用64位元的.dll或.so檔案才能透過仿真器進行分析。

IBIS AMI的使用場景:

IBIS AMI的建模者無法預見其建出的模型如何被使用,然而模型本身便限制了其適用的場景。AMI的使用場景有分為Statistical及Empirical兩種模式;若GetWave函式沒有在.dll/.so裡支持的話,則這個模型將只能透過Statistical模式運作。也就是說:通信渠道將假設為線性非時變,一個突波響應即可用來導出所有的BER。相較之下,一個有GetWave函式支持的AMI模型在Statistical及Empirical兩個模式裡都可被使用而不一定要有渠道是線性且非時變的假設。下圖簡示了兩模式運作的不同:

IBISAMI_Work

 

  • Statistical flow: 在此模式下,渠道為線性且非時變,故可用一個突波響應來以superposition的方式合成數個或更多的位元的真實響應。也就是說,仿真器提供被動渠道部份的突波後,TX 及RX的模型即可在Init裡將自身的轉換函式與其做捲積(convolution)來做如peak distortion analysis般的計算來得到BER。
  • Empirical flow: 在這模式下,渠道為時變或非線性,仿真器會產生長串的位元序列並與被動渠道做捲積,其結果會再被分成數小段,每一段會與TX 或RX的GetWave函式做運算,最終結果再由仿真器重組成長串時域波形而算出眼圖或BER。

在實務上,因為TX, RX的模型可能由不同的IC廠家所提供,故不同組合下會有更多運作上的限制。讀者可參閱IBIS規格文件裡第十章的部份來了解更多的細節。

這篇文章簡述了IBIS AMI模型的構成及使用;記得之前談到IBIS建模時,我們提到其優點之一是工程師毋需了解真實設計內部的細節也可進行建模。這項優點在AMI上可能得大打折扣,首先EQ內部的參數通常很多,建模者需要更多的了解或與原設計師更多的溝通才能決定有那些參數可以外顯,其次,這些等化器的設計需透過如數位信號處理之編程般才能以C/C++語言以符合IBIS AMI表頭規格的方式來進行編譯,除了編譯器的操作本身需要一些專業外,如何對建出的模型進行驗證也是一項挑戰。所以在業界一般是由像我們SPISim使必信科技般:對SI及編程領域都同時有專業的商家來和IC廠家一同合作來完成建模。這中間還有很多細節值得深入討論,我們將來有機會回頭再談。

IBIS模型: IBIS模型的效能參數

在數個或更多的IBIS模型中,假設它們都通過了Golden Parser的驗證而且運作速度也合乎需求,則吾人要如何才能判斷其中何者較其它更適合我們高速設計上的需求呢?在這篇文章中,我們將試圖定義出一些IBIS模型的效能參數以供參考選擇之用。
IbisRttROn

 

之前的文章已數度談及IBIS模型的基本架構。。。再示於上圖;基本上是由上拉(PU)、下拉(PD)電路決定其穩態電壓及輸出阻抗。而靜電保護電路ESD則由一般在反向偏壓的箝位電路(PC), (GC)所組成。上拉電路能多快地由斷路轉成通路、同時下拉電路由通路變成斷路,則決定了此緩沖器上升時的瞬態表現。下降波形的形成也是同樣一的道理、只是開關的極性方向相反。由於PC, GC電路操作在反向偏壓區間,其漏電電流一般很小。

 

RttTerm

 

另一種常見的狀況則如上圖所示。。。一般是用在動態記憶體裡。這裡因為有晶片上的阻斷電路(On die termination)…由兩個電阻組成一分壓器(voltage divider), 所以即便是緩沖器是在高阻抗無輸出的狀態之下,由分壓器所導致的輸入電流也遠比之前所提的漏電電流來得大而不能加以忽略。

由這兩種常見的操作情況,吾人可合理地將一緩沖器在輸出阻抗及其瞬態反應(以信號斜率及上升、下降需時來表示)的相關參數用做比較用的效能參數。再詳述於下:

IBIS輸出阻抗:

若緩沖器的輸出阻抗和立即接到其輸出端點元件的輸入阻抗不相匹配,則信號在一開始之初就會形成相當的反射而來回振盪;一般而言,緩沖器的輸出即是封裝部份穿過各腳位的拉出傳輸線(特性阻抗一般是50歐姆);而解決這種不能匹配的問題一般則是再加上一個串聯的電阻以便使總阻抗能達到50歐姆左右。下圖為一輸出不匹配而造成巨大振盪的例子:
ZMismatch

 

由於IBIS緩沖器有上拉及下拉的電路, 兩者的輸出阻抗在參考電壓(一般是高位電壓的一半)間的輸出阻抗未必一樣;工程師一般得取這兩者的中間值來做為還要再加上多少串聯電阻的依據。

IBIS的時域參數:

為能有較佳的信號整合性,一般來說我們需要用的緩沖器輸出的信號速度只要夠快就好。。在夠快的條件下愈快其實愈不好。為說明這原因,我們可以常見的對一方波解構的各個諧波為例,如下所示:最上面的是一純Sin的波形、其頻率和方波同(稱基本頻率或基頻);其下則是此Sin及其二倍頻的組合,依此類推;我們可以看到:隨著更高頻Sin Wave的加入,所組合出來的波形就愈來愈像一方波。也就是說:一個信號上升下降速度很快、趨近無窮快、的方波,是由很豐富的頻率信號所組成。
Harmonics

 

又:不同頻率的信號在同一介質中的傳播速度並不相同,故會造成信號的失真。這種傳輸速度隨頻率而異的現象一般稱作“色散”;若一信號速度慢又和緩(在夠快了的前題下,相較於更像方波的快速上升/下降),則其色散的情況會較輕微而傳送的速度也就較不易為高頻部份所影響而形成信號失真。

效能參數:

綜上所述,吾人可建議並定出下列的效能參數以作為IBIS緩沖器模形間的比較之用:

  • PVT: 也就是快/中/慢,供應電壓及環境溫度等的資料。這些值都已在模型裡清楚定義。使用這模形的工程師必需確保應用範圍在這些值的區間內,則仿真出來的模形效能才具有實際上的意義;
  • C_Comp: 也是已在模形裡定義的,總結連到pad的電容負載;
  • Z_PU: 即上拉電路在參考電壓值時的輸出阻抗;
  • Z_PD: 即下拉電路在參考電壓值時的輸出阻抗;
  • Z_PU_MM in %: 即上拉電路在距參考電壓值之下及之下相同的距離(比如說100mv)時輸出阻抗的變化程度;這可視為阻抗線性變化程度的參考;
  • Z_PD_MM in %: 即下拉電路在距參考電壓值之下及之下相同的距離(比如說100mv)時輸出阻抗的變化程度;這可視為阻抗線性變化程度的參考;
  • Z_RTT: 當有之前所述的晶片上阻斷電路時(ODT, on-die termination),緩沖器的輸出阻抗;
  • RT: 輸出自 20%~80% 的上升振幅所需時間;
  • FT: 輸出自 20%~80% 的下降振幅所需時間;
  • FREQ: 在不被超頻的情況下此緩沖器可運作的最高速率。

除此之外,有些時候傳播遲延, 即數位信號輸入到一緩沖器到其輸出跨過參考電壓所需的時間Tco, 也被拿來做為參考數據之一。我們認為這其實是沒太大意義的。原因在於同之前的文章所述,為保存大部份的瞬態反應又容許模型在高頻下操作,建模工程師或是使用的仿真器就常會把一開始平穩的穩態波形點所刪除,在這種操作之下,所量得的Tco也就不準了。其次,信號整合性工程師常看的眼圖(eye plot)本身即由一連串的時脈波形相疊而成,不論Tco的真實與否,因其整個波形被順勢位移了,故在眼圖裡並不會看到任何影響。也就是說, Tco實際上不會對眼圖有任何的改變。

由以上所建議的數項性能參數,則吾人可利用如我們SPISim BPro模組裡的功能,將一個或多個IBIS模形裡的性能製出一表總結以供參考選擇緩沖器之用,並能因使用適當的模型而提高系統的信號完整性。

參數模形:

利用這些參數,我們也可更進一步地建出一假設的IBIS模形;抑或是對其中的數個參數進行掃描以產生多個可能的模形進行比較分析。當有了以仿真結果做依據的分析後,建模或完整性工程師便可以此建議晶片上緩沖器設計師應設計出的效能。也就是說:完整性工程師可坐在一個主導的地位來導引緩沖器所應被設計出的效能。現時的緩沖器設計一般有數個腳位可供微調速度及輸出強度之用,有了建議的效能值,晶片設計師便可試著不同的腳位開關組合或甚至是改變場效體通道的寬度來滿足所需。

 

SPISim BPro's Spec. model generation

SPISim BPro 的參數建模流程

我們SPISim使必信技的 BPro 便在此考量之下加入了參數模形產生的功能。這是完全不需要做任何的仿真的。用戶只要填入適當的效能參數,含兩組上升、下降波形表在內的IBIS模形就會即刻產生。用戶也可進一步利用如下所示的手動微調功能來為一些點或波形做改變,這些人工產生的(非由仿真結果產生的)IBIS模形在前期分析及甚致是外部模形的釋出上都有其實際上的用處及意義。

BPro generated spec model will have smooth transitions.

BPro 建出的參數模形均有平順的變化曲線

 

IBIS模型: IBIS模型的除錯及效能調校

我們將在此文談到如何對IBIS模型資料進行除錯及超頻調校;如之前文章所述,IBIS建模程序中首先的驗證程序即是以Golden Parser為模型進行檢查,若模型資料有問題,則一般會看到下列的錯誤訊息:

  • DC mismatch: 即VT及IV穩態資料間相衝突;
  • Non-monotonic data points in I/V curve;
  • Extreme currents in IV data。

我們將在以下為這些錯誤訊息詳做解釋。至於效能調校部份,我們將談談IBIS模型的超頻及其可能衍生的精確性顧慮;為確保您產生的模型可在預定的時脈速度下運作,確保其工作頻率的準確性是很重要的課題。最後,我們也將簡單談談我們使必信科技發展出來的工具裡是如何來克服這些技術上的挑戰。

DC mismatch:
IBIS建模程序中最麻煩的莫過於碰到下面的錯誤訊息:
DCMismatchMsg

當發生這種誤差(mismatch)時,建模者所會看到的是在VT的穩態部份電壓和自原緩沖器設計(Transistor)跑出來的結果位準不同。一般的解決方式是回頭去檢查穩態分析部份(IV:PU/PD/PC/GC)設定偏壓是否正確,而後重新仿真、產生模型後再測一次。最後不得已的手段則是手動地去改資料點,以便能減輕這種誤差的程度至可接受的範圍、或是讓其完全消失。不論何種方式,我們都得先對這個誤差的成因做一了解才不會如瞎子摸象不知從何修起。

VT 波型資料的起迄點均為穩態

VT 波型資料的起迄點均為穩態

VT 波型資料的起迄點均被視為已達穩態;也就是說,不論時間點(橫軸)的變化,這兩點的電壓均不再變化。Golden Parser即取這兩點的值來算出由VT所顯現出的負載電流。

DC mismatch 係起因於IV/VT穩態資訊的不相容

DC mismatch 係起因於IV/VT穩態資訊的不相容

上圖中, 我們在左下方簡單表示了緩沖器的負載情形,輸出電流I取決於端點電壓及其輸出的負載,也就是說,當VT達到穩態時,吾人可由模型裡的負載組合來做下列的試算:

  • I_LoadLine = (V_Pad – V_Fixture) / R_Fixture

其中Fixture部份即測試負載、而PAD即緩沖器的輸出端口。從電路來上來看,當緩沖器輸出為高態時,大部份的電流都是由上拉電路PU所貢獻;下拉電路PD此時可看作是完全地斷路而不提供任何電流的。若我們以V_Pad為值,減去Vcc(因為PU的X值是相對應於Vcc的, 即Vcc relative),則可用PU的IV資料表來找出相對應的輸出電流。然後,由於靜電保護電路PC/GC均在反向偏壓的狀態,我們也可用同樣的方式及值(PC也是Vcc relative)來找出相對應的電流。總結而言,由IV資訊所顯示出的應有的電流輸出即是I_Out=I_PU-I_PC-I_GC;所謂的DC Mismatch即表示這由IV所算出的輸出電流I_Out和由VT資料所算出的應有的負載電流I_LoadLine並不相同。

我們剛剛提到的只是輸出高態的部份,輸出為低態的情況也是一樣,只不過在低態時,上拉電路可視為完全斷路。故大部份的電流都是由下拉電路PD所提供。

由於一個IBIS模型裡可以有好幾組VT表,每個表產生時的測試負載均不相同,所以這個DC Mismatch的問題一旦產生,常是每個VT表的兩個靜態值都會有錯誤而顯得錯誤很多。

由上所述:mismatch的成因在於IV及VT所提供的資料對算出來的輸出電流不相符合,則修正之道即在於改變IV或VT以使再算出來的資料能相符。通當建模者需回頭檢視當初在做穩態仿真時偏壓是否正確,或是在“偽穩態分析”時輸入的電壓是否改變過快而使量得的電流並不真是像穩態時的值。一般來說,VT的瞬態仿真一般是較沒問題的。因為若VT有問題的話,在其仿真結果上就可很直接的發現出錯誤。

 

Non-Monotonic Points in I/V data:

這訊息意謂資料表裡的值為非單調性增加或減少;也就是其一階導數有正負性變化的問題。一般而言這類的警示是可被忽略的。唯有在非單調性增加/減少情況較嚴重時,仿真器會在這部份的範圍有不收歛的可能,因其一階導數(找牛頓解用)之不穩定變化之故。

這些資料表裡的問題點常是在緩沖器的非工作區間,故解決之道之一是也可以用人工的方式去消去一些點或增加一些點使得其看起來更平滑些。要注意的是有些緩沖器的設計在先天上就會有這些非單調性存在。故若使用模型的人對這類的緩沖器有所了解,則事後人為的改變資料反而會使的建出來的模型看起來像是假造的而有精確上的顧慮。

Extreme current in IV data:
ExtremeIError

這類的警示或錯誤訊息常發生在代表靜電保護電路(ESD)的PC/GC資料上。另一種情況是上拉下拉電路的穩態仿真結果不對。因為PC/GC的逆向雷流無所不在,故在建模過程中,當將由PC/GC的電流自PU/PD電流做減去的運算是便使得PU/PD也顯示出了如PC/GC般的崩潰區曲線而形成大電流的通過。

PowerGndClamp

如上所示,一般在正常工作區間,PC/GC兩者都是反向偏壓的。。。在很大的範圍內都是平線且值很小(即漏電電流很小);唯有在崩潰區才有如指數般的電流成長。惟由於IBIS規格中,為將遠端之全反射列入考慮而有的-Vcc ~ 2Vcc掃描區間的要求,故ESD電路便可能在這些很少可能才發生的時候顯出高電流。解決之道一般是在開始進入崩潰區的一伏特後對在那之後的電壓做線性外插。如此一來電流在模型裡將不再是指數性、而是變線性的改變。於此同時當ESD發生作用時也會有足夠的崩潰電流在仿真時保護連接到緩沖器輸出端的電路。

 

超頻(Overclocking):

每一組瞬態的上升/下降時態曲線加起來可表示出此一緩沖器模型運作的最小週期T。而這模型可運作的最高頻率即為此週期的倒數FMax = 1 / T; 也就是說:週期愈短,模型在不被仿真器更改資料的前題下可運作的工作頻率也就愈高。

若在真實運作時(如在通信渠道裡全仿真時),若操作頻率超過了如前所述的FMax, 這個模型便是在被超頻。一個被超頻運作的模型將有精確性及效能一致性上的顅慮產生。
Tolerance上圖中,有很長的一段時間緩沖器的輸出都是在穩態的情況下。若建模時能將這些部分、外加上一些容許範圍、地被移走;則最後留下的VT部份將維時甚短, 這表示雖然大部份的上升/下降時的變化情形仍在建出模型中,但這個新模型將可以更快的頻率來運作。

一般而言,業界裡常用的仿真器都可透過參數來進行如此的調校。問題在於在IBIS規格裡並未對一仿真器應如何消去這些穩態資訊來定義。其結果便是兩家仿真器對同一模型在超頻時所產生的結果可能不同。作為一個建模工程師,您不應對將有可能使用您產生模型的用戶為他們做仿真器使用上的限制。所以較理想之道應是您在建模之初便能將這些穩態資料點適做處理,並在模型表頭的部分明列這模形可操作的最高工作頻率。

MIN曲線有很長的時間延遲

MIN曲線有很長的時間延遲

上面的圖表則列出了另一種可能形成超頻的原因。圖中MIN曲線的延遲遠比其它兩者(TYP/MAX)來得多。由於IBIS規格裡要求三者在模型裡均由同一橫行、即時間點、來表示;上面的圖形將可能形成超長的MIN曲線的起始穩態值而很可能地自動變超頻。有些時候甚至還沒法及時將MIN曲線的資料完全含括在欲建的IBIS模型中。

為了解決這些技術上的問題,我們使必信科技BPro模組裡的解決方式是該建模者有更大多的操作選項可以來移除這些穩態資料。移除之後再由我們的工具自動地計算並優化以避免造成之前所述的DC Mismatch的問題。最後,我們也在同一模組中提供了直覺的工具供建模者可以手動地為現在模型資料做調整。

 

Tuning

SPISim BPro 的手動調整工具

 

最後要再加以註解的是:以上所述僅限於電壓部份的資料除錯及調校。對於IBIS 5.0後的模型、因其亦含有輸入電流的資訊、故要考慮的面向也就更多了。舉例而言:這些輸入的電流因也含有前級部份切換電路的部份,故很有可能在緩沖器輸出的電壓還仍在穩態時(還沒開始上升或下降)就有很大的波動性。因為VT和Composite Current 的IT在時間上是連動的,故吾人就不能隨意地將一開始時的穩態資料做移除,因為這麼一來輸入電流部份的時間點就不對了。凡此種種,將再在日後的文章中另作討論。