running problem

[mossaied]

Hi everybody,

 

I have a problem in running my systemC-AMS code, when I run the code in microsoft visualstudio in debugging mode, I found that the kernel of systemC-AMS stuck in the following function:

 

// yield to the next coroutine

 

void

sc_cor_pkg_fiber::yield( sc_cor* next_cor )

{

    sc_cor_fiber* new_cor = SCAST<sc_cor_fiber*>( next_cor );

    SwitchToFiber( new_cor->m_fiber );

} 

 

which is belong to a cpp file called: sc_cor_fiber.cpp, which is not belong to my code, it is belong the kernel of systemC-AMS

 

The attached file show you the message that visualstudio show up when it began to run

 

problem.pdf

 

I hope somebody help me to fix such problem!

 

Thanks in advance  

[maehne]

The error you observed happens in the process switching of the discrete event simulation kernel of SystemC and thus probably not specific to the SystemC AMS extensions. You don't provide enough context so that anyone could help you to resolve the problem, as you just show where the program stopped inside the SystemC kernel, but you don't provide any information about your model that you try to execute on top of the SystemC kernel, and which is most likely the source of the problem. Try to observe, what part of your model was last executed before the error occurs and analyze that context for anomalies. If that doesn't help, you can try to reduce progressively your model as much as possible so that it still exposes the problem. Then, analyze what is left.

[mossaied]

Thanks Mr Toresten for your reply,
 
When I debug my code, noticed 2 things:
   1) none of methods has executed, I put "cout << "Hi" << endl;" at the begining of each method of my code, for example:
      
       void DEAD::DEAD_cir()
       {
          cout << "Hi DEAD" << endl;
          ....
       }
 
       and when runing none of these messages appears in the cmd window output
 
   2) I put another "cout" just before the "sc_start();", 
      
       int sc_main(int argc, char* argv[])
       {
            sc_report_handler::set_actions("/IEEE_std_1666/deprecated",SC_DO_NOTHING);
 
           ....
    
          cout << "it is ok till here!" << endl;
          sc_start(5000,SC_NS);
          return(0);
       }
 
       and I also put a breakpoint at "sc_start(5000,SC_NS);", then I noticed that the message  "it is ok till here!" appears and the debugger stops at the "sc_start(5000,SC_NS);" statement as expected but when I proceed forward the problem that I mention occured without execting any of my code methods. 
 
please, Mr Toresten if this is also not enough, plz tell me.

 

Also, I'd like to know more about that method sc_cor_fiber, may be I can figure what part of my code could cause the problem.

 

Thanks in advance

[maehne]

This information is still not sufficient to debug the problem. It seems that you have used one of the examples coming with the SystemC proof-of-concept implementation as a starting point for your own model. Does the original model work with your SystemC setup?

 

sc_cor_fiber is an implementation detail related to the implementation of SystemC processes of type SC_THREAD on windows. Do you follow the rules for registering the SC_THREADs in your modules' constructor?

 

Do you actually do wait() calls in your SC_THREAD instances?

 

Do you instantiate an unusual big amount of SC_THREADs?

 

Do you use a lot of stack memory in your threads?

 

These questions are merely poking into the fog and no one on this forum will have time to debug a big model of yours.

 

Therefore, I suggest that you proceed methodologically: Start from a model that is actually working and then progressively introduce you modifications to see when it breaks. This may allow you to locate the problem.

 

Your approach of big bang testing is making things unnecessarily difficult. Test first the individual module's functionality separately.

[mossaied]

Thanks Mr Torsten for your reply,

 

actually my project is implementing 4x4x4 NoC (64 cores), so I think instantiating this very large number of threads did that (becuase 3x3x3 NoC works), so I will try with lower number of instantiated cores to laocate the problem

 

Thanks again Mr Torsten, and I am really very sorry for inconvenience

[maehne]

How many threads are actually instantiated per core? I guess more than one as 64 different sc_threads doesn't sound like too much.

 

What SystemC version are you using? I strongly suggest you to  use the most recent version SystemC 2.3.1, which includes numerous fixes, which might be also relevant to your case, e.g.,

 

SystemC 2.3.1 Releasenotes:

  - Fixed incorrect GCC i386/x86_64 function call stack alignment when

    using the QuickThreads/WinFiber-based process implementations (16-byte

    boundary).  This avoids segmentation faults in some cases where the

    stricter stack requirement is implicitly assumed by the compiler.

 

 

 

For what Windows platform are compiling SystemC and your NoC model? 32 bit or 64 bit? Especially, on a 32 bit platform, you might run out of memory soon, as each sc_thread gets allocated its own stack and process memory size is limited to 2 GiB. These two blog postings contain more information:

 

http://blogs.msdn.com/b/oldnewthing/archive/2005/07/29/444912.aspx

http://blogs.technet.com/b/markrussinovich/archive/2009/07/08/3261309.aspx

 

You can set the stack size of a spawned sc_thread using set_stack_size() in the module's constructor (see clause 5.2.16 in IEEE Std 1666-2011). You can also override the default stack size of each sc_thread during the configure phase of the SystemC library using SC_OVERRIDE_DEFAULT_STACK_SIZE=<size> (see SystemC INSTALL file).

[mossaied]

Thanks a lot Mr Toresten, I have installed SystemC 2.3.1 according to your advice, and the project ran successfully (I am surprised but really happy!)

 

Thanks again for your effort and time, I have gained much knowledge from that discussion

[maehne]

You are welcome.