[i3c] Open points in Target top level
Nobody has claimed this yet.
- Dominant language
- SystemVerilog
- Stars
- 3.6k
- Forks
- 1.1k
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 141
Description
**Note**: This list is not complete. To be extended from the `TODO`s in [i3c_target.sv](https://github.com/lowRISC/opentitan/blob/master/hw/ip/i3c/rtl/i3c_target.sv).
### Data Synchronizers (`i3c_sync_data`)
- [ ] The synchronizers which transport data from the system clock domain to the SCL bus clock domain are reset by the transceiver reset signal but rely on toggle-inputs generated in `i3c_target_fsm` for input handshake (data validity signaling). The latter signals are however reset on the main (system) clock reset signal.
This can lead to situations where the synchronizers come out of reset and immediately observe a rogue rising edge on the src side, leading to bogus data propagation toward the SCL domain.
- [ ] The `dst_dataloss_o` port of all synchronizer instances is currently open and unused, so the "Data loss shall be reported" contract in the module header isn't met anywhere yet.
- [ ] There is a postulated contract in `i3c_sync_data` about the `src_toggle` behavior:
"Data loss shall be prevented by the IP domain waiting on the 'src_toggle_o' change before supplying new data and changing 'src_toggle_i' again."
However, this contract can be violated through the `tx_suspended` mechanism in the Target FSM which unconditionally triggers the [`clr` input of the `i3c_dword_splitter`](https://github.com/lowRISC/opentitan/blob/55d8d87832760911cb586512484ff8c6c4eba2f4/hw/ip/i3c/rtl/i3c_target_fsm.sv#L367) which then releases the [`unit_valid`](https://github.com/lowRISC/opentitan/blob/55d8d87832760911cb586512484ff8c6c4eba2f4/hw/ip/i3c/rtl/i3c_target_fsm.sv#L376) signal, thereby affecting the toggle signal towards the synchronizer.
- [ ] Migrate Target-specific definitions into the local packages.
- [ ] Simplify and replace the `i3c_dtype_e` enumeration with something more appropriate to the Target transceiver <-> core signaling; the single type for both Controller and Target turned out to be inappropriate.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the TODOs in hw/ip/i3c/rtl/i3c_target.sv, then read i3c_sync_data and the related logic in i3c_target_fsm.sv, including the i3c_dword_splitter interactions. Determine how reset and toggle handshakes, data-loss reporting, target-specific definitions, and i3c_dtype_e should be resolved; done means the listed open points are addressed and their contracts are satisfied.
Written by the indexing model from the issue text.
Assessment
- Domain
- embedded-iot
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100