本日让技能项目的验证职员串讲集成验证环境方案。
会议一开始，就直接上测试用例的脚本，让我觉得有些突兀。可后面看到验证环境全貌后，发觉这个确实是技能项目验证环境最关键的地方，不过只是针对这个项目。
下面还是说下验证环境讲解的顺序和过程中的问题吧。
验证用例。
之所以是验证环境的关键，是由于它采取了完备不同于历史项目的方法，用纯脚本开拓和管理用例。
首先，用例配置。除了少数组件用dutcfg调用外，其他模块均用tcl脚本直接配置寄存器，并做了文件封装。用例则按照场景复用复用对应的脚本。传统的的做法也是按照bt，it，st逐层调用。
其次，用例实行过程也用tcl脚本掌握，包括配置调用，勉励设置和仿真结束。
利用过这种办法的人，以为这种办法布局用例比较方便，设置大略，也免编译。这些是用脚本管理的好处。
但是这种办法也有不好的地方，便是把全体配置过程打平了，使得st对所有寄存器可见。技能项目的时候这是由集成验证职员开拓调试的。在产品项目中，不会是这种玩法，一定还是汇合成各组件的配置文件。但是如果让组件供应相应的tcl配置脚本的话，那么是让他们统一管理这种办法，还是同时掩护dutcfg呢，貌似都有一定的难度。
实在还有种折中的方案，便是底层配置复用dutcfg，中间基于此做脚本接口抽象，用例配置和掌握也用脚本开拓和管理。这样就凑集了上述两种办法的优点，缺陷是须要重新适配开拓。
集成验证环境须要继续下层验证的组件，这个总体原则不变，而且集成办法须要与下贱环境达成共识。以是，这个问题很有可能影响后续项目是否连续采取这种办法。
验证勉励和checker组件
由于技能项目人力不敷，当时的原则是用最有效的方法把功能验证完成。以是过程中均采取prbs发勉励，然后用prbs自检。我对这个策略意外，但也理解他们这样搞的无奈干饭。可是，这种办法对继续产品化的项目非常不友好。产品化项目没有一prbs到底的，否则如何知足协议的同等性，如果设计做错了，但是自己对接通的，那岂不是玩完了。以是这块完备不能利用历史项目的方案，须要借鉴历史产品项目成熟的方案。
验证场景和路径
集成验证的用例管理了一个用例表单，其描述了所有覆盖的业务路径和模式，以及详细韶光的测试方法。虽然都是采取prbs测试，但是覆盖的策略可以很大程度上复用的。不过有个问题，我原来做过的st项目，用例的实行路径，基本上都是某个口的rx打入勉励，对应的tx接管芯片发送数据，然后在checker中做比对。这种办法在当前的项目中是否存在风险，须要重点考虑的。
chip和core，专项的验证环境。
集成环境须要知足不同模式的验证需求，包括chip层，core层，还有专项。串讲没有对这部分做解答。
分外功能验证，迭代驿码须要采纳特殊的勉励布局办法。
还有一个是，集成验证环境的tag管理办法如何开展，也是个须要考虑的问题。
上述便是本日串讲的紧张内容和疑问，总结起来便是不完全。验证环境是为验证做事的，而验证方案要回答这个最主要的问题便是如何确保可支撑验证的完备性。由于不完全，以是让我对这块有了较大的担忧。这块须要我提前做好准备。
