Welcome to SiliconNotes!

Almost everyone working in the Hardware Design and Verification space has likely heard of the AXI Protocol. Admittedly, it is one of the more challenging topics to learn on top of all the other simulation flows, microarchitecture overviews, etc. But if I were to start learning the protocol today, I would begin with the valid/ready handshake, followed by one of the most commonly asked interview questions.

The Valid/Ready Handshake

The valid/ready handshake is one of the standard handshaking protocol which also forms the fundamental concept which needs to be understood when learning the AXI Protocol.

The handshake mechanism is simple: the manager component (or the requester) initiates the transfer by asserting the valid signal along with any payload data that needs to be sent to the subordinate (or the completer). The completer then asserts the ready signal whenever it has the resources available to accept the payload.

One of the main constraints on the valid/ready interface is that the requester must hold the valid signal and the payload stable until the ready signal is asserted by the completer. This means that on the cycle the valid signal is asserted, the requester must also present the payload to be transferred and wait for the transaction to complete until ready is asserted. The completer does not need to wait for the valid signal to be asserted and is free to assert ready whenever it has the resources to accept the incoming request.

However, in certain cases the resources needed to complete the transfer might be part of the payload itself. In such cases, the completer would need to wait for the requester to assert the valid signal along with the payload before asserting ready. The ready signal being dependent on the valid assertion is an allowed scenario however, the valid signal must never be dependent on the ready signal and should be asserted regardless of the ready signal’s state.

The above seemingly simple constraints play a big role in how the corresponding hardware communicates using the valid ready protocol.

The above scenario is quite common when designing valid/ready-based interfaces. Adding a pipeline stage on the ready signal is a simple solution however, it breaks the valid/ready protocol.

Skid Buffers

The issue with inserting a flop on the ready signal is that it alters the cycle at which the ready signal is observed by the requester and the completer. The completer asserts the ready signal and accepts the payload in the same cycle, while the requester holds the valid and payload signals for an additional cycle, as it samples the ready signal a cycle later.

This misalignment can introduce more bugs in the valid/ready protocol, as seen in the waveform below:

In the above waveform, the signals in yellow are the requester side of signals (usually called the ingress side) and the signals in orange are the completer side of signals (called the egress side). With the ready getting asserted a cycle before (signal: e_ready_i) the ready on the ingress side is seen a cycle later (signal: i_ready_o). This leads to an incorrect transfer on the requester side which ultimately leads to a missed (or a dropped) transaction on the completer's end and also a protocol violation where the valid on the completer side gets de-asserted without a ready.

How are these bugs avoided? Well, Skid Buffers are the answer. The skid buffer basically breaks the path on the ready signal without disrupting the valid/ready protocol. As the name suggests it buffers the transactions between the ingress and egress ports without dropping any data or breaking the protocol rules.

How are Skid Buffers designed?

If you want to learn more about Skid Buffer and their implementation, I recommend checking out this problem from my Hands-on RTL Design course, where I discuss this problem in detail along with the RTL implementation of the Skid Buffers with waveform analysis.

Well, that's it for this edition of the SiliconNotes.

Have a great week!
Rahul