[[sec:future]]
== Future Ideas

*All items in this section are future ideas and should not be considered
part of the specification.*

Some future version of this spec may implement some of the following
features.

. The spec defines several additions to the Device Tree which enable a
debugger to discover hart IDs and supported triggers for all the harts
in the system.
. DTMs can function as general bus subordinates, so they would look like
regular RAM to bus managers.
. Harts can be divided into groups. All the harts in the same group can
be halted/run/stepped simultaneously. When a hart hits a breakpoint, all
the other harts in the same group also halt within a few clock cycles.
. DTMs are specified for protocols like USB, I2C, SPI, and SWD.
. The debugger can communicate with the power manager to power cores up
or down, and to query their status.
. Serial ports can raise an interrupt when a send/receive queue becomes
full/empty.
. The debug interrupt can be masked by running code. If the interrupt is
asserted, then deasserted, and then asserted again the debug interrupt
happens anyway. This mechanism can be used to e.g. read/write memory
with minimal interruption, making sure never to interrupt during a
critical piece of code.
. The Debug Module can include a serial interface for re-using the DTM
interface as a generic communication interface.

=== Serial Ports

The Debug Module may implement up to 8 serial ports. They support basic
flow control and full duplex data transfer between a component and the
debugger, essentially allowing the Debug Transport to be used to
communicate with a debug monitor running on a hart, or more generally
emulate devices which aren’t present. All these uses require software
support, and are not further specified here. Only the DMI side of the
Debug Module serial registers are defined in this specification as the
core side interface should look like a peripheral device.
