Specify a DMI port for Debug Modules

[kmeinhar]

I am student that did a research project on open-source implementations of the debugging specification.

What I noticed was that a lacking specification of an interface to the Debug Module resulted in multiple different interfaces that are similar but not compatible with each other.

The Problem:

The specification reads:

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.

And:

The DMI uses between 7 and 32 address bits. It supports read and write operations.

The only mention of signals to and from the Debug Module are in the description of JTAG-DTM. There register dmi specifies the three fields: address, data and op.

The inspected open-source implementations took those three fields as an inspiration for an interface to the Debug Module. This lead to the following interfaces:

Signal Name	PULP	SweRV	SCR1	Rocket Chip	Piccolo	Piccolo JTAG TAP
Request Ready	dmi_req_ready_o	-	-	dmi.req.ready	-	jtagtap.dmi.req_ready
Request Valid	dmi_req_valid_i	dmi_reg_en	dmi_req	dmi.req.valid	-	jtagtap.dmi.req_valid
Request Address	dmi_req_i.addr	dmi_reg_addr	dmi_addr	dmi.req.addr	dm_dmi.read_addr(addr)	jtagtap.dmi.req_addr
Request Data	dmi_req_i.data	dmi_reg_wdata	dmi_wdata	dmi.req.data	dm_dmi.write(addr, data)	jtagtap.dmi.req_data
Request Op	dmi_req_i.op	-	-	dmi.req.op	-	jtagtap.dmi.req_op
Respond Ready	dmi_resp_ready_i	-	-	dmi.resp.ready	-	jtagtap.dmi.rsp_ready
Respond valid	dmi_resp_valid_o	-	dmi_resp	dmi.resp.valid	-	jtagtap.dmi.rsp_valid
Respond Data	dmi_resp_o.data	dmi_reg_rdata	dmi_rdata	dmi.resp.data	dm_dmi.read_data	jtagtap.dmi.rsp_data
Respond Status	dmi_resp_o.resp	-	-	dmi.resp.resp	-	jtagtap.dmi.rsp_response
Reset Signal	dmi_rst_ni	-	-	-	-	-
Write Enable	-	dmi_reg_wr_en	dmi_wr	-	-	-

Benefits of a specified DMI port:

• DTMs can easily reused from other implementations
• The DMI-Bus can be easily swapped out for one that fits better the amount of Debug Moduls

Suggested Improvement:

DMI-Request signals:

• RequestAddress [abits-1:0]
• RequestData [31:0]
• Op[1:0]
• RequestReady
• RequestValid

DMI-Respond signals:

• RespondData [31:0]
• Respons[1:0]
• ResponsReady
• ResponsValid

The survey I have done: SurveyRiscVDebugging.pdf

[timsifive]

DMI is intentionally left unspecified so that people have a lot of flexibility in how to structure their system, and can even reuse their main system bus as DMI if that makes sense. But you raise a good point that in a fairly common case of one DM with one hart directly attached to it, most interface choices between them are arbitrary. It could be helpful for a common implementation in that interface.

I still don't want to add this to the prescriptive part of the specification, since in the end the debugger doesn't care how this happens. But it makes a lot of sense to add a suggested interface to the appendix, to be read in conjunction with the sections that sketch out the possible hardware implementations. If you're interested in writing that up, I'd be happy to work with you to get it in shape to be included.

[kmeinhar]

I am not familiar with your workflow so please correct me if I have done something wrong.

I have created a work in progress pull request #524

This one creates a new section in Appendix B. There a table is given with suggested signals for the DMI.

[jjscheel]

Hi, @kmeinhar, I'd like to chat more with you about this commit. Would you kindly accept my invitation to connect on LinkedIn so we can discuss this contribution more? Thanks!