设计模式
在软件开发的世界中，有一个非常引争议的话题，那就是要不要造轮子。为什么有这样的争议，归根结底，造轮子有利也有弊。
越是大厂，越是倾向于自己造轮子。不管是不是真的有价值，至少看上去很牛逼。
总体上，轮子不可避免。一些已经得到广泛的实践证明了的东西能够让团队内每个人的工作更有价值。并且，这种价值是持续性的，能够让一个小白轻松承接复杂的任务。
在日常的项目工作中，不应该反对造轮子。也许别人强推的轮子不是那么好用，但是这不能否定造轮子&使用轮子这个事情本身的价值。
对于芯片验证来说，当然需要非常多的创造力。验证最多的工作可能就是在你脑袋里对于各种复杂场景的发散和对于客户需求的深刻理解。
而针对芯片验证环境的搭建而言，就不得不需要轮子了。尤其是考虑到系统级验证环境的集成，建立共识是非常非常关键的事情。
到这里，你就发现了，芯片验证工作的难点还是模块上下游之间、软硬件之间的沟通。但凡有一方模棱两可，就有极大的概率发生bug遗留。
软件开发中轮子，或者换个看起来专业点的词汇，提供一般性问题解决方案的设计模式，在芯片验证环境的搭建中也是必不可少的。
芯片验证借助软件开发技术是大趋势，但是又有自己的特色。
关于设计模式有一本最经典的书籍：
Design Patterns: Elements of Reusable Object-Oriented Software
中文《设计模式：可复用面向对象软件的基础》
介绍了绝大多数软件开发世界的设计模式，包括设计模式的应用场景、名称以及代码示例等。
设计模式在UVM中的示例数不胜数，例如信息报告机制用了单例模式、对象例化用了工厂模式等等，有机会的话后面可以一一分享各个设计模式在SystemVerilog或者UVM中的实现细节。
为什么需要UVM？
回到我们熟知的验证领域，我们为什么需要UVM？
这个问题挺大的，可以从一个问题开始。如果将芯片EDA验证环境的开发看成一个软件开发项目，那么
- 这个软件项目的特点是什么？
- 这些特点能够利用到哪些设计模式以提高芯片功能验证交付的效率和完备性呢？
前面提到的软件设计模式书籍介绍了数十个设计模式，这些都是软件编程的精华。但是并不是每一个设计模式都是被我们芯片验证环境开始所需要的，这个时候UVM就从中提炼出一些关键的设计模式用于高度复用的验证环境搭建，并支持在相同的验证组件进行不同的用例场景构造。
另外UVM针对芯片验证的特点，还考虑了验证环境的可配置型、覆盖率驱动、受约束随机等等 。
作者：验证哥布林
来源：芯片验证工程师
推荐阅读
- 聊聊覆盖率驱动、受约束随机和UVM
- cache学习系列2：cathe的缺点，直接映射cache及组相联cache
- 处理器中基本的cache结构概述及一些cache相关的术语
- cache学习系列3：cache的性能及Write和Fetch buffer
更多数字IC设计技术干货等请关注数字芯片实验室专栏。添加极术小姐姐（微信：aijishu20)微信可申请加入IC设计交流群。
