Clarify JTAG IDCODE requirement in an SOC

[steven-bellock]

From issue : chipsalliance/Cores-VeeR-EL2#146.

When DTM is implemented in an SOC with multiple RISC-V processors and multiple TAP controllers, what are the requirements for IDCODE? For example suppose an SOC has a topology of

• TAP
  • Top Level TAP Controller (IDCODE = NVIDIA)
    • Second Level TAP Controller 1
      • RISC-V Processor
    • Second Level TAP Controller 2
      • RISC-V Processor

My expectation is that either

1. The second level TAP controllers do not support IDCODE.
2. The RISC-V Debug specification defines some generic IDCODE value for the second level TAP controllers.

In my experience IDCODE is only used to identify chips on a PCB. Once the chip is identified then its BSDL or ICL file can be retrieved that specifies the internal layout of the JTAG chain.

[algrobman]

In my experience IDCODE is only used to identify chips on a PCB. Once the chip is identified then its BSDL or ICL file can be retrieved that specifies the internal layout of the JTAG chain.

many JTAG based debuggers use ID code for detecting CPU features to tune debugger operation .

[timsifive]

You appear to be using some kind of cJTAG topology. The Debug Spec does not define what happens in cJTAG at all.

Having said that, I would expect every TAP to still implement IDCODE, even the ones behind a top-level controller. It makes it easier for debuggers to do discovery, and I don't see a downside.

[steven-bellock]

You appear to be using some kind of cJTAG topology.

The above topology is achievable through 1149.1.

The Debug Spec does not define what happens in cJTAG at all.

Can this be restated as

The Debug Spec assumes there is one TAP controller connected to one RISC-V processor.

?

and I don't see a downside.

The RISC-V Debug specification states, regarding ManufId,:

Identifies the designer/manufacturer of this part. Bits 6:0 must be bits 6:0 of the designer/manufacturer’s Identification Code as assigned by JEDEC Standard JEP106.

In particular there will be RISC-V processors designed by entities who do not have a JEDEC manufacturer code, for example universities. In such a case their processor would not conform to the specification.

But ultimately I think if

The Debug Spec assumes there is one TAP controller connected to one RISC-V processor.

is true then that solves the issue at hand. Ie, it's fine to remove IDCODE from the second level TAP controllers, since they are outside of the specification.

[pdonahue-ventana]

The Debug Spec assumes there is one TAP controller connected to one RISC-V processor.

I'm not sure what your definition of "processor" is. I don't think that you intend processor=SoC since the DTM would presumably be part of the SoC and not "connected to" the SoC. I'm assuming that you intend either processor=core or processor=hart in which case the statement is not true. A JTAG DTM is defined to be connected to a single DMI which is connected to an arbitrary number of DMs, each of which can be connected to up to 1048576 harts.

[steven-bellock]

I don't think that you intend processor=SoC

Correct. These are independent RISC-V processor cores integrated into a single SOC.

A JTAG DTM is defined to be connected to a single DMI which is connected to an arbitrary number of DMs, each of which can be connected to up to 1048576 harts.

Thanks for the clarification. This also provides a solution for the issue at hand. Ie, if a RISC-V processor core is to be integrated into an SOC then it should expose an interface as a Debug Module. The SOC Integrator uses its single DTM / DMI to allow debugging of, possibly, multiple RISC-V processor cores.

[algrobman]

BTW, multithreaded EH2 implements with one DM manages 2 harts .. By extending address field of JTAG DTM dmi register multiple DMs can be connected to one JTAG DTM if DMs implement nextdm register. (not implemented in EL2)

[steven-bellock]

Thanks for the clarifications. Closing now.