Difference between revisions of "GDBTrace: A Post-Simulation Trace-Based RISC-V GDB Debugging Server (1S)"
From iis-projects
(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...") |
|||
| Line 30: | Line 30: | ||
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. | 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 | + | Is this really the best way we can inspect our program's execution? Alternative methodologies do exist, but come with their own shortcomings which we want to address in this thesis. We aim for a source-centric debugging experience, i.e. in which the program execution can be inspected at the source (or high-level language) level. We thus do not mention any approach which aims at making the trace-centric debugging experience more "confortable". |
| − | If your processor has a debugging interface (exposed e.g. over JTAG) | + | If your processor has a debugging interface (exposed e.g. over JTAG), you can actually connect a debugger to the simulation and communicate with the processor over the JTAG interface port [1]. This method is extremely powerful, as the debugger provides us with the desired fully-featured source-centric debugging experience. This method is also extremely portable, any RISC-V core with a JTAG debugging interface can reuse the same infrastructure. However, simulating the serial connection on the JTAG interface can significantly slow down the simulation to the point where it becomes unpractical to use. This is especially true when dealing with large and complex designs. |
| + | |||
| + | More | ||
<!-- | <!-- | ||
| Line 82: | Line 84: | ||
* Preferred: Knowledge or prior experience with RISC-V | * Preferred: Knowledge or prior experience with RISC-V | ||
* Preferred: Experience with ASIC implementation flow as taught in VLSI II | * Preferred: Experience with ASIC implementation flow as taught in VLSI II | ||
| + | |||
| + | --> | ||
= References = | = References = | ||
| − | [1 | + | [1] https://github.com/pulp-platform/pulp-debug-bridge <br /> |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 23:47, 12 October 2022
Overview
Status: Available
- Type: Semester Thesis
- Professor: Prof. Dr. L. Benini
- Supervisors:
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 come with their own shortcomings which we want to address in this thesis. We aim for a source-centric debugging experience, i.e. in which the program execution can be inspected at the source (or high-level language) level. We thus do not mention any approach which aims at making the trace-centric debugging experience more "confortable".
If your processor has a debugging interface (exposed e.g. over JTAG), you can actually connect a debugger to the simulation and communicate with the processor over the JTAG interface port [1]. This method is extremely powerful, as the debugger provides us with the desired fully-featured source-centric debugging experience. This method is also extremely portable, any RISC-V core with a JTAG debugging interface can reuse the same infrastructure. However, simulating the serial connection on the JTAG interface can significantly slow down the simulation to the point where it becomes unpractical to use. This is especially true when dealing with large and complex designs.
More
