Yosys仿真模块中的FST内存泄漏问题分析与修复

在数字电路设计验证工具Yosys的仿真模块中，开发团队发现了一个与FST（Fast Signal Trace）文件处理相关的内存泄漏问题。这个问题主要影响使用cosim（协同仿真）功能时的内存管理，可能导致长时间仿真运行时的内存消耗持续增长。

问题背景

FST是一种高效的信号波形存储格式，Yosys使用它来记录仿真过程中的信号变化。在协同仿真场景下，系统需要从FST文件中重建特定时间点的信号状态。原实现采用了一种基于回调函数的机制来处理时间序列数据，但这种设计存在潜在的内存管理缺陷。

问题根源分析

内存泄漏发生在以下调用链中：

1. run_cosim_fst启动协同仿真
2. 调用reconstructAllAtTimes方法重建时间点数据
3. 该方法内部使用fstReaderIterBlocks2进行块迭代
4. 迭代过程中通过calloc分配了内存(scatterptr)
5. 回调函数lambda在遇到FST文件结束时抛出异常
6. 异常抛出导致内存释放代码被跳过

关键问题在于异常处理路径绕过了正常的内存释放流程，使得scatterptr分配的内存无法被回收。

解决方案

开发团队经过深入分析后，确定了以下修复策略：

1. 移除了基于异常的时间范围控制机制
2. 在回调函数内部添加了显式的时间检查
3. 确保所有内存分配都有对应的释放操作

修复后的实现更加健壮，不再依赖异常来控制流程，从而保证了内存的正确释放。值得注意的是，虽然FST库提供了fstReaderSetLimitTimeRange函数，但它并不适合解决这个特定问题，因为协同仿真需要根据周期数而非绝对时间来控制仿真长度。

技术启示

这个案例展示了几个重要的软件开发经验：

1. 在C++中使用异常处理需要特别注意资源管理，特别是在与C库交互时
2. 回调函数中的非局部控制流（如抛出异常）可能破坏调用者的预期行为
3. 内存管理在长时间运行的工具中尤为重要，微小的泄漏累积可能导致严重问题

影响评估

该修复显著提高了Yosys在长时间协同仿真场景下的稳定性，特别是在处理大型设计或长时间仿真时。用户现在可以更放心地使用FST格式进行复杂的验证工作，而不必担心内存泄漏问题。

这个问题的发现和解决过程也体现了开源协作的优势，通过社区成员的共同参与，能够快速定位和修复复杂的技术问题。