路科验证官网：路科验证 – 专注于数字芯片验证的系统思想和前沿工程领域
EETOP路科首页： EETOP – 路科验证 – IC验证培训
CSDN路科首页：CSDN – 路科验证 – IC验证培训
昨晚读到一篇关于对DFT测试寄存器建模的论文，写得非常好，One Stop Solution for DFT Register Modelling in UVM，来自于AMD HUANG,Rui 北京office。这也是我至今看到的不多的利用UVM寄存器模型扩展到超长位的测试寄存器模型，并且实现特殊的扫描链访问的[一站式解决方案]。尽管路桑也之前在公司内部推动DFT的UVM验证环境应用化，不过现在看来，我们与友司在测试DFT TDR（Test Data Register）的方案上已经是两套科技树了，也必须得承认我们在该方向的测试封装方案还不够完整，在可读性和复用性方面还欠佳，另外一方面，我们在测试自动化方面已经不错了。接下来，路桑觉得可以邀请该论文的作者，亲自为我们做一期对DFT TDR寄存器建模解决方案的介绍。
今天路桑又读到一篇今年同为DVCon2018-China论文评审委员会成员，Srinivasan Venkataramanan （VerifWorks Pvt Ltd. India Bangalore）的论文，Architecting “Checker IP” for AMBA protocols，关于如何实现“检查IP”的详细建议。我认为这一篇论文对于任何一家公司，如果想自己做技术储备，实现验证IP和检查IP的话，都有必要熟悉一下，做一下比较，看自己在实现验证IP和检查IP的过程中，还有哪些事项需要注意，还有哪些流程可以参考学习。还是老规矩，对这两篇论文感兴趣的都可以到路科官页资源处下载。
验证IP（VIP, Verificatioin Intellectual Properties）已经在动态验证环境中无处不在了，它也可以分为两部分——一部分包括sequences,tests和configuration部分；另外一部分，它包含一个VIP的检查部分，譬如scoreboard/checker以及coverage（function & assertion）。在上面的部分中，对于形式验证（FV, Formal Verification）而言，它往往只需要VIP的检查部分（assertion properties）和部分coverage。因此，该篇论文为了区分VIP的开发，将检查部分称为了CIP（Checker IP）。也就是说，VIP中可以包含CIP，而CIP既可以为动态仿真提供checker，也可以为形式验证FV提供checker。这一篇论文就单独将CIP拿出来说事儿，讲了讲在实现CIP过程中需要注意的地方，以及一些心得体会。路桑觉得这篇文章好的地方就在于系统，在于从一家验证咨询公司开发CIP的过程提供了专业视角，为多数工程公司在实现VIP/CIP过程中也提供了一些建议。
接下来，该论文以AXI CIP开发为例，从CIP的结构，实现过程，单元测试和最终发布上都做了介绍，更多的细节请诸君在论文中去学习吧。
CIP架构
同做设计一样，在实现CIP时，也需要考虑软件结构，以AXI master/slave对应的CIP开发为例，需要注意到CIP是针对master还是针对slave。例如对于master而言，要检查的输出信号，需要作为assert类型，而这些master的输出信号对于slave而言作为输入，则变成了assume类型，即对激励加以限制。
譬如property p_vw_awburst是用来检查master AWBURST的信号行为，因此在针对AXI master一侧时，则是“assert”属性，而这些针对master的assert属性在slave一侧时，可能就变成了“assume”属性。
所以，这使得我们在开发CIP时，需要将property先声明，至于其在master和slave两侧被指明为assert或者assume又或者cover属性，需要我们区别对待。这里，需要注意一点，assume属性主要在形式验证时会被用来对激励加以限制。从下图也可以看到，对于master和slave的不同属性（asserts/assumes）所使用到property数量和类型也都不相同。从复用角度而言，我们可以将property尽量描述在同一文件，而将它们针对master或者slave的属性声明分别置于master CIP以及slave CIP。
创建CIP的容器和注意事项
放置CIP即assertion的容器无外乎是module或者interface。这两种容器在使用时有各自的特定。对于module而言，一旦我们在其内部声明了assertion，针对DUT，我们可以将其assertion容器（module/interface）bind绑定到DUT。这样，在编译后，assertion容易“vf”就看起来同例化在“dut”中一样，当然bind并不会由此修改设计，而是做到了attach但是不影响设计功能。不过bind有一点不尽如人意的地方，那就是无法很方便地深入dut的层次查看到更多的信号。
接下来，我们看看interface的信号probe方式，无论是直接利用SV的信号路劲层次赋值、EDA仿真器提供的信号probe函数、又或者利用UVM DPI接口的函数，都可以使得DUT中的信号很容易地被监测到接口中的各个信号。只不过在使用接口时，如果我们想将CIP（module）例化在接口，可就会遇到一点麻烦。因为interface只能够例化interface，而无法例化module。因此，CIP需要被装载到interface中，这样可以完成CIP的复用。
此外，考虑到CIP会同时被使用在动态仿真环境和形式验证环境，尤其在形式验证环境中，对于非综合的或者UVM相关的代码支持地不够那么友好，所以CIP的代码在实现中，需要结合编译指向来提供灵活的应用方案，以下即通过编译选项“VW_CIP_SIM”来区分动态仿真环境和形式验证环境。
如何开发及发布VIP/CIP？
这是一个鸡生蛋蛋生鸡的问题，包括路桑最近也在主持一些AHB/AXI开源VIP开发工作的事情。APB2.0 & 3.0 VIP目前已经完成，我们将会在不久之后发布到路科官网的资源供大家下载学习使用，AHB/AXI也在准备当中。路桑在开发过程中，是通过已有VIP来验证自开发的VIP，而接下来介绍的方式也有助于VIP在每一版开发时的准确发布。
该观点涉及到的软件单元测试概念以及测试开源包SVUnit已经在路桑的红宝书中介绍过，大家可以自行补充概念。该论文也是基于SVUnit和软件单元测试概念，在开发每一个property时，不但提供正确的场景，也提供错误的场景分别来测试其反应，即检查是否在正确场景和错误场景中做出了期望的响应。
从该论文的CIP发布经验，以及路桑团队自身在开发开源VIP的过程中，我们一致认为标准的单元测试环境非常有助于前期开发以及后期版本的稳定推出。也就是说，越偏向软件的部分越容易和越应该将单元测试的概念贯穿下去，当然，在开发VIP的过程中覆盖率的完善的灵活的随机配置都有助于我们更快使得VIP能够稳定下来。
不久之后，路科将会发布APB2.0、APB3.0 VIP的开源版本，只作为大家的学习使用，在我们接下来发布了AHB3.0 VIP后，路桑将会出一个VIP开发的文章系列，指导有需要的朋友，从想法、到结构、到开发流程、最后到VIP发布的完整生命周期——懂行的验证老司机，该知道这个福利有多么难得吧？
与诸君共勉，只要你还热爱验证，热爱技术。另外，路桑在回顾DVCon US这两年最佳论文的时候发现，投自Austin（德州）这个城市的论文和验证专家出气地多，论文质量也都奇佳。路桑觉得这似乎同当地收入和生活水平存在某种联系，或者也能够说明，居住在让你能够静下心来做研究的地方对于工程师更友好一些吧。
