chipsalliance / chipsalliance/rocket-chip
A possible mismatch?
- Dominant language
- Scala
- Stars
- 3.9k
- Forks
- 1.3k
- Avg merge
- 5d 13m
- Merged PRs (30d)
- 1
Description
https://github.com/chipsalliance/rocket-chip/blob/69d92c2dedbeaeee325f8f2cf1e7388ad7d4645a/src/main/scala/tilelink/AtomicAutomata.scala#LL244C11-L244C66
I am going through `TLAtomicAutomata` module, and feel confused about the loc above. Should that be
`in.d.bits.corrupt := d_cam_corrupt || out.d.bits.corrupt`
Also, I wonder if `TLAtomicAutomata ` supports handling of burst atomic messages? I went through the implementation and had trouble understanding it clearly. According to the code below:
```
when (out.d.fire() && d_first) {//hjr todo why only d_first get cached into r.data?
(d_cam_sel zip cam_d) foreach { case (en, r) =>
when (en && d_ackd) {
r.data := out.d.bits.data
r.denied := out.d.bits.denied
r.corrupt := out.d.bits.corrupt
}
}
(d_cam_sel zip cam_s) foreach { case (en, r) =>
when (en) {
// Note: it is important that this comes AFTER the := GET, so we can go FREE=>GET=>AMO in one cycle --todo
r.state := Mux(d_ackd, AMO, FREE)
}
}
}
```
It seems that only the first beat of an AccessAckData(response to a transformed Get) will be cached into cam_d. Can anybody confirm this?
Thanks.
Contributor guide
Research direction
Start with src/main/scala/tilelink/AtomicAutomata.scala at line 244 and read the TLAtomicAutomata logic around d_cam_corrupt, out.d.bits.corrupt, d_first, and cam_d. Trace how AccessAckData and burst atomic messages move through the module. Done means the suspected corrupt mismatch and first-beat caching behavior are confirmed, with any required change identified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- scala
- Domain
- embedded-iot
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100