Author Archives: Wei-hsing Huang

IBIS-AMI: 黑箱密技

Posted on by
Reply

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

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-AMI: 利用Proxy類別來做模型分析

Posted on by
1

前言:

近幾年來在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:　模型所用的資源如ＣＰＵ或記憶體等不應隨著被呼叫次數而一直增加，除非有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檔。

IBIS-AMI: 模型架構分析

Posted on by
Reply

前言:

在前篇貼文, 我們大致探討了有關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: 使用場景

Posted on by
Reply

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

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裡。

電源完整性之最佳化：設計合成及解耦電容之選擇

Status

Reply

在系統分析中,電源完整性的部分一般可分為佈線前及佈線後兩種情況,至於電源完整性, 因需由佈線後的設計來算出供電網路(power delivery network, or PDN)的模型來分析, 而這些佈線一般是由佈線工程師透過軟體手動製成,PDN的計算也多需透過費時的3D場解, 故在優化的過程上, 就與其在信號完整性(簡介於前兩篇貼文)不甚相同。

電源完整性: 

Power delivery model

電源完整性的目的在於能將電力透過PDN來”乾淨”(即無雜訊)地傳到最右邊的裸晶部份(die), 以透過有源元件(driver 及 receiver)對系統進(即通訊通道)行操作, 以上為PDN的簡易模型,PDN從最左邊的穩壓器, 經過包含主機板、晶片封裝、終至於最右邊的裸晶;這中間的連接因為種種的阻抗, 會造供應電流在流過其中時形成壓降及漣波(ripple);這些供應DIE的電流最終是由最左邉的穩壓器所提供, 但中間的種種解耦電容(decoupling capacitors)也會在運作間儲能而與穩壓器一起提供瞬態電流。由於不同數目及在不同工作區間的buffer切換運作,整體的工作電流也會隨之變化而使得漣波的情形更加顯著。也正由於這壓降及漣波,使得連到DIE上的buffer驅動強度及速率會形成變化及顫動(jitter); 故欲達電源完整性, 就非得對在最右側裸晶DIE的部份能有的、含漣波在內的壓降做一規格上的限制。

一般而言, 這PDN上的阻抗可分為電阻性及電感性兩種成分;電阻性的壓降是用歐姆定律般而正比於通過其上的電流, 而電感性的壓降則歸因於電流在時域上的改變(di/dt), 故欲減低後者的影響, 就得減少PDN上的有效電感;一般減低的方式是在安排不同值的解耦電容使其在不同頻域上能發揮作用, 終至在工作頻寬的範圍內有均有較低的阻抗。

也正由於這PDN的模型是佈線後的結果,故而無法如給spice做仿真的網表(netlist)一樣,直接或簡易地產生由不同參數形成的設計; 而解耦電容一般也是由第三方廠家所提供(e.g. Murata), 所以工程師也在設計過程中也得面臨如何安置及選值的問題。一般而言,電源完整性的分析包括下面兩個項目:

  • 封裝疊層、電源性通孔的安排及腳位輸出等(pin out)
  • 解耦策略(僅能使用land side cap, die side cap或兩者)、電容值、數目及安排位置等

透過合成設計來優化:

PDN 的佈線是透過3D場解來分析, 故若吾人能透過一事先計劃的規則而很快的透過軟體或AI合成的方式來產生多種不同參數的佈線, 則設計週期就能大大地縮短。其次, 以此產生的多種設計也可透過批次的方式(batch mode)平行地或依序做場解而在不費人工的情況下很快地得到不同設計的結果,透過對這些結果來做分析便可間接達成優化的效果。

antenna

