2014年4月27日 星期日

從 IC流程中探索數位工程師的風格--II

Back-end而言:
Back-end的工作內容,主要的負責單位是CAD部們,數位工程師只是輔助的角色。如果是輔助的角色,那麼應該要注意哪些細節呢?

1. 建立primetime環境來驗證CAD做完APR後的netlist是否是符合自己的需求。

2. CAD給一套和他工作環境相同的primetime環境,做為最後驗證timingpath的依據。

3. 任何因為timing不符合時,需要修改netlist時,請CAD重做一份,數位工程師不代勞。

4.任何因為bug問題,需要修改netlist時,數位工程師要做,但是再請CAD工程依修改的netlist做出一份新的post netlisttiming model。不用數位工程師修改的版本來做primetime check。要用CAD的版本做primetime check

5. 數位工程師要跑post-level simulation,驗證post-netlist是否是正確的?

6. 如果都驗證無誤時,要用CAD部門的版本當成是對外要tapeout的版本。

或許你會覺得有些地方是多餘的,像是第一點和第二點,就是要一套primetime來做timing check,誰建的還不都一樣。曾經遇到CAD拿到錯的timing constrain,結果CAD報一大堆timing violation,我用CADprimetime環境查半天才發覺。所以當CAD報有timing無法收斂時,第一個要先確認是不是環境設定問題。畢竟你給出去netlist時,在DC都是timing收斂。很少有機會到primetime時,發散,除非 margin留得不夠,不然前後應該是一致的。所以為了確保CAD的環境的同步,就只好自己先建一個primetime,兩邊同步在相同的認知上,再開始工作。
另外,對於為什麼要堅持CAD部門提供tapeoutnetlist?以及發現timing violation時,數位工程師為什麼不能自己修改?我舉一個案例分享。

有人曾經遇到,project leader發現bugtiming violation時,而為了趕上當初承諾的行程,project leader自己修正bugtiming後,自己用primetime check static timing以及formal check比對RTLnetlist。發現都沒有問題後,就直接tapeout。晶片回來後,發現有部份的設計,有hold-time violation的疑慮,project leader不敢說自己有修正netlist,直說是CAD的版本有問題,CAD部門查了半天,都查不出來。重做第二版時,就用新的RTL code合成,也真的是用CAD部門的netlist tapeout,結果第二版的晶片出現和第一版本的錯誤完全不同。總經理就疑惑,「不是沒有改RTL code為什麼會這樣子?」工程師在第一顆晶片查到的有些問題,都無法在第二顆晶片上得到解釋。Project leader也無法在第一顆和第二顆晶片實驗中,得到他完滿的解釋。最後是誰背黑鍋,還是CAD。因為hold-time violation沒有再出現,但是新的問題又出現,而從頭到尾第一顆晶片和第二顆晶片的RTL都是一樣的,只是第一顆的RTL是在tapeout前才底定。

Back-end這個階段,數位工程師只是輔助的角色,那就做好輔助的工作,一切都是CAD說了算,project leader也沒有能力去修正netlist,數位工程師的本份就是盡力幫CAD版本的netlist做最大的驗證;發現任何問題,就是要讓大家都知道,然後再跑一次流程。每個計劃中,有很多的成員加入,尊重每個領域的專業,並讓他確實的負責,這樣子才會讓加入的工程師有參與感和使命感,才能留住工程師的心。

token的轉移和劃分的概念,不光是用在design上,還可以用在IC的流程上,實際上,它很多其他的地方。整個project的規劃也可以用這個概念,只不過當方法和規則建立後,你願意嚴格遵守並確實的執行嗎?

有的數位工程師會嚴格遵守並確實執行,有的不會。我們都知道,事實上是很難,因為project leaderschedule(行程)壓力,project leader怕別人知道做錯的壓力等等,總是可以找到合理解釋,來縮減IC流程中的步驟。運氣好的話,沒事,運氣不好的呢?

工程師是做科學驗證的工作,希望能嚴格遵守並確實執行,提昇晶片的穩定度及品質。或許有著各式各樣的壓力,但是能堅持下去,就是知行合一實踐。不然光說不練,對於管理上也是一種很大的傷害。


沒有留言:

張貼留言