systemverilog硬件设计及建模_UVM方法学与设计模式（一）：从OOP的本质，设计模式到设计原则...

面向对象编程（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出现的概率最低化，这样你就有更多的时间用于喝茶，聊天和提升自我。

你在解放自己的同时也在为团队和公司创造更多的价值！