Home › AMBA › AXI › AXI Handshake

The AXI Handshake

The core mechanism of flow control in AXI. Every channel uses the VALID/READY handshake to transfer information.

The Golden Rule

A transfer occurs ONLY when both VALID and READY are High on the same rising clock edge.

  • Case 1: Source provides Valid. Destination is busy (Ready Low). Transition occurs when Ready goes High.
  • Case 2: Destination is Ready. Source is busy (Valid Low). Transition occurs when Valid goes High.
  • Case 3: Both assert simultaneously. Transfer happens immediately.

    • Assertion Rules

    Critical Restriction

    Once VALID is asserted, it MUST remain asserted until the handshake occurs (Ready comes High). The Source CANNOT deassert VALID just because Ready is Low.

    However, READY can toggle. The Destination can assert Ready before Valid arrives, or wait for Valid to arrive.

    Deadlock Prevention & Verification

    To prevent deadlocks, the Protocol specifies dependency rules:

    • VALID cannot depend on READY: A Source must not wait for Ready to be High before asserting Valid.
    • READY can depend on VALID: A Destination IS allowed to wait for Valid before asserting Ready (though asserting Ready early is better for performance).
    // GOOD:
assign VALID = data_available; // Purely internal logic
assign READY = buffer_not_full; 
// BAD (Deadlock Risk):
assign VALID = data_available && READY; // Depends on Ready!
    Verification Insight: Deadlocks often happen at Clock Domain Crossings (CDC). If an asynchronous FIFO logic incorrectly waits for a space (Ready) from the Destination clock domain before asserting Valid in the Source domain, the bridge will hang.

    Always use Protocol Checkers to catch these violations. A good checker will trigger an error if it sees READY waiting for VALID across multiple channels in a loop.

    Simulation Failure: The "Polite" Master Bug

    A common novice mistake is writing a Master Driver that tries to be "safe" by checking READINESS before sending data.

    The Buggy Code (DO NOT USE)
    // Buggy Driver Logic
// Waits for Slave to be Ready first
if (vif.READY == 1'b1) begin
    vif.VALID <= 1'b1;  // Too polite!
    vif.DATA  <= req.data;
end

    The Failure Mode:

    • Scenario A (Fast Slave): Slave asserts READY by default. The driver sees it, asserts VALID. Transfer happens. (Bug is masked)
    • Scenario B (Power-Saving Slave): Slave waits for VALID to wake up. Master waits for READY. Result: Deadlock. Both signals stay low forever.

    Common Interview Questions

    Q: Can the Master wait for AWREADY before asserting AWVALID?
    No. This is a protocol violation. The Master must be able to assert AWVALID solely based on its own availability of an address. If it waits for READY, and the Slave is waiting for VALID (which it is allowed to do), the system will deadlock.
    Previous The 5 Channels of AXI Next Atomic Transactions (Exclusive Access)