SystemVerilog学习笔记2——硬件设计描述（MCDF）

---

多通道数据整形器(MCDF, multi-channel data formatter)，它可以将上行(uplink)多个通道数据经过内部的FIFO，最终以数据包(data packet)的形式送出；其上行数据和下行数据的接口协议不同；有寄存器的读写接口，可以支持更多的控制功能。

• 上行数据的通道从端(Channel Slave)，负责接收上行数据，并存储到与之对应的FIFO中；
• 仲裁器(Arbiter)，可以选择从不同的FIFO中读取数据，进而将数据进一步传送至整形器；
• 整形器(Formatter)，将数据按照一定的接口时序送出至下行接收端（将数据打包以数据包的形式发送）；
• 控制寄存器(Control Registers)，有专用的寄存器读写接口，负责接收命令并对MCDF的功能做出修改。

MCDF接口描述

系统信号接口

• CLK(0)：时钟信号；
• RSTN(0)：复位信号，低位有效。

通道从端接口

• CHx_DATA(31:0)：通道数据输入；
• CHx_VALID(0)：通道数据有效标志信号，高位有效；
• CHx_READY(0)：通道数据接收信号，高位表示接收成功。

整形器接口

• FMT_CHID(1:0)：整形数据包的通道ID号；
• FMT_LENGTH(4:0)：整形数据包长度信号；
• FMT_REQ(0)：整形数据包发送请求；
• FMT_GRANT(0)：整形数据包被允许发送的接受标示；
• FMT_DATA(31:0)：数据输出端口；
• FMT_START(0)：数据包起始标示；
• FMT_END(0)：数据包结束标示。

控制寄存器接口

• CMD(1:0)：寄存器读写命令；
• CMD_ADDR(7:0)：寄存器地址；
• CMD_DATA_IN(31:0)：寄存器写入数据；
• CMD_DATA_OUT(31:0)：寄存器读出数据。

MCDF接口时序

• 通道从端接口时序：valid为高时表示要写入数据。如果该时钟周期ready为高，则表示已将数据写入；如果该时钟周期ready为低，则需要等到ready为高的时钟周期才可以成功将数据写入。
• 整形器接口时序：整形器发送数据是按照数据包的形式发送的，可以选择数据包的长度有4、8、16和32。整形器必须完整发送完某个通道的数据包，才可以转而准备发送下个数据包；发送数据包期间，fmd_chid和fmt_length应该保持不变直到数据包发送完毕。
• 整形器准备发送数据包时应先将fmd_req置为高，同时等到接收端的fmt_grant。当fmd_grant变为高时应在下个周期将fmt_req置为低。fmt_start必须在接收到fmt_grant高有效的下个时钟被置为高且需维持一个时钟周期，即一个时钟周期的脉冲信号。
• fmt_start被置为高有效的同个周期数据也同 时传送，数据间不允许有空闲周期，即应连续发送数据直到发送完最后一个数据，同时fmd_end也应被置为高且保持一个时钟周期。
• 相邻的数据包之间应保持至少一个时钟周期的空闲，即fmd_end脉冲为低以后，至少需经过一个时钟周期，fmd_req才可被再次置为高。
• 控制寄存器接口时序：控制寄存器接口首先需在每个时钟解析cmd，当cmd为写指令时需要把数据cmd_data_in写入到cmd_addr对应寄存器中；读指令时需要从cmd_addr对应的寄存器中读取数据，在下个周期cmd_addr对应的寄存器数据被输送至cmd_data_out接口。

MCDF寄存器描述

地址0x00 通道1控制寄存器 32bits 读写寄存器：

• bit(0)：通道使能信号。1为打开，0位关闭。复位值为1。
• bit(2:1)：优先级。0为最高，3为最低。复位值为3。
• bit(5:3)：数据包长度，解码对应表为， 0对应长度4， 1对应长度8，2对应长度16，3对应长度32，其它数值（4-7）均暂时对应长度32。复位值为0。
• bit(31:6)：保留位，无法写入。复位值为0。

地址0x04 通道2 / 地址0x08 通道3控制寄存器 32bits 读写寄存器：

• 同通道1控制寄存器描述。

地址0x10 通道1状态寄存器 32bits 只读寄存器：

• bit(7:0)：上行数据从端FIFO的可写余量，同FIFO的数据余量保持同步变化。复位值为FIFO的深度数。
• bit(31:8)：保留位，复位值为0。

地址0x14 通道2 / 地址0x18 通道3状态寄存器 32bits 只读寄存器：

• 同通道1状态寄存器描述。

激励发生器

