SERDES通道分析三部曲

前言:

本司日前完成開發測試並釋出了數款可免費使用的網上應用程式以應通道分析的一些步驟所需 (相關資訊請按此) 雖然這些軟體個自的產品網頁對其功能及使用上都有單獨的介紹, 但我們認為若也能在一套流程裡把它們串連起來則使用者就更能有個完整的概念並對背後的設計理念能有更深的了解。所以寫此篇貼文有雙重的目的: 首先我們希望對一般通道分析(channel analysis)的流程做個介紹,其次也希望展示讀者我們的這幾款APP可如何應用於其上。相較之下,一般要開發AMI模型並得到可做此類分析的仿真程式沒有十數萬美金起跳是不可得的, 現在直接從網頁就可免費執行!

概觀:

[Fig. 1, A SERDES system]

  本文係以上圖的SERDES系統做為案例, 至於其它的界面如DDR, 則請見上篇貼文對有關本流程適用性的探討; 上圖中中間的藍色區塊所涵括的部分即為通道的部份(channel), 其主要的構成為被動元件如封裝、傳輸線、導孔、連接器甚至是cable等等,話雖如此, 主動元件如TX及RX端的類比前端也應被包含在內, 這些主動元件的模型一般都是IBIS或與製程或有相關的Spice設計呈現。另一種可能的做法是把這些主動元件排除在藍色塊通道的定義之外, 而將其與TX EQ, RX EQ等連在一起做;這種做法下的通道(藍色部份)即可以一S參數來描述。之所以會這樣做有可能是因為主動元件的IBIS模型不可得或是要得到通道響應的仿真器對手上現有的主動元件模型並不支援, 例如現今網上的免費仿真器以我所知都不直接支援IBIS。而如此因而和TX EQ及 RX EQ相結合的類比前端級就會加上AMI模型設計的複雜度所以可謂是收之桑榆但失之東隅。一般而言,這中間的通道部份的確是會把TX/RX的主動元件所包含內的。

有了透過仿真所得的通道響應之後, 接下來就是對TX EQ 及RX EQ的部份加以建模。最常見的模型格式是IBIS-AMI, 有關這些本司之前的大部份貼文都已有許多探討故在此不再多加著墨。

最後有關通道分析的部份, 首先仿真器會將通道的時域響應或S參數轉為突波響應, 而後取決於所選定的Statistical 或bit-by-bit模式,或者將此直接送入TX EQ也或者先和PRBS的位元列先做卷積再送入, 而後把TX EQ的輸出再送入RX EQ後把最終結果以眼圖或bath tub的形式呈現。之前有談到中間含主動元件的通道部份, 其整體來說雖是有源而非被動, 但在通道分析上仍是以線性非時變(LTI)為假設, 所以當EQ部份也都是LTI時, 光用一個位元波(single bit response)就可以拿來透過各種排列組何來算出所有可能位元序列的機率函式PDF, 從而再積分得到CDF而畫出bath tub曲線並能對不同BER下的眼高或眼寬做一量測。但若是EQ部份為非線性或時變(NLTV), 則就只能乖乖地跑上數萬至數百萬的位元再把如此所得的時域波形疊合起來形成眼圖再依此量測。於此尚未提到、本司釋出軟體也尚未內含的、是抖動(jitter)及噪聲(noise)的部份, 理論上而言也是將其各自的PDF再和現有的PDF做卷積而得到加乘的效果, 至於實務上的考量他日再以專文探討。

由上所述的通道分析流程細節可見於第IBIS規格文件的十章第二節裡。簡單地總結來說,一個通道分析的三部曲包括了1.得到通道響應、2.得到或產出EQ模型、及3.把這些都放到通道仿真器裡得到分析結果。

 

一、 通道響應:

