sc_core::sc_in<bool>::read() 上的 SystemC 段错误答案

【问题标题】：SystemC Seg Fault on sc_core::sc_in<bool>::read()sc_core::sc_in<bool>::read() 上的 SystemC 段错误
【发布时间】：2011-05-02 02:39:51
【问题描述】：

我在使用 SystemC 时遇到重复的 seg 错误。在初始化期间，我将值设置为 0。在测试台运行期间，我在模块 (proc) 中将此值设置为 1。这是一个附加到另一个模块 imem 的端口的 sc_signal 变量。输入端口的类型为 sc_in。

理论上，这个分配应该导致输入端口也被分配 1，当我尝试使用 .read() 函数访问它时，它应该返回一个 1 并将其分配给 imem 中的另一个内部 sc_signal。

但是，我却遇到了段错误。

根据 gdb，这发生在我调用 sc_start(10,SC_NS) 期间，这是有道理的，因为此时值应该更新。它专门跟踪它以尝试执行 .read() 的返回。这是堆栈返回的快速 sn-p（-O0 和 -g3 使用 g++ 和 gdb6.6，64 位系统）：

#0  0x00000000004c79a6 in sc_core::sc_in<bool>::read (this=0x881a38) at <redacted>/systemC/install_x64/include/sysc/communication/sc_signal_ports.h:515
#1  0x00000000004e4b60 in imem::reg_write (this=0x881910) at ../src/abstract_proc/mems/imem.cpp:33
#2  0x000000000050578e in sc_core::sc_simcontext::crunch(bool) ()
#3  0x00000000005042b4 in sc_core::sc_simcontext::simulate(sc_core::sc_time const&) ()
#4  0x00000000004c65b0 in sc_core::sc_start (duration=10, time_unit=sc_core::SC_NS)

港口声明：

SC_MODULE (imem) {
...
sc_in<bool> en_wr;

函数声明（发生在 SC_CTOR(imem) 中）：

SC_METHOD(reg_write);
sensitive << clk.pos();

函数死去的地方：

void imem::reg_write() {
data_wr_d.write(data_wr.read());
wr_addr_d.write(addr_wr.read());
cout << "imem::reg_write()" << std::endl;
en_wr_d.write(en_wr.read());
cout << "imem::reg_write() done" << std::endl;
}

imem::reg_write() 在 seg 故障发生之前打印到控制台。

imem端口的声明与绑定：

imem_i = new imem("imem");
imem_i->en_wr(imem_wr_en);

驱动信号的声明：

sc_signal<bool> imem_wr_en;

有什么想法吗？想法？我应该尝试什么？

编辑：有时会发生一些奇怪的事情，即添加或删除代码行会导致段错误消失。一个特定的实例涉及添加调试cout 语句修复了问题，但在其末尾添加<< std::endl 后，段错误返回。这暗示了我有一个竞争条件，但理论上 SystemC 应该处理所有并发线程。

【问题讨论】：

标签： c++ hardware segmentation-fault systemc

【解决方案1】：

听起来像是内存问题。如果您在某处过度运行缓冲区，任何事情都可能发生 - 甚至像您解释的那样：程序在随机位置崩溃。

我真的希望你有好的单元测试。尝试使用 valgrind 检测内存问题。

【讨论】：

嗯，我会调查的。我已经单独测试了每个模块，因此它不是子模块的固有功能。在我拥有子模块之前，顶层模块过程显然是不可测试的。

【解决方案2】：

能否请您告诉您是否有解决问题的方法。实际上，我们在读取布尔 sc_signal 时遇到了类似的问题，段错误。在代码中添加打印后问题就消失了。

【讨论】：