HSPICE、LTspice 没结果，不一定是电路错了。我会看许可证、日志、网表和分析类型。
analogexp/simulation-troubleshooting
做模拟电路实验时，我以前很容易有一种直觉：仿真失败了，所以电路参数有问题。
有时候确实是参数错了。不过更多时候，失败根本还没走到“电路是否合理”这一层。许可证没拿到、网表没跑起来、分析类型混在一起、报告里引用了错误附件，这些都会让结果看起来像电路坏了。
所以我现在做仿真报告时，会先问一个问题：工具链真的跑到能看结果的阶段了吗？
先读日志，别先改电阻
HSPICE 这种工具失败时，日志通常已经把原因写出来了。
如果输出文件很短，里面只有启动信息，最后停在许可证或 checkout 相关错误，那这不是电路问题。此时去改电阻、电容、偏置点，只是在用电路参数掩盖环境问题。
我后来会按这个顺序看：
- 确认仿真器能启动。
- 确认许可证环境变量已经设置。
- 确认日志里出现了有效许可证信息。
- 确认网表被正常解析。
- 最后才看波形、频响或工作点。
这几个步骤少一个，后面的电路分析都容易跑偏。
先分清是哪里坏了
我一般先把问题归到三类：
- 运行环境：许可证、路径、命令、版本、权限。
- 输入文件：网表、模型文件、分析语句、节点命名。
- 电路本身：参数、偏置、稳定性、指标不达标。
只有前两层确认通过后，才应该进入电路层。
这个步骤有点笨，但能少走很多弯路。比如一个 .lis 文件根本没有进入有效仿真阶段，你却根据它“没有结果”去调电路，最后只会把原本可用的设计越改越乱。
AC 和瞬态证据要分开
LTspice 做实验报告时，另一个常见问题是把不同分析类型混在一起。
AC 分析回答的是频率响应、增益、相位、带宽。瞬态分析回答的是时域响应、过冲、建立时间、波形形态。它们可以属于同一个电路，但报告证据最好分开生成。
我更喜欢这样组织：
ac netlist -> frequency response evidencetran netlist -> time-domain evidence我会尽量让一份网表只负责一种主要分析，输出文件和截图也按分析类型命名。这样写报告时不会混淆“这张图到底证明了什么”。
对于状态变量滤波器这类实验尤其重要。频响图用来说明中心频率、增益和选择性；瞬态图用来说明输入输出波形和动态行为。两类证据混在一起，读者会很难判断你的结论来自哪里。
报告附件要和实际文件同步
报告生产还有一个容易被忽略的细节：源码附录和真实仿真文件要一致。
如果报告里写的是某个网表名，但附件实际放的是另一个版本，后面再查时就很难说清结果是从哪个文件来的。尤其是你为了区分 AC 和瞬态，把文件拆成多个版本后，附录必须同步更新。
我会检查三件事：
- 报告正文引用的文件名是否存在。
- 附录里的说明是否对应实际分析类型。
- 每张图能否追溯到对应网表或原理图。
我吃过这种亏：图看着没问题，回头却找不到对应的网表。
调参数要留下过程
当工具链确认没问题后，才进入参数调整。
这时也别只写“经过调整得到较好结果”。更好的写法是把关键调整写进报告：
- 调整前的异常是什么。
- 改了哪个参数。
- 改动方向是什么。
- 调整后指标如何变化。
- 为什么停止继续调整。
这种过程记录比最后一张图更有用。它能说明参数不是随机试出来的，而是看着波形、工作点或指标一点点调出来的。
我的检查清单
现在做模拟实验仿真，我会按这个顺序检查：
- 仿真器是否正常启动。
- 许可证或运行环境是否明确可用。
- 日志是否进入有效仿真阶段。
- 网表和模型文件是否被正确读取。
- 每份网表是否只承担一个主要分析目标。
- AC 和瞬态证据是否分开保存。
- 报告正文、截图和源码附录是否能互相追溯。
- 参数调整过程是否写进报告，而不是只留下最后结果。
这样做比直接改电路慢一点，但写出来的报告更可靠。
先确认工具真的跑通
仿真失败不一定是电路失败。
在工具链、输出文件和报告附件还没对上之前，修改电路参数很可能是在改一个并没有出问题的地方。先确认工具真的跑通，再确认结果能回查，最后才讨论电路是否需要调整。
后来我写报告时，会把截图、网表、日志和结论放在一起核一遍。
继续读