Clock Domain Crossings

Design for portability - clock domain crossings
When a signal goes from one clock domain into an other we have what is called a clock domain crossing. To avoid metastability related problems all these signal paths must be designed with care. Problems related to clock domain crossing are seldom observed during simulations. They do show up in real world and hence needs careful attention. There are basically two ways to deal with this:
1. Handshake protocol
2. FIFO

The basic principle behind the handshake protocol is to ensure that signals are latched in the receiving clock domain when they are guaranteed to be stable. More on this later. A FIFO is an elegant way of solving this problem. The FIFO flags will be synchronous to transmitting side (FIFO full) and receiving side (FIFO empty). Such a FIFO can in an FPGA be built with a dual port RAM with different clocks for write respectively read. The drawback with this method is that implementation requires at least one memory resource.

One robust handshake protocol is the toggle protocol. In this protocol we use a change of state of the handshake signal to carry information. Implementation is made in three modules:
1. source clock handshake logic
2. synchronizer
3. destination clock handshake logic

The basic principle behind the handshake protocol is to ensure that signals are latched in the receiving clock domain when they are guaranteed to be stable. More on this later. A FIFO is an elegant way of solving this problem. The FIFO flags will be synchronous to transmitting side (FIFO full) and receiving side (FIFO empty). Such a FIFO can in an FPGA be built with a dual port RAM with different clocks for write respectively read. The drawback with this method is that implementation requires at least one memory resource.

One robust handshake protocol is the toggle protocol. In this protocol we use a change of state of the handshake signal to carry information. Implementation is made in three modules:
1. source clock handshake logic
2. synchronizer
3. destination clock handshake logic

Source clock handshake logic
The source clock side interface has two signals. The first, data_valid, indicates that we want to send data. Actual data signals do not go through any logic but must be held stable until we receive signal ack indicating that receiving sides has successfully latched the signals. The handshake signal will change state when data_valid goes high. The handshake signal is fed forward to the next module.

Synchronizer
The synchronizer is made up with two D-type flip-flops clock with receiving side clock for the handshake signal and two D-type flip-flops clocked with transmitting clock for the ack signal coming from receiving side and travels back to origin.

Destination clock handshake logic
Destination side logic will sense the change of state for the data_valid signal. A capture signal goes high for one clock period enabling latching of data. Capture going high will cause a change of state of ack signal.

This mechanism works for any ratio between transmit and receive clock frequencies.

For robust design two other aspects are worth mentioning.

Reset signals. Each clock domain should have a dedicated reset signal. Release of reset signal should be done in sync with the associated clock to ensure proper startup. For a design with an active low asynchronous reset signal code snippet below could be used:

always @ (posedge clk or negedge rst_n_i)
if (!rst_n_i)
    tmp <= 2'b11;
else
    tmp <= {1'b0,tmp[1]};
assign clk_domain_sync_rst = tmp[0]; //active high clock domain reset

Asynchronous input signals. All asynchronous input signals should be synchronized with dual D-type flip-flops. Failing to do so will cause unpredictable behavour. We do not want that.

Michael Unneb?ck, ORSoC