最近一直在幫同事解決各種問題。由於臨近項目後期，所以很多問題的解決方法並不能只是告訴他們調整flow，重新跑flow。有幾個問題也是比較常見的問題，大家或多或少可能都遇到過。今天小編挑選幾個主題，做一個簡單的分享，也算做個簡要的歸納，希望對大家能夠有所啟發(小編微信：ic-backend2018)。對文章存在疑惑或者想跟小編做進一步交流的，可以私信。

Power off模塊輸出端未設置dont_touch

大家都知道，對於一個可以powerdown的模塊，其輸出是不可控的。所以需要在其輸出端添加Isolation cell，將其clamp為0或者1，保持一個穩定的狀態。

在數字後端實現時，需要將Isolation cell的輸入端與powerdown模塊的輸出直連，確保中間沒有buffer。為了實現這個目的，可以通過將Isolation cell的輸入端設置為dont_touch。

另外，還需要將這類Isolation cell 擺放在port門口。目的是確保powerdown模塊的輸出端與Isolation輸入端的距離足夠近，沒有transition問題。具體實現方法可以通過magnet placement 來實現。

這些低功耗設計實現經驗，你真的懂了嗎？

那如果碰到比較粗心或者經驗不足的數字後端工程師，他們在實現時並沒有注意或者遺漏這些問題，導致在powerdown模塊的輸出端加了buffer（輸出端的port有上千個），而且此時已經是項目後期，沒有足夠時間重新跑flow。那麼應該如何解決呢？

解決方法其實很簡單，完全不需要重新跑flow，甚至都不需要去挪isolation cell的位置。只需要做一個簡單的ECO即可。將power down模塊的輸出的net斷開，和Isolation cell的input pin連接起來，再把Buffer連接到Isolation cell後面即可。

時鐘樹重要技能

小編也是很好奇，為何很多三四年甚至工作年限更長的數字後端工程師，對於複雜時鐘結構的時鐘樹綜合仍然摸不著頭腦？真的有那麼難嗎？顯然沒有。

數字後端工程師必須掌握的時鐘樹綜合的技能

理清時鐘樹結構，並畫出時鐘結構圖。這點小編在公眾號分享時鐘樹綜合相關分享時，每次都要提到，可是真正會的人可能並不多。

編寫長時鐘樹的constraint。有了時鐘結構圖後，我們就可以寫cts constraint，這個constraint是用來引導告訴工具如何長時鐘樹，即告訴工具某個clock的root點在哪裡，sinks是哪些，哪些clock是要做同步的，哪些clock是需要做inter-balance的，各個mode下時鐘如何長tree等。

這個constraint真心不難寫 。不外乎就是create_clock create_generated_clock set_clock_group以及設置一些exception。這些命令估計沒有一個人不會的。只要你理清了時鐘結構，還是很容易可以寫好的。下圖為一個複雜時鐘結構電路中最簡單的一個分支，大家看看應該如何寫constraint?

其實理清時鐘樹結構，編寫cts constraint這項工作，完全可以說這個是數字後端工程師最核心的一項技能，沒有之一。而且也是數字後端實現整個環節中最具技術含量的一項工作。對於一個複雜時鐘結構的設計，如果你能夠很清楚地寫出cts constraint，長出很「漂亮」的clock tree，那麼整個數字後端實現還有其他的難點嗎？

深度解析Create_clock與Create_generated_clock的區別

為什麼時鐘樹上要用clock inverter(min pulse width check)

數字後端設計實現之時鐘樹綜合實踐篇

合理的時鐘結構能夠加速Timing收斂（時鐘樹綜合中級篇）

Route後沒short，hold fixing後存在short

有的數字後端工程師做事情就是不夠認真。比如拿route後的數據進行了一輪hold fixing後，發現沒有short，以為就萬事大吉了，不再做後續的hold fixing了（評估階段）。等最後拿到final netlist，進行final run後發現hold fixing會引入大量的short。主要原因有以下幾點：

  • 前期hold fixing評估所用的corner不全

前期評估hold所用的corner比較少，所以hold數量偏少。後期將所有corner都考慮進去後，發現hold buffer太多，從而導致route 出現short。

  • Local clock skew偏大，導致hold violation較大。

Clock skew比較大，說明tree長的不平。雖然setup可能是meet的，但是兩個clock tree latency差距比較大的寄存器進行hold check時，很容易出現較大的hold violation。所以在局部區域需要插入特別多的hold buffer，這樣就容易出現short。

一網打盡時鐘樹綜合Clock Skew

  • Local cell density太高，出現局部區域density為100%的情況

這種情況其實還是蠻常見的。雖然局部區域cell density已經達97-100%，但是route和timing都是OK的。所以，很多初級後端工程師誤以為這不是潛在的地雷。其實這是非常危險的，如果碰到這種情況，不做特別處理，後期hold fixing和解route問題都是非常棘手和痛苦的一件事。

所以，小編一直反覆強調每個stage都需要查看congestion map，cell density map和pin density map。這絕對不是為了好玩哦。

數字後端實現時congestion比較嚴重，你hold得住嗎？

動態IR Drop偏大

  • 在高翻轉模塊中預先插入decap cell

通常情況高翻轉模塊，也是design中timing比較緊的地方。在該區域預先插decap cell可能會導致timing變差。因此，插decap cell的方式就顯得尤為重要。主要圍繞兩個原則，一個是timing所受的影響較小，在可接受範圍之內，第二是decap cell要足夠多，足以改善IR Drop issue。

  • 減少power switch cell的電阻

特別是對於需要做power domain的模塊，更容易出現IR Drop問題。由於Power switch 本身電阻較大，Global VDD到Power switch就存在一定的壓降，這個壓降比例值往往能佔到1.5%。所以，如果能夠定製一款低電阻值的power switch cell，豈不是一種很好的解決方法。

  • 利用高層金屬來畫power

高層金屬比較寬，比較厚，所以電阻值相對較小。所以通常都是用高層厚金屬來打power。

  • 加密power mesh

對於項目後期發現的動態IR Drop問題，可以從Redhawk結果中分析找出壓降比較大的點，然後在該區域局部加密power的密度。

IR Drop分析之Redhawk分析流程

小編知識星球簡介（如果你渴望進步，期望高薪，喜歡交流，歡迎加入）：

在這裡，目前已經規劃並正著手做的事情：

  • ICC/ICC2 lab的編寫
  • 基於ARM CPU的後端實現流程
  • 利用ICC中CCD（Concurrent Clock Data）實現高性能模塊的設計實現
  • 基於ARM 四核CPU 數字後端Hierarchical Flow 實現教程
  • 時鐘樹結構分析
  • 低功耗設計實現

  • 定期在星球布置作業題（星球已經支持布置作業功能）

在這裡，各位可以就公眾號推文的內容或者實際項目中遇到的難題提問，小編會在24小時內給予解答（也可以發表你對數字後端設計實現中某個知識點的看法，項目中遇到的難點，困惑或者職業發展規劃等）。

反正它是一個縮減版的論壇，增強了大家的互動性。更為重要的是，微信有知識星球的小程序入口。星球二維碼如下，可以掃描或者長按識別二維碼進入。目前已經有168星球成員，感謝這168位童鞋的支持！歡迎各位鐵杆粉絲加入！終極目標是打造實現本知識星球全員年薪百萬的宏偉目標。（星球的門檻將會越來越高，有需求的朋友趁早上車）


推薦閱讀：
相关文章