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

前言:

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

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

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

概念:

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

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

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

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

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

AMI模型的解構:

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

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

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

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

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

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

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

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

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

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

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

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

模型的優化及發佈:

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

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

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