[rv_dm,dv] Verify that a failed DMI op is reflected properly in dtmcs register (`jtag_dmi_failed_op` BLT)

[andreaskurth]

This issue tracks the implementation of the jtag_dmi_failed_op block-level test, which is specified in the testplan for rv_dm.

estimate 8

[andreaskurth]

Triaged for rv_dm. Assigning to M2.5 with https://github.com/lowRISC/opentitan/labels/Priority%3AP2 because this is an open V2 test.

[GregAC]

This failure case cannot occur in current design, we should document this somewhere and double check and review RTL to ensure it's not possible (or potentially utilise formal to check).

[msfschaffner]

@rswarbrick @jdonjdon need to figure out with impare whether this is part of the RV_DM testplan already (and hence addressed).

[jdonjdon]

@rswarbrick @jdonjdon need to figure out with impare whether this is part of the RV_DM testplan already (and hence addressed).

As @GregAC pointed out, this is not achievable in the current rtl structure. I think we should remove this from the testplan.

[andreaskurth]

@rswarbrick: Bringing this to your attention as M4 coordinator of rv_dm; the suggestion is that this testplan item should be removed and this issue closed

[rswarbrick]

I've just chatted with Greg about the logic behind why this isn't possible. Probably the best thing will be to give a detailed "proof" of it in a comment and drop the test accordingly. I propose leaving this issue open until the test gets dropped, but I'm going to change the expected effort down to 1 day (how hard can it be?!)

[moidx]

Carried over to M5 for resolution.

[rswarbrick]

When working on this in M5: the assertion that this can't happen was wrong.

The testpoint is rather badly written, but it's really talking about making sure we can handle busy response to a DMI command. I think we can probably reproduce it with something like the following (not yet implemented!)

            Verify that a failed DMI op is reflected properly in dtmcs register.

            - Perform a DMI write to the command register, requesting an abstract command which
              reads register zero.

            - Without writing to the HALTED CSR (to allow abstract command to complete), write to
              the dmi register a second time. This time, read a register that should not be
              accessible while the abstract command is running: one of the abstract data registers
              (data0..data11).

            - This should result in a "busy" error, which should have been visible in the JTAG
              transaction that we just performed. Check it is also visible in the dtmcs register.

            - Clear the error by writing to the dmireset bit in the dtmcs register.

            - Now write to the HALTED CSR, causing the abstract command to complete.

            - Perform a JTAG read of the abstractcs register and check that we are no longer busy.

            - This should signal the completion of the abstract command. Check that it made the
              expected change by reading the WHERETO register over TL-UL. It should now point at the
              first instruction of an abstract command.

[rswarbrick]

Bumping up to P1 because it's required for V2 signoff. I suspect that my description above was overly complicated and we can probably do something easier (and I stand by my 1 day effort estimate!)