Jump to content

running problem

Recommended Posts

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




I hope somebody help me to fix such problem!


Thanks in advance  

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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[])

          cout << "it is ok till here!" << endl;

       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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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:
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).
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...