日志

验证的结构篇之三：激励发生器

已有 2124 次阅读| 2016-11-27 23:01 |个人分类:验证系统思想|系统分类:芯片设计

Stimulator（激励发生器）是验证环境的重要部件，在一些别的场合中，它也被称之为driver（驱动器）、BFM（bus function model，总线功能模型），behavioral（行为模型）或者generators（发生器）。Stimulator的主要职责就是模拟与DUT相邻设计的接口协议。与真正的相邻设计相比，stimulator只需要关注与如何模拟接口信号，使其能够以真实的接口协议来发送激励给DUT。stimulator并不需要模拟相邻设计内部的功能细节，这使得实现一个stimulator的工作相对设计而言更容易，且更方便维护。

从模拟接口协议的角度来看，首先stimulator不应该违反协议，但不拘束于真实的硬件行为，还应该给出更多其它丰富的只要协议允许的激励场景。比真实硬件行为更丰富的激励，这使得在模块级的验证更加充分，因为它不但验证过了硬件普通的接口协议情景，还模拟出更多更复杂、在更高系统级别无法产生出来的接口场景，而这些场景只有在模块级验证才可以更容易地产生和分析。往往这些复杂的边界场景（corner scenario），会有几率触发到设计的一些未足够考虑的设计缺陷。对于边界情景所触发的设计缺陷，我们一般遵循立即修正的规定，因为即便该场景可能在系统集成以后很难被触碰到，但是谁也无法保证它在这个项目或者下一个项目中不会被系统触发。

在构建stimulator的时候，核心的准备就是熟读接口协议，并且正确理解。如果stimulator无法完全实现协议的全部，那么可以想象我们利用stimulator生成的场景也是不完备的，这就直接使得验证接口覆盖率的不完整，有大的验证风险存在。

对于接口协议，如果是商业成熟的协议，我们建议使用第三方的商用接口IP，这很大程度上节省了二次开发的成本和对stimulator调校的精力。因为如果是较复杂的协议，我们可能面对stimulator协议实现上的缺陷，或者未完全实现协议，而这些地方对于验证的成功和效率来讲都是有消极影响的。如果处于经济的考虑，我们也仍然不建议使用一个不成熟的stimulator，至少该接口stimulator应该经过足够的时间来开发、自我验证（仍然利用第三方商用接口IP来进行自我验证）。

如果接口协议较为简单，或者是内部设计之间规定的非标准接口，那么应该查阅相邻设计的硬件描述文档，如同上一节《硬件设计描述》中的一样，充分理解接口的时序。如果你不幸遇到了一个没有接口时序的设计，恐怕你需要同DUT和相邻设计的双方设计者沟通，从他们的口中理解接口协议，同时也可以帮助双方在项目前期排除是否有接口协议的理解和实现分歧。但需要注意的是，对于接口的理解，不应该完全遵循设计者的假定，更不应该去看设计的接口实现代码，因为这违反了设计参照的来源应该从系统人员那里来。验证者需要做的是调查、收集有用信息、但不完全采纳设计者关于接口的设定。

stimulator的接口主要是同DUT的连接关系，此外，也应该有时钟和复位的输入，确保生成的数据同DUT的接口一侧是同步的关系。较精细的stimulator还可以有其它的配置接口用来控制接口的数据生成。

最后，stimulator也可以有存储历史接口数据生成的功能，可以在仿真运行时或者结束后方便查看接口数据，用来统计或者调试。

就stimulator同DUT的连接关系来看，我们可以将其进一步分为两种：initiator（ 发起器）和responder（相应器）。就我们要验证的MCDF来看，同下行通道从端的连接或寄存器接口的连接两部分的stimulator都属于initiator，它们的功能是主动发起接口数据传输；而对于MCDF formatter接口的连接，该stimulator则属于responder，它的职责是对接口的数据做出相应，不会主动做出接口数据发送。

接下来，我们进一步从上一节的接口协议和时序来分析，考虑在实现上图中的三种stimulator时，需要考虑的因素有哪些地方。

Channel initiator
由于channel从端接口协议上有握手信号，我们需要遵照接口时序，确保chx_ready为低时，保证chx_data和chx_valid保持不变。
相邻数据之间没有数据包的限制，所以相邻数据之间的关系较弱，但也应该考虑数据之间是否有空闲周期，已经整体数据的传输速率设定。
由于每一个数据从端都有对应的FIFO缓存数据，所以也需要考虑如何使得FIFO的状态可遍历。例如，典型的FIFO状态可以分为empty、full以及中间状态即有数据存储但未写满。要使得FIFO可以触发到这些状态，我们就应该控制channel initiator的传输速率。

Register initiator
寄存器接口上cmd的默认状态应该为idle，但cmd_addr、cmd_data_in并未指出应该为何值，所以可以考虑给出随机数值测试DUT的接口协议稳定性。
在寄存器读写传输上，可以考虑连续的写、读、或者读写交叉的方式测试寄存器模块的读写功能。
对于规定的读写控制寄存器的所有比特位都应该测试到位，同时，也需要测试只读比特位是否为不可写入的状态。
对于规定的只读状态寄存器需要测试是否为不可写入状态，同时，需要检测独处的数值是否为真实的硬件状态。

Formatter responder
作为三种接口协议中相对复杂的一个，首先要侧重DUT的formatter接口协议是否充分遍历。
同时需要详细理解协议的要求，除了按照协议给出fmt_grant的响应以外 ，也需要内置协议检查部分，确保协议的正确性。
fmt_grant的置高，则代表formatter的从端，即formatter responder作为行为模型，它有足够的存储空间容纳formatter要传输的长度为fmt_length的数据包。为此，为了模拟真实场景，我们可以考虑让fmt_grant采取立即拉高或者缓时拉高的行为，测试DUT内formatter的行为。

至此，我们已经结合实际的MCDF，给出了stimulator的连接关系和实现时需要注意的地方，而代码部分我们则会在接下来SystemVerilog和UVM的篇章为大家具体提供可参考的实现。

下一节，我们将进入monitor（检测器）的部分，看一看如何放置检测器较为合理，优劣分别在什么地方。

谢谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。