仍旧是在交付过程中的总结输出，本篇旨在讨论下在系统和模块中设置可维可测寄存器的方案与经验。
为什么
为什么要写可维可测寄存器呢？先扯一扯虎皮，随着电子技术的飞速发展，芯片设计已成为现代电子系统的核心。在这一领域，芯片的复杂性和集成度不断提高，对设计者提出了更高的要求。其中，可维护性和可测试性是确保芯片长期稳定运行和快速定位问题的关键因素。芯片设计不仅仅是电路的布局和逻辑的实现，它还涉及到系统的整体性能、可靠性和成本效益。一个优秀的设计能够在保证功能与性能的同时，降低维护成本和提高系统的可靠性。而状态寄存器作为芯片设计中的关键组件，它记录了系统或模块的实时状态信息。这些信息对于故障诊断、性能监控和系统恢复至关重要。一个设计良好的状态寄存器系统可以显著提高系统的可维护性和可测试性。
扯完了回到咱们的正题可维可测寄存器设计上来。对于一个系统而言，这类寄存器出现目的是什么呢？无非就是反馈系统内部的状态，辅助软件或驱动等使用者计算时间和效率等各项指标，以及重要的在出现问题时能够定位问题所在以及原因。毕竟不管是芯片已经流片回来了还是在FPGA上进行原型测试，看波形都是过于痴人说梦了，这个时候定位问题靠啥呢？只能靠我们聪明的大脑以及不睡觉通宵想，还有就是各种可维可测寄存器了。
做什么
根据上面的讨论，也就能够明确可维可测寄存器（这个名字听起来像法国人呢）的需求从哪里来了：
1.架构师以及设计者对系统内部状态进行记录的天然动力；
2.软件驱动等使用者对问题定位以及功能性能检测而提出的设计需求；
3.设计者出于甩锅目的避免出问题时自己背锅的考虑而添加的保护性状态记录；
明确需求来源之后再来讨论下一个问题：什么时候来规划可维可测寄存器？到目前为止个人一共经历了三种情况：
1.所有寄存器包括状态寄存器均在项目初期规划完成，开发过程中按部就班将对应的信号接入寄存器单元，后期基本没有改动顺利交付；
2.在feature开发阶段并未对所有可维可测状态进行规划，在代码开发过程中设计人员识别需要哪些信号与状态需要体现在状态寄存器中，则伴随代码交付进程进行同步开发；
3.在EDA测试、FPGA测试、上板驱动测试等各个测试环节，根据测试反馈以及新的检测需求在原有feature上进行状态寄存器的补充；
从个人角度和体验而言，我觉得可维可测寄存器越早规划越在项目开始初期明确，在之后的开发中工作量以及反复迭代修改的代价是越小的。比如一个状态开始并没有规划在寄存器中记录，后面代码开发时发现需要接出去，那么就需要①从信号所在的层级一层层的向上增加接口 ②寄存器描述文档中增加寄存器 ③重新生成寄存器模型和RTL ④完成信号的互连修改。这么一套下来其实工作量不说多大但是还是有的，因此必然是越早规划越好。但实际情况大家也都能理解，谁又能一上来就能想的面面俱到呢，尤其很多信号是在RTL实现的过程中才出现或者在软件测试定位问题时才发现需要。刚刚所说的第一个项目之所以能做到项目初期完成全部可维可测寄存器规划，也是因为其本身是继承性项目有前代导入和商用的经验了。
怎样做
OK铺的差不多了，最后咱们来分门别类的聊一聊哪些信号应该或者可以做到可维可测状态寄存器中。先声明一下以下的内容都是继续一个模块或者系统级视角来看的，毕竟也没交付过整芯片。
对外接口信号
对外的接口信号是一定要放在状态寄存器里的，典型的比如握手信号valid/ready、使能与反压信号enable/xoff、选通信号sel等。这些信号可以在出现挂死等问题时排查问题出现在哪里，比如一个任务始终无法完成可以排查系统对外的数据通路接口，如果发现系统对外的awvalid/wvalid记录寄存器为1而awready/wready记录为0，则可以明确此时SOC对该系统进行了反压导致数据无法写出。
内部模块间接口信号
模块间的接口记录目的和上面差不多，真的甩不出去锅了那就必须开始定位，定位顾名思义就是找到问题出在哪是什么问题，因此内部模块间的接口状态记录就能够派上用场了。
计数器和内部指针
各种计数器根据其重要程度均可以加入可维可测寄存器中，很多计数器会在任务、指令等维度结束时清零，其他的也大多是有预期值的，因此在常规维护以及错误定位时，计数器信息大多能派上用场。而且在我们平时仿真环境的搭建时，end_of_check部分同样也会对各种计数器进行结束检查，道理都是一样的。
内部的指针等各类ptr信号也是类似，在任务结束或者发生错误时大多有合理的状态可以预期。比如说读写缓存模块，如果一读寄存器发现读指针都跑到写指针前面去了，那不挂死才是真的难了。
busy/emtpy状态
系统以及内部模块的busy或者empty状态，以及区分维度比如通道、任务、指令、读写的busy/empty状态是非常能够自证清白的，放到寄存器里绝对不吃亏。而且这类信号也不难做，一般就是把内部的enable/valid信号都或在一起再加入ptr/depth/cnt等辅助判定就可以。
FIFO空满
fifo接口、空满、半空半满和深度记录（如果有的话）等信息都是适合上报寄存器的，作为结构里的数据缓冲中心，能够如实的反馈上下游的很多信息。
总线相关记录
典型的比如当前的ostd值、数据读写响应最大延迟（ar-r、aw-b的时间）都可以记录在案，当然了像总线超时那些本身一定要上报的就不多提了。此外还可以记录很多与总线相关的信息，比如一段时间内握手拍数和反压拍数来计算有效的带宽甩锅性能问题，记录不同id的响应时间定位NOC问题等等。
任务与能效记录
任务或者指令的起始时间、完成时间、总耗时以及指令的耗时与切换时间用以检测任务执行情况。指令内运算单元的工作时间、数据读写时间来计算硬件效率。或者定向的记录某些任务的耗时、事件的发生频率（次数/观测事件）、流量与credit功能等都是很常见的，这部分就根据架构师和软件同事的意见规划即可，本质上可以视为RTL功能的一部分。
系列文章入口——
| 【芯片验证】sva_assertion: 15道助力飞升的断言练习 |
| 【芯片验证】可能是RTL定向验证的巅峰之作 |
| 【芯片验证】RTL仿真中X态行为的传播 —— 从xprop说起 |
| 【芯片验证】年轻人的第一个systemVerilog验证环境全工程与解析 |
| 【芯片设计】verilog中有符号数和无符号数的本质探究 |
| 【芯片设计】论RTL中always语法的消失术 |
| 【芯片设计】代码即注释，注释即代码 |
| 【芯片设计】700行代码的risc处理器你确实不能要求太多了 |
| 入职芯片开发部门后，每天摸鱼之外的时间我们要做些什么呢 |
| 如何计算系统的outstanding 和 burst length？ |
| 芯片搬砖日常·逼死强迫症的关键词不对齐事件 |
| 熟人社会里，一群没有社会价值的局外人 |
