huanglenzhi 2015-01-09

SoC設計師常常需要仔細考慮以決定哪種IP核對一個給定的SoC專案最合適。他們必須決定核心的型別（軟核或是硬核）、可交付使用核心和相關產品的質量、IP提供商的可靠性和承諾等。本文將就以上每個環節進行討論，併為如何最好地評估競爭性IP核的特性提供指導。

IP核可以兩種形式提供給客戶：軟核和硬核。兩種方式都可使客戶獲得在功能上經過驗證的設計。軟核也被稱為可綜合核心，需要由客戶進行綜合並在其SoC上實現。而硬核已完全實現（完成了版圖設計），可直接用於製造。（從技術上說，一種設計只有生產後才能實現。但是在此情況下，實現的意思是指安排佈局並可直接投入生產）。SoC團隊只需將硬核像一個單片積體電路片那樣置入晶片即可。軟核和硬核具有不同的問題和好處。

將IP核整合到一個晶片上需要很多步驟。這個過程是否能夠很容易地完成，主要取決於提供的交付成果。另外，客戶不僅必須對IP核進行評估，而且還要評估IP提供商。

軟核與硬核的對比

1。 效能

由於軟核沒有實現，因此它天生在功能和實現方面比硬核更加靈活。另一方面，硬核開發者可能要花更多的時間來最佳化他們的硬核，因為它們要在很多設計中使用。因此，這使人們覺得硬核會提供更高的效能。

事實上，為那些最先進工藝設計的高階、全定製硬核確實能夠提供比軟核更好的效能。透過使用鎖存、動態邏輯、三態訊號、定製儲存器等，全定製設計團隊能實現比完全靜態綜合的設計更好的結果。對於需要達到現有工藝和設計技術極限效能的SoC來說，全定製硬核能夠更好地滿足這些要求。

然而，如果效能目標在一個軟核範圍內，那麼硬核的優勢就無關緊要了。SoC設計團隊能夠使用軟核來滿足效能要求，並利用其固有的靈活性優勢。而隨著工藝技術的進步，軟核的最高頻率限制也在提高，使它們成為更多SoC設計師的一種選擇。在較低時鐘頻率下，硬核或許具有矽片面積方面的優勢。但是情況往往並不是這樣。硬核經常簡單地使用ASIC的方法進行固化，使之不能提供速度上的優勢。在其他情況下，全定製核心不能根據每一代工藝進行重新最佳化，所以削弱了頻率和尺寸上的優勢。

2。 技術獨立和可移植性

軟核的優勢之一是技術獨立的，也就是說，Verilog或VHDL不需要使用一種特定的工藝技術或標準的單元庫。這意味著同一個IP核能夠應用到多種設計中，或現有設計的下一代中。一些軟核提供商採用使其核心技術上非獨立的設計風格，但是這種方式看不到什麼優勢。

圖1：受IP核影響的開發任務。

另一方面，硬核在技術上是非常特定的。事實上，如果代工廠改變其工藝引數或庫，硬核可能就無法正常工作。這就產生了一個風險，因為在工藝引數改變時，IP提供商需要重新對硬核進行驗證。

硬核能夠移植到新的工藝技術，但是重新最佳化全定製核心的工作既費事又昂貴。對於一些先進的微處理器核心，這可能要花兩年或更長的時間。因此，硬核經常根據新的工藝進行光學調整。雖然這一方法既簡單又快速，但是它減少了由設計團隊針對現有工藝進行全定製最佳化的許多優勢。

不僅如此，光學調整同時帶來了另一個風險，因為它只能保證新的設計滿足設計規則，而不能保證準確的時序或功能，而且重新全面驗證經過光學調整的IP核是非常困難的。

3。 速度/面積/功率最佳化

對於要實現的技術來說，硬核通常比可比較的軟核執行速度更快。但是即使對於這單種技術來說，硬核也僅僅是針對一組目標而最佳化。如果目標是在合理的效能上使芯片面積更小，那麼對於這種應用來說，為高度可調效能而最佳化的硬核可能就太大了。

軟核是能夠被“應用最佳化”的。為適合特定的嵌入式SoC設計，時序、面積和功率目標可能需要進行調整。例如：如果SoC使用200MHz的時鐘，那麼設計執行在250MHz的軟IP核心可以改為準確地執行在200MHz上。這在得到更小尺寸和更低功率的同時滿足了設計約束。

這種應用最佳化也適用於低層IO時序。軟核心的IO約束可以進行調整，以準確配合核心的使用環境。如果硬核心有延遲輸出訊號，SoC設計師幾乎無法改善時序。

如果SoC的速度、面積和功率目標與硬核的目標相符，那麼硬核將極具競爭力。但對於大多數設計師來說，軟核在為特定的SoC最佳化方面更具優勢。

