Need help to implement an interrupt controller simulator which handles the ISR

[Jomon]

I am on the implementation of an interrupt controller simulator, which will take signals from other rest of the HW modules in simulation and run the ISR.

Below is the systemC code roughly made to get the concept clear. In this case, we need ISR to be handled in a way that, even if the FW_main is stuck inside while(1) loop.

With the below implementation the context is inside FW_main loop only. Adding a wait in FW_main is not the one we want. We need the correct interrupt controller functionality. Any ideas to get rid of this problem? Please share your inputs. Thanks in advance.

 

SC_MODULE (processor)
{
    sc_in < bool > interrupt;

    void ISR(void)
    {
        cout << "i am in ISR\n";
    }
    
    void FW_main(void)
    {
        while(1)
        {
            cout << "i am in FW_main\n";
        }
    }
    
    SC_CTOR (processor) 
    {
        SC_METHOD(ISR);
        sensitive << interrupt;
        SC_THREAD(FW_main);
    }
    
};

[David Black]

In a cooperative multitasking environment (e.g. SystemC), it is impossible to have an infinite loop without yielding. The only yielding method available in SystemC threads is the wait() method; therefore, you have self-defined an impossible problem.

SystemC processes (SC_THREAD and SC_METHOD) are NOT the same concept as OS processes or threads. They are constructs of the discrete event driven simulator known as SystemC.

Now it is possible in some cases to trick the code, which I have used for some cases. For example, if your FW_main code where to attempt some I/O with a common method, then you could have that method call wait(). This works well when modeling an embedded system using an RTOS and you can modify one of the drivers minimally (i.e. to insert wait()).

[Jomon]

Thanks for your response.

We need to simulate a processor in which the ISR will be invoked even though the FW code is in an infinite loop. Even if we call wait in FW_main, the correct functionality what an interrupt controller is capable of will not be achieved. So I may need to look for something else.

[Jomon]

Hi David,

I am seeing an option for enabling posix pthread for the creation of SC_THREAD. What is your opinion on the same to get the context switch without a wait method?

Can you please reply with what all differences --enable-pthreads will make in SC_THREAD, SC_CTHREAD, SC_METHOD internal implementation.

Thank you,

Jomon

[Jomon]

Compiled the systemC libraries by configuring --enable-pthreads, but same observation as before. It is in the thread's loop only.

Found a link which is saying even we configure for pthread, SystemC only run threads one by one no matter how you configure your SystemC to use pthread or Window native thread.

https://stackoverflow.com/questions/18646936/will-sc-thread-in-systemc-create-a-real-thread

So, how can we use systemC for a simulation like this kind of use case?

[David Black]

Usually, we compile the client code to run on a simulated processor, usually known as an ISS (Instruction Set Simulator). This will give you the correct behavior. The ISS will call wait periodically and thus do what you desire.

One other possibility that I hesitate to suggest is to run your system code in a separate OS thread (not a SystemC thread) and then interact with it via proper thread-safe semantics (probably using a custom primitive channel utilizing asyc_request_update). I can reasonably expect this will not provide satisfactory results because it will not provide the proper timing relationships. This approach is also fairly complicated and requires a solid understanding of concurrency concepts and how the SystemC simulator works.

[Jomon]

Thanks.., Yes as you said running on a different thread does the job but there are lot many problems as you said. We need to try out the ISS as you have suggested.