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?




Share this post

Link to post
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.


Share this post

Link to post
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").

Share this post

Link to post
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...