rockeric.com

这两日游庐山，一路风景秀丽，晚上落榻在一家环境不错的酒店，索性打算明天脱离队伍，在阳台吹着山风享受这山中不到30度的清凉，多读几篇DVCon2017-2018的论文，再做一点笔记，分享出来，一是补交作业，二是考虑一些可结合应用的点。

昨晚读到一篇关于对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。