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

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

為什麼需要使用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)進行資料交換。

  

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

IBIS AMI的使用場景：

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

• 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廠家一同合作來完成建模。這中間還有很多細節值得深入討論，我們將來有機會回頭再談。