Coherency Manager (CM) Behavior

The Coherency Manager is the single serialization point of the protocol: the order in which it processes A-channel messages for a given cache line is the global coherence order of that line.

Directory state

The CM maintains a directory entry per cache line that may be cached. Each entry tracks:

Field	Contents
State	The line’s state from the CM’s perspective: I (uncached), S (one or more sharers), E (one exclusive owner, clean when granted), or M (one owner known to be dirty — reached only via GrantM).
Sharers	Bitmask of cores holding the line (meaningful in S).
Owner	Core ID of the exclusive owner (meaningful in E and M).

Rule	Requirement
PL-CM-01 (E means E-or-M)	Because the E → M transition is silent (PL-MESI-04), a directory entry in E describes an owner that may hold the line in either E or M. The CM shall therefore be prepared for either response to an Invalidate sent to an E owner: InvAck (owner was still E) or WriteBack (owner had silently become M). A WriteBack received in this window shall be committed to memory before the line is granted onward.
PL-CM-02 (stale sharers)	Because clean evictions are silent (PL-MESI-04), the directory’s sharer set and owner are over-approximations: a listed core may have already dropped the line. The CM shall nonetheless send Invalidate to every listed holder and shall accept InvAck from a core that no longer holds the line (PL-MESI-06). The directory never under-approximates: a core is never granted a line without being recorded.

Serialization and concurrency

Rule	Requirement
PL-CM-03	The CM shall process messages for the same cache line one transaction at a time: while a transaction for a line is in progress (e.g. awaiting invalidation acknowledgments or memory), subsequent requests for that line shall be queued or stalled, not interleaved. The single exception is the Nack resolution of a racing Upgrade (rule PL-RACE-01), which denies rather than serves the loser.
PL-CM-04	Transactions for different cache lines may be processed concurrently and may complete in any order. There is no cross-line ordering guarantee.
PL-CM-05	Queued requests for a line shall be served in arrival order. When two requests for the same line arrive in the same cycle from different cores, the CM shall arbitrate deterministically; the reference implementation selects the lower core index first.

Response behavior

The table gives the required CM behavior for each A-channel message against each directory state. “Invalidate holders” always means: send Invalidate to every recorded holder except the requester, collect one InvAck or WriteBack per holder (PL-CM-01), and commit any received WriteBack payload to memory before proceeding.

Request	Directory state	Required CM behavior
ReadShared	I (uncached)	Fetch from memory; respond GrantE (recommended, requester is sole holder — PL-CHAN-06) or GrantS. Record requester.
ReadShared	S	Fetch from memory; respond GrantS; add requester to sharers.
ReadShared	E (owner ≠ requester)	Invalidate the owner; await InvAck or WriteBack (PL-CM-01); commit any writeback; fetch from memory; respond GrantE (recommended — requester is now sole holder) or GrantS.
ReadShared	M (owner ≠ requester)	Invalidate the owner; await the forced WriteBack; respond WriteBackAck to the owner; commit to memory; fetch; respond GrantE (permitted — sole holder) or GrantS to the requester.
ReadExclusive	I	Fetch from memory; respond GrantE. Record requester as owner.
ReadExclusive	S	Invalidate all sharers; await all InvAcks; fetch from memory; respond GrantE.
ReadExclusive	E (owner ≠ requester)	Invalidate the owner; await InvAck or WriteBack (PL-CM-01); commit any writeback; fetch; respond GrantE.
ReadExclusive	M (owner ≠ requester)	Invalidate the owner; await the forced WriteBack; respond WriteBackAck; commit; fetch; respond GrantE.
Upgrade	S, requester is the sole recorded sharer	Respond GrantM immediately. Directory → M, owner = requester.
Upgrade	S, other sharers recorded	Invalidate all other sharers; await all InvAcks; respond GrantM. Directory → M.
Upgrade	Requester not a recorded holder (stale Upgrade — the requester was invalidated while the Upgrade was in flight)	Respond Nack (rule PL-RACE-03). The requester retries as ReadExclusive.
WriteBack	Voluntary (no Invalidate outstanding to this core for this address — PL-TXN-05)	Commit payload to memory; respond WriteBackAck; remove the core from the directory (→ I if it was the sole holder).
WriteBack	Forced (Invalidate outstanding — PL-TXN-05)	Commit payload to memory; respond WriteBackAck; count it as the implicit InvAck of the outstanding Invalidate (PL-CHAN-05); resume the stalled transaction.
InvAck	—	Bookkeeping only: retire the matching Invalidate (by txn_id — PL-TXN-04), remove the core from the directory, and resume the stalled transaction when all acknowledgments are in. No B-channel response.

Grant ordering rules

Rule	Requirement
PL-CM-06	The CM shall not issue GrantM, or a GrantS/ GrantE for a line that required invalidations, until every Invalidate issued for that transaction has been acknowledged (InvAck or forced WriteBack) and any writeback payload has been committed to memory. Granting early would break the single-writer invariant PL-MESI-01.
PL-CM-07	When resolving an Upgrade race, the CM shall send the losing core its Invalidate before its Nack on the same B channel. Per-channel FIFO ordering (PL-ORD-01) then guarantees the loser observes the invalidation before the denial, so a Nack is only ever received for a line already relinquished.

Memory interaction

Rule	Requirement
PL-CM-08	Memory shall contain only clean data. Every WriteBack payload shall be committed to memory before any subsequent grant of the same line, and grant data shall always be sourced from memory (no cache-to-cache forwarding).

• The commit-then-refetch sequence shown in Message Sequence Diagrams is the reference behavior. An implementation may satisfy the refetch from an internal buffer holding the just-committed data, provided the data returned equals what memory now holds.

Permitted optimizations

The following are explicitly permitted, provided all rules above hold:

• Overlapping the memory fetch with the invalidation phase of the same transaction (the fetch may start early; the grant must still wait for all acknowledgments per PL-CM-06).

• Responding GrantS where GrantE is recommended (PL-CHAN-06); the exclusive-grant optimization is a performance feature, not a correctness requirement.

• Concurrent processing of any number of transactions to distinct lines (PL-CM-04).

Forward progress

Rule	Requirement
PL-PROG-01	Every request other than Upgrade shall eventually be served (PL-CHAN-04 forbids denying them). An Upgrade either completes with GrantM or is denied with Nack; the prescribed retry is ReadExclusive, which cannot be denied. A core therefore completes any intended write in at most two requests — PicoLink has no livelock under the Nack mechanism.
PL-PROG-02	The CM shall not depend on a core spontaneously issuing WriteBack: dirty data is reclaimed on demand via Invalidate. Conversely, a core awaiting WriteBackAck is guaranteed a response by PL-CHAN-08.