Ready/Valid Protocol Primer

Aside Regarding Component Names

Phil Karlton once said "there are only two hard things in Computer Science: cache invalidation and naming things." The book Microarchitecture of Network-on-Chip Routers uses the terms "sender" and receiver". The AMBA Specification uses the terms "source" and "destination", or "master" and "slave". I have seen other documents use terms such as "producer" and "consumer", and so on.

I have arbitrarily chosen the names "Transmitter" and "Receiver" because

• they are unambiguous - one transmits data, the other receives it
• they are commonly used in digital signal processing (DSP)
• they both have the same number of syllables
• I like the "Tx" and "Rx" abbreviations

Link State

Since there are two control bits, the link can be in four possible states. We will name those states according to the following table.

According to the AMBA Specification, section A.3.2.1, there are two rules governing ready/valid behavior:

• A transmitter is not permitted to wait until READY is asserted before asserting VALID.
• Once VALID is asserted it must remain asserted until the handshake occurs, at a rising clock edge at which VALID and READY are both asserted.

The first rule is a performance requirement. To achieve full bandwidth on the link, the ready and valid signals must be independent.

The second rule places a restriction on exiting the Wait for Ready state. Once the transmitter has valid data, it is illegal to renege on the transfer. It must wait until the receiver is ready for it.

AMBA does not restrict whether the ready signal is allowed to assert and later deassert without a handshake. However, some implementations may desire this extra level of strictness. For example, a FIFO is "ready" when it has a slot available. If it ever deasserted its ready signal without a data push, that would be a serious error that we need to uncover. I will refer to this extra strict version of the protocol as the "stable ready" requirement.

Figure 2 shows the legal state transitions.

For the less strict version of the protocol with no stable ready requirement, we can effectively merge the Idle and Wait for Valid states, marked in red.

For the more strict version of the protocol with stable ready requirement, we can remove the arrows marked in red. Both of the Wait for ... states may only transition to Transfer state.

We will formalize these rules a little later with SystemVerilog assertions.

Link Signal Timing

Figure 3 shows a timing diagram of three data words being transferred. The style of the waveform mimics debuggers such as Verdi and Simvision. Signals are driven immediately after the clock edge with no visible delay. The upward arrows on the clock signal indicate clock edges when data transfer events occur.

For convenience, the follow table summarizes the events:

Aside Regarding Waveform Perspective

When analyzing logical protocols that are implemented using real-world, analog technologies such as wires and transistors, we need to draw the waveform diagram with appropriate propagation delays. Unfortunately, there is no standard frame of reference for the link.

Figure 4 shows a more realistic representation of Figure 3, but from the perspective of the Transmitter. Notice that the ready signal arrives late.

Figure 5 shows a similarly realistic representation of Figure 3, but this time from the perspective of the Receiver. Notice that the valid/data signals arrive late.

These diagrams help visualize important implementation details. For example, the designer of the Transmitter should avoid adding significant logic to the ready input, because it might violate the setup time.

In addition, considering the handshake signal propagation delays can clarify their meaning. When the Receiver drives ready=1 onto the wire, it does not yet know whether the Transmitter will send data. In plain English, it sends the message: "if you transmit data on this cycle, I am ready for it". Similarly, when the Transmitter drives valid=1 onto the wire, it sends the message: "if you are ready, I will transmit this data to you". Both the ready and valid signals contain propositional logic that can only be satisfied after the signal propagation delay.

Always Check for Xes on Control Signals

Interface control signals should never be unknown (i.e. "X", not in \(\{0, 1\}\)). Also, whenever valid=1 is asserted, its corresponding data should never have have unknown bits. Never underestimate the amount of problems your team will discover by writing X checks to catch uninitialized state.

Using the FIFO module ports from above, with "write" and "read" ready/valid interfaces, the code for this is straightforward:

/*** Transmit (Tx) ***/
// Ready must never be unknown
`ASSUME(RV_Tx_NeverReadyUnknown,
    !$isunknown(read_ready),
    clock, reset)

// Valid/Data must never be unknown
`ASSERT(RV_Tx_NeverValidUnknown,
    !$isunknown(read_valid),
    clock, reset)
`ASSERT(RV_Tx_NeverDataUnknown,
    read_valid |-> !$isunknown(read_data),
    clock, reset)

/*** Receive (Rx) ***/
// Ready must never be unknown
`ASSERT(RV_Rx_NeverReadyUnknown,
    !$isunknown(write_ready),
    clock, reset)

// Valid/Data must never be unknown
`ASSUME(RV_Rx_NeverValidUnknown,
    !$isunknown(write_valid),
    clock, reset)
`ASSUME(RV_Rx_NeverDataUnknown,
    write_valid |-> !$isunknown(write_data),
    clock, reset)

Note that the SystemVerilog $isunknown system task will return 1 if any bits of the input are unknown.

Protocol Violations

Using Figure 2 as a reference, the Transmitter or Receiver commit a protocol violation whenever they cause an invalid state transition on the link. When the link is in "Wait for Ready" state, the Transmitter may not deassert valid on the next cycle. For the strict protocol with stable ready requirement, when the link is in "Wait for Valid" state, the Receiver may not deassert ready on the next cycle. Finally, the Transmitter may not put new data onto the link until after the current data has been successfully transferred.

