Cross-clock domain signal processing--Dedicated handshake signal

In the field of logical design, only a single clock domain is involved in the design of a few. Especially for some complex applications, FPGAs often need to communicate with signals from multiple clock domains. There may be a phase difference between the two clocks involved in an asynchronous clock domain, or there may be no frequency relationship, that is, a different frequency phase that is often said to be different.

Figure 1 is an asynchronous communication instance across a clock domain, with the sending and receiving domains clocks being clk_a and Clk_b, respectively. The two clock frequencies are different and there is a certain phase difference. For the receiving clock domain, the signal data_a2b from the sending clock domain may change at any time.

Figure 1 Cross-clock domain communication

For the above asynchronous clock domain communication, the designer needs to do special processing to ensure the reliable transmission of data. Due to the uncertain frequency relationship of two asynchronous clock domains, the settling time and hold time requirements between the triggers cannot be guaranteed. If there is a settling time or a hold time violation, the receiving domain will be sampled to the metastable data, then the consequences can be imagined.

How to effectively carry out the signal transmission in the cross-clock domain? The most basic idea is synchronization, on the basis of which the designer can communicate using various protocol conventions. one-way control signal detection methods (previously mentioned pulse signal detection method, here in order to be different from the handshake, so called), handshake protocol or by means of memory is a more commonly used processing means.

This article will focus on the handshake mode for asynchronous clock domain communication.

Figure 2 is a basic handshake communication method. The so-called handshake means that both sides of the communication use a special control signal for status indication . This control signal both the sending domain to the receiving domain, and the receiving domain to the sending domain, different from the previous one-way control signal detection method.

Figure 2 Principle of handshake communication

The handshake protocol is used to handle the cross-clock domain data transfer, and only the handshake signals (req and ACK) of both sides are synchronized using pulse detection method respectively . In the implementation, it is assumed that the Req, ACK, and data bus are in an invalid state at initialization, the sending domain first puts the data into the bus, and then sends a valid REQ signal to the receiving domain. The receiving domain latches the data bus after detecting a valid req signal, and then sends back a valid ACK signal to indicate a read complete answer. The sending domain revokes the current req signal after detecting a valid ACK signal, and the receiving domain also revokes the ACK signal when the Req revocation is detected, and a normal handshake communication is completed at this time. Thereafter, the sending domain can continue to start the next handshake communication, so loop. The communication process described above is shown in 3. This method can make the received data stable and reliable, and effectively avoid the occurrence of metastable state, but the control signal handshake will consume more time between the two sides of the communication.

Figure 3 Handshake communication flow

The following is a simple engineering code and its simulation test to further deepen the understanding of basic handshake protocol.

Module Handshack (

Clk,rst_n,

Req,datain,ack,dataout

);

Input CLK; 50MHz system Clock

Input rst_n; Low-Power Reset signal

Input req; Request signal, High level active

INPUT[7:0] DataIn; Input data

Output ack; Response signal, High active

OUTPUT[7:0] dataout;//output data, mainly used to observe whether and input consistent

//--------------------------------------

Req Rising edge Detection

Reg REQR1,REQR2,REQR3;

Always @ (Posedge CLK or Negedge rst_n)

if (!rst_n) begin

REQR1 <= 1 ' B1;

REQR2 <= 1 ' B1;

REQR3 <= 1 ' B1;

End

ELSE begin

REQR1 <= req;

REQR2 <= reqr1;

REQR3 <= reqr2;

End

POS_REQ2 a clock cycle that is longer than pos_req1, ensuring that the data is reliably latched

Wire pos_req1 = reqr1 & ~reqr2; Req Rising edge flag bit, high effective one clock cycle

Wire POS_REQ2 = reqr2 & ~reqr3; Req Rising edge flag bit, high effective one clock cycle

//--------------------------------------

Data latch

REG[7:0] Dataoutr;

Always @ (Posedge CLK or Negedge rst_n)

if (!rst_n) Dataoutr <= 8 ' h00;

else if (pos_req1) Dataoutr <= datain; Latched input data detected when Req is valid

Assign dataout = Dataoutr;

//--------------------------------------

Generate a response signal ACK

Reg Ackr;

Always @ (Posedge CLK or Negedge rst_n)

if (!rst_n) Ackr <= 1 ' b0;

else if (POS_REQ2) Ackr <= 1 ' B1;

else if (!req) Ackr <= 1 ' b0;

Assign ack = Ackr;

Endmodule

The Verilog code of the instance simulates the receiving domain of the handshake communication, as shown in the simulation waveform 4. After the sending domain request signal (req) valid several clock cycles, first the data (DataIn) is effectively locked (dataout), and then the receiving domain's answer signal (ACK) is also in a valid state, then sends the domain to cancel the request signal, the receiving domain also then revokes the reply signal, thus completes one communication.

Figure 4 Handshake Communication Simulation waveform

Cross-clock domain signal processing--Dedicated handshake signal