為了應付日益增長的復雜性，必須提高抽象的水平。但當摩爾定律將SoC（系統單芯片）的復雜性加速到逃逸速度時，哪里能找到一種作為RTL（寄存器傳輸級）補充的新抽象方法？很多觀察家注意到，面向硬件的文本式RTL可替代邏輯圖，從而推斷認為某種系統級描述語言（如SystemC）將提供下一個好的抽象。不過這種情況并不會出現。

Atrenta公司主席、總裁兼首席執行官Ajoy Bose認為：“可重用IP（智能產權）才是新的抽象等級。”如果看看SoC設計團體正在做的工作，就會發現，創建SoC的過程就是對以前所用IP的尋找、特性確定和裝配過程。無論是哪種設計創建工具（SystemC、Verilog亦或邏輯圖），都只是扮演一個填充空白的角色，如專利功能以及IC的締結組織結構。但正如大量EDA公司、代工廠和大多數SoC設計者所想象的那樣，今天的設計流已經緩慢地認識到了這個現實。看一下自己的工具，你就會知道每個SoC都開始于一組功能需求，以及一張白紙。實際上，要考慮的是一個SoC設計中真正做什么，以及從這些觀察數據中可以抽象出什么結論。

新的抽象

Synopsys公司主席兼首席執行官Aart de Geus喜歡樂高玩具，他還喜歡用它們作為硅IP的比擬。他指出，將IP裝配起來創建一片SoC，就像把樂高積木塊裝成玩具一樣。IP塊是其中的RTL抽象，就好像樂高積木塊要比用塑料或木頭，去手工制作出一艘船或一只恐龍來得簡單。這種模擬可以一直做下去，直到開始無效。

樂高積木（尤其是高價主題包中的精密積木塊）也可以體現出以IP為中心的設計流應該是什么樣子。最開始是需求，這與傳統設計流沒有兩樣。但以IP為中心的設計流很快就會與傳統方式分道揚鑣。在傳統流程中，要將需求劃分為更小的模塊，仔細地定義接口，直到這些模塊足夠小，使RTL設計師能用Verilog編寫它們。而以IP為中心的流程則幾乎相反：你要選擇適用的IP塊，將它們與需求匹配，就像裝配樂高積木一樣。你要嘗試盡可能用較少的塊，留下的空間盡量少。然后用新代碼填充這些空白。

設計流程再繼續下去，兩種方案仍然是各行其道。傳統流程經過了功能驗證，綜合，分析，時鐘、電源和測試的精細插入，后端設計以及收斂，這些過程都在不斷去除抽象，創建更多的實現細節，直到需求變成為多層的多邊形。在每個新的級別上，流程都要停下來，驗證該設計是否仍然滿足需求。

而以IP為中心的流程再次走了幾乎相反的道路。它的要點是將IP裝配為一個滿足需求的系統，而盡可能少地尋求有關IP細節的新信息。Bose稱：“在裝配過程中不要陷入調試IP的誤區。”

這種情景對很多團隊都很理想，富有吸引力。de Geus說：“例如在中國，設計方法研究的就是如何快速地從定義走到IP列表，再到裝配。”

但現實情況通常并不是這樣。Open-Silicon公司工程副總裁Taher Madraswala說：“至少今天有些功能有很好的定義，理論上你本可以在整個流程中把它們看作黑箱子，但也僅僅是理論上而已。實際上，最終還要在綜合與門級優化時打開黑箱子。”為解決這些問題，必須遍歷一個理想的設計流，找到希望與現實之間的差距。你必須考慮IP選擇、裝配、實現和收斂。

IP選擇

從需求到一個IP BOM（物料清單）的過程是變化的，而且很不幸要手工完成。如何從A到B取決于系統的性質、IP的可用性、設計團隊在重用方面的經驗、芯片差異化的營銷計劃，以及企業策略等等。這個過程不能依賴的一件事是自動化，Synopsys公司的de Geus指出，理論上說，自動化應不存在障礙。

他發現，在RTL時，Design Compiler能從Verilog源中有效地找出該公司DesignWave的相對復雜塊。不過，對于較大的IP塊，自動化就不穩定了。他說：“用IP時，塊都不太通用，要加入更多的人工選擇。”

