Question relating to the DTM module

[jesseopdenbrouw]

Hi all.

Using version 1.9.9.1. (Well actually only the DTM module)

I'm trying to figure out how the DMI interface of the DTM is working, so I set up a simulation in Modelsim. I can read the IDCODE and the DTMCS. When I write to the DMI interface, it works as expected but I noticed that after the complete DTM word is written, the DMI operation output (dmi_req_o.op, nop, read or write, write in this case) is only active for 1 system clock cycle, regardless of the dmi_rsp_i.ack signal. Then, is there enough time for the DM to respond to that? I would imagine that the data would be available until dmi_rsp_i.ack is deasserted. I traced it back to line 291 where dmi_ctrl.op is set to dmi_req_nop_c;. So basically: why is the operation only active for one system clock cycle and not until the transfer is acknowledged.

I have placed a screenshot of the modelsim waveforms:

[stnolting]

Hey there!

[...] the DMI operation output (dmi_req_o.op, nop, read or write, write in this case) is only active for 1 system clock cycle, regardless of the dmi_rsp_i.ack signal.

Right. This signal is also used as trigger. Hence, there is no additional "valid" or "strobe" signal required. Whenever dmi_req_o.op is != NOP the DM interprets this as a new command trigger.

After sending this one-shot signal, the DTM enters a wait loop until the DM (via dmi_rsp_i.ack) reports the completion of the read/write operation.

[jesseopdenbrouw]

Ah I see. Is this design or by RISCV spec? I will study the DM later.

Thanks.

[stnolting]

The RISC-V debug spec. suggests some specific interface (see https://github.com/stnolting/neorv32/blob/main/docs/references/riscv-debug-stable.pdf, page 106). However, the NEORV32 debug interface uses a simplified version of that.