fmt_pkg.sv 代码分析

fmt_pkg.sv 中的 fmt_driver

driver 分为 inititator 和 responder，之前的 chnl_driver 和 reg_driver 都是 initiator 发送数据或者指令, 而 formatter 的 driver 是一个接收数据的从端 slave，所以我们的 driver 类似要模仿一个 fifo 缓冲数据，而且 fifo 的位宽可大可小。

我们 fifo 接收来自 formatter 的数据，并把它按照我们 fifo 的位宽发送出去，实现缓冲，我们的 fifo 在接收数据时 , 只要按照 formatter的时序，控制 fmt_grant 和接收数据即可。

对于收到来自 formatter 的 req 请求，我们给出 grant=1 同意发送数据，而 formatter 的位宽，深度和我们的 fifo 不一致，当上大下小，我们的 grant 发送的就慢一些，可能要经过好几拍，当上小下大，我们的 grant 就发送的快一些，只有当上小下大时，才可以在 req 拉高之后的下一拍把 grant 拉高。这样可以在下一步继续实现对formatter 的功能验证。

其中， driver 中的 do_receive() 和 do_consume() 如下图所示：

do_consume() 的代码解析

do_consume() 也就是按照我们给 fifo 的带宽不断地往下流出数据

do_receive() 的代码解析

do_receive() 也就是按照formatter 的时序，不断（forever）的接收数据，当grant=1,代表我们同意接收来自formatter的数据，按照数据包的长度往fifo里放数据。

给 formatter 发送 grant = 1 的条件是 fifo 内部的余量大于来自formatter的数据 (我理解的也就是 fifo 的深度余量和来自formatter数据包的长度)

也就是（ this.fifo_bound - this.fifo.num() ） >= intf.fmt_length

提醒一下自己： fifo 是个 mailbox, 回顾mailbox的相关函数， fifo.new() 创建一个信箱实例，fifo.put() 往信箱里放数据, fifo.get()/fifo.peek() 从信箱里拿数据，get()/peek() 是阻塞的拿，拿不到会一直等着， fifo.try_put() fifo.try_get()/fifo.try_peek()都是非阻塞, 放不进去或者拿不到都返回0，

fifo.num() 返回信箱里的数据的数量。

do_config() 的代码解析

do_config 里面对 fifo 进行了 new() , 为什么还要在 driver 的构造函数里再进行一次 new？有必要吗？

答：引用这个博主写的很详细路科验证MCDF_svlab4笔记_Hardworking_IC_boy的博客-CSDN博客_路科验证

这个问题有个假设，就是do_config需要存在，也就是你需要一开始就进行配置。但是这个假设并不是一直成立的。有时候是没有do_config的，比如有一些组件是作为slave，他不可能每次接收master的数据都事先配置。
这种情况下，你就没有办法通过req_mb得到req,也就不知道req.fifo，没法得到fifo_bound，因此也就无法根据fifo_bound的大小来对fifo进行new，那么fmt_pkg也就不工作了，没法模拟下行。
事先例化fifo，其实就相当于一个初始值，让fmt_pkg在没有配置的时候也能工作。
此处fifo_bound设置为4096，以及data_consum_peroid设置为1，只是为了让FIFO的空间比较大，消化数据比较快，那么当fmt发送req时，fmt_pkg模拟的下行能够更快地让grant拉高。
也就是说，这里将fifo_bound设置成4096并不是一个硬性的要求，也可以是其他的数值，比如64、256等等，目的都是为了更快地让grant拉高。
不探究fifo_bound和data_consum_peroid的影响时，就选一个最好的值就行了。等需要探究了，再特地改变他们的值。（比如下行从端低带宽测试就是探究低带宽带来的影响）

MCDF 实验4 (1)相关推荐

MCDF实验4（4）
目录引言:接着上篇的MCDF实验4(3),解释一下添加的检查 1)通道 en=0 时的检查 2)arbiter 的仲裁功能的检查在tb.sv 中连接信号引言:接着上篇的MCDF实验4(3),解 ...
MCDF实验——Lab4
在之前的Lab3中,通过一个初具规模的MCDT的验证环境,学习到: 验证环境按照隔离的观念,应分为硬件DUT,软件验证环境,和处于信号媒介的接口interface. 对于软件验证环境,需要经历建立阶段 ...
MCDF实验_lab0（0）
目录一.MCDF功能描述[^1] MCDF结构 slave端口时序 formater端口时序寄存器时序二.代码分析时间单位信号例化产生时钟产生复位发送激励三.Questasim的M ...
MCDF实验_lab1（1）
目录一.问题二.实验要求三.代码分析时间单位信号例化产生时钟产生复位发送激励模块产生数据实例化slave模块发送激励三.Questasim的Makefile[^2] 四.波形 ...
MCDF实验——Lab5
Lab5主要完成如何定义覆盖率,如何从验证计划到测试用例的实现,最后再到覆盖率的量化.验证量化分为代码覆盖率和功能覆盖率. 一.编译在编译过程中,需要对于设计相关的文件设置额外的覆盖率编译选项. 只 ...
MCDF实验_lab4（4）
目录一.框架图二.代码分析 reg_chnl reg_trans,传输的数据包 reg_generator reg_driver reg_monitor reg_agent fmt_pkg fmt ...
路科验证MCDF_svlab3笔记
实验3和实验2的区别(以实验2的tb4和实验3的chnl_pkg和tb为例) 1. chnl_trans变复杂了. 1.1 填充更多的数据. lab2的是实验代码很简单,也没有随机化,只是通过gene ...
IC验证学习笔记（MCDF）实验0-MCDT
实验0:目标是写出MCDT的程序,也就是slave+fifo+arbiter的部分最终目标是实现MCDF:MCDF为多通道数据整形器(multi-channel data formatter),它可 ...
电力电子转战数字IC——路科MCDF全览（持续更新）
经过两次面试后,对MCDF做一次全面的深入总结. 目前进度:硬件部分的node,fifo,寄存器,formatter,MCDF顶层,APB接口,TB接口软件部分的chnl_pkg,fmt_pkg,a ...

MCDF 实验4 (1)