Debug. And Trace. They’re not always two sides of the same coin
A recent MINRES project with Accemic made me stop and think about how debug and trace are often lumped together in the design flow. But I would suggest that thinking about them separately can make a significant difference during a project.
When integrating processor IP into a platform, the question of how to address requirements for tracing and debugging are often very important. There are plenty of techniques and ideas to address tracing and debugging during the development process before the HW is available. But it can be tricky to analyze the interaction of HW and SW once the hardware is available and the software components have to be deployed. This is especially true in the RISCV environment, where many new players and applications are starting to appear. Also, the increased importance of heterogeneous multi-processor systems increases the challenges when platforms are more and more complex and the interaction of components becomes increasingly difficult to predict.
So, while trace and debug are often used together, the requirements, and the solutions, are often quite different: If I’m debugging, I need to access internal state information at a particular point in time and easily step through code execution.
Tracing, however, means I’m summarizing information over longer periods of time. I may not need to know the content of every register. But, I do need to understand how the control flow in my SW is executed and when I’m reaching certain points in my SW. And this should be done over longer periods of execution time. This implies compressing and transporting the information in a very efficient manner.
Tracing is essential for safety-relevant real-time applications where worst-case execution time (WCET) bounds have to be determined in order to demonstrate deadline adherence. The trace IP from Accemic which has been developed during the Tristan project is providing such capabilities. But the trace IP has to get the relevant information from the processor.
Minres has been working with Accemic on this interface between TGC cores and the trace IP. We can demonstrate the whole tool chain from processor through the Trace IP, generating input for analysis tools like the CEDARtools and TimeWeaver and this is where we can demonstrate value. If different solutions from different companies work together, it demonstrates the value of an ecosystem. Publicly funded projects try to foster those synergies, but don’t always deliver. Hopefully, here at MINRES, we can continue to help the RISC-V ecosystem to mature.
Are you interested how to verify your designs with The Good Cores from MINRES?
Contact us to learn more about The Good Cores