有些情況下，手工IP選擇的輕松程度可以接近于自動化工具。例如，很多較小的SoC仍然采用一種簡單的、類似于微控制器的架構：一個CPU核心、一個本地緩存，還有一系列外設接口。所有需要的塊一般都能從第三方IP庫中獲得，再補足AMBA（先進微控制器總線架構）接口的管腳，就可以插接到一起了。對于其它情況，IP的選擇并不能從需求明顯看出。例如，假設一個智能手機SoC有多種授權與加密的要求。你是獲取一個大且昂貴的第三方加密引擎許可證，還是選擇一個較小的加密數據路徑協處理器？另外，你是用MathWorks的MatLab開發自己的塊并做綜合，還是采用一個較快的（或第二個）CPU核心，并用軟件處理需求？

功能的選擇并不是過程的結束。功能類似的模塊之間可能有很多方面的差異，包括性能、面積、功耗、接口要求、可配置性、對時鐘與電源控制的條件、驗證覆蓋范圍以及使用史。IP塊的數據表中應有很多這類信息，但有些需要詳細詢問該塊以往的用戶，甚至要做少量反向工程。

要從一個可執行的SoC需求文件去推論出一個復雜IP塊，這種邏輯問題也許是可以解決的。大多數需求文檔仍然采用人類語言，不過并非可執行格式。此外，選擇某個IP所需要的多數支持性信息也是零散的，缺乏標準的格式，并且可能是專有的。顯然，自動IP選擇還需要做大量工作。

現在存在一種非常有趣且大部分尚未披露的可能性。通常人們認為形式驗證是相關的驗證工具。但據Jasper設計自動化公司營銷與業務發展副總裁Oz Levia稱，形式上測試某個特性真實性的能力擁有超出傳統驗證的應用。例如，設計者可以用Jasper公司的ActiveDesign在開發期間研究RTL，有助于掌控RTL代碼的創建。從這個想法擴展開去，Levia描述了Jasper與ARM工程師如何合作起來，將針對ARM存儲器相關協議的英語規范手工轉換為一個可執行的規范，Jasper再將它綜合為一組斷言。原理上說，一個設計團隊可以使用這個過程，從需求創建出一組斷言，然后再用形式工具檢查一個IP塊與需求的符合程度。可編程IP或可配置IP都會帶來挑戰，但過程中至少會產生一個將IP塊裝入一個設計的工作說明。

裝配

IP裝配是以IP為中心設計的流程基礎。有些設計者使用“裝配”，而不是“集成”，以示一種重要的區別。在這個階段的想法是，將IP塊看作是可配置的黑箱，而只編寫一些在完成黑箱配置后，要將它們膠合到一起的RTL。這種情況與“集成”這一名詞所代表的日益膨脹IP塊有很大不同。

理想的裝配過程必須開始于系統級仿真。在另一個意義上，系統仿真就是IP選擇的驗證階段：你要檢驗所選擇的IP塊是否能以一種滿足系統需求的方式聯結在一起。de Geus說：“在一個IP裝配流中，系統校驗與驗證更加重要。通常，我們需要一個快速的原型來驗證軟件可以在芯片上工作。”

快速原型的重要性表明，IP塊的事務級模型可能很有價值。但IP供應商有時并沒有事務級模型，或這些模型對現有IP版本不再正確。不過，你幾乎總能用到軟IP的RTL源，從而創建基于FPGA的快速原型，這就是FPGA原型對IP中心化設計的重要性。

另外，還可以在裝配期間做另一種早期評估。靜態分析可以檢查IP有無違背規則，是否符合最佳實踐。評估通常可以相當接近于最終芯片的功耗、性能和面積。Atrenta公司的Bose說：“今天，使用高等級綜合的結果要比用軟IP有更多的不確定性。”

在一個理想化的世界里，一旦將各個塊裝入原型，驗證了系統的性能，并研究了大致的特性，則要做的唯一驗證工作將是現有塊和新塊之間的連接情況。但不同的情況下，對于理想的接近程度也會不同。

也許最接近于理想的方案是：IP、互連，以及IC實現全是一個來源（圖1）。附文“FPGA的情況”是這種情況的一個實例。真實世界里確實能有這種好運氣，但僅適用于那些有強大的設計重用文化的垂直型集成公司，如IBM、意法半導體、幾家最大的日本公司，以及在私募投資者重新關注自己優先權以前的恩智浦和飛思卡爾。如果沒有強大的企業重用文化，以及公司對IP開發過程的控制，很難獲得一種純粹的黑箱裝配流程。Bose說：“人們仍然懶于做實現重用所需的少量額外工作。”他表示日本的STARC（半導體技術學術研究中心）提供了一本出色的重用手冊。不過，有些開發IP的團隊缺乏訓練與管理支持，不能在這個等級上使自己的設計可重用化。

