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

[andrewkrill]

Background/Problem:

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?

 

 

 

[Eyck]

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.

BR

[David Black]

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

[andrewkrill]

Yes, turns out I misunderstood how thread contexts worked. I didn't realize a thread could call functions then wait within those functions.

Thanks much for the replies!