Who are C0, C1 and H in CHI?

CHI is a packet protocol between nodes, not a set of point-to-point buses. Each node has a type; the course actors map onto three of them. Names and rules here are from the AMBA 5 CHI Architecture Specification, Arm IHI 0050, Issue E.a, section 1.6 (component naming).

Four channels, one per message class

The split is the deadlock rule from Message Classes and Virtual Networks: responses must always sink. Each channel has its own link-layer credits (L-Credits, one per flit buffer per hop), so a full REQ queue cannot block a snoop response or CompAck behind it. CHI states the endpoint half of the rule too: section 4.11.1 requires an RN-F to answer snoops promptly with no protocol-layer dependency on the completion of its own outstanding requests. Only REQ has a rejection mechanism, which is what keeps the request class from clogging.

Transaction identifiers

Every request carries SrcID and TgtID for routing and a TxnID that must be unique among that requester's outstanding requests. In Issue E.a TxnID is 12 bits and a requester may have at most 1024 transactions outstanding (section 2.5). The completer can hand back its own identifier, DBID; the requester then uses it as the TxnID of its CompAck or write data, so the home can find its tracker entry without searching. Forwarding snoops also carry FwdNID and FwdTxnID, so the snooped RN-F can address CompData to the original requester with the requester's own TxnID.

Retry: RetryAck and PCrdGrant

Section 2.11 defines request retry. A first attempt is sent with AllowRetry set. A completer that cannot accept it returns RetryAck with a PCrdType and records the requester. When resources free up it sends PCrdGrant, a protocol credit of that type. The requester resends with AllowRetry deasserted and the same PCrdType, and that attempt is guaranteed to be accepted. A PCrdGrant may arrive before the RetryAck it belongs to, so the requester must remember a credit it cannot yet use. This is the reserved-retry remedy for starvation from Retries, NACKs and Credits: the credit, not luck, guarantees the second attempt.

Worked case on the course model: X started at 0 in memory and in no cache. H's trackers are all busy with other lines when C1 reads X.

UC is the CHI name for E: with no other holder, a ReadShared may be answered unique clean, as in the spec's Figures 5-1 and 5-2 (there the data comes straight from SN-F by Direct Memory Transfer (DMT: the memory node sends CompData straight to the requester)). The check below models the requester side, including the early credit.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

def run(events, keep_early_credit=True):
    st = {"pending": True, "retry": False, "credit": None, "accepted": False}
    for ev, arg in events:
        if ev == "RetryAck":
            st["retry"] = True
            if st["credit"] == arg:
                st["accepted"] = True       # resend with AllowRetry=0
        elif ev == "PCrdGrant":
            if st["retry"]:
                st["accepted"] = True
            elif keep_early_credit:
                st["credit"] = arg          # remember it for the RetryAck
    return st["accepted"]

normal = [("RetryAck", 0), ("PCrdGrant", 0)]
early = [("PCrdGrant", 0), ("RetryAck", 0)]
assert run(normal)
assert run(early)
assert not run(early, keep_early_credit=False)   # credit dropped, request starves
assert not run([("RetryAck", 0)])                # no credit yet, must wait
print("PASS: a resend needs a credit, and an early PCrdGrant must be kept")

Related topics

• Shared course model

• Part 5: responses always sink

• Part 4: retries and credits

• Next: CHI walkthroughs