views:

30

answers:

1

Hello,

I am having a repeating seg fault while using SystemC. During initialization I set a value to 0. During operation of a testbench I am setting this value to 1 in a module (proc). This is a sc_signal variable that is attached to a port of another module imem. The input port is of type sc_in.

In theory, this assignment should cause the input port to also be assigned 1, and when I try to access it using the .read() function it should return a 1 and assign it to another internal sc_signal within imem.

However, I am instead getting a seg fault.

According to gdb, this is occurring during the sc_start(10,SC_NS) call I make, which makes sense since that is when values should be updated. It traces it specifically to trying to execute the return of the .read(). Here is a quick snippet of the stack return (-O0 and -g3 using g++ and gdb6.6, 64-bit system):

#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)

The port declaration:

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

The function declaration (occurs in SC_CTOR(imem)):

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

The function in where it dies:

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() gets printed into the console just before the seg fault occurs.

The declaration and binding of imem's port:

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

The declaration of the driving signal:

sc_signal<bool> imem_wr_en;

Any ideas? Thoughts? Things I should try?

EDIT: Something odd that occurs is sometimes adding or removing lines of code causes the seg fault to go away. One particular instance involved adding a debug cout statement fixed things, but after adding a << std::endl to the end of it the seg fault returned. This implied to some that I have a race condition, but in theory SystemC should be handling all the concurrent threads.

A: 

Sounds like memory problem. If you over run buffers somewhere, anything can happen - even stuff like you explained : program crashing at random location.

I really hope you got good unit tests. Try using valgrind to detect memory problems.

VJo
Hm, I'll look into it. I have tested each module individually, so it's not an inherent functionality on the part of the sub-modules. The top module proc obviously was untestable until I had the sub-modules.
spellman23