LaoShaw Posted June 9, 2022 Report Share Posted June 9, 2022 I can use gdb to debug general systemc code. I can also use the gdbserver-stub built into my ISS to step through the target code(running inside the model, e.g. a small code outputs to UART). now when my code got stuck in the target code that is running inside the model(e.g. UART never output the character), the gdbserver-stub can not proceed to next line of code, attach gdb directly to the systemc model itself does give me a backtrace, which is nice, but it's still difficult to figure out what is wrong in the systemc/TLM's code(e.g. UART implementation in systemc) what's a better approach to debug scenarios like this? i.e. when the code running inside the model that exercises the peripherals from the systemc model is not working, how to find out what's wrong. Quote Link to comment Share on other sites More sharing options...
Eyck Posted June 10, 2022 Report Share Posted June 10, 2022 The simple answer is: use a commercial tool, this is where they shine. If you want or need to stick to freely available tools there is to my knowledge nothing better as gdb, tracing, and printf debugging. For the latter you would need to instrument your code to print out what happens atr wihich time. I saw huge models using the approach generating GBs of log output on . demand. Pretty helpfull is a structured output with a single line per log message having the time and the hierarchy of the originator. One option would be to use the report system in the SCC which build upon and extends the SystemC report system, pls have a look at https://minres.github.io/SystemC-Components/main/report_8h_source.html Tracing would use VCD output and transaction recording base don the SCV. I personally tend to use gdb with all of its features like: dprintf debugging to temporarily create a text trace conditionlal breakpoints based on the this pointer to enable breakpooints for a specific instance (e.g. if there are several instances of the same module) conditionlal breakpoints based on sc_core::sc_time_stamp() (the SystemC library needs to be compiled in debug mode). This allows breakpoints be triggered after a certain simulation time watchpoints to observe a variable an it's value change LaoShaw 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.