MicroBlaze V features a debug interface to support software debugging tools (commonly known as background debug mode (BDM) debuggers) such as the AMD Vitis™ System Debugger tool.
The debug interface is designed to be connected to the MicroBlaze Debug Module (MDM) V core, which interfaces with the JTAG port of AMD Adaptive Computing FPGAs or with a memory-mapped AXI4-Lite interface.
The debug functionality is implemented according to the definition in RISC-V External Debug Support, Version 1.0, and is compatible with any third-party tools following this standard.
Multiple MicroBlaze V processors can be interfaced with a single MDM V core to enable multiprocessor debugging. Each processor represents a single RISC-V hardware thread (hart).
To download programs, set software breakpoints and disassemble code, ensure that the instruction and data memory ranges overlap, and use the same physical memory.
Debug registers are accessed using the debug interface, and are not
directly visible to software running on the processor. The debug interface can either
use JTAG serial access or AXI4-Lite parallel access,
controlled by the parameter C_DEBUG_INTERFACE.
See the MicroBlaze Debug Module V (MDM V) LogiCORE IP Product Guide (PG428) for a detailed description of the MDM V features.
The debugging features enabled by setting C_DEBUG_ENABLED to 1 include:
- A configurable number of hardware triggers and unlimited software breakpoints, which can be configured to halt the processor or cause a breakpoint exception
- External control that enables debug tools to stop, reset, and single step the processor
- Ability to read from and write to: memory, general purpose registers, floating-point registers, and control and status registers
- Configurable number of debug program buffers to select performance or area optimized implementation
- Support for multiple processors (RISC-V harts)
- Configurable number of hardware performance counters (event and latency counters)
- RISC-V N-Trace based program trace with configurable embedded trace buffer size
- RISC-V N-Trace based external trace with Trace Funnel and Trace PIB sink provided by the MDM V
- Non-intrusive profiling support with configurable profiling buffer size
- Cross trigger support between multiple processors (RISC-V harts), and external trigger inputs and outputs provided by the MDM V, using the RISC-V Halt Groups, Resume Groups, and External Triggers functionality.
When the debugger attempts to stop the processor with a halt request and the processor is waiting for an ongoing LMB, AXI4, or AXI4-Stream access to complete, the access is forced to complete after 8192 clock cycles. This ensures that the debugger can always stop the processor. Read accesses update the destination register with the current interface data value in this case.
Trace and Profiling Register Access
Both program trace and non-intrusive profiling registers are memory-mapped, and can be accessed through either of two interfaces:
- The Debug Interface with access from MDM V, using the RISC-V
System Bus.
In this case, MDM V determines the System Bus base address for each connected processor, with the first processor starting at 0x8000, the second at 0x10000, and so on, giving each processor a 32 KB area. With external trace, the MDM V uses the first 32 KB area for the Trace Funnel and Trace PIB Sink registers.
- The Slave AXI Interface (S_AXI) with access from any AXI4 Master, but normally from the MDM V AXI4 master port, using the RISC-V System
Bus.
In this case, the base address is assigned in the AMD Vivado™ Block Design, typically to 0x44A00000 with automatic address assignment. It is recommended to set the base addresses for subsequent processors in a multiprocessor design to 0x44A08000, and so on, to give each processor a 32 KB area.
To use the Debug Interface, the Slave AXI Interface cannot be enabled, and the Embedded Trace Interface must be selected in the MDM V.
It is recommended to use the Debug Interface, which requires no additional connections between the MDM V and the processor, unless the MDM V AXI4 master port is used for memory access.
Secure Debug
Secure debug lets you configure Physical Memory Protection entries that
inhibit debugging. Each bit in the C_PMP_DEBUG_INHIBIT parameter defines whether a particular entry
inhibits debugging. You must also set the Dbg_Inhibit input signal to activate secure debug. This signal must
not be changed while the processor is executing.
- The processor delays halt until it reaches an instruction outside the region, then performs a normal halt.
- An
EBREAKinstruction inside the region does not enter debug mode, even when the matchingdcsrbit (ebreakm,ebreaks, orebreaku) is set for the current privilege mode. - The processor ignores an address-match trigger inside the region when the trigger Action (
A) bit requests entry to debug mode. - The processor does not increment the Instructions-retired counter inside the region.
- The processor does not increment Hardware Performance Monitor counters inside the region, except when software configures event class 2, 3, or 5.
- If software executes a debug-mode abstract command that performs a load or store to an address inside the region, the processor raises exception (5) and does not perform the access.
- The processor does not perform reset-mode debug halt.