For the less strict protocol with no stable ready requirement, do NOT use the assumptions/assertions with *_ReadyStable suffix.

/*** Transmit (Tx) ***/
// Ready must remain stable until Valid/Data
// Note: Optional
`ASSUME(RV_Tx_ReadyStable,
    (read_ready && !read_valid) |=> read_ready,
    clock, reset)

// Valid/Data must remain stable until Ready
`ASSERT(RV_Tx_ValidDataStable,
    (!read_ready && read_valid) |=> (read_valid && $stable(read_data)),
    clock, reset)

/*** Receive (Rx) ***/
// Ready must remain stable until Valid/Data
// Note: Optional
`ASSERT(RV_Rx_ReadyStable,
    (write_ready && !write_valid) |=> write_ready,
    clock, reset)

// Valid/Data must remain stable until Ready
`ASSUME(RV_Rx_ValidDataStable,
    (!write_ready && write_valid) |=> (write_valid && $stable(write_data)),
    clock, reset)

A full explanation of SystemVerilog Assertions (SVA) is beyond the scope of this primer, but let's take a closer look at the RV_Tx_ValidDataStable code. The statement X |=> Y means: "If X is true on this clock cycle, then check that Y is true on the next clock cycle". The $stable(X) statement means: "The value of X on this clock cycle is the same as it was on the previous clock cycle." Putting it all together, in plain English the assertions means: "If the link is in Wait for Ready state on this clock cycle, then both valid/data must stay the same on the next clock cycle".

Cover Properties

After we spend the time to write a thorough test suite, coverage collection will help verify that the tests are exercising all the desired functionality.

First, we want to cover data transfers. If no data transfers have occurred on the interface, we have not actually tested anything.

The following code increments a coverage counter whenever the links are in the "Transfer" state.

// Cover data transfer
`COVER(RV_Tx_Transfer, read_ready && read_valid, clock, reset)
`COVER(RV_Rx_Transfer, write_ready && write_valid, clock, reset)

Another important cover property is "backpressure". When downstream components are blocking new data from being received, they are said to "backpressure" the upstream components. Without going into a full discussion of queueing fundamentals, it is important to exercise backpressure on all components in order to verify that storage buffers are adequately sized.

The following code increments a coverage counter whenever the links are in the "Wait for Valid" (backpressure) state:

// Cover backpressure
`COVER(RV_Tx_Backpressure, !read_ready && read_valid, clock, reset)
`COVER(RV_Rx_Backpressure, !write_ready && write_valid, clock, reset)

Checker Component Methodology

In the previous sections, we have defined several assumptions, assertions, and coverpoints. Good coding practice suggests we group these related items together in a container.

SystemVerilog provides a design element called a "checker" for this purpose, but I do not recommend using it. Not only are checkers not parameterizable, but they are not supported by EDA tools nearly as well as modules. Keep it simple, and just use a module for a reusable checker container.

In addition to a type parameter for the data inputs, we should have parameters for the following:

• Selectively enable transmitter and receiver checks.
• Selectively enable the strict ready stable requirement.

For example:

module CheckReadyValid #(
    parameter type T = logic [7:0]
    parameter bit Tx = 1'b0,
    parameter bit TxReadyStable = 1'b0,
    parameter bit Rx = 1'b0,
    parameter bit RxReadyStable = 1'b0
) (
    input logic ready,
    input logic valid,
    input T     data,

    input logic clock,
    input logic reset
);

// Check either Tx or Rx interface, not both (or neither)
if (Tx == Rx) begin
    $fatal(1, "Expected Tx != Rx, got Tx=%0d Rx=%0d", Tx, Rx);
end

if (Tx) begin : gen_tx_checks
    `ASSUME(NeverReadyUnknown, !$isunknown(read_ready), clock, reset)
    `ASSERT(NeverValidUnknown, !$isunknown(read_valid), clock, reset)
    `ASSERT(NeverDataUnknown,
        read_valid |-> !$isunknown(read_data),
        clock, reset)
    if (TxReadyStable) begin : gen_ready_stable
        `ASSUME(ReadyStable,
            (read_ready && !read_valid) |=> read_ready,
            clock, reset)
    end : gen_ready_stable
    `ASSERT(ValidDataStable,
        (!read_ready && read_valid) |=> (read_valid && $stable(read_data)),
        clock, reset)
    `COVER(Transfer, read_ready && read_valid, clock, reset)
    `COVER(Backpressure, !read_ready && read_valid, clock, reset)
end : gen_tx_checks

if (Rx) begin : gen_rx_checks
    `ASSERT(NeverReadyUnknown, !$isunknown(write_ready), clock, reset)
    `ASSUME(NeverValidUnknown, !$isunknown(write_valid), clock, reset)
    `ASSUME(NeverDataUnknown,
        write_valid |-> !$isunknown(write_data),
        clock, reset)
    if (RxReadyStable) begin : gen_ready_stable
        `ASSERT(ReadyStable,
            (write_ready && !write_valid) |=> write_ready,
            clock, reset)
    end : gen_ready_stable
    `ASSUME(ValidDataStable,
        (!write_ready && write_valid) |=> (write_valid && $stable(write_data)),
        clock, reset)
    `COVER(Transfer, write_ready && write_valid, clock, reset)
    `COVER(Backpressure, !write_ready && write_valid, clock, reset)
end : gen_rx_checks

endmodule : CheckReadyValid