Jump to content

andrewkrill

Members
  • Content Count

    2
  • Joined

  • Last visited

  1. 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!
  2. 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?
×
×
  • Create New...