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 :doc:`message_fields`. Global signals -------------- .. list-table:: :header-rows: 1 :widths: 15 12 15 58 * - 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) ----------------------------- .. list-table:: :header-rows: 1 :widths: 15 12 15 58 * - 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 :doc:`message_fields`). * - ``a_src_id`` - ``ID_W`` - Core - Requester (core) identifier. * - ``a_txn_id`` - ``TXN_W`` - Core - Transaction identifier (see :ref:`txn-id-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) ----------------------------- .. list-table:: :header-rows: 1 :widths: 15 12 15 58 * - 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 :doc:`message_fields`). * - ``b_dst_id`` - ``ID_W`` - CM - Destination (core) identifier. * - ``b_txn_id`` - ``TXN_W`` - CM - Transaction identifier (see :ref:`txn-id-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. .. list-table:: :header-rows: 1 :widths: 20 80 :class: rules-table * - 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). .. mermaid:: 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: .. list-table:: :header-rows: 1 :widths: 20 80 :class: rules-table * - 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 :doc:`races_ordering`). * - ``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.