How to ensure handling interrupt in time when using quantum keeper?

[taog]

Dear experts,

I'm developing an ISS SystemC wrapper for a processor. In the SystemC wrapper, I decided to use quantum keeper to improve simulation performance. But, I found some issues when handling external interrupt. An external interrupt controller model is connect with my processor model by using some "sc_signal". When executing interrupt handler, SW need to clear interrupt by write some register in the external interrupt controller. But, my model used quantum keeper, it always need to execute enough instructions to reach quantum without sync with SystemC kernel. So, of cause, it do not know that the interrupt has already been cleared until it reached quantum. It always entered interrupt handler multi times. Who can tell me some solutions???

[Eyck]

There are several ways to do this: you might use a different way to carry signals which are more TLM like. One option would be to use tlm_signal. The other common option is if your CPU writes into the register of your interrupt controller via TLM it carries the delay which is essentially the offset of the CPU local time to the SystemC kernel time. If you here just break the quantum and call a wait() so that the SystemC kernel can sync up and the signal change propagates you should be fine.

[taog]

It looks like we need to sync with SystemC kernel once CPU access other models in the system. Anyway, we must balance simulation performance and correct model behavior.

[taog]

For solution 2 "if your CPU writes into the register of your interrupt controller via TLM it carries the delay which is essentially the offset of the CPU local time to the SystemC kernel time. If you here just break the quantum and call a wait() so that the SystemC kernel can sync up and the signal change propagates", what if this interrupt is cleared by other models instead of my CPU model? How my CPU model can sense the external signal change(Interrupt value change) immediately?

[Eyck]

Well, your interrpt is set in a SC_THREAD or SC_METHOD and these are active when the ISS thread sleeps. In that sense the sensing is immediate when the ISS thread wakes up. But since the  ISS thread is ahead of the SystemC simulation when the irq is activated in SystemC there is no way to have an immediate sensing. This is the accuracy you give up to gain simulation speed: the delay until the ISS acts on an external event is determined by the quantum. On solution could be to use a dynamic quantum which changes in the course of the simulation: you start with a large quantum until you reach a certain point in simulation (e.g. until you booted the system) and then you lower the quantum to get more accuracy.

[taog]

On 8/5/2019 at 1:02 PM, Eyck said:

Well, your interrpt is set in a SC_THREAD or SC_METHOD and these are active when the ISS thread sleeps. In that sense the sensing is immediate when the ISS thread wakes up. But since the  ISS thread is ahead of the SystemC simulation when the irq is activated in SystemC there is no way to have an immediate sensing. This is the accuracy you give up to gain simulation speed: the delay until the ISS acts on an external event is determined by the quantum. On solution could be to use a dynamic quantum which changes in the course of the simulation: you start with a large quantum until you reach a certain point in simulation (e.g. until you booted the system) and then you lower the quantum to get more accuracy.

OK, I see, thanks. So the guideline is using TLM like way(Pure function call, no SystemC schedule related) to carry signals when using quantum, right?

[Eyck]

If you can you should do it this way. But if the source of the irq is outside of the LT domain you can only reduce the quantum.