andrewkrill Posted July 10, 2019 Report Share Posted July 10, 2019 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: Is it possible to have a C++ function that is called normally wait until an SC_thread is finished? Is there a way to handle hardware interactions that require waiting without having to spawn or use a thread? Quote Link to comment Share on other sites More sharing options...
Eyck Posted July 10, 2019 Report Share Posted July 10, 2019 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 andrewkrill 1 Quote Link to comment Share on other sites More sharing options...
David Black Posted July 10, 2019 Report Share Posted July 10, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
andrewkrill Posted July 24, 2019 Author Report Share Posted July 24, 2019 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! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.