Category Archives: S-參數

IBIS-AMI: 在COM流程中使用IBIS-AMI模型

Posted on by
Reply

[這篇貼文系為2018 DesignCon IBIS Summit發表的同標題文章做準備, 相關簡報檔及現場錄音(英文)已連結於此文之末。]

研究動機:

AMI模型的主要部份是二進位檔.dll (dynamic link library, on windows) 或 .so (shared object, on linux)的函式庫, 這些檔案本身是非執行檔而無法直接使用;需要先有另一個”驅動程式”把這些函式庫讀進來才能開始運作;EDA公司如新思的HSpice裡就有這麼一個需要License才能用的AMICheck, 其能對讀進來的AMI模型做上升沿/下降沿及單一位元波的試驅動; 本司也提供了類似功能的SPISimAMI.exe但不需License且還可以用戶自定的波形來驅動。這些小驅動程式在簡易快速地測試所得的AMI模型可否使用上頗有助益、但若要拿來測試模型在完整通路/鏈路分析上的實際運作上則有不足之處。在理想情況下, 一個通路分析的仿真器會把TX及RX端的AMI模型都讀進來而後與通路的response運作並將結果做分析。如果一個AMI模型開發者的IDE (integrated development environment)可以讀入這仿真器並有其源碼可編譯, 則不論是在仿真器中欲讀入AMI模型時, 抑或是AMI模型裡, 都可設入break point並在除錯時暫停於此或步步前進(step through)以能完整地分析模型的實際運作。

即便是開發人員沒有仿真器的源碼, 至少理論上IDE也可”attach”到這仿真器的程序(process)而僅對開發中的模型做除錯。這”attach”的動作需在程式一開始還未讀入AMI模型函式庫時便需執行。現實情況則沒想得那麼簡單, 因為現今的EDA軟體多允許用戶透過圖形使用者界面(GUI)來對AMI的參數、分析模式(statistical or bit-by-bit)、擾動參數等等先做設定, 而在按下”Simulate” 或”Run”的按鈕後仿真的動作才正式展開, 在全部運算完後再把結果傳回給前端的GUI顯示。而在按下開始仿真鈕的那一瞬間, 另一個程序(process)是被”生出來的” (spawn, or forked), 所以事先不知道其ID為何, 故而也就連自己有源碼的AMI模型也無法偵錯。Windows下的visual studio也是直到最近才有”自動attach到spawn process”的功能, Linux上的GDB對此則是付之闕如。再者, 當通路裡有TX及RX端一同做優化(optimize)的動作時, 單單只偵看TX或RX端的AMI模型也是不夠的..無法得知優化是如何進行。凡此種種, 皆造成在AMI模型開發上的挑戰。

有鑑於此, 對於那些非EDA公司而無法得到仿真器源碼的模型開發人員而言, 開源的通路分析平台就是一種可能的方向了;至今為止, PyBert 及COM (channel operating margin)就至少是兩種可能的選擇;就我所見,這些平台大都已有基本的TX/RX演算法模組供使用, 故而把這些以AMI的方式來取代或許就可解決我們之前談到的需求且可縮短模型的開發時程上述兩者之中, pyBert己有初步的AMI架構在內, 則這篇文章就為如何在COM流程裡加入同樣的功能來做探討。

關於COM的背景資訊:

COM (Channel Operating Margin)是已確認通過的IEEE802.3規格, 有興趣的讀者可發現連結於下的COM原主要作者(也是我之前在英特爾的同事)Richard 的簡報:[Channel Operating Margin Tutorial], 若郤知更深的技術資訊及所用到的數學式, 則可直接參閱802.3的規格文件、Richard在2013年DesignCon發表的同標題文章甚或是公佈在802.3官網的COM程式原碼。

要在本貼文內短短的兩三段就把COM說清楚顯然是緣木求魚, 所以以下就僅以AMI模型開發者的角度來看COM對AMI的可能運用。

