Jump to content

How to yield control from SystemC thread to another thread


katang

Recommended Posts

As I mentioned in a previous post, I want to display the state of the simulated object in a GUI thread, while the simulation thread is suspended. Can I do that in an elegant way?

I mean, that if I am after receiving my event, the event queue is empty, so the simulation stops immediately. If I suspend it before triggering the event,  then the  event queue is empty again; so my waiting terminates again. If I trigger the event first, then I stop at a wait(resume-event), the simulation goes to serve the event first, I wanted to stop at; and comes back to my wait(resume-event), and since the event queue is empty, stops again. I guess I need to forcefully prevent taking out the event before the GUI thread returned a resume_event. How can I do that?

Link to comment
Share on other sites

Keep in mind that SystemC's kernel is not threadsafe. SC_THREAD and SC_METHOD processes are completely different animals than OS threads as well. You can use the async_request_update() method to interface into SystemC from the outside. From the inside you can of course stall everything in the SystemC side because it is cooperative multitasking system. In either case, you will need to use appropriately setup mutex to protect shared resources. Due to differences in the concept of time (simulated vs real), you will also likely need to use mailboxes for communication.

You might also what to consider scheduling events to happen at the end of a delta cycle (ie. event.notify(SC_ZERO_TIME) or perhaps even a non-zero time in the future.

Link to comment
Share on other sites

When implementing some simulation control I usually have the logic as part of a SC_THREAD. Once the thread is active it is save to access all the other data structures as -like @David Black mentioned- SystemC is cooperative multi tasking. Based on the GUI thread you can then decide to run for a certain time, until a certain event, or stop simulation entirely using sc_stop()

 

Link to comment
Share on other sites

My case is less complex. I am aware of that this process is not that process, and this scheduler is not that scheduler. My intention is exactly just to stall SystemC at some point of execution, and just to read some variables for displaying it in the GUI. I am interested in sc_time only from the aspect to display it in the GUI. I do not want any other communication, than emitting a message that SystemC stalled, then -- after finishing the GUI update -- to resume it. A kind of breakpoint. In the same way as used in a debugger. To resume, I can ask the thread to send a message. I wonder if I can stall SystemC safely, without interfering with anything.

Maybe SC_ZERO_TIME solves the problem; however the simulation itself also uses SC_ZERO_TIME in some cases; so they may interfere; I need to check.  I do not want to use non-zero time as it falsifies the simulation time, which is also important.

 

Link to comment
Share on other sites

So you say that rather than stalling in SystemC, I need to wait for a SystemC event generated by the GUI? then the SystemC thread can emit a signal, and the two guys can ping-pong with the signals? It sounds good, thank you.

That is, as @David Blacksuggested, I shall use the async_request_update() method from the thread, running SystemC? Is some sample around? in the book and the examples I do not find a call like this.

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

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