Trace Debugger for custom RISC-V Core
Debugging is a fundamental part of software development. It furthermore aids in bringing up silicon quickly and makes a software developer's life a lot easier. In smaller processors like the ones developed at IIS we rely on an external debugger for this purpose.
External, in-contrast to self-hosted, debugging relies on a more powerful host machine attached to the target device. They communicate via a standardized interface like SPI or JTAG with a proprietorial protocol.
This external debugging comes with one major disadvantage: it is very slow. But sometimes it is required to debug at full speed to see certain effects (e.g.: if the environment has a certain impact). Moreover external debug solutions are obtrusive in the sense that they do not resemble the actual execution flow but break it into smaller pieces like halting the CPU and flushing certain data-structures.
That is where trace debugging comes into play: A trace debugger observes certain events (like interrupts, branch decisions, load and store effective addresses or simply a trace of all program counters) at full speed and stores those events on a fast on-chip memory. The slow external debug interface can then read this memory and re-construct the execution trace.
The difficulty in developing a trace debugger relies on the fact that it should not have any impact on the maximum achievable clock speed of the processor. Another challenge in designing a trace debugger is the fact that on-chip RAM is expensive. For that reason a suitable (loss-less) compression scheme is viable. The trace can then be re-constructed on the more powerful host machine out of the compressed data.
This thesis consists of three parts:
- Evaluation of existing trace debuggers and their implementation (for example see the RISC-V Debug Specification ).
- Specification, RTL design and host software development of a trace debugger for one of our custom RISC-V processors.
- FPGA evaluation of your implementation.
If time permits and you interested in manufacturing your own ASIC this project is suitable to do so. In any case your successful design will help dozens of software and hardware developer around the world who are using our cores in their designs.
- 15% Literature Research
- 50% RTL Design
- 20% FPGA Design
- 105% Software Design
- Looking for Interested Students
- Supervision: Florian Zaruba, Germain Haugou (email@example.com)
- Preliminary knowledge in one HDL (hardware description language) of your choice (for example VHDL or (System)-Verilog) as thought in VLSI I and II
- Basic knowledge of computer architecture/processor design as thought in the Energy-Efficient Parallel Computing Systems for Data Analytics class (formerly known as Advanced System on a Chip)
Meetings & Presentations
The students and advisor(s) agree on weekly meetings to discuss all relevant decisions and decide on how to proceed. Of course, additional meetings can be organized to address urgent issues.
Around the middle of the project there is a design review, where senior members of the lab review your work (bring all the relevant information, such as prelim. specifications, block diagrams, synthesis reports, testing strategy, ...) to make sure everything is on track and decide whether further support is necessary. They also make the definite decision on whether the chip is actually manufactured (no reason to worry, if the project is on track) and whether more chip area, a different package, ... is provided. For more details confer to .
At the end of the project, you have to present/defend your work during a 15 min. presentation and 5 min. of discussion as part of the IIS colloquium.