上圖所示即為COM的參考流程。右邊的上半部份講的是through type的inter-symbol-interference (ISI)影響, 右下半的部份則是遠端或近端串擾(cross-talk)的部份, 這兩者之外, 其它可能的系統雜訊、諸如擾動jitter等等也都有列入考慮; COM本身算的即是這廣義的信號/雜訊比, 信號強度是以單一位元脈波, (Single Bit Response, SBR)的最高點來定義;由於COM也已界定了一同傳訊速度/界面下不同參數的內定值, 所以在使用上很直接, 至於等化EQ的部份則用TX端的FFE、RX端的CTLE及DFE也都包含在內。

對一欲提供AMI模型的SERDES設計者而言, interconnect的S參數是如何而來並不是重點..其有興趣的是TX/RX兩端; COM直接能做的是能對所有FFE 不同TAP比重及CTLE DC增益的部份做窮舉式的掃描而回報最佳值,在每個不同EQ參數組合的試運算過程中, 有一個Figure of merit (FOM)值會被算出來以代表這個組合的最佳化程度, 在最佳EQ組合被決定之後, 完整的如BER般的SBR分析流程才會開始進行終於包括DFE及擾動等把所有的結果都算出來。

在通路分析的流程中, 第一步做的是對interconnect “characterize”的工作以便得到其impulse response, 這裡面其實魔鬼的細節很多:單端量測到的S參數要如何轉成差分S參數、不同部份封裝及breakout的部份要如何和主interconnect串接起來、甚至到串接後的S參數要如何先做conditioning以便其為passive, causal等等終能透過IFFT來得到突波響應, 凡此種種都是分析裡的重要環節且詳細研究起來要耗掉不少精力卻又未必與AMI建模正相關,所幸的是這些在COM裡也都有完整周延的考量及列作計算。

對於EQ的等化部份, 在早期(2014左右)的COM分析FFE的部份僅含有一個pre-tap及post-tap, 最近的更新已將其拓展為兩個pre-tap及三個post-tap, 至於CTLE部份, DC的增益是可以被掃的,除此之外的兩個極點及一個零點則用戶可以自定, 然後透過簡單的公司成CTLE的頻域響應再轉到時域來和突波做計算。也由於是突波被使用, 所以是以LTI為前提。接下來的流程就如IBIS規格裡的AMI流程敍述般一樣:interconnect的突波分別給TX及RX端算完後, 再與UI做計算形成SBR, 最後透過DFE完成對這一特定EQ參數組合的FOM計算, 所有的組合的FOM都計算過後擇最佳者做完整的BER-般分析流程。

如前所提, COM裡的EQ計算是窮舉式的, 所以當打開COM的源碼時, 讀者會發現在上圖的行數附近會有多層的迴圈, 黃色方塊裡可見到DC增益及FFE不同的比重在不同的迴圈裡被列舉(iterate)過去, 故而要把它們以AMI取代, 就是在這附近開始著手。

於COM流程中使用AMI:

由於AMI也需要參數, 所以兩個TX/RX在COM Matlab裡的函式要被取代為對AMI模型的讀取及運用, 除此之外, 在流程的更改上有兩種可能的方向:

  • 線性非時變設計: 由於COM對EQ的計算是以突波為主, 所以如果模型是LTI (即運算不必然在GetWave裡做), 則以AMI_Init的部份直接取代相對應matlab 函式即可。

流程上來說, 第一步是把上述的多層迴圈以單一迴圈來取代, 這單一迴圈可以是對可能的EQ參數組合(未必是窮舉)一一列舉過去, 也可以是有一”stopping criteria”的決定式在內的(近)無窮迴圈, 一旦裡面TX/RX或一起的優化過程收歛之後即break而跳出去; 而由於是用自己的AMI模型,所以TX/RX的結構為何也就不受原COM設計所限, 比如說CTLE的部份可以是很多預先決定好的頻響曲線等等, 至於若TX及RX一起做優化, 則原COM 裡FOM的或可繼續拿來用也或可以自定的cost function來取代。

  • 非線性時變設計: 在這情況下, 一類似PRBS的數位訊號需先被產生, 而後與interconnect 的突波convolve成波形後才能依序傳給TX及RX的AMI_GetWave函式; COM裡的DFE或可用也或可不用但FOM則需由用戶來自行對最後波形計算而得。

