8 RISC-V External Debug Support Version 0.13.2
3.1 Debug Module Interface (DMI)
Debug Modules are slaves to a bus called the Debug Module Interface (DMI). The master of the
bus is the Debug Transport Module(s). The Debug Module Interface can be a trivial bus with
one master and one slave, or use a more full-featured bus like TileLink or the AMBA Advanced
Peripheral Bus. The details are left to the system designer.
The DMI uses between 7 and 32 address bits. It supports read and write operations. The bottom
of the address space is used for the first (and usually only) DM. Extra space can be used for custom
debug devices, other cores, additional DMs, etc. If there are additional DMs on this DMI, the base
address of the next DM in the DMI address space is given in nextdm.
The Debug Module is controlled via register accesses to its DMI address space.
3.2 Reset Control
The Debug Module controls a global reset signal, ndmreset (non-debug module reset), which can
reset, or hold in reset, every component in the platform, except for the Debug Module and Debug
Transport Modules. Exactly what is affected by this reset is implementation dependent, as long
as it is possible to debug programs from the first instruction executed. The Debug Module’s own
state and registers should only be reset at power-up and while dmactive in dmcontrol is 0. The
halt state of harts should be maintained across system reset provided that dmactive is 1, although
trigger CSRs may be cleared.
Due to clock and power domain crossing issues, it may not be possible to perform arbitrary DMI
accesses across system reset. While ndmreset or any external reset is asserted, the only supported
DM operation is accessing dmcontrol. The behavior of other accesses is undefined.
There is no requirement on the duration of the assertion of ndmreset. The implementation must
ensure that a write of ndmreset to 1 followed by a write of ndmreset to 0 triggers system reset. The
system may take an arbitrarily long time to come out of reset, as reported by allunavail, anyunavail.
Individual harts (or several at once) can be reset by selecting them, setting and then clearing
hartreset. In this case an implementation may reset more harts than just the ones that are selected.
The debugger can discover which other harts are reset (if any) by selecting them and checking
anyhavereset and allhavereset.
When harts have been reset, they must set a sticky havereset state bit. The conceptual havereset
state bits can be read for selected harts in anyhavereset and allhavereset in dmstatus. These bits
must be set regardless of the cause of the reset. The havereset bits for the selected harts can be
cleared by writing 1 to ackhavereset in dmcontrol. The havereset bits may or may not be cleared
when dmactive is low.
When a hart comes out of reset and haltreq or resethaltreq are set, the hart will immediately enter
Debug Mode. Otherwise it will execute normally.
我的内容管理
展开
