Jump to content

async reset does not reset singlas assigned in a CTHREAD


Recommended Posts

Hello everyone,


here's the secenario:





CTHREAD A and CTHREAD C are both triggered by the same clock signal, CTHREAD C has an async reset signal assigned to it.

This reset signal is controlled by THREAD B.


1. A starts B via notif(), which means B will start in the current evaluation phase.

2. The scheduling happens to be that C runs before B.

3. C runs and does some signal assignment.

4. B runs and asserts the async reset signal of C.

5. The reset code of C is run.


But the singal writes in step C are already applied to the corresponding signals in step 5.

Since C is a CTHREAD I would have expected that the singal update happens at the next rising clock edge, not after one delta cycle.


The behavior I want, is to revoke all signal assignments done in step 3. Maybe I'm too much influenced by VHDL. For me this is a clocked process and the singals represent registers. The register load the inputs at the clock edge and not in between.


Can someone please tell me how to realize this kind of behavior correctly?

Link to comment
Share on other sites

The behaviour in SystemC matches the one in VHDL pretty closely: In VHDL, the outputs of a clocked process are also updated in the next delta cycle. How would would you model the desired behaviour in VHDL?



That said, it seems you're somewhat mixing abstraction levels here, having an immediate notification (of thread B ) in an otherwise clocked system. If you indeed need to immediately reset C, you can explicitly call the 'reset()' function on (a process handle of) C from within thread B. This might still cause C to be evaluated twice, but at least now both runs would happen in the same evaluation phase.


Hope that helps,


Link to comment
Share on other sites

Hello Phillip,


thanks for your answer. Well that's not what I expected, but it defnitely explains my problems.


I'm not sure how to correctly model the reset. The problem is that the information to do the reset is just available in the same clock cycle as the reset must happen (or deasserting a write enable or something like that would be sufficient too).


My first approach would be to write a combinatorial process to handle the reset trigger. But I have problems implementing such a method in SystemC, since the sensitivity list is not static.


I have tried something like that some time ago:


for (...) {

    sensitivity << array;



But that lead to some really wired behavior. That's why I'm using events to "emulate" a sensitivity list and trigger a thread per hand.


But this approach now also fails me.


I'm currently trying to get a process handle of the other CTHREAD but I really don't know where to start. The constructor takes a sc_process_base, but I can't find the corresponding header in my installation. Is there another way to get the handle, like just using the function pointer?

Link to comment
Share on other sites

Wait a minute. I think I know what's "wrong". I think I'm interpreting my deboug outputs wrong.


If I hava a CTHREAD and I print out a signal value along with the time stamp. Then the print out shows me the "old" value of that register from the previous clock cycle?


And one delta cycle later all registers hold the corret values that are meant for this clock cycle.


It would be great if someone can confirm the above (though it would mean I've wasted a whole afternoon for being stupid).

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.

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