一种包含IP或多级driver绑定ral模型的思路

  最近在搭建一个新项目的验证环境，需要把ral模型的例子引入进来，正常操作就是reg_vip+adaptor在env中做个连接就行了，这样直接操作reg_block，相应的读写行为也会在寄存器对应的总线上生效，但是这个项目中的特（s）殊（b）就特殊在寄存器的下发并不是由验证组件直接来驱动的而是经过如下阶段：

 

         DUT正常是由C类型总线（以下简称C总线）来进行驱动，C总线是一个很简单的4线协议，大概需要2周就可以开发完毕一个bfm，奈何我接手的时候已经没有给我时间开发验证vip了，所以需要沿用旧项目的寄存器配置方案，旧配置方案是：

1. 由s_vseq产生符合A协议的总线协议
2. B模块将A协议转换成C协议
3. C协议对应的模块严格来说是一个rtl模块，当我需要对DUT的X地址写入数据Y的时候，我需要
   1. 通过s_vseq下发一个写地址X到特定寄存器的操作
   2. 通过s_vseq下发一个写数据Y到特定寄存器的操作
   3. 通过s_vseq下发一个写数据的长度到特定寄存器
   4. 通过s_vseq下发一个send指令到特定寄存器

这样的话，s_vseq对DUT去写一个数据，至少要经过s协议进行4次寄存器配置，在旧的验证环境中这个write操作已经封装成task来实现了，包括single-wr/rd，连续-wr/rd

 

但是如此一来ral模型是没办法直接和C协议对应的agent来绑定的，于是有如下方案，兜个圈子来实现ral模型的嵌套实现

          

 

新加一个virtual agent，并且将ral模型与v-agent进行绑定，该trans包括addr、data、type，正常发送读写数据包，最终数据包会在virtual_driver中出现，但是driver中不用做任何总线驱动的事情，直接将trans送给env_cfg.req_fifo，req_fifo是在env_cfg中定义的一个缓存队列，这个队列在base_vseq中也可以被看到（因为env_cfg通过config_db已经set过去了）

在base_vseq中新增一个fork join_none的线程，通过子类的seq调用super.body()来保证持续运转，将收到的trans通过之前封装好的write函数发送出去，也就是说，每一个trans最终会对应4笔寄存器操作，无论读写，都需要在这4笔寄存器操作结束之后，再返回一个rsp_trans，通过req_fifo通道，driver拿到rsp之后，再进行item_done，如果是读报文，还要进行put_response操作，这样一来，ral模型就可以通过非验证代码的ip发送出去了，核心还是在于reg_adaptor到底和哪个agent去做绑定，再就是如果判断写操作什么时候算是真正完成了，因为virtual_driver发送写数据后，还会有4笔对应的操作，如果连续发写，C模块是不支持连续写的