moon9999的博客

MOSFET晶体管有两种类型：NMOS和PMOS。它们被称为有源器件，因为它们可以转换和放大电压和电流。

VLSI芯片是在半导体材料上制造的，这种材料的导电性介于绝缘体和导体之间。

在芯片开发领域中，脚本指的是用于自动化执行特定任务或流程的程序。这些脚本可以是各种编程语言的程序，包括但不限于Tcl、Perl、Shell、Python等。在芯片设计过程中，脚本被广泛用于各种任务，例如创建和编辑设计文件、执行仿真测试、生成报告等。使用脚本可以大大提高设计效率，减少重复性工作，并确保整个设计流程的一致性。

脚本思维本质上是对重复人力操作的汇总与提炼，也就是说如果一件事情可以通过人不需要大量思考的按部就班操作能够完成，那么理论上脚本就可以进行替代。那么什么时候需要写脚本呢？这个问题就有点类似于在写代码时，我们什么时候要封一个函数、一个宏定义呢？

前言小时候记得excel里有一个神秘的赛车游戏，发现excel原来并不简单啊；之前我哥跟我讲excel可能是最牛逼的编程软件，但是当时我没信，现在我有点信了；工作后发现很多代码原来并不需要写，通过excel、xml直接生成还是爽爽的；最好的是，自带的编译器自动补全自动大小写转换自动联想比平时用的IDE舒服多了；所以说啊，学一学VBA还是挺有意思的，你也不知道啥时候就用得上；作为我写的第一个excel vba demo，必须好好记录下。目标通过excel添加信号，并生成Veri

这一节呢主要是检查一下Linux和win环境是不是能正常的支持咱们的脚本学习，所以来答应各种语言的hello world!，毕竟打印了就是学会了٩(๑❛ᴗ❛๑)۶顺便从最基础的细节咱们一点一点来。

这一章仍然是一个简单的脚本练习，用来熟悉匹配替换与文件流。

大大小小的脚本我们写了几个了，在上一篇我们借助bashrc简单了解了bash语言的一些语法和组织规则。这一篇呢我们还是回到shell简单看下三个常用命令，毕竟脚本也可以视为复杂的命令尤其shell脚本其实就可以理解为命令的集合。grep/sed/awk被称为linux三剑客，具有强大的文本处理能力，使用得当的情况下可以获得比写脚本更高效的体验。这也正引出我的另外一个思考：不要遇到事就想着写脚本，先看看原生的命令是不是已经给你搞定了。

本文仍旧以培养脚本使用的思维和常见操作为主，不过多的进行脚本编码说明。

完成芯片的入门虚拟项目专栏之后，决定开始更新更适合IC宝宝的脚本练习专栏ψ(*｀ー´)ψ。专栏会涉及到perl、python、shell、tcl、makefile、awk、vba、html、css等语言，当然并不会面面俱到，仍然以入门和示例讲解为主。内容上会综合很多之前我已经在博客上完成的脚本，对开发和代码进行进一步的讲解，因此如果已经比较了解脚本语言和操作的，不建议订阅该专栏否则会失望的。后续如果有修改和调整，会及时在本页面更新。

一旦你在简历中写上了“熟悉xxx脚本语言”，那么面试官就不可避免的会问你脚本相关的知识点。那么在众多知识点里，评选出来哪个是最常考的呢？个人的经历是正则表达式。

前言Makefile有一个经典教程，相信大部分人认识和学习Makefile都是通过这篇文章入手的：跟我一起写 Makefile —— 陈皓不过之前和朋友聊，觉得这篇文章虽然接近完美但是篇幅还是有些长，导致我们很难静下心来攻克，同时这篇教程以c语言编译环境为基础讲解，实际上比硅农常用的编译环境还是要复杂些的；综上所述就是，我们用不了这么多，那么不如做一个极简版硅农专用的Makefile教程，本文内除vcs相关的内容外，基本所有信息均可以在上文中查阅（因此有引用部分就不在单独标注），属于n手资料

TCL（Tool Command Language）是一种简单但功能强大的脚本语言，它经常用于自动化任务、测试和快速原型开发。你看这个名字就能知道，这个语言最主要的作用就是用来操作工具，尤其我们常用的EDA比如vcs、verdi、dc、pt等。所以这篇文章我们就先熟悉下tcl的语法，然后再看看tcl对eda工具的使用好啦。

这是一个非常简单的perl脚本示例，展示一下perl语言“极简”的编码习惯。perl是我脚本入门的语言，一度也是最擅长的，但是因为python的强势现在我基本不写perl了。上一个大的perl脚本是用来做代码生成的，我至今记忆尤深写了3000多行各种循环正则套用，一旦debug间隔时间超过1周我就根本看不懂这脚本了。可见perl的可读性确实吧，真的不高，即使他写起来确实爽。

shell语言在芯片前端的工作中有两个主要的作用，一是流程自动化脚本，二是工作站环境的配置。为什么shell用于流程自动化相较于perl和python我感觉最舒服呢，个人理解是shell在linux中是真实的线程不像python即使用os.system()这种操作也是创建的虚拟线程，即使里面cd /path但是实际上是没有cd过去的。而shell不同，你在里面写cd /path那是真的会跳转回去的。

当然只不过是参考，个人不建议在寄存器测试这个环节投入太多的经历，也没有必要非在环境中讲寄存器模型以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后，对验证同学交付的第一版代码就准备好了。完成模块的初步编码后，我们就面临着向验证和后端交付代码的事情了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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