今天講一個非常簡單的設計思想，這個東東也是IC設計方法里的基本矛盾之一：模塊劃分與overdesign。

模塊劃分乃是IC設計最基本也最經典的概念之一。該步驟出現在芯片架構設計之初。多方設計人員一起討論，決定要做什么功能，各個功能究竟要做到什么程度。然后將整個芯片切分成多個邏輯清晰的子模塊，決定由誰來實現各個子模塊，通常伴隨著一些嘴仗跟討價還價。討論結束之后，每個人就會大致清楚自己要實現什么功能，然后雙方會寫作接口文檔和自己模塊的功能定義及大致框圖。再接下來，各方進一步確定接口的信號名、位寬以及操作時序。最后開始各自獨立研發，coding自己的模塊。

模塊劃分允許多個IC設計人員同時協作，不需要考慮接口以外別人會怎么做，而只需要考慮自己的模塊怎么做就行。毫無疑問，提高了工作效率。

但是并不一定會提高設計質量，因為它會帶來overdesign的問題。

什么是overdesign?就是過度設計，IC設計人員因為不了解與之對接的模塊是怎么coding的，也不關心對方是怎么coding的，導致很多情況下，考慮了過多的可能性，而把自己的設計搞得過于復雜。明明可以優化的地方，沒有做到優化；明明不需要的東西，卻增加了上去。

模塊劃分是很經典的概念，搞IC設計的人都知道，教科書也愛講。但是沒有人講overdesign，因為這并不是一個經典的概念，也沒有引起該有的重視。

很可惜的是，overdesign是很容易發生的事情。IC設計人員傾向于只在乎自己的功能模塊，一旦接口定義完之后，就不會考慮對方會怎么做，只需要對方提供恰當的接口時序，對于對方的內部的行為不聞不問。

一個很常見的現象，就是IC設計人員在寫作自己的模塊的時候，會傾向于用很多buffer，而非實時處理。我先收到對方的內容，然后buffer住，這樣我可以有更大的設計自由度決定何時處理。因為設計人員對對方模塊沒有精確的預期，不確定對方模塊能否立即回應，多久回應，并且不愿冒風險假設對方模塊會何時回應，所以更傾向于假設無論對方何時回應我都能夠處理，這樣自己的模塊才更加strong。設計人員會認真考慮很多邊界情況，即便這些邊界情況不會發生，他也會做到自己的design里面去以防萬一。

這些overdesign現象，主要原因是因為我們不了解對方的內部設計，有些時候又懶得溝通，深挖細節，所以采用一種保險穩妥的設計方案。有時候會導致，明明雙方可以并行的地方，我們做不到并行，明明不需要的資源，我們無謂的加了上去。有時候對方給我們一根內部信號就能解決我們的控制難題，我們因為不知道對方有這個信號，所以自己兜兜轉轉費大量精力才搞定。

所以，在設計架構定義完成之后，每個設計者在對自己的模塊有了深入細致思考之后，其實還需要一個設計步驟，雙方需要再次開會，確定設計中有哪些可以壓縮的地方，有哪些重復設計或者過度考慮的地方。這個會議的存在將會對整體架構進行一次優化，達到更高的設計水準。

簡單來說，有兩次會議非常重要。一次是在架構定義之初，各方開會決定怎么做模塊劃分，并對各個模塊的功能有一個基本的討論。另一次是各方對自己的模塊進行了深入到RTL層的細致思考之后，再開一次會，確定各方的細致架構合在一起有什么冗余或者低效的地方，進行架構優化。兩次會議，一次為“分”，一次為“合”，才是最合理的設計流程。

當然，很多團隊并沒有開第二次會議的習慣，如果有的話，你會驚訝于overdesgin的現象有多么普遍，也會驚訝于搞設計的人有多么閉門造車。

歡迎大家關注我的微信公眾號：半導學社。

總結

以上是生活随笔為你收集整理的模块怎么用_IC设计方法：模块划分与overdesign的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。