Target identification and discovery

[nipo]

I've been implementing JTAG-DTM and DM lately, and have been wondering about automatic target identification and discovery methods. I skimmed through public discussions I could find around DM, DTM and DMI and did not find this point discussed. Maybe I missed it. If so, please point me to relevant documents.

For now, entry point is JTAG TAP, which has an IDCODE register. This is the only target identification we have, but:

• Per IEEE-1149.1, IDCODE is optional,
• Not everybody is a JEDEC member with a legit JEP106 manufacturer ID (this is particularly relevant with FPGA implementations where the chip may never be produced as an ASIC -- we already have examples of this on github where some RV32 implementations feature JTAG-DTMs with non-allocated IDCODEs),
• Many chips will have a TAP that only features DTM (no BSCAN), implementors be tempted to reuse TAP IDCODEs across chips,
• it is dependant on the fact we have JTAG as DTM (we may have other DTMs later, which may not feature identification registers with the same structure).

Let's take an example in an existing infrastructure that has been quite successful: ARM Cortex. In CoreSight world, there is a full hierarchy of components, each one with its identification registers (See DDI0314H for details):

• Entry point is DP (JTAG or SWD), it has an IDCODE, it designates ARM DP implementation (not the target SoC),
• DP bridges to one or many APs, each AP has an identification register (IDR), it designates ARM (or other) AP type,
• Mem-APs (AXI-AP, AHB-AP) have a ROM Address register, giving a pointer to a tree of ROM Table descriptors,
• Root of the ROM Table contains an ID Code specific to the target (i.e. the actual SoC),
• ROM tables describe all the components available through the debugger infrastructure, including vendor-specific components.

This allows complete blind enumeration of the target, which is a very appreciable. One drawback of this model, though, is target identification relies on access to the main memory bus, which may be disabled by memory protection features.

I would suggest adding a method for identifying target at the DMI level, but before the main memory bus. Moreover, with increasing availability of softcores, I would suggest not relying on JEP106 IDs for namespacing. Something like a 128-bit UUID would totally eliminate the need for a central registry.

[timsifive]

Currently, if a JTAG debugger knows that it's talking to a RISC-V target, it can discover just about everything that it needs to know. There are some details about the system (like what kinds of triggers are supported) that are hard to discover. We hope to use https://github.com/riscv/configuration-structure/blob/master/riscv-configuration-structure-draft.adoc for that. (This has the same memory access drawback as you describe. I'd be open to adding some DM functionality that provides access to the structure.) If there are other details that are important, stuffing them into the configuration structure generally feels like a good solution.

[nipo]

For trace and debug, of course, we can reasonably assume access to main memory as a prerequisite to CS. Most things described in CS will require accessing DM anyway.

Let me rephrase my point:

I think we should be able to identify the target platform before enabling any DM, but we don't require any details at the level of CS.

Yet, I think we should not rely on IDCODEs from TAP because:

• JTAG is not the only DTM that will ever exist,
• There is no guarantee other DTM will feature IDCODEs with the same semantics / allocation policy,
• JEP106 ID codes (manufacturer IDs used in JTAG) are nearly exhausted (JEP106BE has allocated up to 0xd/0x39 out of 0xf/0x7f: only 324 IDs left). IIRC there is idea of making continuation modulo 16. If this happens, JTAG IDCODEs may collide. From a debugger perspective, I expect some (not so) "fun" to handle there.

What to do then ?

Bluetooth, for instance, managed to mix between standard-allocated numbers and non-allocated, freely-generated IDs by using UUIDs everywhere (allocated numbers derive from a "base" UUID, but this is an implementation detail, actually). This is quite nice as it avoids need for central allocation. Hence the proposition for an UUID.

Something like 128-bit vendor UUID (totally freely generated), and 32-bit (or more) vendor-allocated ID for chip / version would solve those needs with no chance of running out of IDs.

[timsifive]

I'm not sure what the action item here is. If someone wants to propose a new, better, discovery mechanism, then we can talk about that.