moon9999的博客

上一篇文章我们已经完成了测试点的相关指导，在工程目录下看到一份推荐的测试点分解文档。当然这只是一种参考，大家可以按照自己的理解进行测试点分解，并在实践中不断完善和改进测试点分解的能力。完成测试点分解后，下一步就是将测试点转化为覆盖率文件。一般而言，覆盖率的收集和测试点是呈对应关系的，当然这个东西并不绝对。在测试点文档中进行反标的一般称之为plan coverage，整体的称之为function coverage。

当然只不过是参考，个人不建议在寄存器测试这个环节投入太多的经历，也没有必要非在环境中讲寄存器模型以seq方式呈现，只要用起来方便就是最合适的。如果之后在实际的项目中寄存器模型时通过seq的方式集成到环境中的（比如我现在负责的项目，验证环境就是如此），那么转换过来也是没有什么难度的，这点大可放心。此外，在组织更多随机用例的过程中可以练习多种不同约束的transaction以不同的比例关系通过同一个seq/sqr uvm_do的操作。好了，具体的用例大家可以参考我的代码，尽量以自己的思路来进行扩充。

这里的send_num是我自己的一个写case的习惯，通常我会把发激励的数量设置为传参这样在调试时如果少量激励能pass那么就可以在不重新编译的情况下快速测试更多的激励，主打一个节约时间。sanity_case_inst从inst_transaction继承，自然方法和约束都会继承过来，在此基础上写一下sanity_case_seq_cons就可以了。几乎所有的case都是基于transaction的随机进行的，而sanity_case自然就是测试最简单的随机情况。

大家在环境里看到ral_model、adapter、apb_agent相关的组件就按照给出的环境中代码实现复刻就好了。除非是在社招，一般校招进行验证岗面试大家普遍不会把ral_model问太深，太深了也都不会了。

分析以下哈，各个agent我都放在env里了，其实我觉得考虑到向上集成的情况，放在base_test里或许更合适一些。base_test里平级放着三个东西：env、ral_model和axi_ram_model，axi_ram_model上一篇文章已经说明，ral_model的例化下一篇中会简要说明下不做重点。上一篇里解决了最难搞的axi_ram_model，接下来呢就会简单又常规一些了，比如这一篇要说的env和base_test的搭建。

这里面还有一个问题，可以看到我用了fork-join_none＋#0的线程组织方式，这是因为我不希望上一个rdata的发送进程阻碍下一个rdata的寻址取数过程（简单来说，希望随机延时体现在总线上，而不是体现在取数上）也不要阻碍下一个axi_ar的处理，如果不用fork-join_none线程那么上一个rdata在总线上接收完这里才会继续组织下一个axi_r transaction，这是要避免的。axi_ram_model的顶层就完成了，鉴于它和mvu_env平级例化，所以其类型也是uvm_env。

就我自己而言，因为有gen_uvm_agent和gen_uvm_tb两个工具在手，同时也习惯于先打好地基看到波形和组件行为，清理组件存在的问题之后再向上组织，所以优先的选择必然是自下而上的搭建方式。“在芯片验证领域，"agent"通常指的是一个特定的验证组件，它模拟了某一类外部设备或内部组件的行为，用以对设计中的接口或功能进行测试。在芯片验证中，根据不同的验证环境和需求，可能还会有其他类型的agents，比如-scoreboard，它负责比较监视器捕获的数据和预期数据，以确保设计的正确性。

同样的，环境中的ram_model也暂时不需要投入太多的经历，把主要的力量放在base_test和env内rm的搭建上才会事半功倍，而后在学习了virtual seq之后再来独立的写一下ram_model。而关于验证方案文档，大部分时候都不是太重要，有结构图和组件说明已经足以。相比而言，测试点文档才是重中之重，下一篇我们就从测试点文档介入。