下一個最接近理想環境的就是工業標準（如AMBA），它定義了塊間的全部互連，還有所有符合標準的IP（圖2）。此時，裝配只是要確保信號名稱以及極性一致，并且所有接口都可以工作在所要求頻率上。如果沒有一個統一的總線標準，則事情就變得更復雜了。你必須根據已配置IP塊的實例去了解接口，必要情況下，還要創建額外的RTL膠合邏輯，以執行各塊之間的事務，并且必須驗證所有這些工作。

Open-Silicon的Madraswala稱，關鍵是尋找到一種驗證交互作用的方式，而不用驗證IP的所有內部東西。他說：“你可以利用IP以前已被用過這一事實。看看自己的計劃日期表，決定把自己的驗證時間花在什么地方。你可能更愿意編寫斷言或測試，來驗證IP數據表中的邏輯集成要求，而不是做一個全面的驗證計劃。但要知道檢查什么和不檢查什么，經驗很關鍵。”Madraswala補充說，這種驗證方案對仿真的依賴高于形式工具。

實現

在這一點上，IP中心設計流開始與傳統流程重新匯合了。軟IP塊、新的塊以及互連都要去做綜合，并進入掃描插入、布局與布線。硬IP也進入了布局布線的流程。然后，團隊關閉設計。不過，在某些方面，IP為中心的設計仍有自己的獨特性。

Madraswala認為，差異之一是電源管理的方案。他說：“針對電源管理的設計調整正在成為設計流的一個獨立階段。這正在成為一種獨有的藝術與技術。”Madraswala解釋說，當你自己設計一個塊時，可以使用綜合開關，做再對位以簡化時序；做精細粒度的時鐘門控，以及其它網表級的優化技術，其中大部分可獲得功耗的優勢。

舉例來說，其它工具可以改變時鐘的偏移，以控制峰值的時鐘電流。Teklatech公司首席執行官Tobias Bjerregaard說，用綜合開關也可以做一些此類工作，但工程師們仍然會手工完成這些任務。所有這些技術都非常有用，但全都用于第三方IP也許并不明智。

Madraswala稱：“我們可能沒有原始源碼，因此無法做等效性檢查。通常我們沒有權利去改變塊的設計。”問題是，對一個許可證優化到何種地步，才會違反一個IP塊的保證條款，這件事很難確定。

Synopsys公司的de Geus也懷疑對等效性檢查器的依賴性，但原因不同。他說：“形式工具不斷地尋找可以生成的綜合。例如，綜合工具可以做延遲瀏覽，但形式等效性檢查器卻可能看不到與原電路等效的重組電路。 ”

相反，Open-Silicon的Madraswala則建議在塊級對IP使用時鐘門控與電源門控。他解釋說：“我們圍繞代碼放了一個封裝器，讓它表現出我們想要的方式。”這種方案避免了修改第三方的代碼。Madraswala說，物理設計仍保持傳統方式。硬IP塊加入了布局布線流程，具體要依賴于供應商的集成指導。Madraswala說，他的公司會對塊運行一個DRC（設計規則檢查），以確保它符合當前的規則平臺，并與供應商對集成進行目視評估。他說：“有時候，他們尚未寫好有些指南。”Open-Silicon在這個過程后會做一個平面設計的DRC，但Madraswala稱，99%的情況下不會有任何問題。

相對來說，后端流程從基于IP的設計獲益不多。除FPGA設計以外，都不能省略DRC、提取或時序、信號完整性，以及功率完整性的收斂。在這些領域中，仍留有太多的技巧和細節，如不同的約束、電源管理策略以及DFT（可測試設計）方案。這些差異可能只在集成后的芯片上才體現出來。不過，仍然存在著以IP為中心設計流的理想情況，這就是選擇并嵌合起多個塊、驗證互連，然后按一個鍵就獲得了最終設計。

這樣一個流程要求非常訓練有素的IP設計人員。de Geus認為：“樂高積木的智力只限于思考插頭與插座，但這只走了一半。另一半是弄明白如何保持非常嚴格的公差，使插頭與插座可以反復再三地工作，而不會卡住或松脫。”這也適用于以IP為中心流程的進一步自動化：能與門控起到同等作用的也許就是提高IP的標準化水平和創建技巧。