如何让ALG、FPGA、EMU、SOC、SubIp实现驱动复用

     摘要

         在芯片验证场景中，我们通常涉及到算法team、fpga测试team、EMU team、SOC验证和Subip验证如何对芯片的完备性测试的探讨。由于各个team都是相互独立的，很多flow都是独立开发出来，对于交互的文件也是五花八门，这些文件各team协助起来很不方便，如何打通各个team之间的快速协助以及保证各team提供的文件彼此能快速复用起来成为了一个需要解决的问题。

       本文以多媒体isp/vpu为例，介绍一种flow： auto_gen_reg_cfg。该flow可以不受验证平台和上下级复用的束缚可以快速实现alg、fpga、emu、subip和soc验证解耦且达到并行验证目的，驱动可以相互复用。

     算法team是一般是独立的部门，往往在芯片前端走在最前面，所以相关的flow也是自己独立的。一般算法的flow都是提供alg_cfg文件(里面包含各个算法模块C参数配置)、图像源和算法打包的可执行文件(xxx.exe)就可以吐出RefCmodule的输出文件。

     Fpga team往往可以通过python script产生丰富的alg_cfg文件，通过编写c结构体来将硬件的寄存器和算法的C参数进行一 一映射，当寄存器变动比较大的时候又是需要重新做映射。       

     Emu team往往是覆盖一些大的分辨率，需要的配置往往需要soc/subip dv team来提供。

      DV team一般在sv中通过随机约束register的random value 再通过regmodule配置给rtl，同时在产生一份alg cfg给RefCmodule的可执行文件生成exp data。如果现在fpga出现跑出来一个错误，提供了一个alg_cfg文件和图像源需要验证快速复现问题，你需要如何操作呢？

        soc验证一般需要集成subip的验证平台和驱动，这两个耦合性太强了需要确保subip的tb没有问题才能工作，每一次subip改动必然会拖累soc的验证，解耦且能并行验证才是重中之重。

    AUTO_GEN_REG_FLOW:

  ​​​

       在图中我们可以将算法的alg_cfg作为源端的文件，这样在fpga、emu、alg、SubIp、Soc上如果需要相互复现问题只需要提供一份图像源和alg的配置文件。这样彼此之间交付源就可以确定是唯一的。

       唯一的源有了但是如何让alg_cfg文件在各个team之间能够简单使用起来,这边我们就需要借助寄存器的excel文件了，设计交付的文件中有一个excel用来描述模块的寄存器的相关行为，例如下表：

       注意表中有一列是Cmodel_key，这是将alg_cfg文件中算法C的配置参数和硬件的寄存器的field进行了映射。但是我们在REGB中发现Cmodel_key是空着的，这是因为在isp/vpu中寄存器也包含了响应的控制信号、中断、地址、模式等非算法模块有的配置，对于这些信号可以通过脚本进行筛选出来生成一个hw_cfg文件，用来进行专属的硬件配置cfg。

         通过脚本我们可以将alg.cfg + hw.cfg + register exlcel文件作为script的输入，可以产生寄存器配置。       

   通过上述flow我们可以生成寄存器配置信息，如何验证正确性呢？

   在DV侧我们可以通过编写sequence来实现，在vsequence中set  regmodule和生成的reg_cfg.txt到mm_auto_gen_reg_flow_base_reg_seq中，在check_auto_genreg_flow_cfg_seq中进行配置驱动。

    FPGA team可以通过excel、alg_cfg、hw_cfg进行配置寄存器映射成结构体进行驱动，同时fpga也可以运行生成的reg.txt文件进行驱动配置。

    对于EMU 来说生成的reg.txt文件可以直接进行驱动。

    基于该flow我们可以实现各team之间进行配置交叉验证，数据源头可以是同一源，生成的寄存器配置文件可以直接在FPGA、EMU、SOC、SubIp之间进行流转和复现错误问题。 在SOC层和EMU层可以自己产生测试激励，不在依赖于subip提供验证平台和配置，这样验证过程中subip、SOC、EMU可以并行验证，大大提高收敛时间。

    在后面的章节中我们会重点介绍该flow是如何开发，以及通过json进行文件库管理提高flow的复用性。