可以看到目前提供的RTL代码在1G时钟下的最差路径是-270ps，如果是正常交付里最差路径是-100ps以内都是可以接受的，后端可以搞定，当然了Total Negative Slack必然不能太大。那么对于这个虚拟项目呢，1GHz要求-100ps以内确实比较强人所难，所以可以尝试在600MHz或者800MHz时钟下收敛时序。看起来这个面积是真的不大，本身mvu就是一个不算很复杂的模块。而对于不从事芯片设计的同学，则不需要在这件事上花费时间了，直接进入验证流程即可。

最后是io.sdc的设置，mvu的接口实际上是比较简单的所以直接通过get_ports的方式把接口区分输入和输出拉出来就可以，注意要把时钟去除掉，一般我们也会把复位单独处理不过因为mvu面积不大一拍内复位信号抵达所有的寄存器也没有什么压力，所以保留在里面也没关系。这个文件中我们定义了后面要使用的众多变量，注意clk_period决定了时钟频率此处设置为1单位默认为ns，因此默认的综合频率是1Ghz，并且将uncertainty设置为1/200，latency设置为1/5，这里可以根据实际情况设置经验值。

和上个虚拟项目的lint清理环节一样，关于spyglass的lint清理功能与流程还是大家通过各种资料去学习下就好啦。和之前不同的事，这次的虚拟项目里我把流程封装为Makefile，更加的贴近了实际项目交付流程。而后就可以根据提示进行lint的清理工作了。

那么向验证侧交付代码，通常编译通过之后就可以视为可交付，可启动环境集成与验证工作。这一篇我们视为向验证侧交付的记录，完整这一篇后如果准备走验证方向，就可以直接转入验证流程了。向验证侧交付，交付的是什么呢？同样的，代码我们也已经完成了，那么剩下的就是组织filelist给验证。脚本是对vcs命令行的组织，可以帮我们清理比较明显的编译问题和连线问题，在清理了所有的error和warning后，对验证同学交付的第一版代码就准备好了。完成模块的初步编码后，我们就面临着向验证和后端交付代码的事情了。

我自己规划和集成顶层一般有一个习惯，就是在top层下面封装core层和其他模块，比如mvu的top层下例化了mvu_reg和mvu_core两个模块，而mvu_core下面是前三篇文章中所阐明的模块：inst_buffer、read_path和write_path。当然了，集成工具还有很多这个只是我个人使用比较熟练的罢了。2.区分时钟域和复位域，保证core层是独立的时钟复位不需要糅杂太多的其他的考虑，比如本设计中，如果加入了配置寄存器快速复位，那么mvu_reg和mvu_core的复位域就必然不同了；

那么rece_xxxx_buffer和send_xxxx_buffer这两组buffer怎么用呢，大的规则就是，达到发送标准的数据就放到send_buffer，没达到的就暂存在rece_buffer等下一笔数据过来。第一笔返回的数据中有10byte有效，根据地址偏移shift后发现没有满足发送的要求（写效率最高，指令内的写出数据是来连续的，即只有一条指令的第一笔写和最后一笔写的前后可以出现strb为0的情况），所以要等待下一笔数据到来。3.first_buffer：标记这笔数据是否为一个指令的第一笔数据；

本工程为IC虚拟项目工程，预期完成时间为3~4周，规划如下。

而在计算得到一个指令能拆多少个transfer后，再根据burst_len（即一个transaction中可以包含多少个transfer），就可以把指令一笔一笔的拆分为transaction了，每个transaction就是一笔ar请求。在学习完成AXI4协议后，再继续进行read_path模块的搭建。过多的细节请参考代码吧！要维护的三个核心寄存器就是如上所示这三个了，需要注意的是因为burst_len和outstanding是可以配置的，因此每一笔ar请求发出去之后地址如何跳转是需要分别考虑的。

