Analysis of cross clock transmission in tinyriscv

I am a Snow fish , a FPGA lovers , The research direction is FPGA Architecture exploration .

Official account , Pull you in “IC Design communication group ”.

I wrote this blog at the invitation of a friend , Explain tinyriscv Cross clock domain transmission in .
The resolved code path ：

• tinyriscv\rtl\utils\full_handshake_rx
• tinyriscv\rtl\utils\full_handshake_tx

One 、full_handshake_rx

1.1 Input and output signals

Let's look at the interface first , The compiled schematic diagram is as follows ：

On the left is the input signal , On the right is the output signal .

Signal name	Direction	effect
clk	input	Clock signal
rst_n	input	Reset signal
req_i	input	TX End request signal
req_data_i	input	TX Input data at the end
ack_o	output	RX Terminal response TX Terminal signal
recv_data_o	output	RX The data received by the terminal
recv_rdy_o	output	RX Whether the terminal receives the data signal

1.2 Code logic

Look at the code first ：

The classic three segment state machine , I have marked it with a red box , A three-stage state machine is a machine that will

• The transfer of state
• The generation of substates
• Generation of output results

Three are placed in three always Block , The advantage is clear logic , Fast , The disadvantage is that it takes up a lot of hardware resources .

This state machine , There are only two states , One is STATE_IDLE, One is STATE_DEASSERT.
After initial reset, it is in STATE_IDLE state , here

• When the request signal req = 1 when , Will be taken from STATE_IDLE The state shifts to STATE_DEASSERT state , And receive the data sent by the sender , And feedback the response signal .

So only in STATE_IDLE Status and req = 1 when , The receiving end can effectively receive data and respond .

There is another one in the code always block , It synchronizes the signal by taking two beats .

Two 、full_handshake_tx

2.1 Input and output signals

Let's look at the interface first , The compiled schematic diagram is as follows ：

On the left is the input signal , On the right is the output signal .

Signal name	Direction	effect
clk	input	Clock signal
rst_n	input	Reset signal
ack_i	input	RX End response signal
req_data_i	input	TX Data to be sent at the end , Just keep it up for one clock
req_i	input	TX End request signal , Just keep it up for one clock
idle_o	output	TX Whether the terminal is idle , Data can only be sent when idle
req_o	output	TX End request signal
req_data_o	output	TX Data to be sent at the end

2.2 Code logic

Look at the code first ：

The same classic three-stage state machine .

This state machine , There are three states ：

• STATE_IDLE
• STATE_ASSERT
• STATE_DEASSERT

After initial reset, it is in STATE_IDLE state , here

• When the request signal req = 1 when , Will be taken from STATE_IDLE The state shifts to STATE_ASSERT state , And lock the data to be sent , And make a request to send data .

So only in STATE_IDLE Status and req = 1 when , The sending end can effectively send data and request the lower level rx Receiving data at the terminal .

3、 ... and 、 Cross clock domain transmission summary

First of all, you need to know why you need to synchronize across clock domains , stay tinyriscv Debug module for jtag_top in , Two sub modules are implemented , Namely jtag_dm and jtag_driver, jtag_driver Realized JTAG TAP and DMI, Used to send according to the external debugger JTAG The signal came right DM Access operation . Here the problem arises , This access operation is based on JTAG TCK Signal generation ,tinyriscv The author is set to 1MHz, and jtag_dm The clock signal of is the system clock 50MHz, Accessing when the clock is out of sync is an error in most cases , Or the transmission data is wrong , Or the control signal is wrong when the data is correct , It should be well understood .

adopt full_handshake_tx and full_handshake_rx To realize that data is transmitted only when handshaking , Ensure the stability and correctness of data transmission .
In two modules with different clock domains , Both modules are added , Such as jtag_driver adopt full_handshake_tx Send data to jtag_dm
that jtag_dm adopt full_handshake_rx To receive data , Re pass full_handshake_tx Send feedback back to jtag_driver,jtag_driver adopt full_handshake_rx receive ,over. So this is Full handshake protocol , Complete orientation dm Write data and reply back will shake hands four times . As shown in the figure below ,tx And rx A request or response to a is a handshake , That is, an arrow in the figure represents a handshake , Four times in all .