通道分析第一步的是對通道做時域仿真以得到其響應,如前所說我們也把TX/RX的類比前端包括在仿真的原理圖或網表裡,並以全部響應會是LTI為假設。如果現有欲分析的通路是佈線後的結果,則第三方的全波場解程式則為必需, 因為諸如VIA或連接器等都需以全波的形式場解(field solve)才能得到精確的描述;broadband spice也常是需要的, 因其可將場解出的頻域轉成如RLC/EFGH的仿真器內建元件而於時域上使用;若通道是為佈線前的分析, 則這些Via/Connector的模型仍為必需但傳輸線的部份則可以現有元件代替。如果S參數會一同參與仿真的話則這裡沒做更多說明的部份、即藏在魔鬼裡的細節、包括了調適S參數以期為passive, causal, symmetric and asympotic  以及最終將單端的S參數轉成差分的形式。當所有的模型都就緒之後, 則可到我們的[SPISim_IBIS 程式]端並把IBIS 轉成免費仿真器可支援的格式:

再來到Analog Device的官網免費下載LTSpice仿真器或直接用我們的SPILite:

而後或是編輯原理圖或是用網表把所有不含EQ的通道的部份都建出來,再以時域做階波響應的仿真;若是一位元終將會有N個取樣點的話(這個設定值用戶可自行決定,一般是32 或40…以可整除整個bit-time為主,等一下分析設定裡會用到),那階波從0至1的變化就需以在這個取樣點所代表的時間裡完成, 仿真出來的結果(不論是LTSpice或是NGSpice, SSovler等,均為SPISim_IBIS所支援)會是.raw的波形格式而可為本司免費的SPILite來觀看確認。

 

二、 EQ模型:

如果沒有EQ電路參與其中, 則用戶大可直接在上述的輸入裡更改相關的設定或激勵信號以而直接以傳統的SI分析方式在時域做多位元的仿真,再將結果做後處理及分析。但對SERDES或即將到來的DDR規格而言,EQ多為必要才能把眼圖打開, 而通道分析(一般是以StatEye的理論為基礎)之所以成為必要,即是因為其可在短時間內以卷積的方式把大量的位元和EQ模組做運算而得到可分析的結果, 也就是說, EQ模組(Fig.1裡綠色的TX及橙色的RX部份)也必需支援這種(以端點高阻抗High-Z為前提)的運算方式才能一起運作。現今這種EQ的模型多是以IBIS-AMI, Behavioral或是Spice的格式存在, 其中又以AMI為主流因其能為各不同廠家的通道仿真器所接受。所以分析流程的第二個步驟就是要得到或產生相對應的EQ AMI模型。

若是從無到有的話, 一般的做法是要以C/C++的語法透過合乎AMI API的格式來把動態函式庫開發出來, 所需不是三到六個月就是要更久;但用戶現在就可直接到本司的 [SPISim_AMI程式] 直接產生..完全毋需寫CODE及編譯:

把TX端及RX端的EQ參數填入之後,甚至還可以直接在程式裡用內建的PRBS或用戶可提供的波形(唯一的前提是需為固定均時步uniform time step)來對所欲產的的AMI模型加以驅動:

