Signal Descriptions and Flow Control

This chapter defines the signal-level transport of a PicoLink link. One link connects one core to the Coherency Manager and carries both channels. Each channel uses an independent valid/ready handshake, one message per transfer (no multi-beat bursts: the data bus is a full cache line wide).

All signals are synchronous to the rising edge of clk and are qualified by the active-low reset rst_n.

Parameter names below (ADDR_W, DATA_W, ID_W, TXN_W) are defined in Message Field Definitions.

Global signals

Signal	Width	Driven by	Description
`clk`	1	System	Link clock. All signals are sampled on the rising edge.
`rst_n`	1	System	Asynchronous-assert, synchronous-deassert active-low reset.

A channel signals (Core → CM)

Signal	Width	Driven by	Description
`a_valid`	1	Core	Asserted when the core presents a valid A-channel message.
`a_ready`	1	CM	Asserted when the CM can accept an A-channel message this cycle.
`a_opcode`	4	Core	Message opcode (see Message Field Definitions).
`a_src_id`	`ID_W`	Core	Requester (core) identifier.
`a_txn_id`	`TXN_W`	Core	Transaction identifier (see Transaction identifier rules).
`a_addr`	`ADDR_W`	Core	Cache-line address (line-aligned; carries no offset bits).
`a_data`	`DATA_W`	Core	Full-line write data. Meaningful only when `a_opcode` is `WriteBack`; otherwise ignored by the CM.

B channel signals (CM → Core)

Signal	Width	Driven by	Description
`b_valid`	1	CM	Asserted when the CM presents a valid B-channel message.
`b_ready`	1	Core	Asserted when the core can accept a B-channel message this cycle.
`b_opcode`	4	CM	Message opcode (see Message Field Definitions).
`b_dst_id`	`ID_W`	CM	Destination (core) identifier.
`b_txn_id`	`TXN_W`	CM	Transaction identifier (see Transaction identifier rules).
`b_addr`	`ADDR_W`	CM	Cache-line address (line-aligned; carries no offset bits).
`b_data`	`DATA_W`	CM	Full-line read data. Meaningful only when `b_opcode` is `GrantS` or `GrantE`; otherwise ignored by the core.

Handshake rules

A transfer occurs on a channel on any rising clk edge at which both valid and ready are asserted. The rules below apply independently to each channel; *_valid denotes the channel’s valid, *_ready its ready, and payload denotes all other signals of that channel.

Rule	Requirement
`PL-SIG-01`	Once `_valid` is asserted, it shall remain asserted and the payload shall remain stable until the transfer completes (`_valid && *_ready`). A message, once offered, cannot be retracted or altered.
`PL-SIG-02`	The sender shall not wait for `_ready` to be asserted before asserting `_valid`. (No combinational or sequential dependence of `valid` on `ready`; this prevents handshake deadlock.)
`PL-SIG-03`	The receiver may assert `_ready` before, together with, or after `_valid`, and may deassert `_ready` at any time while `_valid` is low. Receivers should default `*_ready` high when able to accept, to minimize latency.
`PL-SIG-04`	Payload signals carrying no information for the current opcode (e.g. `a_data` on `ReadShared`) may take any value and shall be ignored by the receiver. Verification IP may drive zero and check stability, but shall not flag their value as an error.
`PL-SIG-05`	While `rst_n` is deasserted (low), `a_valid` and `b_valid` shall be driven low. The first assertion of a `valid` shall occur no earlier than the first rising `clk` edge after `rst_n` is asserted (high).

        sequenceDiagram
    participant S as Sender
    participant R as Receiver
    Note over S,R: Cycle n:   valid=1, ready=0 → payload held stable
    Note over S,R: Cycle n+1: valid=1, ready=1 → transfer occurs
    Note over S,R: Cycle n+2: sender may present a new message or idle

Flow-control and dependency rules

The two channels are independent at the transport level, but protocol-level responses create cross-channel dependencies (e.g. the CM withholds GrantM until it has received InvAck on channel A). To keep such dependency chains acyclic, message acceptance must never depend on the opposite channel:

Rule	Requirement
`PL-DEP-01`	A core shall not make assertion of `b_ready` dependent on the progress or completion of any of its outstanding A-channel messages. In particular, a core shall accept and process `Invalidate` while it has requests outstanding, including for the same line (see Ordering, Races, and Atomicity).
`PL-DEP-02`	The CM shall not make assertion of `a_ready` dependent on the acceptance of any B-channel message. In particular, the CM shall continue to accept `InvAck` and `WriteBack` messages while its B channel is stalled.
`PL-DEP-03`	A receiver may deassert `ready` for a bounded number of cycles for capacity reasons, but shall not withhold `ready` indefinitely while `valid` is asserted.

Together with the bounded number of outstanding transactions (PL-CHAN-02), rules PL-DEP-01 through PL-DEP-03 guarantee the link is deadlock-free: channel A messages sink unconditionally at the CM, channel B messages sink unconditionally at the core, and every protocol dependency chain (request → invalidation → acknowledgment → grant) therefore terminates.