{"id":10126,"date":"2026-09-02T06:03:28","date_gmt":"2026-09-02T06:03:28","guid":{"rendered":"https:\/\/inskill.in\/training\/?p=10126"},"modified":"2026-09-15T06:06:22","modified_gmt":"2026-09-15T06:06:22","slug":"how-to-design-safe-handshake-logic-between-rtl-modules","status":"publish","type":"post","link":"https:\/\/inskill.in\/training\/vlsi\/how-to-design-safe-handshake-logic-between-rtl-modules\/","title":{"rendered":"How to Design Safe Handshake Logic Between RTL Modules"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Modern RTL designs rarely consist of one block doing everything. A typical SoC or digital system is divided into multiple modules, with each block responsible for a specific operation. One module may generate data, another may process it, and a third may store or forward the result.<\/span><\/p>

The difficult part is not simply connecting these modules with wires. The receiving module may be busy when data arrives, while the transmitting module may not have data available on every clock cycle. Without proper control logic, this can lead to lost data, duplicated transactions, overwritten values, or modules waiting indefinitely for each other.<\/span><\/p>

This is where handshake logic becomes important.<\/span><\/p>

A handshake provides an agreed mechanism for two RTL modules to communicate. The most common approach for synchronous data transfer is the ready-valid handshake, where the source indicates that data is available using <\/span>valid<\/span> and the destination indicates that it can accept the data using <\/span>ready<\/span>. A transfer takes place when both signals are high at the active clock edge.<\/span><\/p>

For some control or clock-domain-crossing applications, a request-acknowledge handshake is more appropriate.<\/span><\/p>

The important point is that a handshake is not just two control signals. It is a protocol with rules that both sides must follow.<\/span><\/p>

Why Is Handshake Logic Needed in RTL?<\/span><\/h3>

Consider two synchronous modules:<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Data<\/span><\/p>

Module A \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba Module B<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Control<\/span><\/p>

\u00a0<\/p>

Module A produces data, while Module B consumes it.<\/span><\/p>

Suppose Module A produces a new value every clock cycle, but Module B needs two cycles to process each value.<\/span><\/p>

If Module A continues sending data without knowing whether Module B can accept it, some values may be overwritten or lost.<\/span><\/p>

A handshake solves this problem by allowing the receiver to apply <\/span>backpressure<\/b>.<\/span><\/p>

The source effectively says:<\/span><\/p>

“I have valid data available.”<\/span><\/p>

The destination responds:<\/span><\/p>

“I am ready to accept it.”<\/span><\/p>

Only when both conditions are true does the transfer occur.<\/span><\/p>

This approach allows independently designed RTL modules to communicate without assuming that both sides operate at exactly the same processing rate.<\/span><\/p>

\u00a0<\/p>

Ready-Valid Handshake: The Most Common RTL Approach<\/span><\/h3>

A basic ready-valid interface contains three signals:<\/span><\/p>

valid<\/span><\/p>

ready<\/span><\/p>

data<\/span><\/p>

\u00a0<\/p>

The source drives <\/span>valid<\/span> and <\/span>data<\/span>.<\/span><\/p>

The destination drives <\/span>ready<\/span>.<\/span><\/p>

The fundamental transfer condition is:<\/span><\/p>

assign transfer = valid && ready;<\/span><\/p>

\u00a0<\/p>

At a rising clock edge:<\/span><\/p>

valid = 0, ready = 0 \u2192 No transfer<\/span><\/p>

valid = 0, ready = 1 \u2192 No transfer<\/span><\/p>

valid = 1, ready = 0 \u2192 No transfer<\/span><\/p>

valid = 1, ready = 1 \u2192 Transfer<\/span><\/p>

\u00a0<\/p>

This behavior is also used extensively in industry-standard streaming interfaces. AMD documentation, for example, defines a valid transfer when <\/span>READY<\/span> and <\/span>VALID<\/span> are asserted at the rising clock edge.<\/span><\/p>

A useful way to remember the protocol is:<\/span><\/p>

VALID means “the source has something to transfer.”<\/span><\/p>

READY means “the destination can accept it.”<\/span><\/p>

VALID && READY means “the transfer happens now.”<\/span><\/p>

\u00a0<\/p>

The Source Must Hold Data When the Receiver Is Not Ready<\/span><\/h3>

One of the most important rules is what happens when:<\/span><\/p>

valid = 1<\/span><\/p>

ready = 0<\/span><\/p>

\u00a0<\/p>

The source cannot assume that the transaction has completed.<\/span><\/p>

Instead, it must keep the transaction available until the destination accepts it.<\/span><\/p>

For example:<\/span><\/p>

always_ff @(posedge clk) begin<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0if (reset) begin<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0valid <= 1’b0;<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0data\u00a0 <= ‘0;<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0end<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0else if (valid && ready) begin<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0valid <= 1’b0;<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0end<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0else if (new_data) begin<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0data\u00a0 <= input_data;<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0valid <= 1’b1;<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0end<\/span><\/p>

end<\/span><\/p>

\u00a0<\/p>

The exact implementation will depend on the surrounding architecture, but the principle is critical:<\/span><\/p>

Once a source presents a valid transaction, it must not change the transaction simply because the destination is temporarily unable to accept it.<\/span><\/p>

Ready\/valid references similarly emphasize that data and <\/span>valid<\/span> must remain stable while the source is waiting for <\/span>ready<\/span>.<\/span><\/p>

This prevents the receiver from sampling one value while the source has already moved to another.<\/span><\/p>

\u00a0<\/p>

A Simple RTL Handshake Example<\/span><\/h3>

Suppose one module sends an 8-bit value to another module.<\/span><\/p>

The interface could be:<\/span><\/p>

module producer (<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0input\u00a0 logic \u00a0 \u00a0 \u00a0 clk,<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0input\u00a0 logic \u00a0 \u00a0 \u00a0 rst_n,<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0input\u00a0 logic \u00a0 \u00a0 \u00a0 start,<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0input\u00a0 logic [7:0] input_data,<\/span><\/p>

\u00a0<\/p>

\u00a0\u00a0\u00a0\u00a0output logic \u00a0 \u00a0 \u00a0 valid,<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0output logic [7:0] data,<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0input\u00a0 logic \u00a0 \u00a0 \u00a0 ready<\/span><\/p>

);<\/span><\/p>

\u00a0<\/p>

The basic transfer event is:<\/span><\/p>

wire transfer;<\/span><\/p>

\u00a0<\/p>

assign transfer = valid && ready;<\/span><\/p>

\u00a0<\/p>

The producer can capture the data and assert <\/span>valid<\/span>:<\/span><\/p>

always_ff @(posedge clk or negedge rst_n) begin<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0if (!rst_n) begin<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0valid <= 1’b0;<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0data\u00a0 <= 8’d0;<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0end<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0else begin<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0if (start && !valid) begin<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0data\u00a0 <= input_data;<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0valid <= 1’b1;<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0end<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0else if (transfer) begin<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0valid <= 1’b0;<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0end<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0end<\/span><\/p>

end<\/span><\/p>

\u00a0<\/p>

The receiving module can indicate that it is able to accept data:<\/span><\/p>

assign ready = !busy;<\/span><\/p>

\u00a0<\/p>

The actual implementation may be more complex, but the fundamental relationship remains the same.<\/span><\/p>

\u00a0<\/p>

Never Make VALID Wait for READY<\/span><\/h3>

One of the most common handshake mistakes is creating a dependency such as:<\/span><\/p>

if (ready)<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0valid = 1’b1;<\/span><\/p>

\u00a0<\/p>

This may appear logical:<\/span><\/p>

“I will only say that I have data when the receiver says it is ready.”<\/span><\/p>

But it can create a deadlock.<\/span><\/p>

Imagine the receiver follows the opposite rule:<\/span><\/p>

“I will assert READY only after I see VALID.”<\/span><\/p>

\u00a0<\/p>

Now:<\/span><\/p>

Source waits for READY<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u2193<\/span><\/p>

Destination waits for VALID<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u2193<\/span><\/p>

Neither signal changes<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u2193<\/span><\/p>

Deadlock<\/span><\/p>

\u00a0<\/p>

The source should therefore be able to assert <\/span>valid<\/span> independently when it has a transaction to send.<\/span><\/p>

The destination can assert <\/span>ready<\/span> independently when it has capacity.<\/span><\/p>

This independence is one of the fundamental rules of a robust ready-valid interface.<\/span><\/p>

\u00a0<\/p>

Avoid Combinational Loops Between Modules<\/span><\/h3>

Another important design problem occurs when <\/span>valid<\/span> and <\/span>ready<\/span> are allowed to depend directly on each other through combinational logic.<\/span><\/p>

For example:<\/span><\/p>

Module A<\/span><\/p>

\u00a0\u00a0VALID \u2500\u2500\u2500\u2500\u2500\u25ba Module B<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u25b2\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u2502<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u2502\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u25bc<\/span><\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u2514\u2500\u2500\u2500\u2500 READY \u2500\u2518<\/span><\/p>

\u00a0<\/p>

If Module A’s <\/span>valid<\/span> depends on Module B’s <\/span>ready<\/span>, while Module B’s <\/span>ready<\/span> depends on Module A’s <\/span>valid<\/span>, a combinational loop can be created.<\/span><\/p>

This can cause:<\/span><\/p>