lowRISC / lowRISC/opentitan

[usbdpi] Introduce fault reporting

Open
#17,259 2 comments 0 reactions 1 assignee View on GitHub

@alees24 is already working on this.

Since Feb 9, 2023.

Component:DV Earlgrey-PROD Candidate IP:usbdev Priority:P3
Dominant language
SystemVerilog
Stars
3.6k
Forks
1.1k
Avg merge
2d 22h
Merged PRs (30d)
141

Description

### Description

In many places the DPI model (now) catches unexpected data/timing/behavior in the USB traffic to/from usbdev but does not cease operation and indicate failure. In a few places it still has assertions that are not directed purely at catching faults in its internal logic.

Any fault that may be induced by traffic on the USB, rather than being purely an internal failure, shall be signalled to the test, such that the software on the simulated Ibex CPU may terminate the test with a failure status in the normal manner. This mechanism is yet to be decided, and a couple of approaches may be required, but perhaps a vendor-specific control transfer to endpoint zero may be used to return the test status, fault code and ASCII text description (including file/line within usbdpi), at least for higher-level faults.

It is suggested that perhaps a bus reset to the device to force it, and more importantly the usb_testutils software, into a known state before transmitting the control sequence, may be a good way to ensure that this mechanism is more robust, since this is clearly a fairly high-level operation, requiring the USB itself to be functioning.

> estimate 8

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.