Disappointing SystemC Debugger Integration Paper

Since I have a certain interest in debugging, I was happy find the article “Guidelines for SystemC – Debugger Integration” at the usually interesting Design and Reuse website. However, I must say that it was pretty disappointing.

The key idea of the article is to put the debug service in a thread and the debugged SystemC system in another thread, and stop SystemC using a mutex. Yes, you have to do that.

But the really interesting part is how to connect the debugger into the virtual platform, and what that requires from the models and processors and the infrastructure. Unfortunately, the article is pretty silent on that. There is some talk of breakpoint handling required in the ISS, and how to update target memory that mostly corresponds to the debug interface of SystemC TLM-2.0 in scope.

Also, nothing about multicore debug and how to deal with temporal decoupling and debugging, or the need for repeatability across runs. Or breakpoints on things like hardware accesses and internal actions in the simulator.

Too bad.

 

 

2 thoughts on “Disappointing SystemC Debugger Integration Paper”

  1. Hi Jakob,

    Thanks for the feedback. (I dont intend to take this into a ‘I know; you know debate’.). But thought will just update you with some additional details.

    Regarding how to connect the debugger into the virtual platform:
    The first requirement is that the debugger should support the possibility to have debug hooks there by permitting the introduction of external processor models.
    If the debugger in question supports such integration with external process model, only then this paper comes into scope.
    There are different ways in which a particular debugger will support the integration of external processor models – but it usually defines a set of APIs/Callbacks to be supported (and then, for e.g., dynamically linked with the debugger executable). The scope of the paper was restricted to ONLY the understanding of this API architecture.
    (This integration mechanism was intentionally left out as this is specific to the particular debugger in use).

    Multi-core debug was outside the scope of this discussion. But just to provide you some details, for multi-core debug, one can think having the different processor/cores to implement a callback mechanism, which is triggered whenever a breakpoint in any core is hit. This callback then does the handling of the ‘Stop’ request for that core. The Callback can be triggered from the debugger once it gets the notification from any of the cores.

    For the things like HW access, the same mechanism which is used for returning the control from SystemC to the debugger can be employed, when the SystemC model finds an access to a particular HW resource. But this would have to be implemented in the SystemC model so that the same mechanism for the updating of the shared variable as mentioned in section: B.3.

    Hope this was helpful.

    Thanks and Regards,
    Mohit.

  2. Thanks for the comment. I did not quite get the context before – basically, you think of the systemC system as something subordinate to the debugger and started from the debugger. I tend to view them as peers that connect and disconnect dynamically, so understanding that does help in reading the paper. At least with my background, it was not obvious.

    Still, it would have been interesting with more details about how the ISS and VP supported breakpoints.

Leave a Reply

Your email address will not be published. Required fields are marked *