|
2#
樓主 |
發表於 2007-8-4 11:34:21
|
只看該作者
研發SoC 核心CPU技術該挑軟?選硬?(下)
研發SoC 核心CPU技術該挑軟?選硬?(下)
8 Z8 a/ S- {. q$ K如何評估、選擇IP產品及供應商
- g. t& W2 M3 W1 e( n: `. G) w. ^/ y
評估IP廠商提供的附加材料
8 ]. I5 E" D, B% Q) f
0 @ E8 s! [3 B0 Y# s0 ?: M$ k$ ^ 高競爭力的IP軟核不僅只是一套Verilog或VHDL程式碼。同樣的,完善的硬核也不僅只是一套電路配線資料庫。現今的IP核心包含一整套的技術文件及技術支援副物,讓SoC研發團隊能將IP核心整合至設計方案中。這些附加材料就是要儘可能簡化IP整合至各個研發流程的作業。7 C* u4 M; p) X: m. |, c# m
" ~. m5 {1 ?/ m
■技術文件
& L4 v' f! W( a- }4 O, t/ h
& q. z1 H& ^5 J9 V3 B/ g# t 明確的技術文件是大多數技術產品必要的先決條件。然而,各種人士對於IP核心文件的需求差異相當大,且需要的文件數量也相當多,讓業者在提供IP核心文件時面臨極大的挑戰。
# P0 p6 e1 K+ H" r' P, d
7 d% \ x, D2 l3 K) v 每種研發作業都有不同的文件需求。例如,軟體研發人員需要瞭解硬體的撰寫特性,但可能不必瞭解硬體如何建置。因此,妥善整合的文件讓軟體研發業者能輕易找到所需的資訊,而不必逐一閱讀本身不需要的資料。
) E0 P! o& U" s. Z W9 ?$ T) b. D5 y* z- j9 _' V* W$ b: q2 N
最後,若SoC團隊須為其SoC撰寫技術文件,則可能需重複使用到部份的IP核心文件,IP供應商應提供可編輯的文件原始檔案,並授與客戶節錄核心文件的權限。
* T3 ~+ e9 V7 P" p/ s, C2 |8 v+ E) {! j- G* D8 P& t* W
■介面檢查器% _6 a- I% E# P, f7 d
' S( M/ c' r- R/ H# W) A( H SoC團隊需做邏輯設計來與各種IP核心的訊號與通訊協定建立介面,為判斷設計是否正確,IP供應商可提供介面檢查模組,檢驗所有介面訊號與通訊協定是否正常運作。其流程可能僅是單純的確認靜態訊號沒有被改變,或是複雜到檢驗多重週期的匯流排通訊協定是否正常運作。6 }% y/ q- x; f7 [' P* r
. q0 c; d. v3 |, J8 V 由自動檢驗特定種類介面的運作是否正確,這些檢查器能大幅節省SoC設計所耗的人力與時間。若發生錯誤的運轉動作時,檢查器應指出錯誤狀況,讓SoC設計師能輕易找到有問題的邏輯並排除故障狀況。; F8 q6 x+ [! M* q+ k, J5 D
( R5 N/ K( k8 }/ ]6 j' W& ?, A 介面檢查器並不存在於實際的硬體中,可是必須在SoC研發環境中正確運作,也必須能輕易整合至功能模擬的流程中。6 p8 F8 W% C& `4 d
% J" C6 C7 F6 {) g ■介面規範的列表(Protocol Tabulators)& K- m& G9 @" z/ R- \5 J
; G: y4 _; Y$ {' r, X( q( q IP供應商可提供協助簡化介面檢驗的另一類資源就是protocol tabulator。這種模組能監視介面交易以及監看各種特殊運轉狀況。protocol tabulator能記錄所有交易類型,並回報尚未遭遇的特殊運轉狀況。IP供應商須提供一份各類特殊運轉狀況清單,以達成介面完整檢驗。
* u% i+ B2 {, X6 a& Q
" M; }! v, b3 |. M/ W2 n1 @ 在研發階段,protocol tabulator能協助SoC團隊判斷那些特殊運轉狀況尚未進行檢驗。當研發完成後,它亦能讓SoC團隊確認已執行所有必要的特殊運轉狀況。由於IP供應商最能掌握核心介面的技術,故其特殊運轉狀況的清單會遠比SoC團隊自行擬定的還要詳盡。
+ @( \. Z( @: ]1 ]9 G4 o8 }- \" p2 o# v5 O N2 n* Z) v4 M
■RAM檢查器
4 G& ^5 S2 M- {0 p+ ?, v
1 g3 U2 ~' P) W# m; E7 q* f$ ^ 若SoC團隊須編譯與整合IP核心中的RAM記憶體,過程中可能會造成某些錯誤(bug)。要找出深層嵌入的RAM所衍生的錯誤,對SoC團隊而言極為困難,因為這些問題通常需要涉及內部核心模組的訊號追蹤,而RAM檢查器就能大幅減輕此類除錯的負擔。透過迅速偵測RAM模組介面上的錯誤,SoC團隊能避免進入IP核心的內部進行除錯,並快速解決RAM內部的問題(SoC團隊應當擁有正確無誤的運作模式可供使用,以避免針對整個IP核心進行除錯。)# ?( B. R: T. D3 I- t3 U7 c
) {5 \7 [* `/ m/ X ■高速模擬的模型
( f7 a+ E, Q: G3 z/ ]
/ _% X2 O3 f9 T9 q% T6 S H 對於SoC研發業者而言,運用大型IP核心中的RTL模擬整套SoC,其速度可能相當緩慢。若IP供應商能提供一套核心的快速功能模組,且能精準模擬運作時脈,則用戶將可享受更快的模擬速度、更快的除錯作業、以及使用較少份的模擬方案授權。即使是時脈不精準的模組,亦足以協助業者進行大多數的SoC研發與除錯工作。只要模組能在最後一回達到精準的時脈,快速功能模擬模組就有助於研發工作的推展。
& t- ], w& v" r! G! H' ?4 s3 P# d) B. Z+ e [
■EDA工具支援+ @7 [$ m9 j1 M) U/ q% d
# P/ s5 d2 L a2 m. Q/ u& y. n. K 另一項評斷核心品質優劣的標準就是EDA支援工具的廣度。由於不同研發團隊需要運用不同的工具,現今各種高階核心通常會支援各種不同的EDA工具。( q; }$ ]6 }* X" g" ~, X
! }' D! _; }8 {& A* o* X 舉例來說,即使IP核心是使用Verilog語言來設計,對於使用VHDL語言及EDA工具與技術的顧客而言,他們需要支援VHDL的方案。若核心僅提供Verilog的支援,則SoC團隊須進行繁瑣且容易出錯的轉譯過程才能使用該套核心。. ]: g+ j2 Q, a% }0 l
, C: L; `$ d! [5 k% R [
此外,IP供應商應提供不同格式的支援。不同的EDA工具可能有不同的建置規格。在上面的範例中,IP供應商不僅應為Verilog方案顧客提供Verilog RTL文件,且此文件須是針對顧客用的Verilog模擬器。否則,因模擬器的執行狀況可能與IP供應商自己測試時有所差異,顧客可能須針對Verilog模擬器衍生的問題進行除錯。. K! c+ ] I) x2 H. Z* S
7 V% t l; K. r 這種觀念幾乎可應用在所有的IP。對於硬核而言,這種觀念亦適用於建置階段。硬核提供的格式亦須是SoC團隊後端工具所能接受的格式。IP供應商須針對使用到的後端工具提供支援。
/ T) [% r+ s- ^8 |' K
( v6 P# g* K2 ]- H5 v ■EDA Scripts指令檔範例0 R& g! f9 g! e6 p3 q3 @2 s
' @3 W1 y& j3 `) U p
為協助顧客立即開始啟動各種研發作業,IP供應商應針對所支援的EDA工具提供範例指令檔(script)。IP供應商可透過這種途徑讓SoC團隊有效率地運用IP核心進行研發。指令檔可以僅是makefiles的格式,然後編譯成功能模擬器。也可以是一套複雜的指令檔,用來自動執行各種功能的重新驗證。不論是那個種類,範例指令檔幾乎永遠都是SoC研發業者最有用的工具。
) K! ]+ i8 ?; \/ P$ k
0 l* R! n; l+ r9 z' M- ?# f 對於軟核而言,合成指令範例幾乎是必要的。它們至少應包含置於最頂層的限制宣告、不符條件的false-paths、以及multi-cycle paths。可能的話,範例亦應包含種業界標準的合成技術。當然,範例指令檔若愈簡化,SoC研發業者就愈容易瞭解、修改、以及整合至其合成步驟中。
3 a! n2 n0 O/ U4 \( x0 k- G- r
0 w( z! L/ D; R$ u ■功能核心檢驗
7 ^- J1 U+ d+ H+ X# E7 F3 @# A5 A- J7 [! Z4 H2 k4 P" }9 p; [4 u
雖然SoC研發業者不會變更IP軟核中的RTL設計內容,然而在正常的晶片開發流程中的確會變更部份的功能。變更設計功能的例子包括插入掃瞄鏈(scan-chain)、時脈緩衝、以及RAM BIST。SoC團隊須能檢驗這些變更沒有影響核心的正常運作。+ Z% d; H6 V& G: ]
/ D' E$ x! U# [% `$ f0 T% H1 o
欲驗證新設計變更沒有影響到原來的設計,其中一種方法就是IP供應商提供一個能用來驗證核心是否正常運作的環境與測試方案。不幸的是,對於許多核心而言,完整的測試方案本身過於龐大,不適合作為IP核心的附加方案。因此,大多數IP供應商選擇提供部份的檢驗方案,能用來檢驗核心是否正常運作。大多數的情況下,這類子集合方案已足以用來偵測在變更後所可能衍生的任何錯誤。/ F6 P8 u# P) A- r( F, }5 A4 F
( Y9 m- x; g, ]* q$ _ 然而,用正規驗證工具(formal verification tool)在確保運作正常的檢驗流程會更加完整。此種工具用數學方法來證明新的設計方案與原有的核心功能相同。支援正規驗證工具讓SoC團隊不須重新執行上述的邏輯閘層級檢驗作業。& i7 q) d" }! u x2 ~
0 p/ R0 [+ c( `0 p1 G3 x
■軟體協同開發的工具
8 ] [# C* w( d) J) N" X5 c% [/ x% D: N/ F2 H: G( x) g
針對新系統的軟體開發標準流程是先製造硬體樣本,然後再開發軟體於此一硬體上執行。在許多狀況下,這種流程會延長產品上市時程,因此軟體研發通常與硬體研發同時進行。8 T3 ~ P3 h( D* u
9 N9 U( T8 o/ F; I6 o5 q$ l8 E2 P8 t
研發軟體比開發硬體更需要快速的系統模擬機制。因此,IP供應商須提供極快速的IP核心功能模型。這種模型方案能提供充裕的效能以滿足低階軔體的研發需求。/ M- G# n6 `5 F& c
4 W: x/ @; X2 N4 t! @( a5 z8 n0 P
面對更快的模擬速度需求,業者有時會運用硬體邏輯模擬器,其執行速度超過純軟體模擬系統(雖然它們的速度仍比真正的硬體慢2到3級)。但眾所皆知,這些硬體模擬器很難使用,且需要進行特殊的合成。對於計畫同步研發硬體與軟體的SoC團隊而言,這方面的技術支援是IP核心的一項必備條件。" D$ \! f& N" A s
9 o T: x; u( X6 r" b& d% T
如何評鑑IP供應商
% ~& e3 w3 _) J/ u! S3 D; w/ J: ?( b& u& x; r3 N
市場上有許多供應IP核心的廠商。有些是剛成立的小型設計公司,有些是歷史悠久的大型公司,將IP核心視為另一種為顧客提供設計方案的新模式。不幸的是,公司的規模並不是IP核心品質的指標。SoC研發業者應瞭解供應商對IP核心產品的投入程度。
% U1 O7 P- f4 \% n* x* }" n+ W. |$ k" M. x/ C, J
■是否設計成能夠重複使用?
' R q; H6 [' h! Z! m
4 r. M' C% d% j& p s3 |: Q7 r 例如,本身不是專門開發IP方案的供應商,其IP核心產品可能只是將原有的設計方案重新包裝而成。全心投入開發高品質核心的廠商,在從頭開始研發時就會考量重複使用的能力。本節將詳細介紹能重複使用的設計方案具有那些特徵。
& q/ M5 k/ {9 X: N B2 k4 {# @) b0 T: s k* _% e; P9 y" M, W
首先需特別留意那些原始程式碼是否原本用於完全客製化的硬核,這些設計方案最初並未納入合成的考量,故比原本設計用來能夠合成的方案遜色。在開發硬核時,可根據已知的建置型態進行最佳化設計。然而,在軟核部份因尚未建置,故可能不適合採取這種方法,因為如此可能造成無法運作或次佳的建置。6 y1 Q1 O. t5 @& E. x
7 e3 @% c2 q% Y9 Z4 Z2 J! q* o D1 N4 u 另一項軟核的重點就是各種被登錄(registered)的介面訊號,透過將I/O存入暫存器,SoC團隊就不必擔心IP核心內部邏輯的時序限制。此外,這種作法能輕易的預測時序,並讓SoC研發業者獲得完善的時序限制環境。以上所有效益都讓SoC的研發更為容易。6 m, q( Z- J- q& t
# Q' G' [- U: U2 j( T 一套從頭開始研發且設計成能重複使用的軟核,本身擁有更多可設定的選項,且在建置上有更高的彈性。這類方案亦有考量須支援多重研發環境。一個設計方案若在設計時沒有納入重複使用的考量因素,就可能較缺乏功能與建置上的彈性。
" z: u9 Z$ P @4 b# T1 N, s3 K0 Z) n E9 q) B; i
■完整系列產品9 X, z2 z) a+ P; E2 k: x
$ w8 [% W# K: L" z. i 理想IP供應商的另一項特徵就是完整的IP核心系列方案。若您選擇軟核,請確認該公司是否提供完整的軟核方案,以支援未來產品的改良需求。若您選擇硬核,須應確認廠商是否支援所有您正使用的製程技術。# z2 S2 z( z6 W9 b
+ n( O" B ~0 C( w) j9 N( g
此外,您應確認IP供應商對於未來IP核心有明確的研發方向。廠商是否計畫擴充其軟核方案?廠商對於硬核移植至新世代的製程有何規畫?
7 M% S/ w0 I6 d% V& h4 q
m t+ q0 W) m: _1 D ■維護與支援
+ w: V4 a* b# l$ X1 h
# u3 U$ ?" [' J! y+ h ^; P IP核心亦須注重產品維護與支援的品質。尤其須注意沒有提供專屬支援服務的新公司。即使是歷史較久的企業,亦須投入專屬的資源來支援維護IP核心的機構。以下是檢驗項目的清單:1 y# ^* I P1 f5 Z2 ?; H+ l [' j
8 }* o/ l$ Q( H" `9 U' L7 C
◆廠商是否有明文記載的說明,指引顧客如何獲得專人答覆所面臨的問題
' N+ V1 U+ ?% R# U9 z7 x& y8 R$ P8 J8 @# g' @
◆SoC團隊技術支援的收費模式?(您是否有無法獲得支援的危機?)" |( E5 w$ o1 `! U, Y6 U% j/ [
: I6 V* x1 D6 |0 s/ a* B3 w5 n' o
◆廠商是否坦承透露其設計方案中的錯誤(bug)- S6 w! C8 H0 V; {5 b) {" x
* a" C! @, M* Q/ X) ~( E' T ◆廠商發佈新修正方案的頻率
2 [# E4 n: ^0 W- u! n9 W8 y8 Q) T$ r" o0 P+ I/ R. v q
◆IP供應商是否會發表維護版本方案,針對IP核心或其支援方案增加新的功能(例如像支援更多的EDA工具)?7 x! M. o: r2 N2 _, Z2 B" n
{. O/ z! g2 X
◆當提出支援要求時,廠商會如何回應4 [0 h% E, [8 Z5 F* F( O
7 \6 ~; z& q7 l! t6 L. D
◆支援是否過於遲緩,問題是否會因而愈來愈嚴重- o8 N) j' ?3 g3 ~# {
1 V B1 N- |( q! a
◆第一線的支援人員是否有充份的專業知識
1 K3 }9 |) ^+ Y3 H) y( `( }4 I& m0 h5 N
在許多案例中,支援的品質並未被列為IP核心的採購決策依據。然而,當設計團隊急需協助時,不完善的支援就會成為嚴重的問題。最高品質的支援是專案成功的必要因素。' j$ S! Q' F* C6 a3 q- s
( `2 F$ u2 R1 ]: q8 t( ~7 \
結論# T6 N: W6 U- A; D
7 I" ^- y+ b/ j; u1 n8 j. ?- c
IP核心設計是一個全新的領域。許多廠商積極搶攻這個迅速成長的市場。SoC設計業者須小心評估設計方案以及IP供應商,避免落入任何新技術經常遭遇到的陷阱。
) N# k8 K3 |+ f8 G% F4 u: E/ b* k- \3 w- O& O
對於少數正好能符合硬核設計目標的設計而言,運用最佳化的硬核是不錯的選擇。但對於大多數的設計而言,具有高彈性的軟核會是最佳的選擇。
3 P6 K1 ^0 P" u/ R3 G' w8 q$ s+ g" z" p2 K6 |
◆應用最佳化" @+ @: l" M% S3 @: \+ o' j! g
# Z+ V3 f3 ^* }1 S b$ [
◆自行調整編譯時間( M5 a1 j0 K t* z
0 L! Q# _; ^" J) l6 J. q ◆技術的獨立性7 N) q# \6 c) W: w: Z* A
" ?+ F7 H! T0 w [4 g ◆能輕易整合至SoC環境% J y, l, `! K3 B5 N- v$ l
" O! Q+ ^5 z% R5 b: Q( B; j5 S 技術文件與技術支援不足的IP核心,亦很難整合至SoC的開發流程中。因此,業者須注意評估IP核心的技術文件與技術支援,確認是否有支援所需的EDA工具以及所有SoC的研發流程。
) j/ ? }+ n# m F. C3 x' ^( A, |0 H9 ^8 a/ R' T7 O3 `6 U
選擇IP供應商與選擇IP核心一樣重要。專注於開發IP核心是IP供應商的必要條件。此外,SoC團隊須確認未來IP供應商是否能為其產品提供支援以及繼續推出新產品。# ^3 L" v( o, _' ~5 F" A `- D
* E% A& p- r, W2 w& v } 現今的SoC研發業者面臨許多挑戰。運用知名廠商提供的高品質IP核心,讓客戶能輕易克服這些挑戰。) m; V8 j8 [4 Y2 z7 t( M' k) u
/ h% g/ n' `# S(本文由MIPS Technologies, Inc.提供)資料來源 : digitimes |
|