AXI Handshake Mechanism | VALID & READY

The Two-Person Trade (Analogy)

Think of an AXI handshake like two people, Alice and Bob, trying to trade a book.

VALID (Alice): Alice holds the book out and says, "I am ready to give you this book right now."
READY (Bob): Bob holds his hands out and says, "I am ready to take a book from you right now."

The trade only happens when they are both doing this at the same time. If Alice is holding the book but Bob is looking at his phone (Ready is Low), no trade happens. If Bob has his hands out but Alice hasn't arrived yet (Valid is Low), no trade happens.

The Waiting Game

There are strict rules about how Alice and Bob must behave while waiting:

Rule #1: No Changing Your Mind

Once Alice (the Sender) holds the book out and says VALID, she is legally bound to keep holding it out until Bob takes it. She cannot say "Never mind" and pull her hand back. This ensures Bob doesn't reach for a book that isn't there anymore!

Bob (the Receiver), on the other hand, is allowed to be "fickle." He can put his hands out (Ready) and then pull them back if he gets busy, as long as Alice hasn't provided a book yet.

Handshake Combinations (The Fast Food Counter)

Imagine a fast-food counter. Let's see how different VALID/READY combinations play out:

Scenario	VALID	READY	What Happens?
The Patient Customer	1	0	The customer (Master) has the money ready, but the cashier (Slave) is busy. The customer must wait.
The Eager Cashier	0	1	The cashier is waiting for a customer. No money is exchanged yet because nobody is there.
The Perfect Match	1	1	Handshake! The order is placed instantly. This is the fastest way to move data.

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.

The AXI Handshake