[tlul] Agree on spec mismatches, document them, and align DV
- Dominant language
- SystemVerilog
- Stars
- 3.6k
- Forks
- 1.1k
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 141
Description
While working on https://github.com/lowRISC/opentitan/pull/30902 and studying https://github.com/lowRISC/opentitan/pull/22588, I noted that some of our tlul modules don't actually follow the TLUL specification. In particular, the spec defines in Section 4.1:
> "Note that a sender may raise valid and then lower it on the following cycle, even if the message was not accepted on the previous cycle."
Some of our device-side modules don't follow this. E.g. tlul_adapter_sram.sv currently expects the A channel signals to remain stable for at least two clock cycles or until a_ready is observed.
The good thing is that our TL-UL hosts (at least Ibex) are well behaved in the sense that they always wait for the a_ready before changing the A channel signals. However, DV often does the right thing and verifies blocks against the TLUL spec, but then we tune the TLUL host agent to avoid the failure case:
https://github.com/lowRISC/opentitan/blob/377160a7ea64bf6b187127db5f2bc6819b7ff196/hw/ip/sram_ctrl/dv/env/seq_lib/sram_ctrl_base_vseq.sv#L77-L79
I think we should do the following:
1. Define what we our device-side modules should support.
2. Document that in our bus specification: https://opentitan.org/book/hw/ip/tlul/
3. Align the DV accordingly and enforce this with SVAs.
Because our hosts are currently well behaved, this may not be the most urgent thing. However, we risk to complicate verification and coverage closure thereby wasting resources if we don't document and align things.
Contributor guide
Assessment
This issue has not been assessed yet.