4。 可定製性

軟核相對硬核還具有另外一個優勢：編譯時間定製化。這些是實現之前的設計選項。

高速緩衝儲存器的記憶體大小就是一種常見的編譯時間使用者定製專案。根據特定嵌入式應用所需的高速緩衝儲存器的大小，軟核處理器能夠精確地被配置。而硬核在這方面就不能被定製。

另一種在許多軟核中應用的定製專案就是指令專用，或選擇性支援某種特殊指令。例如，一些SoC可能需要對外部協處理器的支援。然而，在一些不使用這些特性的系統中，多餘的硬體可從軟核中去掉，以節省面積和功率。

軟核還可以包括實現配置引數。這是一種特殊的編譯時間定製，可幫助軟核更好地配合SoC團隊使用的設計風格。例如，微處理器核心經常透過使用門控時鐘電路來實現，但這種時鐘不能與某些時鐘佈線工具很好配合。如果處理器核心可提供一種將所有門控時鐘變為相等的多路複用器（MUX）的編譯時間設定，SoC團隊可使實現更為容易。

5。 易於整合

軟核很可能更容易被整合到SoC設計團隊使用的流程中，除非內部設計小組已經實現了硬核。其原因是SoC設計團隊將在他們認可的IP核周圍新增RTL模組。這些核心看上去就像另外的SoC模組，也可像它們一樣地實現。

另一方面，硬核看上去更像一個黑匣子RAM，特別是在它採用全定製技術實現時。這意味著硬核提供商將需要為該核心提供更多的黑匣子模型，使SoC設計師能夠在其周圍設計其模組。這本身就比使用軟核更困難。例如，全定製硬核也許沒有門級網表。這是因為該設計已經在電晶體級完成，而沒有使用邏輯閘。但是設計團隊可能需要透過背注時序執行門級功能模擬，因為缺少門級網表，這將難以進行。

附加提供物

一個有競爭力的軟IP核不只是一個Verilog或VHDL原始檔的集合。出於同樣原因，一個好的硬核也不只是一個版圖資料庫。今天的IP核包含一系列可交付使用的提供物，可使SoC設計團隊將IP核整合到他們的設計中。這些附加提供物的目標是使IP核儘可能容易地整合到設計流程的各個環節。

圖1顯示了採用不同IP核的SoC開發活動。這裡包括了軟核和硬核都必需的一些可交付使用的提供物。

1。 文件建立

清晰和簡練的文件是大多數技術產品的先決條件。然而，需要參考IP核文件的人差異非常大，這使IP核技術文件建立面臨非常大的挑戰。

在圖1中，每一個開發活動都有不同的文件需求。例如，軟體開發者需要了解硬體的可程式設計特性，但他們可能不關心它是怎樣實現的。因此，一組好的文件可使軟體開發者更容易發現他們所需的資訊，而不致被大量無用的資訊困擾。

最後，如果SoC團隊要為能複用部分IP核文件的SoC建立文件，IP提供商應該提供可編輯的原始檔和引用權。

2。 介面檢查器

SoC團隊必須設計邏輯，以便與不同訊號和IP核協議進行介面。為了確定其設計是否正確，IP提供商能夠提供介面檢查器模組，以驗證所有介面訊號和協議的正確執行。它可能與確認不變的靜態訊號一樣簡單，也可能像驗證多週期匯流排協議的正確執行一樣複雜。

這些檢查器透過自動驗證給定介面處理型別是否正確執行的工作，大大簡化SoC團隊的工作。在一個非法處理的情況下，檢查器應該報告錯誤，使SoC設計師能夠容易地查明有缺陷的邏輯並排除故障。介面檢查器必須在SoC設計環境中準確工作。它們應該能夠非常容易地整合到功能模擬中，而不是以一種實際硬體的形式出現。

3。 協議製表器

IP提供商能夠提供另一種交付成果使介面驗證變得更加容易，這就是協議製表器。這是一個監測介面處理的模組，可觀察到各種特殊狀況。協議製表器儲存所有可見的處理型別並報告沒被執行的“邊際”（corner case）。IP提供商必須提供一個進行介面完全驗證所需的邊角情況表。

在開發過程中，協議製表器將幫助SoC團隊決定哪些“邊際”情況需要繼續驗證。一旦開發結束，它同時確保通知SoC團隊已經執行了所有必需的“邊際”情況驗證。由於IP提供商對核心介面具有最佳的理解，這個“邊際”情況表將比SoC團隊能夠想象的任何方案更加完善。

4。 RAM檢查器