如果結果波形不合所需, 則回到參數設定處加以更改後再度即時測試, 最後按下”Generate” 按鈕相對應的AMI模可就產生了。這個模型不僅是可在本司的軟體上跑,拿到其它廠家的軟體(如ADS, HyperLynx, HSpice等一樣可以操作且結果都應一致;即便是用戶需要其它作業系統的AMI模型格式(如Windows 32, Linux 64)等,也可透過相同免費的SPILite以同樣的GUI操作而得之。

在本段落之初我們有提到很多EQ的其它形式是諸如behavioral或spice等(不論有無編碼加密), 在那種情況下,其很多含有細節的EQ響應(諸如有ringing等等)就無法透過如之前所示的預設AMI模型加以實現,則可以採用的做法是透proxy(代理人介面)的形式, 這點我們的免費SPILite也有支援且設計理代已揭諸於2017年的IBIS峰會中, 其概念是這代理介面AMI(Proxy AMI)會把用戶現有的spice檔案”包起來”, 而在仿真過程中透過用戶現有且指定的時域仿真器把這spice EQ的響應取出來,最後再以AMI API相容的格式傳會原始呼叫的通道仿真器, 以此形式的AMI建模以下圖簡示:

 

三、 通道分析:

當TX EQ, RX EQ及通道時域響應都在前兩步驟取得之後,接下來就可把它們都放入 [SPISim_Link 程式]做通道的Stat-Eye格式仿真了:

基本上就是把各模型及資料填入相關的tab裡, 再設定仿真運算模式(statistical or bit-by-bit)而後直接按”Simulate”加以計算;要注意的是如果所用EQ為非線性或時變(NLTV)如DFE/CDR之類的話,則仿法無法以statistical方式進行。凡此種種的程式詳細操作在其產品網頁已有視頻展示及說明, 故於此不再贅述。仿真數秒之後, 結果就會直接呈現:

其它資訊如bath tub曲線等也會同時產生:

其實直到這裡才做的說明是通道分析的前兩步驟(取得響應及產出AMI模型)都可直接在這個程式裡進行,用處其中之一是可以直接對所要有的EQ參數就其對通道整體的影響直接做更改後再重新仿真, 而不用回頭先以SPISim_AMI產生模型再以本程式跑之; 比如說用戶可以直接透過簡易快速設定頁來更改TX端的TAB加權值:

更改後再次仿真當就可見其在RX輸出端形成的效應:

其次,對一系統設計工程而言,其也把從所用的IC設計商處得到的AMI模型置入本程式加以仿真;而對於IC供應商而言,如此產出的AMI模型即可馬上提供給下游的系統用戶在其所擁有的通道仿真器裡測試使用;本文討論至今,這一切的軟體都可直接透過所連結的網頁取得並使用, 用戶完全不用花一毛錢甚至是提供諸如EMAIL的個人資訊。

以上..一個經濟又快速有效的通道分析流程或可做為您設計流程上的考量, 也歡迎舊雨新知繼續提供本司意見及建議。

IBIS-AMI: 新DDR規格裡EQ的應用

前言:

在月前DesignCon會期同時舉辦的IBIS峰會上, 後半部的會議時間針對EQ (等化)在即將到來DDR5/DDR6上運用的趨勢及可能機制有很多的討論。過去幾年來, IBIS-AMI及Stat-Eye般的通道/鏈路分析在SERDES界面上獲得了很大的迴響及成效,而DDR則直到最近DDR4 3200之後或未來的新規格上才開始漸漸對EQ的應用有所著墨。現有AMI上的EQ之建模及分析機制是否可直接適用到DDR上仍有很大的討論空間,無疑地,其之終將為DDR所用是不可避免的一個趨勢。

在峰會上, 各EDA廠家甚或是DDR生產廠家都對AMI甚或是VHDL的EQ建模方式有所分享,有興趣的讀者可直接到IBIS官網下載相關的簡報檔做為參考;本司在事後也針對AMI於DDR的應用上做了一些分析及研究,僅以此文分享其中的一些所學及經驗。

SERDES及DDR間的一些主要差異:

SERDES及DDR存在一些以下的幾點差異使得其在運用EQ上會有所不同。

  • Point-to-point vs Multi-Drop:

SERDES通道是點對點式的(point-to-point), 信號從最左端的TX透過通道傳到最右的RX;中間的channel包括了所有的被動元件;其次,這個”點對點”通道的定義是廣義的…其未必只有一小段,不同段的類似連結可透過repeater來串接(cascade)起來, 一個repeater本身即含有一個RX在前及TX在後。Repeater的存在是因為一個SERDES通道可以展延很長, 以USB3來說,從控制晶片連到板邊緣的連接口再走CABLE連到最終的接收端, 所以必需透過repeater來補償或加強可能消失中的信號, 也就是說, 一個SERDES通道的本質是長且有損的(Long and Lossy)。

DDR的連結如上所示則有所不同…其為多端點式的(multi-drop), 一個最左的TX可配上好幾個最右的RX端。比如說一個筆電通常會有至少兩個SODIMM模組…或是直接焊在板上或是透過連接器可外插或升級;桌上型或伺服器級的板子上DIMM就更多了…以雙通道/參通道或是四通道來看成對的DIMM會以2/3/4為一組的模式呈現。一般而言,在主板上的晶片控制器與其它記憶體相距不會太遠以免造成通訊上的遲延,正因如此, 一個DDR的通路通常是是短但具反射性的(Short but Reflective), 也就是說因為阻抗於不同分义點間的變化、再加上各RX端不同的termination impedance, 會使得信號不斷反射並形成很多的ISI干擾。

  • 差分 vs 單端點信號, 時脈信號:

SERDES信號無疑是差分為主的, 正因如此, 其對於如Voltage Droop/Ground Bounce等的電源雜訊具有較高的免疫性, 因為同樣的雜訊會同時出現於P及N端則相減之後便互相抵消; 所以如IBIS V5.1開始所提到的Power-aware IBIS很少會運用到SERDES上因並無此需要。但DDR則不然, DQ信號是以單端點為主(single-ended)所以其對於電源雜訊就必需要有特殊的考量。

其次, SERDES和DDR的時脈機制也不盡相同, SERDES的時脈是透過編碼形(如8b/10b)和資料一起走同樣的線路傳過來的,也就是所謂的embedded clocking。 這也就是為什麼CDR對於SERDES之必要…其必需要將內含的時脈解碼出來;而DDR的機制則是source synchronous, 也就是說時脈是另有專線傳送而不和資料混在一起,文中稍後會看到,這一點的不同也就造成對DFE運作的差異。

  • 運作模式:

SERDES基本上只有一種運作模式, 其信號傳輸的方向是單一的…即由最左的TX到最右的RX為止。DDR則有讀/寫模式的不同, 晶片控制器和不同DDR模組間於不同的模型分別扮演TX及RX的角色, 更有甚者, 因為傳統上DDR很多是透過不同的on die termination (ODT)阻抗值來消弭ISI的影響,眾多DDR端的ODT值對正傳送/接收者和IDLE者而言未必相同, 所以這些不同的排列組合情況就造成了DDR在分析上、尤其是要優化EQ的設定值,有更多的掃描或分析要做。

幾種SERDES上常見的EQ在DDR上的應用:

一直到最近幾年之前, SERDES和DDR的SI分析模式大致上是差不多的, 也是說佈線前的各元件(傳輸線,連接器, 導孔等)模型都兜起來後, 或者是從佈線後轉出來後(extract), 透過如SPICE的時域分析來做仿真, 所謂的worst-case pattern或是事先定義也或是就乾脆跑足夠久的時域仿真以便蓋括大部份可能的位元序列, 之後再把仿真波形做後處理來把和SPEC相關的係數提取計算出來以決定通道的效能如何, 之後再做相對應的設計改變或因應。

但由於SERDES速率的快速提升及對低BER的需求,這種SPICE似的時域仿真已不足所需, 相對應的是以high-Z為前提的EQ模型及STAT-EYE般以convolution 為主的仿真之崛起,這也就是為什麼AMI運用愈來愈廣的主因, 而這類的EQ模型,又將如何被套用到DDR4 3200或更新的規格之上呢?

  • FFE: 其運用不同數量的tap及不同的weight 以對傳送(通常用在TX端)信號做加權以期能消減不同UI所形成ISI的影響。正由於DDR的反射性雜訊(reflective noise)較耗損上更嚴重,所以可見的是這種EQ模組應會有很大的效用。實際的考量是FFE的tap及weight通常得事先決定而不能隨時適應調變(non-adaptive), 所以在運作上有些限制。

下圖所示的是同樣的FFE及weight對單端(SE)及差分信號造成的輸出差異。

  • CTLE: 這類的EQ常用在特別加強某一頻率的訊號或對整體的信號加以放大, 比如說USB3的運作頻率是5G左右, 則一個CTLE便可針對這頻帶特別地加強以弭補通道的牦損。CTLE通常位於RX端, 其另一主要功用也常是提供DC boost以使接收的voltage level能放大而達到SPEC的眼圖需求。實務上來看, 以一如下的data sheet而言:

吾人常可會有一組不同組合的頻響曲線於此CTLE中以提供EQ效應:

而由於DDR如之前所述地非以lossy為主, 可預見的是CTLE在DDR上的運用將不較其於SERDES上普遍且廣泛。

  • DFE: 在SERDES裡, DFE和CDR常是一起出現的, 因為DFE需要CDR以便於適當的時脈信號對進入的信號”slice”以便對其所含的tap做適應調變:

由於DFE本質上也是如FFE般是對ISI做消弭的應用, 所以其應可一樣常適用於DDR上, 而與FFE不同之處是DFE的TAP只能消去post-cursor的部份且其weight常是隨時調變(adaptive)的, 也就是說, 在tap的weight達到約略穩定值之前, 此EQ尚未被鎖定(locked)所以輸出的位元應被忽略 (ignoring bits),其次, 由於DFE需針對隨時進入的信號做計算, 所以其為非LTI的特性造成只能在bit-by-bit的模式裡運作, 而非像FFE可同時用於statistical及bit-by-bit流程。

由於FFE及DFE兩者對ISI上相似的特性, 可能兩者擇一使用即可而不需要同時並存, 我們最近跑了一個案例正證實了此一假設, 如下圖所示, 同時使用FFE及DFE開眼圖的效果並未比單獨使用FFE或DFE來得明顯:

如果說此一結論可廣泛地套用到DDR的設計上的話,則接下來的重點則是如何有效地”掃描”以便得到FFE或DFE所應用的tap數量及其加權值(weight).

現有AMI規格欲套用到DDR上不足之處:

至今為止, 現有IBIS-AMI規格要套用到DDR上若未加改變是無法實現的, 這是因為AMI仍是以SERDES為主而未考慮到上述DDR的差異性, 僅就以下來做實際上的探討:

  • Step response/RF response: 在AMI規格裡的”statistical” flow很明確地提到傳到AMI_INIT的波型為通道的突波響應(impulse response),這種響應實際上只在教科書或理論上存在而不易以SPICE仿真器來實現取得, 所以一般上都是以階波響應(step response)來取代,鏈路仿真器(link simulator)事後再將此波形做一階微分以得到突波響應的形式。這一流程的缺陷是如此獲得的波形假設是上升沿(rising transition)及下降沿(falling transition)為對稱的, 也因此眼圖是上下對稱於 0.0 volt, 這個對稱性的假設於單端點的DDR信號未必存在, 也就是說, 現有規格於statistical流程上對DDR的分析會不準確, 有可能的解決之道是直接以bit-by-bit模式取得通道對PRBS的一連串位元信號的響應,再用外插的方法來得到低BER值。
  • Clocking: IBIS 規格裡的另一假設是時脈信號為embedded…此點一樣不適用於DDR, 如下圖Spec裡的AMI_GetWave函式定對所示:

這個clock_time的參數是只用來傳值回仿真器用的, 一個RX EQ模組可決定是否要將從*wave序列的波型把時脈解碼出來(所以說是以SERDES為前提),若然,則透過這由仿真器預先設好的位址把時脈傳回來。

之前有提到,DDR本身的時脈和資料是分開的,但做為一個DFE, 其又必需要有時脈才能適時地把信號slice以決定位準並調應,那時脈又將從何而得? 個人認為這點的解法不會太難:因為目前clock_time的傳址呼叫只是在回傳時脈時派上用場,所以SPEC只要改定義為:當時脈為外顯時, 仿真器會將其透過這clock_time傳入EQ模組即可, 也就是說,當用在SERDES時, 這參數用來回傳時脈,但用到DDR時,其會被用來輸入值到EQ模組。無疑地,這部份的定義更改只是個人意見而尚未實現於AMI現今的規格裡。

  • Signaling: 最後一點是有關差分/單端信號的假設, AMI現今的規格裡的確是只針對差分信號為主, 如下敍述所示…激勵信號只存於-0.5~0.5伏特之間:

根據定義, 一個LTI EQ模型的轉移函數並不會由於輸入信號放大縮小或位移(scaling and shifting)而有所不同, 所以對於輸入信號是單端或差分處理上應無異處, 但就NLTV的EQ如DFE而言, 其就對位準有特別的需求才能決定位元信號並調應, 就好像NRZ或PAM4的編碼也會對其運作造成不同一樣。理論上,一個link simulator應可就其channel characterization的結果自動測知這一通路的信號模型而自動先加以位移, 再於EQ模組處理之後調回原位準, 如此一來現有的很多NLTV EQ模組都毋需重寫而可直接使用, 另一種可能是於AMI規格裡明白寫出此一level shifting為模型的職責, 則建模人員則可於前及後各加一及的位準位移模組而不用去更動中間以差分為主/現已開發的EQ模型。

本司於之前提到的DDR實驗中亦證實了上述流程的運用,上圖所示是一EDA大廠的鏈路仿真器,圖左可見到的是這channel於characterization的過程中顯示出振幅位於0.95~1.35間, 故為單端點信號, 但當我們的AMI模型放到這仿真器裡去跑時,卻發現所接收到的信號已轉為-0.2~0.2間,由於最後由同仿真器所示的眼圖仍然為單端點信號,故吾人可知這大廠的仿真器已”聰明地”自動為位準做轉換以便能合於現有AMI規格的要求卻又可適用於DDR。唯這一運作模型未必為其它EDA廠所採用, 也就是說AMI模型未必可互換流通, 這也就是什麼現今AMI於DDR的解決方案常鎖定於特定的AMI模型及EDA廠家裡(通常是同一家…綁模形也綁軟體)。

其它可能EQ建模方法:

最後值得一提的是, 在IBIS峰會裡, 有別於AMI的VHDL/Verilog-A建模流程也被提出來分享及探討,就那篇研究而言, 其所運用的傳統時域上分析配合這VHDL的EQ模型可和convolution為主的結果相仿, 主要的賣點是如此一來, 毋需曠日費時地對現有的AMI規格加以更動而可直接以[External Model]的方式及現有對Verilog/VHDLh語法上的支援而加以體現…. 也就是說可直接套用到DDR上, 而由相仿的結果來看, 並沒有需要對DDR跑上幾十萬/百萬個位元而仍可沿用傳通的分析流程。

個人認為這樣的結論只存在於那篇研究上而沒有太多延伸的空間,此一看法是立足於VHDL/Verilog做為建模語言上的一些侷限性,稍舉數點略列於下:

  • 函式庫: 欲以C/C++來做數值分析有許多現有的函式庫可供使用, 比如說GSL及LAPACK就是其中兩種,以其為基本並架構於上的分析流程開發起來即省時又省力, 但Verilog/VHDL相對應的函式庫所在何處? 沒有這些做為基礎,欲開發不同的EQ模組可謂事倍功半;而函式庫存在的一個前提也包括了可攜性及簡易性等等, 正如由C/C++所編出的DLL可把上述的數值函式庫全靜態連結到一起, 但在VHDL/Verilog上則未必如此。
  • 智財保護: C/C++編譯出的形式即為機器碼而不能輕易地被反解譯(de-compile),這也就是為什麼AMI被視為具有IP保護的特性,一般上而言本司的客戶都會要求把模型所用參數黑盒化更遑論是模型本身;峰會上的那篇研究作者亦提到對VHDL/Verilog源碼加密或obfuscate的可能, 唯如此一來, 亦只有特定的仿真器能加以解碼及interpret, 則如此喪失了可攜性的EQ模型又有何益?
  • 速度及彈性: Compile的模型跑得比interpret的快應是大多數認可的事實, 即便論點是未必都需要有Compiled 模型所跑速度的必要,其結論所欲採用的建模語言也未必會落到VHDL/Verilog上, 個人認為Python反到是更好的選擇…其有跨平台性且有眾多現存的數值函式庫可供使用(NumPy, SciPy等), 唯現有的IBIS規格對這類的高階語言的支援仍是付之闕如, 再者一旦允許Python,則Perl, Ruby等眾多不同語言勢必跟進, 如此一來又會喪失了模型可攜性的原則。

以上為個人對EQ於DDR上應用的一些看法及所學供讀者作為參考; 就算是形式上未必以AMI的方式體現(個人所知DDR committee裡有些公司會員未必支持AMI),但就內容上而言應仍不出現有通訊理論上所提到的相關EQ原理, 也就是說,不論最終形式為何, 我們終將於現有EQ/仿真理論基礎上繼續往下一里程標而前進。