面向對象編程（OOP）是業界使用非常廣泛的一種編程范式。以C++的OOP為例，其包含通常我們所說的OOP三大要素：繼承、封裝和多態。

C++ OOP 組成

C++的OOP內容相對來說比SystemVerilog（SV）或者Java （sv很多特性都是借鑒了java）來說更加豐富一些。

以我們最喜歡的特性“繼承”來說，C++不僅支持三種不同level的繼承方式，public繼承，protected繼承和private繼承，還支持多繼承和虛繼承（謹慎使用），簡直強大到沒朋友。

但是在芯片建模、驗證領域使用的最多的還是public繼承。SV參考了Java的設計，并不支持這么多種的繼承方式，并且也只支持單繼承。這減少了很多不必要的麻煩，同時也引導出一個問題：“繼承”是OOP的核心嗎？我們必須擁有強大的繼承方式嗎？

答案是否定的。

SystemVerilog作為專業的驗證語言，目前只支持最簡單的單一繼承，在繼承上你只需要使用extends這個關鍵字。但這并不影響它構建復雜的框架，比如UVM。

事實上也正是如此，“繼承”是OOP初學者最喜歡使用，也最容易被濫用的特性。我們總認為加入了“繼承”，我們的代碼看起來就更加的OOP。事實可能恰恰相反。“繼承”很好，但應該被謹慎使用。繼承代表了is-a的關系，如果你的代碼并不是在描述這樣一種關系，那么你可能需要思考這里我真的該使用繼承嗎。

OOP的本質或者說核心并非“繼承”，而是“多態”。多態所描述的概念用一句來說就是：同樣的接口，不同的實現，即所謂的面向接口編程。具體的從廣義上來說，多態包括靜態多態和動態多態。靜態多態是指在編譯期構成的多態性，動態多態則是運行期。還是以C++為例（因為它足夠全面），廣義上說靜態多態包括function overload，operator overload（本質上也是function overload）以及Template。SV中并沒有function overload（但是有一點點operator overload特性，用不太到），原因稍微有一點點復雜，你需要了解function overload的原理，以及兼容性的考量。Template在SV中也有簡化，成為了“帶參數的類”的概念。SV和C++都有的也是多態的一般所指是所謂的動態多態：function override。

OOP的核心是多態，多態的一般意義就是function override，簡而言之，多態就是通過父類指針/引用/句柄去調用子類對象的虛函數/方法。（這里注意，不要和C++中的dynamic_cast或者SV中的$cast搞混了，在我的另一個專欄《圖解C++對象模型》中將會深入的討論cast的實現原理。）

BTW：這里需要做下說明，關于function overload和function override的中文翻譯：因為SV中并沒有function overload的概念，所以很多人把function override翻譯成了函數重載，這種翻譯是不正確的。如果有一天SV開始支持function overload，將會對讀者造成很大的困擾。所謂的function overload是通過利用函數簽名不同，但是函數名相同，從而利用編譯器的name mangling技術進行實現的一種“相同函數名不同實現”的重載技術，如果以類為例，他們都在同一個類中。而function override是指以虛函數的方式實現子類對父類相同函數簽名的函數進行覆蓋的一種技術。（關于虛函數的實現原理，可以關注我的另一個專欄《圖解C++對象模型》）

SystemVerilog中只有function override，即函數覆蓋，沒有函數重載。這一個最重要的OOP特性是構建UVM框架的關鍵，也是大多數設計模式中的精髓。

設計模式最早被明確提出來是上個世紀90年代，GOF（四人組）出版了《設計模式》這本書，最重要的是書的副標題：可復用面向對象軟件的基礎。誰敢說自己的書是OOP軟件的基礎？！他們敢！

