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

就Back-end而言：

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

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

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

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

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

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

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

或許你會覺得有些地方是多餘的，像是第一點和第二點，就是要一套primetime來做timing check，誰建的還不都一樣。曾經遇到CAD拿到錯的timing constrain，結果CAD報一大堆timing violation，我用CAD的primetime環境查半天才發覺。所以當CAD報有timing無法收斂時，第一個要先確認是不是環境設定問題。畢竟你給出去netlist時，在DC都是timing收斂。很少有機會到primetime時，發散，除非 margin留得不夠，不然前後應該是一致的。所以為了確保CAD的環境的同步，就只好自己先建一個primetime，兩邊同步在相同的認知上，再開始工作。

另外，對於為什麼要堅持CAD部門提供tapeout的netlist？以及發現timing violation時，數位工程師為什麼不能自己修改？我舉一個案例分享。

有人曾經遇到，project leader發現bug和timing violation時，而為了趕上當初承諾的行程，project leader自己修正bug和timing後，自己用primetime check static timing以及formal check比對RTL和netlist。發現都沒有問題後，就直接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 leader有schedule(行程)壓力，project leader怕別人知道做錯的壓力等等，總是可以找到合理解釋，來縮減IC流程中的步驟。運氣好的話，沒事，運氣不好的呢？

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