如果一個IP核擁有SoC團隊必須編譯和整合的內部隨機儲存器，在處理過程中有可能引入瑕疵。排除由深度嵌入式RAM導致的故障對於SoC團隊是一件非常困難的事情，因為它經常涉及透過核心模組跟蹤故障的工作。RAM檢查器能夠大大簡化排除RAM模組導致的故障的工作。（當SoC團隊不得不透過一個IP核來排除故障時，這是一個非常糟的情況。他們應該能夠信賴它的正確執行。）

5。 快速模擬模型

對於SoC設計師來說，用一個大型IP核的RTL模擬完整的SoC可能非常緩慢。如果IP提供商能夠提供一個週期精確的核心快速功能模型，客戶將從更快速模擬、更快速除錯及更少地使用模擬授權中獲益。即使是一個非週期精確的模型，對於大多數SoC設計和除錯已經足夠好了。只要最後執行週期精確模型，在開發過程中就可以從快速功能模型中受益。

6。 EDA工具支援

另一個核心質量指標是EDA工具的支援情況。由於不同設計團隊可能使用不同的工具，支援多種EDA工具的多種形式的可交付使用成果是目前先進核心經常能提供的。

例如，一個IP核使用Verilog設計而成，但那些使用基於VHDL的EDA工具和方法的客戶仍會要求VHDL。如果一個核心只針對Verilog，那麼SoC團隊在使用該核心時，將不得不忍受一個麻煩且容易發生錯誤的轉換過程。

此外，IP提供商應該提供比需求格式更多的東西。不同的EDA工具可能有標準格式的不同實現方法。在以上的例子中，IP提供商不能僅為Verilog客戶提供Verilog RTL，它必須支援客戶使用特定的Verilog模擬器。否則，該客戶可能要除錯與IP提供商所用的略微不同的Verilog模擬器相關的設計問題。

這個概念實際上適用於所有交付成果。對於硬核，這個概念同樣可在實現階段應用。硬核必須以一種被SoC團隊後端工具所支援的形式提供。而且IP提供商必須支援客戶使用的特殊後端工具。

對硬核來說，這個概念在實現階段同樣適用。硬核必須以能被SoC團隊後端工具支援的形式提供，而且IP提供商必須支援使用特定的後端工具。

7。 EDA指令碼例項

為了幫助快速展開各種設計活動，IP提供商應該提供所支援EDA工具的例項指令碼。這是IP提供商幫助SoC團隊有效地使用IP核進行系統設計的另一種方法。該指令碼可能如makefiles一樣簡單，可實現彙編功能模擬器。這些指令碼也可能如一個全套的、針對功能迴歸執行的自動化設計指令碼一樣複雜。在任何情況下，例項指令碼對於SoC設計師來說總是很有用。

對於軟核來說，例項綜合指令碼幾乎是必要的。至少它們應該提供頂層約束、故障路徑和多週期路徑。如果可能，應該同時提供實現若干工業標準綜合方法學的指令碼。當然，這些例項指令碼越簡單，對於SoC設計師來說就越容易理解、進行修改並整合到他們的流程中。

8。 功能核心驗證

雖然SoC設計師不會修改軟IP核的RTL設計，但是他們確實會改變作為晶片設計常規部分的一些功能。這樣的例子包括掃描連結插入、時鐘快取和RAM BIST整合。SoC設計團隊需要驗證這些改變不會對核心的正確執行產生影響。

驗證新設計在功能上與以前設計沒有改變的一種方法是採用IP提供商提供的測試基準和測試套件，以全面驗證核心是否正確執行。不幸的是，對於許多核心來說，完整的測試套件太大了，以至於不能作為IP核的一部分來提供。因此，大多數IP提供商選用完整驗證套件組的子集，它同樣能夠驗證執行。大多數情況下，對於發現那些由以上設計變化型別引起的錯誤來說，這個子集已經足夠了。

然而，形式驗證工具對於保證正確執行是一個更徹底的方法。這些工具可精確地驗證新設計與老設計的相同之處。支援形式驗證工具可使SoC團隊無需執行門級迴歸。

9。 軟體協同開發工具

為新系統開發軟體的標準方式是，首先生產硬體樣片，然後開發執行在上面的軟體。然而，在很多情況下這延長了產品上市時間，因此軟體開發經常與硬體開發平行進行。

軟體開發比硬體開發需要快得多的系統模擬。因此IP提供商必須提供一個非常快的IP核功能模型。這為低層韌體的開發提供了足夠的效能。

對於更高的模擬速度，有時會使用硬體邏輯模擬器，它可比純模擬快一個數量級（雖然這仍然比實際硬體慢2至3個數量級）。這些工具非常難用，而且需要特殊的綜合。對於計劃進行硬體和軟體協同開發的SoC設計團隊來說，支援這些技術是對IP核的一個關鍵要求。