async reset does not reset singlas assigned in a CTHREAD

[wasdf]

Hello everyone,

 

here's the secenario:

CTHREAD A

THREAD B

CTHREAD C

 

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?

[Philipp A Hartmann]

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,

  Philipp

[wasdf]

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?

[wasdf]

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