• stimulator（激励发生器），也被称为driver（驱动器）、BFM（bus function model，总线功能模型），behavioral（行为模型）或generators（发生器）；
• 主要职责是模拟与DUT相邻设计的接口协议。只需关注于如何模拟接口信号，使其能够以真实的接口协议发送激励给DUT；
• stimulator不应违反协议但不拘束于真实的硬件行为，还应该给出更多其它丰富的只要协议允许的激励场景；
• 比真实硬件行为更丰富的激励，使在模块级的验证更加充分，因为不但验证过了硬件普通的接口协议情景，还模拟出更多更复杂、在更高系统级别无法产生出来的接口场景；
• stimulator的接口主要是同DUT的连接关系，此外也应该有时钟和复位的输入，确保生成的数据同DUT的接口一侧是同步的；较精细的stimulator还可以有其它配置接口用来控制接口的数据生成；
• stimulator可以有存储历史接口数据生成的功能，可以在仿真运行时或结束后方便查看接口数据，用来统计或者调试；
• 将stimulator进一步分为initiator（发起器）和responder（响应器）。就MCDF来看，同下行通道从端的连接或寄存器接口的连接两部分的stimulator都属于initiator，主动发起接口数据传输；而MCDF formatter接口的连接，该stimulator属于responder，对接口的数据做出响应，不会主动发送数据。如下图所示：
  

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要传输长度为fmt_length的数据包。为了模拟真实场景，可考虑让fmt_grant采取立即拉高或延时拉高的行为，测试formatter接口的响应时序。

监测器

Monitor的功能是观察DUT的边界或内部信号，并经过打包整理传送给其它组件；

• 观测DUT边界信号：对于系统信号如时钟，可以监测其频率的变化；对于总线信号，可以监测总线的传输类型和数据内容，以及检查总线时序是否符合协议；
• 观测DUT内部信号：灰盒验证，需探视DUT内部信号，用来指导Stimulator激励发送，或完成覆盖率收集和内部功能的检查。

全局性的monitor——监视整个环境中的信号：

分布式的monitor——每个monitor都对应一个stimulator：

• 独立性：方案二较好，不同接口信号的采集交给相应的Monitor；
• 复用性：方案二较好，相对独立的Monitor可以更好的作为验证IP被其它验证环境所复用；
• 可维护性：方案二较好，定向维护Monitor不需要考虑其它的Monitor；
• 封装性：方案二较好，Monitor和Stimulator一一对应，可封装成独立的小组件，使其提供激励和监测。

内部信号监测建议

• 没有特殊需要，应该采取灰盒验证的策略；
• 观测的内部信号应尽量少，且应当是表示状态的信号；
• 可以通过接口信息计算的，就尽量少去监测内部信号，因为这种方式有悖于假定设计有缺陷的验证思想，观测到的内部信号在被环境采纳之前也有必要确认它们的逻辑正确性，可通过动态检查或断言触发的方式实现。

比较器

• 比较器实现难度较大且费时费力（最费时），同时还需要维护；
• checker负责的是模拟设计行为和功能检查；
• 可以缓存从各个Monitor收集到的数据；
• 将DUT输入接口侧的数据汇集给内置的reference model，它扮演模拟硬件功能的角色；
• 通过数据比较方法，检查实际收集到的DUT输出端接口数据是否同reference model产生的期望数据一致；
• 对于设计内部的关键功能模块，也有相对应的线程进行独立的检查；
• 可以将检查成功的信息统一纳入到检查报告中，检查失败也可以采取暂停仿真，同时报错。

实现方式

• 线上比较：在仿真时收集数据和在线比较并实时报告。
• 线下比较：在仿真时收集的数据记录在文件中，仿真结束后比较。

将checker添加到验证环境中，需要它分析DUT的边界激励，理解数据的输入，按照硬件功能预测输出的数据内容，这种预测发生在reference model中，有时也称为predictor。reference model会内置一些缓存，分别存放从DUT输入端观察的数据，以及经过功能转换的数据，同时也有其它缓存来存放从输出端采集到的数据。

checker分散搁置

• 各自检查对应模块的功能；
• checker之间的通信需要特殊连接；
• 报告信息较难统一；
• 对于各个checker的使能控制因其分散而变得复杂。

checker集群搁置

• 各自检查对应模块的功能；
• checker各自相邻，可以共享monitor的输入，减少复杂的连接关系；
• 可以按照统一的报告形式，写入到记录文件中，集中管理各个checker。

比较器结构实现建议：

• 对于复杂系统验证，倾向于集中管理stimulator和checker；
• monitor相对更加独立，只作为监测方将数据传给checker即可；
• monitor与checker一一对应， 通常进一步将它们封装在agent单元组件中，而checker则最终集群搁置在中心化的位置。