|
2#
樓主 |
發表於 2007-8-4 11:34:21
|
只看該作者
研發SoC 核心CPU技術該挑軟?選硬?(下)
研發SoC 核心CPU技術該挑軟?選硬?(下)1 r" B( \2 |. C( T3 y
如何評估、選擇IP產品及供應商 9 o; m& E' Z1 i/ l9 j
( Z: S7 c% N, f$ K, s* S' t
評估IP廠商提供的附加材料
9 w1 y; h! b, _1 g# u9 x$ Y4 \6 g$ Q' J: l/ W: K6 b0 \ D1 Z
高競爭力的IP軟核不僅只是一套Verilog或VHDL程式碼。同樣的,完善的硬核也不僅只是一套電路配線資料庫。現今的IP核心包含一整套的技術文件及技術支援副物,讓SoC研發團隊能將IP核心整合至設計方案中。這些附加材料就是要儘可能簡化IP整合至各個研發流程的作業。
/ s1 V" Z2 c% X: k `: W B5 e c. G2 l; I K
■技術文件% [3 \1 x2 A0 g, f* }2 K
0 R+ r9 |/ }- Z6 H
明確的技術文件是大多數技術產品必要的先決條件。然而,各種人士對於IP核心文件的需求差異相當大,且需要的文件數量也相當多,讓業者在提供IP核心文件時面臨極大的挑戰。. s2 u2 w/ I0 a5 c
) H% b* Y: Z' P& `
每種研發作業都有不同的文件需求。例如,軟體研發人員需要瞭解硬體的撰寫特性,但可能不必瞭解硬體如何建置。因此,妥善整合的文件讓軟體研發業者能輕易找到所需的資訊,而不必逐一閱讀本身不需要的資料。0 G2 {/ {( R* l4 u4 r* \' d
+ J1 r2 I4 C+ `3 _
最後,若SoC團隊須為其SoC撰寫技術文件,則可能需重複使用到部份的IP核心文件,IP供應商應提供可編輯的文件原始檔案,並授與客戶節錄核心文件的權限。
1 }8 j2 r) u+ ~; Z5 e P/ T5 u/ ^0 {! S! ?; `9 D" J
■介面檢查器- d u' H' B: t1 Z: |
) b! g, L a4 M8 L SoC團隊需做邏輯設計來與各種IP核心的訊號與通訊協定建立介面,為判斷設計是否正確,IP供應商可提供介面檢查模組,檢驗所有介面訊號與通訊協定是否正常運作。其流程可能僅是單純的確認靜態訊號沒有被改變,或是複雜到檢驗多重週期的匯流排通訊協定是否正常運作。$ G9 L3 V4 O. }9 V& ^# A2 j
1 ?0 w7 [, G# H5 N2 h7 r% |6 a2 {
由自動檢驗特定種類介面的運作是否正確,這些檢查器能大幅節省SoC設計所耗的人力與時間。若發生錯誤的運轉動作時,檢查器應指出錯誤狀況,讓SoC設計師能輕易找到有問題的邏輯並排除故障狀況。
9 n9 C7 ?; u t* _" p
6 t/ N' y# l+ D/ v4 i) _ 介面檢查器並不存在於實際的硬體中,可是必須在SoC研發環境中正確運作,也必須能輕易整合至功能模擬的流程中。
! j: E) t7 V4 q! ^: C/ f/ U8 N# u7 ]) A% s
■介面規範的列表(Protocol Tabulators)6 h3 R& z" _* `7 `" ~( I+ e
7 _$ C) N/ _) ~' B& j
IP供應商可提供協助簡化介面檢驗的另一類資源就是protocol tabulator。這種模組能監視介面交易以及監看各種特殊運轉狀況。protocol tabulator能記錄所有交易類型,並回報尚未遭遇的特殊運轉狀況。IP供應商須提供一份各類特殊運轉狀況清單,以達成介面完整檢驗。' t. n: I+ Q$ T. t& I
. l: v/ j- q2 C5 }5 z/ X
在研發階段,protocol tabulator能協助SoC團隊判斷那些特殊運轉狀況尚未進行檢驗。當研發完成後,它亦能讓SoC團隊確認已執行所有必要的特殊運轉狀況。由於IP供應商最能掌握核心介面的技術,故其特殊運轉狀況的清單會遠比SoC團隊自行擬定的還要詳盡。$ n) B& [1 o+ H5 l4 V5 l! ~
- D# P. U4 n% _' C3 f+ [ ■RAM檢查器8 n" m7 u- F: T0 ~
( ^! ~5 j# O1 _ D7 q
若SoC團隊須編譯與整合IP核心中的RAM記憶體,過程中可能會造成某些錯誤(bug)。要找出深層嵌入的RAM所衍生的錯誤,對SoC團隊而言極為困難,因為這些問題通常需要涉及內部核心模組的訊號追蹤,而RAM檢查器就能大幅減輕此類除錯的負擔。透過迅速偵測RAM模組介面上的錯誤,SoC團隊能避免進入IP核心的內部進行除錯,並快速解決RAM內部的問題(SoC團隊應當擁有正確無誤的運作模式可供使用,以避免針對整個IP核心進行除錯。)
$ L1 L. R/ v7 G+ R7 H, N2 h
/ l1 O) [% f: {2 b3 K ■高速模擬的模型
" z! e' r" Y% z0 E. G' F
( Y) U0 ?$ h: b4 q+ D. z 對於SoC研發業者而言,運用大型IP核心中的RTL模擬整套SoC,其速度可能相當緩慢。若IP供應商能提供一套核心的快速功能模組,且能精準模擬運作時脈,則用戶將可享受更快的模擬速度、更快的除錯作業、以及使用較少份的模擬方案授權。即使是時脈不精準的模組,亦足以協助業者進行大多數的SoC研發與除錯工作。只要模組能在最後一回達到精準的時脈,快速功能模擬模組就有助於研發工作的推展。. M. a, z" Z, S" V
: C# x6 ]4 \( y d/ n5 y1 T( v
■EDA工具支援3 t: P: I7 ?& I; S
% ?) O. }; e9 T4 c4 h' a5 {" l
另一項評斷核心品質優劣的標準就是EDA支援工具的廣度。由於不同研發團隊需要運用不同的工具,現今各種高階核心通常會支援各種不同的EDA工具。8 C9 x" K0 T' q1 }( t* W% @
1 E t* v3 E, r7 |/ \, ?% A/ K
舉例來說,即使IP核心是使用Verilog語言來設計,對於使用VHDL語言及EDA工具與技術的顧客而言,他們需要支援VHDL的方案。若核心僅提供Verilog的支援,則SoC團隊須進行繁瑣且容易出錯的轉譯過程才能使用該套核心。9 d. }0 L* g5 F0 y
( b# E# ^& k) ~" d 此外,IP供應商應提供不同格式的支援。不同的EDA工具可能有不同的建置規格。在上面的範例中,IP供應商不僅應為Verilog方案顧客提供Verilog RTL文件,且此文件須是針對顧客用的Verilog模擬器。否則,因模擬器的執行狀況可能與IP供應商自己測試時有所差異,顧客可能須針對Verilog模擬器衍生的問題進行除錯。6 p' g5 R8 q8 ~! ]5 e
+ E5 h5 A2 G* k# y7 l1 h) f 這種觀念幾乎可應用在所有的IP。對於硬核而言,這種觀念亦適用於建置階段。硬核提供的格式亦須是SoC團隊後端工具所能接受的格式。IP供應商須針對使用到的後端工具提供支援。; P9 q) A4 k4 A
% X, f; O! o7 G0 G4 W. K
■EDA Scripts指令檔範例
. O7 E; D+ f) n$ |
4 ^- I- b4 {- y k0 h 為協助顧客立即開始啟動各種研發作業,IP供應商應針對所支援的EDA工具提供範例指令檔(script)。IP供應商可透過這種途徑讓SoC團隊有效率地運用IP核心進行研發。指令檔可以僅是makefiles的格式,然後編譯成功能模擬器。也可以是一套複雜的指令檔,用來自動執行各種功能的重新驗證。不論是那個種類,範例指令檔幾乎永遠都是SoC研發業者最有用的工具。% }+ k8 Q- f+ U7 _: X
3 u$ I! ^* k* x2 I( p
對於軟核而言,合成指令範例幾乎是必要的。它們至少應包含置於最頂層的限制宣告、不符條件的false-paths、以及multi-cycle paths。可能的話,範例亦應包含種業界標準的合成技術。當然,範例指令檔若愈簡化,SoC研發業者就愈容易瞭解、修改、以及整合至其合成步驟中。
, Q; r. K% }2 j8 C. h0 a3 ~( C& b8 D0 \" M& L3 L7 Q
■功能核心檢驗) n9 h) O' X- z: |' x) g
8 b$ @ N/ s$ D, C5 K/ k) ] 雖然SoC研發業者不會變更IP軟核中的RTL設計內容,然而在正常的晶片開發流程中的確會變更部份的功能。變更設計功能的例子包括插入掃瞄鏈(scan-chain)、時脈緩衝、以及RAM BIST。SoC團隊須能檢驗這些變更沒有影響核心的正常運作。. k/ d4 }# c3 r$ @4 L
5 P# ^3 C$ f w5 ]% {5 Z
欲驗證新設計變更沒有影響到原來的設計,其中一種方法就是IP供應商提供一個能用來驗證核心是否正常運作的環境與測試方案。不幸的是,對於許多核心而言,完整的測試方案本身過於龐大,不適合作為IP核心的附加方案。因此,大多數IP供應商選擇提供部份的檢驗方案,能用來檢驗核心是否正常運作。大多數的情況下,這類子集合方案已足以用來偵測在變更後所可能衍生的任何錯誤。, {# N! v6 ^; M8 R. |
) [7 N: l4 y- A; M
然而,用正規驗證工具(formal verification tool)在確保運作正常的檢驗流程會更加完整。此種工具用數學方法來證明新的設計方案與原有的核心功能相同。支援正規驗證工具讓SoC團隊不須重新執行上述的邏輯閘層級檢驗作業。+ ?' I0 I4 B8 G+ s
# u$ P8 s1 M; r' {1 d ■軟體協同開發的工具
; Q! H& E* Q4 n9 g6 Z9 I5 v S6 P% F! {5 u) Z7 ~0 ~
針對新系統的軟體開發標準流程是先製造硬體樣本,然後再開發軟體於此一硬體上執行。在許多狀況下,這種流程會延長產品上市時程,因此軟體研發通常與硬體研發同時進行。3 V) ^0 h$ ?' G$ @% U
( W% K! X6 J. B. t q1 r
研發軟體比開發硬體更需要快速的系統模擬機制。因此,IP供應商須提供極快速的IP核心功能模型。這種模型方案能提供充裕的效能以滿足低階軔體的研發需求。
2 [( ^2 s' Y+ b- `
. O6 a2 S! Y: Z! B+ E9 s 面對更快的模擬速度需求,業者有時會運用硬體邏輯模擬器,其執行速度超過純軟體模擬系統(雖然它們的速度仍比真正的硬體慢2到3級)。但眾所皆知,這些硬體模擬器很難使用,且需要進行特殊的合成。對於計畫同步研發硬體與軟體的SoC團隊而言,這方面的技術支援是IP核心的一項必備條件。
- v$ r1 j7 ]- K1 L' I
0 A. e! O) B( Z5 F$ G. V 如何評鑑IP供應商' X: b5 Z7 S1 l! W1 j3 }- n$ |
5 x; k3 c* H# _* x+ c K4 x9 {
市場上有許多供應IP核心的廠商。有些是剛成立的小型設計公司,有些是歷史悠久的大型公司,將IP核心視為另一種為顧客提供設計方案的新模式。不幸的是,公司的規模並不是IP核心品質的指標。SoC研發業者應瞭解供應商對IP核心產品的投入程度。
$ T' H& ]1 \5 Q, y& o5 v
3 L# A" q8 M. P* ~1 U/ x0 Z/ @ ■是否設計成能夠重複使用?9 V- N2 B2 A6 B! l; d
, G, V, E Z0 d" O h8 i! ^ 例如,本身不是專門開發IP方案的供應商,其IP核心產品可能只是將原有的設計方案重新包裝而成。全心投入開發高品質核心的廠商,在從頭開始研發時就會考量重複使用的能力。本節將詳細介紹能重複使用的設計方案具有那些特徵。
. `, Z1 G. ?# T! H; a1 T
2 \8 w6 [! X3 v+ G 首先需特別留意那些原始程式碼是否原本用於完全客製化的硬核,這些設計方案最初並未納入合成的考量,故比原本設計用來能夠合成的方案遜色。在開發硬核時,可根據已知的建置型態進行最佳化設計。然而,在軟核部份因尚未建置,故可能不適合採取這種方法,因為如此可能造成無法運作或次佳的建置。: t: v/ V8 Z, t) o( ?
# b4 D! `! W7 A* q
另一項軟核的重點就是各種被登錄(registered)的介面訊號,透過將I/O存入暫存器,SoC團隊就不必擔心IP核心內部邏輯的時序限制。此外,這種作法能輕易的預測時序,並讓SoC研發業者獲得完善的時序限制環境。以上所有效益都讓SoC的研發更為容易。
2 J4 ]6 M# U& I( U# z; v) `" c& f- o( h9 Z% q
一套從頭開始研發且設計成能重複使用的軟核,本身擁有更多可設定的選項,且在建置上有更高的彈性。這類方案亦有考量須支援多重研發環境。一個設計方案若在設計時沒有納入重複使用的考量因素,就可能較缺乏功能與建置上的彈性。7 ]; k( U0 e+ l; y% m2 U1 a* D
' [; V* E4 { r) A/ m1 s
■完整系列產品
4 ^# e# ]# b6 F8 ^* d$ \! ]( t3 L4 O7 {
理想IP供應商的另一項特徵就是完整的IP核心系列方案。若您選擇軟核,請確認該公司是否提供完整的軟核方案,以支援未來產品的改良需求。若您選擇硬核,須應確認廠商是否支援所有您正使用的製程技術。7 K4 P, i8 \3 d: c6 t+ H- M
5 D& p: f9 W2 w1 e
此外,您應確認IP供應商對於未來IP核心有明確的研發方向。廠商是否計畫擴充其軟核方案?廠商對於硬核移植至新世代的製程有何規畫?
: }9 ` T3 [, H8 b$ W8 r7 e7 ?5 _& A/ C) D7 l. _* ]
■維護與支援
G$ N$ L3 G& ?% W' @
% o/ @" c9 A$ O7 m" |& ]- Z IP核心亦須注重產品維護與支援的品質。尤其須注意沒有提供專屬支援服務的新公司。即使是歷史較久的企業,亦須投入專屬的資源來支援維護IP核心的機構。以下是檢驗項目的清單:+ S2 D: {! e6 W3 u+ s
: R3 g5 J# b4 G# p. ^/ T ◆廠商是否有明文記載的說明,指引顧客如何獲得專人答覆所面臨的問題
- @! g3 j" Y5 o
" s# ^! @" j0 i$ |2 C2 x* i$ N ◆SoC團隊技術支援的收費模式?(您是否有無法獲得支援的危機?)5 e- c8 n: J5 ^
9 U. k2 _+ c- l4 w* @/ L ◆廠商是否坦承透露其設計方案中的錯誤(bug)
]! b/ @6 s( t4 o# I; [& r; u! V: E/ Y2 A9 M1 \+ H( w( ]; k
◆廠商發佈新修正方案的頻率% x( r- h9 k/ w) z: f
9 @( w# {7 K0 Y, G2 C
◆IP供應商是否會發表維護版本方案,針對IP核心或其支援方案增加新的功能(例如像支援更多的EDA工具)?( F& P* k l9 ^* F3 y8 X
- h1 o5 z7 g k4 W. }
◆當提出支援要求時,廠商會如何回應
0 V; q# \# W4 c, ?; D# t F
5 i0 `, I; W; |0 M ◆支援是否過於遲緩,問題是否會因而愈來愈嚴重! t) G$ q, @- }$ R( p( |
" `; i' \" b5 m% V5 i3 M# s
◆第一線的支援人員是否有充份的專業知識
8 _- n$ [" z2 P! c; u
# \ M I, K5 q: e @& y4 `6 ?5 ~ 在許多案例中,支援的品質並未被列為IP核心的採購決策依據。然而,當設計團隊急需協助時,不完善的支援就會成為嚴重的問題。最高品質的支援是專案成功的必要因素。4 E6 F; p7 w& [6 c9 k# z
, V/ G' z( W8 a! D' s" a( k
結論, n8 `; ?) y! v6 V6 J% E: r4 I
* G; J, Z6 D) u, ^) I! E- P
IP核心設計是一個全新的領域。許多廠商積極搶攻這個迅速成長的市場。SoC設計業者須小心評估設計方案以及IP供應商,避免落入任何新技術經常遭遇到的陷阱。
/ C! Z9 U$ E( Z1 k* g5 f: s2 N" N* d# t
% [6 ?) g6 P* n( i& G 對於少數正好能符合硬核設計目標的設計而言,運用最佳化的硬核是不錯的選擇。但對於大多數的設計而言,具有高彈性的軟核會是最佳的選擇。
' q2 ~+ ]# ~+ r% R$ V3 v, @# L! F, [. D: L8 s6 x# K3 P* H; E
◆應用最佳化; E$ L3 \# h3 b- ~
8 s0 s: _! I, p- W4 \ ◆自行調整編譯時間" s. K: ^; `" f. T
* V) _" T/ n/ t" D& ]
◆技術的獨立性
o5 y0 @2 H2 S. e8 H8 z4 {( h! P( c( F* ~$ ]+ U. Z
◆能輕易整合至SoC環境
0 U7 v& W B9 x% D
: N' K2 c4 o3 [# @- Y& @ 技術文件與技術支援不足的IP核心,亦很難整合至SoC的開發流程中。因此,業者須注意評估IP核心的技術文件與技術支援,確認是否有支援所需的EDA工具以及所有SoC的研發流程。
+ ?8 \' O3 i& i9 ?* D+ M# H
, i: |% |1 M" f% H 選擇IP供應商與選擇IP核心一樣重要。專注於開發IP核心是IP供應商的必要條件。此外,SoC團隊須確認未來IP供應商是否能為其產品提供支援以及繼續推出新產品。& b/ ]& A4 A. ^; a$ i3 Y3 {
" A8 i3 S+ w8 P6 N. o s 現今的SoC研發業者面臨許多挑戰。運用知名廠商提供的高品質IP核心,讓客戶能輕易克服這些挑戰。8 o( a& c7 x' s9 @6 u2 ^
: v: D, Y1 F% G( J4 x(本文由MIPS Technologies, Inc.提供)資料來源 : digitimes |
|