事實上，設計模式并不是GOF發明的，前人已經有了很多關于軟件開發的總結。很多思想，諸如高復用低耦合，分離變化和不變已經在軟件開發中被大家廣泛認可和使用。設計模式是全人類的智慧結晶（至少也是所有軟件工程師的），但是GOF做了非常好的總結，書中總共包含23個實例，并且第一次在軟件領域明確提出了“設計模式”這一概念，雖然“模式”這個概念最早其實來自于建筑學。

GOF的設計模式

《設計模式》所講述的是利用OOP中核心的特性，特別是多態進行軟件開發的技巧，以及具體的實例。到現在為止，雖然軟件開發誕生了很多其他的編程范式，但是OOP一直保持非要重要的地位，很多框架都是基于設計模式的思想進行開發的。設計模式是框架的抽象。UVM中就大量借鑒了設計模式中的思想，如果說UVM的使用方法是“術”的話，那設計模式就是“道”。UVM工程師更應該從中汲取營養，構建更加強大、高效的代碼。

23種設計模式

BTW：設計模式不是萬能的，它不能解決所有問題，很多問題也不適合使用設計模式。設計模式適合解決的典型問題是，你的代碼包含了變化和不變的部分。將變化和不變分離，進行更好的解耦和復用才是設計模式的正道。如果你的代碼在項目中，項目間沒有任何復用的可能，那它就不適合使用設計模式。（然后芯片建模/設計/驗證正是會大量復用、迭代的場景，不管是同一顆芯片不同level間的復用，還是芯片版本間的復用，甚至不同芯片間的復用）

最后要介紹下設計原則。

如果說設計模式是具體的框架的抽象，那么設計原則就是具體設計模式的抽象。

我把八大設計原則貼在下面，需要我們有更多的時間進行學習和體會：

1.Dependency Inversion Principle (DIP)

The DIP requires that high level modules should not depend on low level modules, both should depend on abstraction. Also, abstraction should not depend on details, details should depend on abstractions.

2. Open-Closed Principle (OCP)

The OCP requires that each software entity should be open for extension, but closed for modification.

3. Single Responsibility Principle (SRP)

The SRP requires that a class should have only a single responsibility.

4. Interface Segregation Principle (ISP)

The ISP requires that clients should not be forced to depend on interfaces that they do not use.

5. Liskov Substitution Principle (LSP)

The LSP requires that objects in a program should be replaceable with instances of their subclasses without altering the correctness of that program.

6. Composite Reuse Principle (CRP)

Use combination more than inheritance

7. Interface Oriented Programming (IOP)

Interface programming, not implementation programming

8. Least Knowledge Principle (LKP)

talk only to your immediate friends

事實上，設計原則其包含的設計思想不僅僅可以在寫具體驗證代碼中發揮作用，在做很多芯片設計架構工作中也有非常多可以借鑒的地方。

其實這8個原則大部分都是在講同一個東西的不同側面。這八個原則中我最喜歡的是開閉原則和依賴倒置原則。以開閉原則為例：對擴展開放，對修改關閉。這一條對芯片工程師來說是非常重要的，特別是驗證工程師，已經被充分驗證過的代碼，甚至已經在silicon上充分被驗證過的代碼，應該盡量避免再去修改（不管是RTL code還是你的tb code/test code）。修改意味著所有的regression都要重來，而且還不能保證沒有silicon bug。

但是“永遠不變的是改變本身”。需求總是會有變化，代碼總是會更新，關鍵在于你如何組織你的代碼，讓容易發生變化的部分與不變的部分分開，最小化變動，就是在最小化風險，也是在最小化你的工作量。

工程師要學會解放自己，將繁瑣的工作自動化，將bug出現的概率最低化，這樣你就有更多的時間用于喝茶，聊天和提升自我。

你在解放自己的同時也在為團隊和公司創造更多的價值！

總結

以上是生活随笔為你收集整理的systemverilog硬件设计及建模_UVM方法学与设计模式（一）：从OOP的本质，设计模式到设计原则...的全部內容，希望文章能夠幫你解決所遇到的問題。

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