在上述的 IC流程中,還有其他工程師也是參與其中;而你是數位工程師,你對其他工程師的責任是什麼你有清楚嗎?
案例分享:
在這個 IC流程中,數位工程師會需要類比工程師的幫忙部份,絕大部份是在synthesis LIB的參考和simulation時的模型建立。曾經遇過類比工程師需要數位工程師幫忙驗證他們建立的LIB是否正確?在這個IC流程中,確實可以幫類比工程師驗證LIB。但是當初在規劃行程時,有把這個時間算進去嗎?而且整個design在進入synthesis階段時,在很多的synthesis條件都沒有穩定的情況下,拿去幫類比工程師驗證 LIB是否是正確的選擇?所得到的結果是否會是正確?不正確的話,又需要多少時間收斂?所以類比工程師的LIB 驗證,應該是要在他自己的環境下去完成,而不應該在整合的環境中去做驗證。
IC流程裏,它不是幫類比工程師驗證LIB,它是依據類比工程師提供正確的LIB來做合成的工作。所以在synthesis之前,數位工程師就應要求類比工程師提供正確的LIB,不然就無法合出最合適的netlist。
為什麼synthesis時,要有正確的LIB?
DC-compiler依據LIB上的資訊,利用它的演算法,計算出哪一個gate是最合適的,計算出所有path的timing,告訴你哪一個是很緊的。依據這種概念,合出來的netlist才會是最接近真實的情況。
以下是案例的分享:
類比工程師進度落後,告訴數位工程師,你用設delay方法來收斂 timing,類比工程師會按規格要求,處理好 interface timing,之後就可以tape-out。LIB部份,類比工程師會用手動的方式建立,讓整個 synthesis 流程順暢。 結果晶片回來後,在某些頻率下,會容易出錯。問題查了很多,原因是data出錯;所以數位工程師不可避免的成為主要的負責人。從design到synthesis,然後再到primetime check,之後還check floor-plan。結果發現,是類比工程師在設計介面時,使用推力不足的cell,所以在頻率快的情形下,setup-time violation。但這完全查不出來,因為LIB是非常完美的LIB,它不是擷取類比電路所計算出來的。它是人工的,所以在這個流程中,數位工程師當然查不到setup-time violation的報告。
合成時為什麼需要LIB?當然是想要在最接近真實的情況下,合出適合的netlist。因為LIB太過理想,所以合出來的netlist當然也是太過理想。
為什麼國外大廠的晶片穩定度高?技術好是一個原因。另外一個是他們嚴格要求IC流程的模擬要符合真實情況。所以他們一定用軟體來擷取類比電路,計算出正確timing後,才會公佈 LIB給數位工程師使用。儘量讓所有的數據都是最接近真實情況。
說完IC流程後。我大約分類一下風格,大家或許就可以知道我所說的是什麼意思。希望藉由這些分類,可以更了解你的工程師伙伴在想什麼?
1. Front-end
RTL level數位工程師:遇到問題時,想盡辦法在RTL-level解決,並在RTL-simulation確保function的正確性。其寫出來的RTL code都是synthesizable,了解RTL
code限制,也知道如何在DC環境下,寫出適合的constrain,也知道怎麼看懂的所有的timing
report。其程式風格像前面RTL
code的解決方式一.
2.Front-end post-level數位工程師:程式的風格像前面的RTL code的解決方式二,需要CAD的工程師幫忙保證 timing,無法在RTL-level就保證其timing和正確性。
3.Front-end artificial數位工程師,程式的風格像前面的 RTL code的 interrupt machine的原始範例,用人腦推論;對於DC-compiler提出來的 timing violation時,人工確認是否為假錯( false-error )。
4. cell-base數位工程師:使用verilog語法並參照standard cell/customized cell,畫出電路,不是用寫程式的觀念來寫程式的。
5. Back-end數位工程師: 熟悉DC的指令、primetime指令。對做ATPG, IO scan非常清楚,但是對RTL-coding觀念比較薄弱,因為對DC和 primetime指令熟悉,所以較適合做IP整合工作。
其實還有其他種類的數位工程師,在此就不一
一敘述,我就針對以後我的分享風格做一個說明,讓大家知道我為什麼這樣做,我的原因有在哪裏?我的要求在哪裏?
做為一個數位工程師,你會遇到的問題和困難一定會很多,有時候你無法保證一定可以在RTL
level就把它解決,這其中包括 timing。 而
timing的部份,你可能需要別人的協助,才能把問題解決。但是我希望所有的問題盡量在RTL-level就解決完,除非不能解決時,才會請CAD幫忙保證
timing。之後如果我有分享程式時,你會看到我程式都會在RTL-level解決問題。每個程式也都一定會知道怎麼寫 timing
constrain和看它的 timing
report。
從 IC流程中探索數位工程師的風格--III,布布扣,bubuko.com
原文地址:http://www.cnblogs.com/orchid123/p/3708797.html