moon9999的博客

上一篇文章中，我们通过在环境中配置后门路径的方式来实现了寄存器的后门访问，但是在实际应用中，无论寄存器RTL文件、例化还是寄存器模型大概率都是工具生成的，比如在本专栏中实现的gen_reg.py脚本，那么在这个流程中如何接入backdoor后门路径配置呢？

在之前工作的基础上，补充关于关于寄存器后门访问的测试，以及如何在流程上进行后门路径生成方法（放在下一篇吧）。以及和两份官方资料。虚拟项目中的寄存器结构，不过该虚拟项目中的寄存器结构和本专栏中所设置的结构完全一致，因此仅供参考即可，仍就可以用该专栏中之前的结构与代码就行啦。

spt_agent utils已经完成了（虽然之后可能还会有微调），接下来完成配置通路cpu interface对应的utils。这个通路比较特殊，一是带反馈的接口，二是时序上非常的复杂，而且还是个异步接口。鉴于除非在芯片最外围的模块，我们平时极少面对这种接口，因此个人的建议是不要在这里的时序上花费太多的时间，“又不是不能用”，嗯。

完成utils组件的搭建之后，距离组织整体的验证环境还差啥呢？观察一下可以发现还需要：ral_model和RM，那么这一章我们来完成ral_model的组织。，本章所涉及的代码均已上传gitee/ral目录。

本篇文章完成ppu整体uvm环境搭建的指导，在进行整体环境搭建之前，请确认spt_utils、cpu_utils和ral_model均已经生成。之后所有的filelist均使用$PPU_ROOT以适配不同的下载目录。

寄存器专题其实已经完成的差不多了，今天这篇是因为有一个新的需求。当一个系统的启动配置项非常多时，如果通过低速的32bit（或其他位宽）apb总线进行配置，那么可能需要几十甚至上百拍的配置时间。假设apb总线时钟为200M，配置寄存器数量为50个，那么就是50ns * 50 = 2500ns = 2.5ms，对于芯片处理而言2.5ms的启动时间可以说是一个极大的时间消耗了。此外，如果以寄存器作为查找表等结构，apb总线配置的方式同样会掣肘整体的处理速度。因此需要寻找一种变通的方式。

本篇文章旨在讨论环境仿真中对于寄存器配置的随机。

本文以组织一个系统（或模块）寄存器为例，进行寄存器与ral生成相关的全流程展示。内容包括如下几个部分：寄存器文档组织描述文件与辅助RTL代码结构ralf/ral/rtl文件代码结构UVM RAL访问环境组织。

思来想去我还是感觉xml格式的寄存器描述信息太繁琐了（虽然不否认xml很强大），所以我还是决定以excel格式来组织寄存器，之后通过脚本来转成xml格式（其实直接转ralf格式也是可以的）。

终于在经历了众多流程后，终于到了激动人心的一刻——在uvm验证平台中连接ral_model！在之前研究验证平台时，uvm的ral_model例化就一直觉得特别的难懂尤其里面复杂的配置和mapping关系（显然，我现在也不太懂），因此这次在大神的帮助下完成了ral_model的例化连接和读写操作，让我觉得简直是神清气爽！

完成组件编写后，进行下组件的环境自测。

以上一篇文章为分界线，从这一篇博客开始进入ral_model在uvm环境中的集成环节。

在完成一版基于xml描述的寄存器模型生成后，我们来分析一下rtl代码的组成。

接上文，以此篇作为集成rtl和集成ral_model两个独立部分的分界线。因为验证环境集成ral_model的工作我刚刚把初版的demo完成，还没有系统的整理这部分内容，因此先用个脚本缓一缓。

基于前文的寄存器组织形式和xml文档，我们进行各层次的寄存器描述。

在上文中分析了生成代码中host_itf和sys_ral部分的代码，后面继续分析block和register的代码。

完成RTL的代码分析后，我们来搭建一个简单的环境进行下读写寄存器的测试。搭建的测试环境基本基于中使用的环境，对tb.f、cfg.mk和testbench做了修改，因此对整体搭建环境的过程就不再赘述。

ral_model是验证方法学中非常独立且重要的一个篇章。可以说在我维持不长的芯片验证生涯中对ral_model的使用达到了贼溜水平，甚至参考了各种资料组织了部门第一版uvm寄存器验证sequence。但是呢，我从来没有涉足过寄存器的组织与ral_model的生成这部分，这个系列就是为了补齐这部分的短板，距离芯片全栈工程师更进一步啊。当然这个系列还是基于我以往先入门再探究的习惯，先把东西跑出来看到结果确定理论是可行的，再去进行理论拓展和探究。

理论知识初步建立后，不妨直接实践出真知，来生成一个简单的寄存器demo吧。