其次在實做的細節上, 因為COM原碼係以matlab 寫成, 故需以其相對應的讀取並呼叫外部DLL的程序來運作AMI模型, 簡單地說, 第一步是在Matlab的IDE裡用mex -setup來讓其自行找到系統上安裝的C/C++編譯器並做擇, 除此之外, 與C相容的AMI API 表頭檔(.h)也需事先準備(就把編AMI DLL時的header抓出來用即可), 而後依下列步驟進行AMI的操作:

  • Load AMI model using: load(‘XXXXXX.dll’, ‘ami.h’)
  • check libisloaded(‘XXXXXX’) and list functions in the library using libfunctions(XXXXXX’)
  • Call AMI library function using calllib(‘XXXXXX.dll’, ‘ami_init’, htInput, rowSize…)
  • Finally unloadlibrary(‘XXXXXX’)

最後值得一提的是因為我們只是要針對在開發中的AMI模型做偵錯, 並不是要把COM改成一個通用或給其它人也可以用的通路仿真器, 所以未必需要先建一個.ami檔案的parser. 我們可以事先把其會形成的key-value pairs以字串值存在一變數內再行使用即可, 至於PyBert則有其自己的AMI Parser。

實驗結果:

在此案例中, 我們不想要經過窮舉的方式來得到最佳的FFE比重值, 所以開發了一個可自行優化算出比重的FFE AMI模型並把它套到COM裡運動, 這優化的原理很簡單:當我們知道channel的突波之後, 因為所要recover的信號(bit-sequence)也就是一開始所傳, 所以FFE的比重當為何可以用pseudo-inverse及線性代數的技巧直接解出,這算出的結果是in the sense of Minimum Mean-Squared-Error. 我們想要確認做出來的AMI模型可運作無誤且其和透過原COM裡窮舉法得到的結果差不多。

上圖所示為運算結果, 因為CTLE裡的DC增益有十三個值, 而且FFE的比種有24種不同的可能組合, 所以原COM總共要算三百多次, 每一次的FOM在上圖以紅點表示, 可以約略看出從左到右有十三個block, 每一個block內又冇24個值; 相較之下,我們的AMI TX模型只要算十三次(仍要列舉不同的Gdc), 其結果以藍點表示, 可以看到的是從左到右的每一藍點相對應那十三個紅色區塊大都是在最頂點或更高(高表示FOM好, 值可能更高是因為原COM的掃描有FFE GRID點的限制), 由此結果可認證我們的TX模型可操作無誤。另外可能的實驗案例包括做如PyBert般把TX及RX透過”Hula-Hoop”的優化演算法(2016 DesignCon paper)來同步做優化。

結語:

對於這個研究, 我們要先強調的是動機及需求….COM只是一個可能的方案。也就是對於一個模型開發者而言…不論是模型供應商或是被賦與建模任務的SERDES設計師而言, 能有一個完整的通路分析流程可透過IDE來讀取、偵錯開發中模型或與TX/RX同步偵錯是很有價值的,這一需求無法為簡單的驅動程式(AMI dll driver)所取代且也常不可得於一般商用的通路仿真器。

所幸此一需求已可以現有的開源分析平台所滿足, 其中 COM又因其已通過認證、逐漸廣而被使用、有充足的參考文件及最不可或缺的源碼而值得被列入考慮;其原有的TX/RX EQ部份架構簡單, 但要以我們所有或所開發中的模型來取代其實不難。不論是更改成適合LTI的statistical或是NLTV 的bit-by-bit都有可能, 而原COM裡的很多其它模塊或函式則可沿用;這種混合流程一旦建置完成, 將可大大縮短AMI模型開發的時程並增加模型在實際操作時的可信度, 所以很值得一究。

相關連結:

簡報檔: [請按這] http://www.spisim.com/support/paperetc/20180202_DesignConSummit_SPISim.pdf

現場錄音(英文): [請按這]

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

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
  • 不同解耦安排的假設性分析: 由於上述的分析均在很短的時間內可以完成,故而就能對不同解耦電容的安排(位置、數目及電容值乃至於其價格等)做假設性分析並依此而達到優化的目的。

 

仿真器之研發：建模 (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的公司如我者而言，是一項值得的投資。