Personal tools

GDBTrace: A Post-Simulation Trace-Based RISC-V GDB Debugging Server (1S)

From iis-projects

Revision as of 23:20, 12 October 2022 by Colluca (talk | contribs) (Created page with "<!-- A Post-Simulation Trace-Based RISC-V GDB Debugging Server (1S) --> Category:Digital Category:High Performance SoCs Category:2022 Category:Semester Thesis...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Overview

Status: Available

Introduction

In any chip design project, a lot of effort is spent on verifying the design before it can be delivered for tapeout. For general purpose processor designs, verifying the functionality involves running some code on the core(s) and comparing the outputs of the program with the expected results. On a mismatch, we will have to identify where the bug originates in the hardware and, for this to be possible, we need to identify at what point the program behaviour deviates from our expectations.

If your processor has a debugging interface (exposed e.g. over JTAG) and can be implemented on an FPGA, you will possibly be able to connect a debugger to your FPGA board and benefit of a fully-featured debugging experience, as you might be used to from programming embedded systems. However, this is not always the case, as bringing a design onto an FPGA requires additional effort, and for large designs which do not fit on a single FPGA it might not be possible to have an exact 1-to-1 correspondence between the FPGA implementation and the original design.

If testing your design on an FPGA is not an option, you will have to debug your code directly in RTL simulation. In this setting, you can forget the bells and whistles of integrated development environments (IDEs) with their powerful debugging features and convenient graphical interfaces. Oftentimes, your best tool at hand is the core's bare execution trace, i.e. a flat record of the instructions which were executed by the core during the simulation, accompanied by auxiliary information such as the values of the registers involved in the instruction at the time of its execution.

Is this really the best way we can inspect our program's execution? Alternative methodologies do exist, but present their own shortcomings which we want to address in this thesis.

If your processor has a debugging interface (exposed e.g. over JTAG)