同样的，写完成后进行一样的操作。于是，在代码中维护了四个指针：inst_in_ptr表示指令待写入的位置，inst_cmt_ptr表示待提交指令的位置，rd_done_ptr表示已经读完成位置，wr_done_ptr表示已经写完成。结构的核心部分是一个8项深的cmt_buffer，用于接收、存放和提交指令，同时buffer中还记录着本条指令的状态：读完成、写完成。一般指令的cmt_queue类型结构必然是支持乱序的，不过因为项目里指令本身就是顺序执行的，所以采用顺序更新的结构就可以了。

那可就多了，先依据软件的需求把他们需要上报的状态都加上，然后再把内部关键的状态机、计数器、状态信号都加上，再把busy/empty、时间戳啥的记上。最后别忘了，把能够“甩锅”的信号都记上，比如对外接口的valid/ready状态、ostd状态等等。兜兜转转又回到了寄存器，但是没有办法，虚拟项目肯定要贴近真实真实项目的，而一个真实项目里不管是做模块设计还是SOC设计，寄存器总是难以避免的。在上层我已经帮你包好啦，直接在顶层例化这个模块就好，所有的结构都已经体现在接口上了。寄存器文档在rtl的reg目录下。

后续在其他公司，对DS的要求也是测次不齐。DS - Design Specification（设计规格）："DS" 表示设计规格，它是在架构规格之后，进一步细化和准备进入实际设计和开发的文档。判断DS文档是否合格，有一个最简单的标准，就是进行项目和模块交接时，后来者能够通过DS文档看懂整个模块80%以上的代码。于我个人而言，DS文档还是应该尽量丰富的，因为我是一个不爱写代码注释的人（我那些注释基本都是用来生成代码的）。通俗来说，DS这东西就是写给自己看的，是在编码前进行思路梳理和电路描述的文档。

FS - Functional Specification（功能规格）："FS" 表示功能规格，它是芯片设计和开发的早期阶段的一个文档。Feature List：功能列表，即为功能进行编号，罗列模块的各项功能。罗列的粒度自己把控即可，这部分通常也作为测试点的参考。Introduction：介绍模块功能以及模块的主要特性，子章节里可以着重介绍几个主要的功能点和实现方案或是实现目的（为了支撑哪些更上层的功能）；Block Diagram：结构框图以及对框图的描述，通常还会有对主要通路或主要子模块的功能说明；

mvu根据指令进行数据的搬运，将所有的数据搬运完成后向idu进行指令提交。

这些全部是手撕代码，当然会借助verilog-mode/auto_testbench/gen_uvm_agent/gen_uvm_tb等诸多工具辅助开发，不需要担心。文档目录在“MVU芯片前端设计验证虚拟项目”中，截至本篇文章时，包含了MVU_FS.md/project_req.md和mvu_vp_list.xlsx三个文件。由于目前只完成了代码编写和功能验证，目录内容暂不全面，后面会逐步补全。

我使用的是芯王国的虚拟机，大家可以关注其公众号进行虚拟机的获取。然后source一下就可以了。基本的工程目录使用方式就是这些。

我个人在工作中svn和git都有使用过，感觉上来讲，芯片项目开发使用git有些“不值当”，因为很少有多人同时开发同一个文件的场景，这使得分支管理不是非常的重要。而一旦分支较多时（尤其设计分支和验证分支），对于bug修改和提交同步也带来了一些困扰，所以至今我还是喜欢基于svn的芯片项目管理。对于大型项目或需要分布式开发的情况，Git更为强大，因为它提供了更灵活的分支管理和更高效的版本控制机制。分支和标签： 分支和标签在SVN中存在，但相对来说较为复杂，并且在操作时会对整个目录进行复制。

感觉第一个项目其实设计的难度不太大（当然我写出来的bug也不少哈），验证环境搭建也比较简单，整个项目更加侧重于熟悉流程和设计验证的入门。而且包传输协议更多应用在网络芯片架构中，和现在比较火的处理器方向距离比较远。所以呢第二个虚拟项目就显得挺有必要了。