chipsalliance / chipsalliance/tilelink

Tilelink spec query: 9.4. TL-UL and TL-UH Messages on Channel A and D

Open
#5 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
Scala
Stars
42
Forks
10
PR merge metrics
No merged PRs in 30d

Description

Hi,

We have few doubts on Tilleink spec.

**9.4. TL-UL and TL-UH Messages on Channel A and D**

In addition to new messages, TL-C specifies implied permission transfers for these existing messages from TL-UL and TL-UH.

Get implicitly Cap the permissions as None (Invalid).
{PutFullData, PutPartialData, ArithmeticData, LogicalData} implicitly Cap the permissions as not Read+Write [Trunk] or [Tip], i.e. as None [Invalid] or Read [Branch].

From above section of the spec, we understand if a data block is already acquired and the TL-UH command is tried from one Core (i.e. M1) then it affects the permission of the Cache attached to M1.

**Queries**:

1. Suppose we have Acquired a block, then send Get for that block. As per my understanding if a data block is Acquired, with at least with Read permission and assuming this access is not released then that Master/Core should not get Read miss and so should not send Get command further. So in which case this scenario might arise? Please confirm whether my understanding correct?
2. With sending Transfer Access command from Master to Slave, does the permission automatically updated or any additional Probe command needed? Because as specified in spec the permission is capped.
3. Does it impact other Cores as well? If yes how would slave conveys? Does it send Probe command?
4. If we send PutFullData after a Acquire message with Read+Write permission, then the permission can be reduced to None or Read only. How we decide which permission to achieve? Who decides it whether Master or Slave?

Regards,

Asutosh

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with TileLink specification section 9.4 and review the three issue comments for existing context. Address the four permission and Probe-behavior questions, then confirm whether the specification needs clarification or an update; the issue is done when the behavior is documented and maintainer-approved.

Written by the indexing model from the issue text.

Assessment

Domain
distributed-systems, documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.