芯片设计
一段规格，Micius 写出 RTL、跑通自检，再出电路图
聊聊你的设计流程 
- 7/7 通过
- 4 位计数器的一次运行；7 项自检由 Micius 按规格编写
- 一次对话
- 从规格到 RTL、仿真和电路图；通常要几个人接力
- 同一份 RTL
- 电路图由通过验证的那份代码生成，工具输出留在对话里
从一段规格到通过测试的 RTL，通常要几个人接力，每交接一次就丢一点上下文。这一次，数字设计工程师只写下规格：写代码、跑检查、读报错、出电路图，都由 Micius 在一次对话里做完，证据和电路图一起交回。
先说一个最小的例子：带高电平异步复位和使能的 4 位计数器。设计本身十几行，自检用的测试平台却能写到上百行。真实模块大得多，链路一样：写规格、写 RTL（硬件描述代码）、编译仿真、改错，最后出电路图和波形，拿去评审。
这条链平时要几个人接力。每交接一次，上下文就掉一点：写测试的人要重新揣摩设计意图，画图的人手里未必是最终那版代码。验证通过的代码和评审看的图，可能悄悄对不上。
方案
工程师写下规格，Micius 写代码、跑工具
起点是一段规格。工程师写清顶层模块和端口、复位和使能怎么动作，以及要测的四种行为：异步复位、使能关闭时保持、连续计数、从 15 回到 0。交付要求也写进去了：失败就按工具的诊断修好再验；通过之后用同一份最终代码出电路图；交回完整的 RTL、测试平台和真实结果；没通过就照实说没通过。
Micius 先讲计划，再写 RTL 和自检测试平台，然后自己调 EDA 工具：语法与语义检查、lint、编译、仿真。调哪个工具由它判断，每条命令和工具返回都原样留在对话里，对话本身就是运行记录。
检查都过了，第一次编译却卡在测试平台的一个错误上：测试平台给设计的输出端口赋了值。输出只能读、不能写，这是写测试平台时常见的错误。这类错误，它可以照着报错直接改掉，再重新编译。
纠错
仿真跑完、自检不过，先分清错在设计还是测试
更难的是仿真跑完、自检却报失败。第一个问题是：错在设计，还是错在测试平台？两边时序差一个时钟周期，一整组检查都会报错。
这次的检查项能看出规律：复位和保持两项通过，三项计数类检查都晚了一个时钟周期。Micius 判断测试平台在时钟沿上取样，计数器还没更新；复位后第一拍的预期值也写错了。它的处置是改成在时钟沿之后取样，只改测试平台，RTL 一行没动。重跑仍差一个周期，它把问题收窄到复位释放后第一个有效时钟沿的预期值，再改、再跑。每次诊断和改动都写在对话里，工程师可以逐条看它为什么这么改。
流程示意失败的都是计数类检查，都晚一拍：问题在测试平台。
成果
同一份 RTL，7 项自检逐条通过
另一次运行用的是同一份 RTL，一字未改，不是上面那次调试。那一次 lint 零错误、零警告，7 项自检逐条通过，覆盖了规格里的四种行为。之后它才综合代码、生成电路图，并核对图来自通过检查的那份 RTL；综合出来的是带异步复位的触发器，和规格一致。
工程师拿到的报告里有完成情况、通过检查的 RTL 和测试平台、自检日志，可以对照着看。报告也写明边界：仿真结果是功能验证的参考，不等于签核，关键结论由工程师复核；这份代码用不用，工程师定。
电路图
在图上拨一次复位，看计数归零
电路图从通过检查的代码直接生成，不用再找人另画。工程师能在图上拨时钟、复位和使能，对着波形看计数怎么变。Micius 附了操作顺序：先拉高复位，确认计数为 0；再松开复位、打开使能，打几个时钟，计数往上走；关掉使能，计数停住；数到 15 再打一拍，回到 0。最能说明问题的一步，是先让计数数到非零值，再在两个时钟沿之间拉高复位，计数立刻清零，规格里写的“异步”在波形上就是这个样子。
流程示意在两个时钟沿之间拉高复位，计数立刻归零。
电路图用来看懂结构、动手试。功能对不对，仍以自检结果为准，Micius 交付时也写明了这一点。
这次的设计很小，多模块、总线协议、覆盖率收敛这些都没涉及。它还列了几个可以接着做的方向，让工程师自己挑：把位宽做成参数、加一个计数相等时的输出，或者给这个计数器搭一套 UVM 验证环境。
这套做法也适用于
-
修复已有 RTL
把报错的旧代码交给它：先按原样跑一遍检查，定位问题、修改，再跑一遍，确认通过后交回完整代码。
-
综合并评估规模
模块写好后先检查、再综合，说明用了多少逻辑单元，以及还有哪些风险没有覆盖到。
-
给已有模块补测试
按规格列出要覆盖的场景，写成测试平台并跑仿真；失败时先分清是设计的问题还是测试的问题。
-
说清环境能做什么
开始新任务前，先检查当前环境能做哪些验证、哪些做不了，并说明原因，再决定怎么分工。
