|
要 點 SoC(系統級芯片)越來越不適應基于中心化總線的架構。 精確的使用模型對于理解流量模式非常重要。 要理解互連，就必須有ESL(電子系統級)方案和周期精確方案的結合。 隨著SoC的發展，互連建模會變得不可或缺。 SoC上各塊的連接正在成為先進芯片設計中的一個主要問題。 SoC（系統級芯片）在先于它出現的板級計算機上開始了自己的生命：作為一個中央處理器，其CPU總線連接到本地內存與外設控制器。從此以后，這種以CPU為中心、面向總線的架構一直是很多SoC的優先規劃。但集成化帶來了一種復雜性，表現為復雜的外設及其DMA（直接內存訪問）控制器、協處理器和附加中央處理器，所有這些都存在于同一個晶片上。因此，SoC的互連架構正在變化。以CPU為中心的老式總線正快速隱退到芯片的功能塊中，代替它的是多總線、專用的點對點連接，以及片上網絡。 改變的速度很快，架構師差不多都在擔心這個變化會遠遠超過需要支持它的工具。ASIC供應商eSilicon的營銷副總裁Hugh Durdan注意到：“今天，我們仍能看到很多經典的SoC設計，它們采用ARM核心、外設和內存接口。即使這些設計發展到包含多個處理核心，它們通常也會保持傳統的AMBA AHB（先進微控制器總線架構先進高性能總線）結構。” 但是，越來越多的跡象表明，SoC互連的中心式總線方案正在日趨完善（見附文《問題是總線帶寬還是處理器帶寬》）。這個問題部分表現在架構上。隨著一只芯片上處理結點數的增長，以及這些結點生成或消耗數據流量的增加以及日益多樣化，僅對原始帶寬的需求就成為一個問題（圖1）。無疑，用九個金屬層以及統計時序工具能夠使一個多主控總線具有近乎任意的帶寬。但復雜布局、信號完整性分析、功耗以及擁塞的成本使這種方案幾乎難以處理，尤其是今天有嚴格的可制造性設計原則。 問題也部分涉及到工具。坦率地說，傳統SoC總線使用的工具是微軟的Excel。在比較簡單的時代，架構師可以只累加起總線上各個塊的帶寬需求，為高峰擁塞留一些余量，即可用總和決定總線的帶寬需求。可用的總線帶寬大大超過了單個塊的需要，因此從數學上不可能出現問題。 但這些日子已成過去。Silistix營銷副總裁David Lautzenheiser警告說：“你不再能從累積帶寬估計中獲得任何結果。”隨著中心化總線快速讓位于更復雜的互連架構，電子數據表也讓位于更復雜的系統級建模、統計工具，還有周期精確的模型，這同時考驗著架構師的技術和耐心。 問題評估 累積帶寬并非問題所在，中心化總線也并非總是正確答案，原因有二：首先，流量特征可以有巨大差異。其次，即使數據與時序需求一樣，但它們功能塊之間也有差異。片上互連的分析和實現問題并能提供人人滿意的答案，只不過有助于在正確的塊之間提供正確的互連。通常，用一個總線就可以實現這個目標。如果無法實現，還有無數其它技術有自我表現的機會。多媒體SoC很好地展示了一位設計人員必須面對的各種數據流。通常可以用到一個CPU，這個CPU會產生至少兩個有獨特標志的數據流：新指令的連續獲取，以及裝入與存儲操作的偶發式雙向流。 CPU塊中的緩存一般會修改這種流量模式。因此，當緩存清空或填充行時，來自CPU核心的流量模式是一種隨機散發的突發數據。這種情況與來自其它設備的流量模式有極大的差異。例如，一個射頻SoC中的基帶信號看上去像來自一只ADC的固定間隔（有時非常短）的一兩個數據字。來自攝像頭或DVD播放機的視頻流也很類似。但視頻壓縮引擎推入本地內存的中間數據看來則像一系列按近乎隨機的序列存儲和裝入的宏塊，而不是掃描線排列的像素流。每種類型的數據都有一個屬性標志。并且，如同在CPU中心的情況下，本地內存和狀態機都可以改變這個標志。 帶寬與延遲 正如各種流量都有自己的標志一樣，不同功能塊也是個性化的。CPU、硬接線信號處理流水線、視頻編碼器、串行口和DRAM接口都有不同的需求和期望。MIPS Technologies公司解決方案架構副總裁Gideon Intrater注意到：“處理器對延遲極其靈感，不過與一些帶寬掠奪者比較，它們對帶寬的要求倒是適中的。”CPU緩存控制器并不經常請求數據，但一旦它這樣做時，整個CPU都可能要坐等。 與之相反，一些功能塊只對原始帶寬有興趣。Intrater說：“這些產品包括高性能的連網設備，PON（無源光網絡）是一個很好的例子；視頻引擎，如DVD錄像機中的MPEG編碼器和HDTV中的H.264解碼器；還有圖像引擎，如打印機中的光柵處理器和數碼相機中的JPEG編碼器。所幸，在多數系統中，帶寬掠奪者對延遲不敏感，而對延遲敏感的處理器對帶寬也不貪婪。” 除了這個差別以外，還存在著有特殊要求的塊。采用離散余弦變換算法的圖像或視頻處理器一般是按照宏塊來處理像素，通常是8像素×8像素的信息，因此需要能方便地裝入和保存這些塊，而無需在面向掃描線的內存中去收集或散發像素。 但是，最惱人的還得是無處不在的內存元件，即DRAM。DRAM采用復雜的同步接口，還有分段的存儲陣列，對順序錯誤的請求會產生顯著的延遲。根據存取方式的不同，DRAM提供的有效帶寬可以有很大變動。很多情況下，一種讀寫請求的排列就會產生接近于理論的流量。不幸的是，盡管這些嚴格的需求能相當好地匹配于CPU L2緩存控制器的流量模式，但當幾款不同處理器都共享一個DRAM端口時，它們就不像累積流量的模式了。 簡單地說，互連架構的目標就是：使流量模式適應客戶塊的需求，讓所有數據在恰當的時間，以最小的擴展量到達。由于架構師對流量和客戶端知識的局限，以及他們所用工具的能力，這一說法相當好地描述了今天的情況。但對這些是有嚴格的約束。問題是：要了解流量模式，架構師必須知道完成后系統的使用模型。Lautzenheiser指出：“這里，使用趨向很重要，它涉及無法捉摸的用戶感覺。在手機顯示的視頻中，成功的關鍵可能并非是總線向視頻解碼器提供的每秒字節數，而是用戶是否認為自己的顯示屏在閃爍。要預測這種定性的 用戶感覺，就需要全面搜索那些未曾預料的對系統造成最大壓力的使用模型。并且，要在將物理原型送交實際用戶以前完成這個任務，還需要系統級建模。” 事實上，這個領域可能是系統設計中難以處理的ESL（電子系統級）工具扮演穩固角色的一個地方。互連IP（知識產權）公司Arteris的總裁兼首席執行官Charlie Janac稱：“如果系統架構師可以在完全確定IP塊以前就開始進行數據流建模，那就再好不過了。真正意義上是數據流定義了芯片。” Lautzenheiser與其它專家也持這些觀點，他們建議一個架構的設計流要從概念級著手：哪些塊應連接到哪些塊？然后可以從這個簡化的連接圖嘗試流的建模，即用塊的ESL建模和使用模型的最可能信息，將數據流量化到數量、標志以及客戶要求。最后，架構師要嘗試去證明片上的互連滿足這些標準。但這是一個反復迭代的過程。Lautzenheiser說：“總是會有驚奇。竅門是在架構設計和實現之間建立一個簡單路徑，這樣你就可以作快速迭代，以及一個足以適應各種變動而無需作重大架構修訂的可擴展基礎方案。” 鏈接與整形 片上網絡的建立有兩個基本工具：鏈接與整形資源。鏈接是為各個塊之間提供數據路徑。它們的實現可以是一個共享總線的一部分、一種專用連接、交換網絡中的一條路徑，或更有創意的方式。整形資源包括緩存、FIFO、排隊引擎，以及再排序緩沖區等。從傳統CPU總線架構轉向更強大方案的最簡便方法也許就是將總線分段。Janac建議說：“在媒體SoC中，可以將流量劃分為低延遲事務、大帶寬事務以及不太關鍵的外設事務。”可以分別處理各種類型的事務，雖然這樣意味著在同一塊上有多個總線連接。Denali Software公司IP產品副總裁Brian Gardner指出，這種方案不僅將每種類型的流量放在與之相應的物理介質上，而且還連接到能以類似方式建模的數據流上，從而大大增加了用于其后鏈接的建模精度。 Lautzenheiser稱，這一過程的結果一般是一個層次化的互連鏈接。這一結果在Raza Microelectronics的網絡處理器中表現得非常明顯（圖1）。當深入觀察一些功能塊時，就會發現一種相似的模式，例如在一只現代CPU內的互連，如ARM Cortex A9。在這里，內部鏈接將處理器核心連接到L1指令緩存和數據緩存。而多主高速緩存總線則將L1緩存連接到L2級緩存，供多達四個處理器核心使用。其它鏈接則用于控制和探測背后的邏輯潛伏。兩個系統總線的連接來自L2控制器。但當無法為每個數據流提供一個正確的物理鏈接時會發生什么？SoC的DRAM控制器就是一個很好的例子，它必須接受芯片上多個處理器傳給它的任何流量混合，但必須設法將這種混亂局面理順，成為DDR DRAM可以接受的、高度有序的指令流。為了說明問題的復雜性，請看這樣一款控制器（圖2）。這個器件在一系列分立級上處理各個事務。首先，一個仲裁引擎根據某種優先級方案，決定對控制器的訪問。然后，控制器將請求裝入指令、讀和寫隊列，它們在隊列中按照服務質量要求和DRAM時序的實際情況，等候重新排序。最后，這些請求傳遞到一個事務處理引擎，它預先檢查隊列，以重組和獲取最能發揮DRAM用途的請求。 對其它功能塊，相同觀點正變得越來越普遍。通常，信號處理或編碼器/解碼器塊包含有復雜的DMA引擎，它提供很多與DRAM控制器相似的功能，如散播/獲取處理、數據重新排序以及將隨機請求轉為突發請求的緩沖等。引擎完成這些功能并不會方便DRAM控制器，事實上它們可能把DRAM控制器弄亂，使流量適合于必須通過的物理鏈接。 結果與未來 全部這些工作的結果很顯著。MIPS總裁兼首席執行官John Bourgoin稱，對基本相同的功能塊，SoC調整的結果可以提高系統性能四倍或五倍。這種加速等級已超過從CPU升級或更快處理中獲得的好處，有時甚至快于增加一個硬件加速器的結果。 當SoC架構從功能區別的異質多處理，向半對稱的多處理器轉變時，對互連架構的專注需求也從增強性能和節能替代方法轉而成為系統設計的一個必要部分。沒有對數據流的詳細分析，一個動態多處理系統可能只是要求更多的互連，從而超過一個合理硅片設計所能提供的水平。 這種可能性使我們回到工具的問題上。Lautzenheiser說，今天架構師（如果他們沒有用白板或電子數據表的話）的工具流是ESL建模工具、基于排隊理論的統計分析（可以給出一個良好的整體圖像，但可能完全錯過角落情況）以及周期精確模型（可以尋找各個角落但可能因太慢而找不出它們）的一個特殊組合。 Arteris的Janac同意這個說法：“你需要架構級的建模。對一個電子數據表來說，問題變得太復雜。但對ESL，即使最好的工具也不具有現實性，它們給出的是一個抽象。因此，你必須將系統級的研究與你的IP周期精確模型捆 綁在一起。” MIPS的Intrater建議，做這種捆綁的一種方法是使用硬件仿真。“周期精確模型是基于RTL，它們用于引導Linux或運行一個應用程序時速度太慢了。今天的最新技術是手工將細粒度的統計工具與周期精確仿真結合起來。但是，如果你在足夠早的階段就擁有互連的RTL模型，那么就可以使用仿真，將周期精確模型運行幾十億個循環。” 這種狀態的工具使架構繼續成為一種藝術。在正確水平上對某種方案建模；擁有來自實際用戶的精確使用模型；找到關鍵情況的正確位置；以及從周期精確模型得出準確的結論，等等，這些都來自于藝術與經驗，盡管系統級工具在逐步涌現，尤其是來自互連IP供應商的產品。但這是一種越來越具生命活力的藝術，當我們步入晶片上大型多處理系統的時代時，它將成為不可或缺的藝術。 附文：問題是總線帶寬還是處理器帶寬 隨著通信與媒體流數據速率的增長，多數芯片設計者很快意識到數據帶寬是設計成功的一個重要因素。Tensilica公司有100個以上的多處理器芯片設計的經驗，它提出了一些基本概念，以解決有關帶寬的疑惑。 例如，不恰當的數據通信會造成原始帶寬的不足：I/O及片外內存的數據通信，片上不同塊之間帶寬共同構成的對持續帶寬的總需求，超出了接口的最大持續帶寬。它還會造成過高的延遲。數據存取的最差情況或典型延遲都會在某些重要場合造成數據饑餓，比如當沒有合適的總帶寬時就會增加競爭延遲。 通信中的瓶頸會出現于設計中的多個地方。三個最常見的位置分別是：片外的內存控制器；片上總線，尤其是當有多個主（特別是處理器和DMA控制器）訪問多個從（內存與I/O接口）時；還有處理器與總線之間的接口。 處理器總線的瓶頸與接口的峰值數據傳輸速率有關，它通常接近于片上總線的峰值帶寬。瓶頸還與如下的數據移動速率有關，即將遠處內存數據沿片上總線或在片外移動，將數據移入本地內存，將數據移入或移出處理器寄存器，通過本地內存移動數據，以及將數據移出到遠程內存等的速率。采用傳統RISC處理器通過片上總線存取數據時，這種數據移動可能每32bit數據字要花費10個"20個處理器周期，即使數據已經在片上，并且處理器在整個路徑中都不修改數據。 打破處理器總線瓶頸有兩種方式。首先，使用第二個總線主控，如其它處理器或一個DMA（直接內存訪問）控制器，將數據移入和移出第一個處理器的本地內存，這樣可以部分解決瓶頸問題。不過，RISC的32bit寄存器與負載存儲寄存器仍有問題。其次，可以擴充處理器接口，使之允許大帶寬的數據流，從而繞過總線接口上的瓶頸。具有直接連接端口和隊列的處理器可以通過處理器執行單元，移動比RISC處理器高一個數量級的數據流。 在復雜芯片設計中，總線互連與非總線互連可以協調工作。最佳的實踐表明，當一個設計者了解到一對子系統需要大互連帶寬和有良好限制的延遲時，他就應該在兩者之間建立一個最佳的路徑。其它通信（包括敏感的子系統間的通信）可以安全地使用一個公共的多主/多從片上總線，用于較低帶寬和延遲敏感的數據移動。這種區分保持了普通總線的通用性，但減少了競爭異常的風險，簡化了建模工作，并且提高了平臺的縮放性能。 對大帶寬鏈接的通信優化亦有助于節省能源。對于處理器與處理器通信隊列之間的直接連接，每次數據傳輸一般比等效的總線傳輸要節能10倍。 |
