Other components on the DMI

[nipo]

I'm wondering about future-proofness of DTM and DM. DTM is a bridge to DMI. DMI is itself a memory bus on which we expose one or many DMs.

DMI is - to me - the root of the debug infrastructure: It sets a 32-bit memory bus with at least 7 address bits as the common factor between DTM and DMs. Defining address space to be at least 7 bit is a great feature, as it gives seamless growth of DMI for more complex implementations, but with no cost for constrained ones.

In spec, there is provision for bridging DMI from something else than a JTAG TAP, but there is no provision for mapping other components than DMs on the DMI bus.

Some day, silicon vendors may need to attach some target-dependant controllers on the debug infrastructure. They would logically do this on DMI bus.

In current MCU market, we can find this kind of controllers to perform some generic platform management like mass-erase, reset control or clock setup. Such examples include (not a complete list, by far):

• Nordic's Ctrl-AP,
• NXP's MDM-AP,
• RP2's Rescue-DP.

These used to be available through the main memory bus, but vendors evolved to this kind of model because they all wanted to be able to disable debug bridges totally.

If we try to translate this to RV world, this kind of controllers would go belongside DMs on DMI, and we should expect vendors to disable some DMs. As DMI is a memory bus, this would be easy to disable some ports of an interconnect. But if we do so, we'll loose access to nextdm on disabled DMs.

An infrastructure with multiple components mapped on DMI, and allowing DM disablement would only be practical if:

• we are able to tell there is actually a DM or something else at a given base address (for now, we assume everything is DM, and we only have a version field).
• we are able to walk through DMs even if some of them are disabled (try to dereference nextdm).

I would suggest:

• to add an identification register in every DM, that would allow to have other components one the DMI,
• to add a new component type with a list of children components (i.e. multiple nextdm-like fields). This would allow to have some DMs disabled and still be able to discover the rest of the components by putting non-permanent DMs as leaves of the tree.

Maybe this second component could also contain target platform identification. See #735.

[timsifive]

Supporting multiple kinds of modules on the DMI bus was definitely intended. We haven't used registers 0--3 in the DM, so those would be natural places to put an ID and a more general "next pointer."

I hadn't considered that you might want to put a device on the DMI bus and then have it so completely shut down that it wouldn't even be able to provide a "next pointer." Adding a module that contains a list of base offsets that a debugger can check to see what's there seems reasonable. Potentially this is also a configuration structure thing.

[nipo]

I had a feeling about offset 0-3, indeed. Now I really think describing DMI address space in CS makes a cyclic dependency.

Thanks for feedback.