以上面的晶片上天線設計為例, 設計雖有不同, 但幾何關係可以利用不同的參數來界定出來, 從而軟體就可針對這些參數來直接合成不同參數及形狀的天線;相較之下, 若是由佈線工程師一點一點地畫出這些天線, 則不儘煩瑣耗時也不易精確。對於PD設計而言,其佈線當然不像天線設計般是以單一元件為主及簡單, 但同樣的精神仍是可以套用。透過最佳實作規範(best practice)及以往設計的經驗而將合成規則或指令設計於軟體內, 則其可達成如下自動化項目:

  • 修改疊層厚度、界質係數(e.g. permittivity, loss tangent)等;
  • 於特定的疊層上、依據net name或其相對於某一晶片腳位的位置自動地產生pin, node, trace, shape生等
  • 依某種樣式產生power via並自動連到power/ground plane or nets, 其間自動地產生void及使用指定的pad stack
  • 對特定區域的設計進行複製、轉向或縮方再以陣列形式產生於晶片上的其它位置
  • 在這些產生的過程中做DRC並產生相對應的資訊(如警告等等)

由於合成的結果是透過特定的3D場解來分析, 故上述的流程一般是針對此一場解器所特別編程的, 也由於不同佈線格式對設計物件(pin, node, via, trace, shape 等等有不同的資料結構及語法, 故這類的流程要廣義化到能適用所有場解器是較為困難的。無疑地, 一旦這種合成流程建置完成, 透過參數性的分析來合成不同的設計再加以比較就不再是問題,也就更能產生優化的設計。

解耦分析:

一旦解耦策略形成後(即決定是Land side cap, Die side cap或兩者), 則接下來的工作便是依此形成佈線,3D場解後分析不同可能解耦電容組合的效果。假設事先不安置任何解耦電容,則場解出來的S參數可看作是”中性的”(neutral)而可透過後置處理的方式針對不同解耦組合用同一個S-參數很快地做分析。也就是說:如果疊層及佈線沒有改變, 是不需要再為不同解耦電容的安排重做3D場解的。

CapEff

如上圖所示, 不同解耦電容的安排下從裸晶(DIE)上看進去的輸入阻抗也就不同, 概念上, 吾人可以把現有的S參數放到如SPICE的仿真器裡來對不同解耦電容的安排做頻域上的分析來得到輸入阻抗, 實務上, 這種仿真是沒有必要的… 因為可透過S參數的數學計算(如轉成Y或Z參數再將電容模型頻域上的響應一起含括便可很快地直接得到下列相關的解耦安排資訊:

  • PDN的輸入阻抗(包含電阻性及電感性的):Lac
  • 不同解耦電容在不同頻域上供應電流的能力:ZIAC
  • 從DIE看入的輸入阻抗:Zf
  • 電容有效性分析, 即若將某一解耦電容拔除,其對DIE埠輸入阻抗會造成的影響:ZFCIF
  • 不同解耦安排的假設性分析: 由於上述的分析均在很短的時間內可以完成,故而就能對不同解耦電容的安排(位置、數目及電容值乃至於其價格等)做假設性分析並依此而達到優化的目的。

 

信號/電源完整性之最佳化：系統性分析

Posted on by
Reply

在前一則貼文中, 我們提到若欲找到”一個“方案時, 線性的假設性分析是一個不錯的優化方式。然而當我們要把更多的設計變數放在一起通盤考量來對更大的解答空間裡求最佳化時, 則必需要有更系統性的、而非挑一兩個變數在固定其它變量於一常數值、的優化程序。

反應曲面模型( Response surface model,  RSM):

在下圖中, 系統輸出Y1, Y2等同時含有可控制變量X及不受控變量Z; 在其它如晶片設計或晶圓廠裡,諸如不可預測的宇宙射線等對載體的影響便可歸類於這些不受控變數;但在透過仿真來得到輸出結果的整合性分析裡, 過程與結果都是確定性(deterministic)的; 也就是說只要輸入情況一樣, 輸出結果每次也都會相同, 所以這些不受控變數Z便可忽略不計; 我們可以把這種輸入轉成輸出的關係看做是一個具有多維空間的反應曲面, 在這曲面上找頂點或最低點便是最佳化的過程。

doersm

這種輸出入間的對應一般稱為”反應曲面模型” (response surface model, or RSM), 透過在解答間裡的諸多取樣點並對其(透過仿真或場解)求輸出後構間出這樣的一個多維模型來優化便是一種系統性的優化流程; 而實驗設計法(design of experiments, or DOE)則是最常與RSM一起運作的建模程序。

實驗設計法 (Design of experiments, DOE):

當系統有許多變量且各含有一定範圍及可能值時, 要透過全面完整組合(full combinatorial, or full grid)來找最佳值是不大可能的; 我們只能透過極有限取樣點來得到反應以建構出RSM。

將上圖中輸出Y寫成是一個由變量x1, x2 ~ xn所形成的函數f(x), 則透過Taylor Theorem, 這些函式f(x)均可以級數的形式來近似:

當更高階級數(bigger alpha)被包含Taylor級數時, 這近似式與原f(x)就更接近了, 這就好比對時域方波做傅利葉轉換時, 若頻域上包含的諧波更高, 則再反轉回時域時就更近似原來的方波。

在現實世界裡, 大部份的現象主要來自於低階的項目的影響, 若我們只取到二階, 則上述的Taylor級數展開後可寫成如下的二次式:

quadraeq

當變數X1, X2的值不同時, 等式左邊的輸Yfit值也就不同, 而系數Beta則決定了各變量對輸出的影響程度: beta值愈小, 則變量就更為次要; 那要怎麼算出相關係數Beta呢? 如果我們有N個取樣點, 則上面這種型式的等式寫在一起時便可以如下的矩陣的樣式來表現:

quadramtx

當將二階拉高為至K階時, 則廣義的矩陣式便可寫成如下:

DOERSMMtx

最左邊的X矩陣大多不是方陣, 所以若要求出相關系數Beta的向量, 則需使用一般線性代數裡的操作技巧:擬反矩陣(pseudo inverse)及奇異值分解(singular value decomposition, or SVD), 而所得的係數是在以最小的平均誤差(mean square error)的情況下的解。

modelfit

欲使用DOE/RSM流程來進行優化, 則有幾項前置作業必需完成:

  • 決定有那些變量X及最高階為何: 如能先有洞見, 則取較具相關性的變量可使建構出的模型更近似;其次, X的數目及階數也影響了欲進行仿真的數目及最後矩陣的大小;
  • 決定取用那些輸出函數Y: 因為我們只用低階的X來置入Taylor級數, 故若是結果得再經過複雜的數學運算或後處理,則過程間的高階操作便可能打破了低階X和Y的關連性;
  • 決定那種取樣方式:在上面矩陣式中, 每一列都是一個系統仿真, 我們只要能在解答空間裡有足夠數目及涵蓋性的取樣點便可, 過多或過少都會影響建出模型的品質; 而這取樣點的方式在統計學上則有許有許多不同的理論可採用。

以實驗設計法優化的流程:

欲利用實驗設計法在對信號或電源完整性上優化; 一般來說有下列步驟:

  • 定義變數: 儘量只將主要變量列如分析的範圍則模型才有意義且建模才有效率; 而主要變量則可透過:線性掃描(linear sweep), 假設性分析, 之前產品設計的分析及經驗等等來決定; 再者實驗設計法通常不會只進行一次, 在每次結果出來後對相關係數的檢視都可為下次再進行分析做參考。
  • 定義取樣點: 取樣方式及數目取決於變量多少及範圍; 在信號/電源完整性的應用上, 一般若變量數目在10左右, 則central composite design 是一個不錯的選擇, 如此選出的取樣點在一千到數千個之間; 若是有更多的變量(<=30),  則使用D-Optimal較佳, 取樣法亦和建模方式有關, 當欲建模型不是透過RSM, 而是由神經網路的方式時, 則二次式的需求便未必需要, 故而可用如space filling等取樣法來進行;所述這些都是統計學上的應用, 故許多統計軟體都可拿來設計相關實驗;在我們的建模模組MPro裡, 則有許多常用的有關的內建:

    Design

  • 產生測試案例: 所定變量一般可分為連續性變量(如電阻值)及非連續性(如各corner等),雖然在變量可能值範圍內有不同的階度可選, 但在上一步驟的取樣點裡, 每一個變數一般只用-1, 0, +1來表示其最小,中間及最大值以用於其案例; 故接下來竹的步驟就是把這取樣點的設定轉為實際的案例以便進行仿真或場解。若是佈線前的分析, 則案例多是Spice的網表(netlist), 故案例的產生可運用如樣板網表(template netlist)進行字串替換來輕易達成; 對於和幾何相關的案例(後佈線或2D傳輸線或3D結構以場解進行), 則得需要更複雜的程序才能將取樣點轉成測試案例。不論那種程序,最後的結果是每一個測試點表示矩陣裡的一個行而必需要有相對應的案例產出。

    Collect

  • 對案例仿真、場解並後處理: 再來就是對產出的測試案例仿真、場解及後處理以得到輸出了; 因為可能有維數上千或上萬的案例需進行, 故一般是透過多執行緒或甚至是利用多台電腦來平行處理,最後再將每個案例的算出結果組合以便和原始輸入形成對應關係; 而在這一步驟中所著重的便是如何迅速有效的管理這些平行處理的案例分析。

    SimMgr

  • 為輸入至輸出建模: 有了輸入及輸出後, 接下來的就是實際的建模了, 若是反應曲面模型, 則可用前述的奇異值分解(SVD)來解相關係數; 其它的建模方式也包括了類神經網路等等;而模型的優劣則可透過其對現有結果的預測及殘值大小來查驗; 殘值(及實際值及預測值間差)愈小則模型愈好; 一般上可用R^2, 即因模型所造成的變異數, 來計模型好壞, R^2 >= 0.95表示是可接受的預測模型。

    modeling

    Prediction

  • 優化: 優化是在一定的變量範圍及條件(如不以是負值)等的前題下進行; 而後對單一輸出Y或是以比重組合出的複合Y (or cost function)來求極大極小化; 取決於所取變量的階度, 也有以下幾種演算法可運用:
    • 線性規劃: 若變數皆為一階且無cross terms, 則可用線性規化方式得到絕對解; 一般而言, 很多和幾何相關的計算(如layer stackup對阻抗的反應)等都只需要用到一階就可有很好的近似;
    • 非線性方法:常有高階項時, 可試著用如Nelder algorithm來求優化值;
    • 基因演算法: 這是需經過許多迴圈但可適用於近乎所有模型(含類神經網路)的優化方式。

      Optimize

  • 審視相關係數及殘值,重覆進行: 最後一步驟則是審視模型中各變量的相關係數, 剔除非主要的變量後再在下一迴圈裡做更進一步的操作; 也可能是對高殘值之案例更進一步檢查看是否是仿值或後處理的過程產生問題以造成離群值。

由上可見, 相較前一則貼文裡所提到的假設性分析, 欲以DOE/RSM的方式來為系統做優化是需要進行更多步驟的及計算資源的; 在另一方面, 一旦所建模型可具預測性(即殘值小), 則此一模型可做為假設性分析的基礎而取代很多不必要的仿真; 下圖中所示:我們的TPro模組先已透過對十數萬案例進行二維場解及建模而能將結果拿來建置成一快速的假設性分析功能使讀者可很快地透過拉BAR來得到相關的性能資訊。

A stackup what-if based on model built via DOE/RSM flow

 

信號完整性之最佳化：假設性分析

Posted on by
Reply

系統性能之優化或最佳化：

就系統上的信號完整性而言，所謂的『系統』一般定義為通信通道的頭尾兩端，亦即是自晶片上IO buffer的driver、經諸如封裝、傳輸線、通孔及連接器等的interconnect、最到接收器的receiver為止。這通道上有許多元件且各有各的設計參數；故若要以系統性能為優化目標，其實含有為數甚多的變量；即便是就『性能』而言，也是有很多不同量測的依據。。。諸如眼圖的寬度、高度及位元錯誤率(BER)等等，它們之間有些也未必成正比、如欲求極大化之眼圖寬度便可能得犧牲其高度等，故在諸性能間也有得取捨的空間或是得用加乘比重的方式來對整合出的複合性能求極大或極小的優化。

系統雜訊的來源：

系統性能除了被許多參與元件之參數所控制外，也可看做是受了許多雜訊的影響。如果我們把元件參數的變量以x1, x2 ~xn表示，則這些雜訊也可看成是函式g1(x1, x2), g2(x2, x3)等而同為元件參數所控制；最終的系統性能則是f(g1(x), g2(x)…) = f(x1, x2~xn);這樣分隔的的目的，在於很多設計或元件參數只對某個性能有影響；比如說傳輸線的間距與串擾(crosstalk)有強烈的相關性，相較之下buffer的驅動特性及速度則不那麼正相關︔也就是說，吾人可將具相關性的參數放在一起來對某系統雜訊的影響做分析，如此可能更具直觀性且不用在含全部參數的廣大解答空間裡尋找最佳值。

一般而言，系統的雜訊來源大致可分類如下:

  • 符碼間干擾 (inter-symbol interference, or ISI):　由於通道的色散特性及各級連接之間阻抗不匹配所造成的反射現象，傳輸的位元信號會與其自身相干擾而在接收端造成失真；
  • 串擾 (crosstalk, or cross-channel interference CCI):　串擾是由於victim及aggressors之間能量透過電容或電感性的藕合來傳遞而造成接收端訊號的減弱；串擾的情形一般在高頻時特別明顯、且也和許多界質及間距有強烈的相關性；
  • 電源雜訊：不同數目的buffer在不同工作區間或頻率運作時有不同的驅動電流之需求，當它們流過power delivery network時就會造成供應端的壓降而使得驅動強度及斜率均相對改變；
  • 隨機雜訊：由諸由有高斯分布特性之熱雜訊及其它顫動(jitter)等；

藉由探討元件參數對這些相互獨立的雜訊的影響，我們可以各個擊破地減少這些雜訊進而對整體系統性能達到優化的效果。

系統優化的方法：

有了這麼多的元件參數x1, x2 ~ xn, 間接形成的雜訊函數g(x)及最終的性能函數f(x), 我們要如何進行最佳化呢？

通訊通道一般都有必需滿足的規格，如業界標準的PCIe GenX, HDMI, SATA, USB, DDR等等，各有其公定的最低標準，唯有滿足其要求通過檢測後才能在最終產品上貼上相符的識別標章；對於較小的設計公司或是有截止期限的壓力時而言，很多情況下工程師都只求產品能通過規格標準即可，也就是說，他們所要的只是『一個』、而非『最佳』的解決方案；但對於有些需要提供design guide的公司，為了確保其它公司使用其產品的設計能順利運作，便得對所有可能的情況做分析以便即使在最壞情況下其結果仍能通過標準，所以它們便得做類似『最佳化』的全面性分析。其次，最佳化的流程常需透過大量的仿真及計算、故非有充裕計算機資源及能力無法完成。為滿足上述的兩種情況，一般而言我們有兩種優化的方式

  • 假設性分析：即what-if analysis， 在這種分析法中，我們將許多參數都先給定一數值，而後只對少數的參數做線性的研究；就信號整合性的例子而言、就好比是藉由調整傳輸線間距或線寬來觀察其對串擾的影響等；由於是線性地調整一兩個參數、所以全域(global)的最佳化不大可能由此分析而獲得，但在另一方面，這種假設性分析通常有如下的優點
    • 可用相對少的計算機資源來找到『一個』解決方案；
    • 可以相對短的時間內快速地得到結果；
    • 透過其近乎即時的反饋，工程師能對所調參數對反應的影響產生直觀上的連結及了解，近而可在日後有益於做出更好的設計。
  • 系統性分析：【如實驗設計法design of experiments等】這種分析法可看做是多維空間的假設性分析；有更多的設計參數可一起列入考量，在為每個參數定出其可能值的上下限後（所以嚴格地說仍不能算是global地優化）進行下列的程序：　（我們會在之後的貼文再對這分析法做更詳細的解釋）
    • 決定取樣空間
    • 就每一取樣點產生相對應的設計
    • 對每一設計仿真及後處理
    • 為取樣點參數到後處理的結果建立模型
    • 透過所建之模型來預測最佳結果時的參數值
    • 研究殘餘值(residue)及參數間之相關係數

再談假設性分析：

由於假設性分析是透過對較少數變量的線性操作來達到探討其對最終結果的反應，故而在可操作變量的選取上便得先決定其是否有主要的影響,否則線性的參數調整將看不到結果的變化而失去其意義；其次、為求結果能很快地產出而有近乎即時反饋的效果，對其餘定量的因素或相關系統模型便可更進一步地做簡化。比如說、若吾人想探討的是系統參數對其ISI及CCI的影響，那我們便可將通道上的元件簡化成下列三部份來分別研究其與前述兩性能間的關係：

  • Driver: driver’s strength, slew rate, supply voltage, EQ （等化）settings
  • Interconnect:
    • transmission lines: layer stackup and materials Dk/Df, trace width, distances and layout etc
    • vias: pad, anti-pad size, barrel width, back-drill etc
    • package/connectors: change of reference and reference impedance etc
  • Receiver: termination scheme and different terminator values, EQ response and settings etc.

上述中的driver/receiver均已是行為模型(behavioral model)而非原始場效體型諸如通道尺吋或載體濃度的參數、也就是說一般是利用IBIS或／及AMI的參數來加以操作；對於interconnect而言,以二維場解器來計算傳輸線物理及尺寸（間距、線寬等等）所造成的阻抗或串擾上的影響是相對簡單的；一旦是必需要用３D場解才能算出的結構：如通孔Via、封裝或連接器connector等，就要需時甚久而使得假設性分析的效果打折扣了︔如果許可的話，應以簡化的的模型來取代。如下圖為例、在大致的計算上通孔設計可以PI模型來取代。

優化方式間的取捨：

我們認為一信號／電源完整性工程師的價值在於其能對各參數對系統性能的問題有其深入的了解進而能找出解決問題的方案。假設性及系統性分析均可做為這種知識及經驗取得的手段；對系統分析性【如實驗設計法】而言，有一可能的陷阱是因為其需要完整的流程及執行許多步驟，一旦前人建置完成，後來的工程師便可能陷入僅僅執行流程以產出結果報告而未對所得的預測模型做更深入的了解的險境；從而在眾多的數據中喪失了對單一參數的認知及了解。

SPISim使必信產品對假設性分析的支援：

基於前述討論的精神之下，我們設計出了支援假設性分析的XPro模組【X即Experiment, 亦即實驗】在這模組中、我們簡化了許多通道模型並提供了對能主要系統參數做假設性分析的功能，以便用戶能分別對ISI, CCI及電源完整性的一些課題分別做直觀快速的分析：

分析時所需的的仿真都是直接透過內建的SSolver無縫進行，一旦性能滿足所需，只要按下”Generate Model”鈕,則相對應參數的模型便可直接產出而在完整通道的分析上使用。這些功能是大部分其它公司的產品所欠缺而獨見於我們使必信的工具程式裡的。