Jump to content

Issues with concurrency and running C++ code on top of SystemC


Recommended Posts


I have some existing code in C++, that runs on my physical hardware that I would like to run within SystemC for testbenching. I would like as much of this code to be identical so the hardware tests match the TB tests. 

At the bottom level I am replacing my hardware read/write class (that interacts with hardware) with a systemC module that all other classes will inherit from. The code I have, that currently runs on hardware, is dependent on the fact that the process doesn't proceed until there is a return from the read() or write() functions. However, in order to interact with the systemC ports, I require the function to spawn a thread to handle this process and suspend the thread while modelsim processes the hardware. Without spawning a thread, I cannot do wait() or have sensitivity functionality.

On the surface this seemed straightforward, however, since I do not want the C++ code to change, beyond adding a top level wrapper, I am running in to issues. First, when I have my C++ code call a function to spawn a thread to do a read/write transaction, I lose the ability to wait until that thread is finished. I could make the C++ code into sc_threads so I can use wait(), but that defeats the purpose of what I am trying to do, (keep all of the abstracted classes similar between hardware and tb).

The only "solution" I can think, if you can call it that, is passing a variable by reference to this spawned thread, then having the process do a while(foo!=barr) until the thread signals it is finished by changing this variable. However I don't know if this is even viable, because in addition to wasting cycles, the spawned thread might not even be executed by the event scheduler in the systemC kernel. So I doubt this would work.

My Questions:

  1. Is it possible to have a C++ function that is called normally wait until an SC_thread is finished? 
  2. Is there a way to handle hardware interactions that require waiting without having to spawn or use a thread?




Link to comment
Share on other sites

Hmm, not sure if I understand you correctly. Your C++ code has an entry function, right? If you just call this entry function from a SC_THREAD it runs in a thread context and can call wait to let other parts of the simulation continue.

The other option you have is to run your C++ code in a second (OS) thread, e.g. a std::thread. This allows to use the usual syncronization primitives of the OS like mutexes and alike.


Link to comment
Share on other sites

Caution: SystemC Kernel is not thread-safe without taking special precautions. If you call into SystemC from outside the SystemC OS-thread, you may need to create a primitive channel utilizing async_request_update(). If on the other hand you are simply stalling SystemC from within, which is what I think is being stated, then you should be fine with simple std::mutex (not sc_core::sc_mutex which is only for use inside SystemC between SystemC internal "processes").

Link to comment
Share on other sites

  • 2 weeks later...

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