3 v# J- ^# Y8 [- z 軟核的其中一項優點就是製程技術獨立性。高階的Verilog或VHDL程式不需要運用某一特定的製程技術或標準的單元庫（cell library）。這意謂同一套IP核心可重複應用在多種設計，或是未來新世代的設計方案中。（部份軟核IP供應商開發出針對特定製程的方案，讓其核心不具製程技術的獨立性，但這種模式的優點尚不明確）。6 v6 l: d0 q/ y7 q9 _4 l
& q# [" {9 W) M# v+ q
另一方面，硬核則具有相當高的製程技術特定性。事實上，若晶圓廠商變更其製程參數或單元庫變數（cell library factor），硬核有可能就無法正常運作。因為IP供應商在製程參數改變後，須重新檢驗硬核，所以這種特性即衍生出運用上的風險。 0 l$ ]* ]- C: W, [) p0 ?, b2 ^# |! n; ~" K- I
硬核可移植到新的製程技術，但須投入相當可觀的心力與成本來重新進行最佳化調校。對於某些先進的微處理器核心而言，須耗費兩年甚至更長的時間。因此，硬核的尺寸通常會針對新製程等比例縮小。這種方法雖簡單且迅速，但可能減低研發團隊針對最初製程進行的最佳客製化效益。& o- o, ^) r; H
. B& E, m6 z+ F# x7 G& Y8 q# U9 \ 此外，光學等比例縮小的作法會衍生額外的風險，因為它僅保證新設計能符合設計規則，但不保證正確的時序或功能。由於光學比例縮小是超捷徑式的設計模式，故業者在重新檢驗這類IP核心時會面臨很大的困難。; E. I5 ]( ?8 `: P
, S% z6 _2 B+ V2 c
事實上，軟核可能是針對單一製程技術與單元庫為設計依據，設計本身與此一技術無關。針對製程技術與單元庫提供最佳的效能，類似的技術可能達到接近最佳化的成效，但是差異性較大的技術（例如搭配速度較慢的RAM）可能就無法達到相同的結果。此種現象並非絕對重要，所以軟核在最佳化的彈性方面優於等比例光學縮小的硬核。 C! l! v7 U2 V- L
) _' }+ u) x2 P, g u" t: T* v ■速度╱尺寸╱功耗最佳化調校 $ n! @3 J! E1 p8 ~9 Q* r! h' U2 a2 D' ?& k+ y0 Y
硬核在IP供應商進行建置時已做了一次最佳化。因核心僅進行一次最佳化，故IP供應商可投入較多的資源。因此，硬核的速度通常高於採用相同建置技術的軟核。即使運用單一技術，硬核僅是鎖定一個最佳化目標。若希望在合理的效能下降低晶片使用面積，則進行大幅效能最佳化的硬核，其面積可能過大。 " I0 |. ]! A; X" A ' j: T: I h. J) j M 相反的，軟核能進行「應用最佳化」的調校。時序、尺寸以及功耗率目標可機動的調整，以配合特定的嵌入式SoC設計方案。例如，若SoC運用200MHz的時脈，則原本為250MHz的IP軟核應將運作時脈調整為200MHz。這種作法能減少使用面積與功耗，同時也符合相關的設計要求。. F9 \% Y; A& H4 Y, U2 N
/ e" U, s9 [: F0 F8 x7 V3 I 低層級的I/O時序部份也可針對應用做最佳化的調整。軟核的I/O速度可配合核心所處的環境進行調整。反之，若硬核的輸出訊號較為遲緩，SoC研發人員就沒有太多可以改善這類時序問題的方法。$ c! }7 `& n4 ~6 {# p
3 W2 v, q: I( M g$ \/ z# Z
若SoC的速度、尺寸以及功耗率即為最初硬核的目標，則這套硬核就能具備競爭力。但是對大多數的設計而言，軟核較能針對特殊SoC進行最佳化調校。 2 |6 ]% I' T6 P4 R4 D4 W * j R8 N9 \* \7 U; ~ ■客製化彈性, p- [. H: n5 v( l) N
9 B% F0 h% a' C9 c5 k 軟核另一項超越硬核的優勢就是：編譯當時才做客製化，在建置之前，可自行選擇許多設計選項。1 m. D/ n }, }( _' X u6 n
8 l, \8 V- F0 ~; D" ^
快取記憶體大小是編譯時常見的一種客製化項目。軟核處理器讓使用者選擇其特定嵌入式系統所需的快取記憶容量。而硬核則無法進行這種客製化設定。& B, e! u6 u4 d. k% W6 @
. ]3 G8 j2 l( N+ {2 t8 K
許多軟核具有的另一種客製化設計就是自行定義指令集，也就是自行支援特定指令的功能。例如若SoC有特殊需要，可使用外部協同處理器，有些系統或許需要運用具有壓縮功能的指令碼，但若系統不需要這些功能時，這些多餘硬體就可從軟核中移除，以節省晶片面積與功耗。% w- U$ u* N) a: Q5 U1 c
& U( S3 }/ X4 I3 H; Y 軟核同時也有一些建置組態參數，這些特殊的客製化參數能使軟核進一步融入SoC團隊所進行的設計環境。例如，微處理器核心通常運用邏輯閘時脈電路進行建置，但這種時脈可能無法搭配部份時脈路由工具。若處理器核心有提供編譯時的設定功能，能將所有邏輯閘時脈變更成等效的再流通MUX（多工）元件，就能減少SoC團隊建置過程中所遇到的困難。, ] `# F8 v* R- e- q& M3 ?
8 L$ K% y1 f: D: @ o( B# v4 c8 C H
■整合的難易度- r! u* B8 D' a' ]3 ?1 v
* F; f$ m9 A1 J
除非硬核由內部研發小組所建置，否則軟核通常比較容易整合至作業流程。其原因是SoC研發團隊將在獲得授權的IP核心週圍加入各種RTL模組。此時核心就如同SoC中的其它模組，亦能採用相同的建置處理方式。" _$ S* z, O- b9 X
; k+ M7 P5 F+ f- l( [) w 硬核比較像一個黑箱RAM元件（black-box RAM），尤其是採用全客製化技術所建置的核心。這代表硬核供應商須提供更多的黑箱式核心模型，讓SoC研發業者能針對這些處理器設計其模組。這種流程應用難度原本就高於軟核。例如，一套全客製化的硬核可能沒有邏輯閘層級的電路清單（netlist）。這是因為設計工作是在電晶體層級中進行，並未涉及邏輯閘。但設計團隊可能需要做含有回饋（back-annotated）時序機制的邏輯閘層級功能模擬測試，此時若缺乏邏輯閘層級的電路圖就很難進行這種模擬。（本文由MIPS Technologies, Inc.提供）作者: masonchung 時間: 2007-8-4 11:34 AM 標題: 研發SoC 核心CPU技術該挑軟？選硬？(下) 研發SoC 核心CPU技術該挑軟？選硬？(下) : Z# K, m7 g# n% ^# M6 k7 m如何評估、選擇IP產品及供應商 % L7 }0 i$ a9 C( ^. r# x8 S; Y, f& s5 X. Y3 e( J
評估IP廠商提供的附加材料. r' ~5 Z" L+ u. d9 \# u. n
% f8 Y; k: @; p! d7 A8 ?/ ]
高競爭力的IP軟核不僅只是一套Verilog或VHDL程式碼。同樣的，完善的硬核也不僅只是一套電路配線資料庫。現今的IP核心包含一整套的技術文件及技術支援副物，讓SoC研發團隊能將IP核心整合至設計方案中。這些附加材料就是要儘可能簡化IP整合至各個研發流程的作業。 ( `. O. n' V+ V4 |7 e% t8 r% o" O, a9 W! Q1 F
■技術文件4 h4 y: a* L- J5 y9 h) _
4 ^. w# c3 A- D4 k: z W
明確的技術文件是大多數技術產品必要的先決條件。然而，各種人士對於IP核心文件的需求差異相當大，且需要的文件數量也相當多，讓業者在提供IP核心文件時面臨極大的挑戰。 $ i \( p* i; E+ T) Q, C ) B1 ~# B# S" c# a5 @ 每種研發作業都有不同的文件需求。例如，軟體研發人員需要瞭解硬體的撰寫特性，但可能不必瞭解硬體如何建置。因此，妥善整合的文件讓軟體研發業者能輕易找到所需的資訊，而不必逐一閱讀本身不需要的資料。( M, ?9 l% b2 ^! {
. [! L1 B' S U% H q+ |! b 最後，若SoC團隊須為其SoC撰寫技術文件，則可能需重複使用到部份的IP核心文件，IP供應商應提供可編輯的文件原始檔案，並授與客戶節錄核心文件的權限。 9 [; z8 X2 }: L$ B . z( d) k' g, O# e* | ■介面檢查器 * ~8 M3 k0 f. }& {0 k0 t5 G9 p c+ Z' w
SoC團隊需做邏輯設計來與各種IP核心的訊號與通訊協定建立介面，為判斷設計是否正確，IP供應商可提供介面檢查模組，檢驗所有介面訊號與通訊協定是否正常運作。其流程可能僅是單純的確認靜態訊號沒有被改變，或是複雜到檢驗多重週期的匯流排通訊協定是否正常運作。 * W/ I) }) I1 @; S" O / P( l* ^ {! Y4 Y6 W' G& m; q 由自動檢驗特定種類介面的運作是否正確，這些檢查器能大幅節省SoC設計所耗的人力與時間。若發生錯誤的運轉動作時，檢查器應指出錯誤狀況，讓SoC設計師能輕易找到有問題的邏輯並排除故障狀況。2 m; W5 `* d+ s/ n: n! j" [
* s2 X0 y- h0 `7 ?3 ]9 U
介面檢查器並不存在於實際的硬體中，可是必須在SoC研發環境中正確運作，也必須能輕易整合至功能模擬的流程中。% U8 B) i+ C7 [4 f4 U
9 P- I' Z' ]; v/ z' v
■介面規範的列表（Protocol Tabulators）2 E% J. u, p$ ^" b# L- Q
, e) ?' T7 k! U# _) v" l IP供應商可提供協助簡化介面檢驗的另一類資源就是protocol tabulator。這種模組能監視介面交易以及監看各種特殊運轉狀況。protocol tabulator能記錄所有交易類型，並回報尚未遭遇的特殊運轉狀況。IP供應商須提供一份各類特殊運轉狀況清單，以達成介面完整檢驗。, O2 c3 n( ^6 R; J! l
7 a) b3 d0 `5 T" r3 [+ F' O 在研發階段，protocol tabulator能協助SoC團隊判斷那些特殊運轉狀況尚未進行檢驗。當研發完成後，它亦能讓SoC團隊確認已執行所有必要的特殊運轉狀況。由於IP供應商最能掌握核心介面的技術，故其特殊運轉狀況的清單會遠比SoC團隊自行擬定的還要詳盡。 $ }1 t: _4 Z3 M1 s' b$ z 6 _/ ]+ L4 i/ Y( b6 s ■RAM檢查器 ) v6 `3 C$ k2 \5 ^- n( Y0 M ) L# ] O3 [$ [, @2 h 若SoC團隊須編譯與整合IP核心中的RAM記憶體，過程中可能會造成某些錯誤（bug）。要找出深層嵌入的RAM所衍生的錯誤，對SoC團隊而言極為困難，因為這些問題通常需要涉及內部核心模組的訊號追蹤，而RAM檢查器就能大幅減輕此類除錯的負擔。透過迅速偵測RAM模組介面上的錯誤，SoC團隊能避免進入IP核心的內部進行除錯，並快速解決RAM內部的問題（SoC團隊應當擁有正確無誤的運作模式可供使用，以避免針對整個IP核心進行除錯。） ( y' K) W0 {4 Y( h; I ! \, O7 Y( b! a8 h$ V" h; P; M u! e ■高速模擬的模型* D V& U- M8 g3 _& B7 M
& k' b0 x& O; O& R" P
對於SoC研發業者而言，運用大型IP核心中的RTL模擬整套SoC，其速度可能相當緩慢。若IP供應商能提供一套核心的快速功能模組，且能精準模擬運作時脈，則用戶將可享受更快的模擬速度、更快的除錯作業、以及使用較少份的模擬方案授權。即使是時脈不精準的模組，亦足以協助業者進行大多數的SoC研發與除錯工作。只要模組能在最後一回達到精準的時脈，快速功能模擬模組就有助於研發工作的推展。+ t3 H: G C3 \5 H0 O# j# J( S
. y( g/ l) C; E* f+ z
■EDA工具支援 s: H( f' r& V/ X$ o8 { / w1 e3 ^: F, j) z 另一項評斷核心品質優劣的標準就是EDA支援工具的廣度。由於不同研發團隊需要運用不同的工具，現今各種高階核心通常會支援各種不同的EDA工具。 7 w( t8 c/ w2 p8 g( F1 z4 o, R' S* \1 [. j/ S
舉例來說，即使IP核心是使用Verilog語言來設計，對於使用VHDL語言及EDA工具與技術的顧客而言，他們需要支援VHDL的方案。若核心僅提供Verilog的支援，則SoC團隊須進行繁瑣且容易出錯的轉譯過程才能使用該套核心。 - v, G! M3 I9 b- H, u. h) l3 T+ ~" \; C4 ^2 H; _$ w3 |: B5 A1 D' |- P
此外，IP供應商應提供不同格式的支援。不同的EDA工具可能有不同的建置規格。在上面的範例中，IP供應商不僅應為Verilog方案顧客提供Verilog RTL文件，且此文件須是針對顧客用的Verilog模擬器。否則，因模擬器的執行狀況可能與IP供應商自己測試時有所差異，顧客可能須針對Verilog模擬器衍生的問題進行除錯。 ; S, b! ]$ s! n! J% S7 v3 J% R: H0 ?9 e3 M3 g* a6 N. S2 m9 w
這種觀念幾乎可應用在所有的IP。對於硬核而言，這種觀念亦適用於建置階段。硬核提供的格式亦須是SoC團隊後端工具所能接受的格式。IP供應商須針對使用到的後端工具提供支援。 4 l. W0 J7 O6 h7 Y7 Y/ g0 j: Z% Y$ r. C3 i
■EDA Scripts指令檔範例 6 l0 D, S" M6 a z& u; p. z& h( E, E) a# i0 q+ i
為協助顧客立即開始啟動各種研發作業，IP供應商應針對所支援的EDA工具提供範例指令檔（script）。IP供應商可透過這種途徑讓SoC團隊有效率地運用IP核心進行研發。指令檔可以僅是makefiles的格式，然後編譯成功能模擬器。也可以是一套複雜的指令檔，用來自動執行各種功能的重新驗證。不論是那個種類，範例指令檔幾乎永遠都是SoC研發業者最有用的工具。1 Y) l: d8 \/ o2 x. c
. Q0 j( Y) J# q' X9 d7 U 對於軟核而言，合成指令範例幾乎是必要的。它們至少應包含置於最頂層的限制宣告、不符條件的false-paths、以及multi-cycle paths。可能的話，範例亦應包含種業界標準的合成技術。當然，範例指令檔若愈簡化，SoC研發業者就愈容易瞭解、修改、以及整合至其合成步驟中。, f" m0 Q Z, f0 s D& [1 q* E# R7 h
0 Y) t: J/ A* C, N' X5 G8 C: d
■功能核心檢驗 ! p3 H# c8 S: i! w 0 d; i8 k/ _" F 雖然SoC研發業者不會變更IP軟核中的RTL設計內容，然而在正常的晶片開發流程中的確會變更部份的功能。變更設計功能的例子包括插入掃瞄鏈（scan-chain）、時脈緩衝、以及RAM BIST。SoC團隊須能檢驗這些變更沒有影響核心的正常運作。% C- K! q j) Q: ^
. P5 _7 T- ?4 }8 L; W0 `, E. j1 D
欲驗證新設計變更沒有影響到原來的設計，其中一種方法就是IP供應商提供一個能用來驗證核心是否正常運作的環境與測試方案。不幸的是，對於許多核心而言，完整的測試方案本身過於龐大，不適合作為IP核心的附加方案。因此，大多數IP供應商選擇提供部份的檢驗方案，能用來檢驗核心是否正常運作。大多數的情況下，這類子集合方案已足以用來偵測在變更後所可能衍生的任何錯誤。 / t7 i; x6 ?- z( s0 f + d! s4 d" O* Q- S 然而，用正規驗證工具（formal verification tool）在確保運作正常的檢驗流程會更加完整。此種工具用數學方法來證明新的設計方案與原有的核心功能相同。支援正規驗證工具讓SoC團隊不須重新執行上述的邏輯閘層級檢驗作業。 0 e+ g/ s9 B @& X2 F& @3 R - q# l, e! G( T7 Y# A' n6 V ■軟體協同開發的工具 7 E! F( C0 G- Z4 J0 h) r0 D8 P/ u4 {" q# W
針對新系統的軟體開發標準流程是先製造硬體樣本，然後再開發軟體於此一硬體上執行。在許多狀況下，這種流程會延長產品上市時程，因此軟體研發通常與硬體研發同時進行。+ H$ \' e( c+ S2 m; d
2 n& W" Y6 ?" s4 c+ W8 z; f
研發軟體比開發硬體更需要快速的系統模擬機制。因此，IP供應商須提供極快速的IP核心功能模型。這種模型方案能提供充裕的效能以滿足低階軔體的研發需求。 0 v& g2 d8 O# [6 J# ~: H6 H/ Y1 f0 d% n5 L
面對更快的模擬速度需求，業者有時會運用硬體邏輯模擬器，其執行速度超過純軟體模擬系統（雖然它們的速度仍比真正的硬體慢2到3級）。但眾所皆知，這些硬體模擬器很難使用，且需要進行特殊的合成。對於計畫同步研發硬體與軟體的SoC團隊而言，這方面的技術支援是IP核心的一項必備條件。$ Q* L f, t! m3 ~3 A/ u4 ^8 e, C+ \
6 }6 X+ \4 o+ Q, F! b
如何評鑑IP供應商( r. b3 ^ C' G; `' t3 \
! a3 [. `5 }# B% s$ I
市場上有許多供應IP核心的廠商。有些是剛成立的小型設計公司，有些是歷史悠久的大型公司，將IP核心視為另一種為顧客提供設計方案的新模式。不幸的是，公司的規模並不是IP核心品質的指標。SoC研發業者應瞭解供應商對IP核心產品的投入程度。# M9 R3 T$ y: S% a( e. r6 q
G( g+ E9 O' @1 q7 x7 C ■是否設計成能夠重複使用？ 7 v( }9 ?6 s4 P+ O5 O' s. k" P& d5 b0 j& O, Z2 `
例如，本身不是專門開發IP方案的供應商，其IP核心產品可能只是將原有的設計方案重新包裝而成。全心投入開發高品質核心的廠商，在從頭開始研發時就會考量重複使用的能力。本節將詳細介紹能重複使用的設計方案具有那些特徵。 7 }; j5 ?- S$ o v) Z! x4 h 3 Z+ H" Y) W2 P4 P8 L6 _- L, \" X 首先需特別留意那些原始程式碼是否原本用於完全客製化的硬核，這些設計方案最初並未納入合成的考量，故比原本設計用來能夠合成的方案遜色。在開發硬核時，可根據已知的建置型態進行最佳化設計。然而，在軟核部份因尚未建置，故可能不適合採取這種方法，因為如此可能造成無法運作或次佳的建置。9 F8 l" W7 k: p9 v, H
, o3 ]$ U6 |! f) ]$ g
另一項軟核的重點就是各種被登錄（registered）的介面訊號，透過將I/O存入暫存器，SoC團隊就不必擔心IP核心內部邏輯的時序限制。此外，這種作法能輕易的預測時序，並讓SoC研發業者獲得完善的時序限制環境。以上所有效益都讓SoC的研發更為容易。& a; H$ @) k% Q" _0 X! e
9 p" h! J! c$ t4 X k 一套從頭開始研發且設計成能重複使用的軟核，本身擁有更多可設定的選項，且在建置上有更高的彈性。這類方案亦有考量須支援多重研發環境。一個設計方案若在設計時沒有納入重複使用的考量因素，就可能較缺乏功能與建置上的彈性。 0 y2 x( Q+ ? l; ~/ Y) |: m) q5 ^% l
■完整系列產品8 N! l: g- x& R6 e. L p% G
* a8 Y( e- J- }+ A6 D* B' M$ N 理想IP供應商的另一項特徵就是完整的IP核心系列方案。若您選擇軟核，請確認該公司是否提供完整的軟核方案，以支援未來產品的改良需求。若您選擇硬核，須應確認廠商是否支援所有您正使用的製程技術。9 g6 J! O: e; F8 D
. I3 Q" f. S8 V6 i0 W& H4 k 此外，您應確認IP供應商對於未來IP核心有明確的研發方向。廠商是否計畫擴充其軟核方案？廠商對於硬核移植至新世代的製程有何規畫？$ r, R; e. |2 g0 R+ Q/ b h
3 R/ o6 J6 w3 h! @/ G ■維護與支援8 Z- h- x$ b" P: t
1 `/ X3 j( |* U: v/ u4 a' D
IP核心亦須注重產品維護與支援的品質。尤其須注意沒有提供專屬支援服務的新公司。即使是歷史較久的企業，亦須投入專屬的資源來支援維護IP核心的機構。以下是檢驗項目的清單：) Z. q z/ m, N% w) L8 h: h1 n
$ c- |& A- q$ t/ r% V0 M* w ◆廠商是否有明文記載的說明，指引顧客如何獲得專人答覆所面臨的問題1 h/ J/ o( A$ w+ |; K/ g; u0 I! h
. v! C. P8 ~ I! D
◆SoC團隊技術支援的收費模式？（您是否有無法獲得支援的危機？）) \/ k0 G1 L" ?+ p; C
( M; w5 w5 {7 @9 ]8 I2 q
◆廠商是否坦承透露其設計方案中的錯誤（bug） 9 Z+ l' |' \+ Y! ~, V 0 e: }: z2 f- O1 o% n! e6 { ◆廠商發佈新修正方案的頻率9 _1 T! I' I- M& v, e7 B
( y' D0 _8 I$ O, @$ Y; |) \/ r3 D' W
◆IP供應商是否會發表維護版本方案，針對IP核心或其支援方案增加新的功能（例如像支援更多的EDA工具）？9 ^ l. ?" l: G$ X5 }* b5 Z! M6 c
$ L" W; H1 M& ?& C
◆當提出支援要求時，廠商會如何回應 # i `( y$ Q- k/ p; Z6 H7 v2 n% |0 b7 {
◆支援是否過於遲緩，問題是否會因而愈來愈嚴重; Z4 y' Z% |( L' @% y0 G- ^
/ ?" J f$ \7 |2 N
◆第一線的支援人員是否有充份的專業知識 ! S7 g- O9 M* I1 g5 v - i' \; _, U5 ]* ?$ N: m1 [( w 在許多案例中，支援的品質並未被列為IP核心的採購決策依據。然而，當設計團隊急需協助時，不完善的支援就會成為嚴重的問題。最高品質的支援是專案成功的必要因素。 ! O S7 E9 W. J G) z o8 F$ H; v6 H9 f 結論 : A) [" s+ P/ d. k" R3 E' L5 ]1 _
IP核心設計是一個全新的領域。許多廠商積極搶攻這個迅速成長的市場。SoC設計業者須小心評估設計方案以及IP供應商，避免落入任何新技術經常遭遇到的陷阱。 # f( \$ \6 n$ z# u2 C$ K3 t @# J( m5 S8 I( }" c5 y
對於少數正好能符合硬核設計目標的設計而言，運用最佳化的硬核是不錯的選擇。但對於大多數的設計而言，具有高彈性的軟核會是最佳的選擇。 % h! X# I% G& O, u5 A! [' J k 8 S, [( m! u( D1 D; F5 A ◆應用最佳化 $ i8 q" J0 w2 c# W- _+ D5 a7 R+ e& s, B* A8 x2 j
◆自行調整編譯時間5 L& Y" W0 w; o9 d, h) i9 Y& ^
% b0 t7 X' K; ]. H2 h( E8 ~
◆技術的獨立性 5 ]. [# D% G( V% L6 D" F1 l$ X/ _: X4 Z, C0 Q4 p
◆能輕易整合至SoC環境3 Y- ]- Q% G( w; q( ~