olo_ft_cc_handshake¶

Status Information¶

Description¶

This component is a TMR-hardened clock crossing with AXI-S handshaking for transferring data from one clock domain to another one that runs at a potentially completely asynchronous clock. A single-event upset (SEU) on any flip-flop of the crossing is masked: it neither corrupts, loses nor duplicates data and it does not lock up the handshake.

It is the fault-tolerant counterpart of olo_base_cc_handshake with the same interface and the same behavior. It implements full AXI-S handshaking but is not made for high performance. It can transfer one data-word every (2 + SyncStages_g) x InputClockPeriods + (2 + SyncStages_g) x OutputClockPeriods.

For high data rates, use the ECC-protected olo_ft_fifo_async instead. olo_ft_cc_handshake is meant for low-rate transfers such as control and status words, where it needs no RAM.

This block follows the general clock-crossing principles. Read through them for more information.

Generics¶

Name	Type	Default	Description
Width_g	positive	-	Data width in bits.
ReadyRstState_g	std_logic	'1'	Controls the status of the In_Ready signal in during reset. Choose '1' for minimal logic on the (often timing-critical) In_Ready path.
SyncStages_g	positive	2	Number of synchronization stages. Range: 2 ... 4

Interfaces¶

Input Data¶

Name	In/Out	Length	Default	Description
In_Clk	in	1	-	Input clock
In_RstIn	in	1	'0'	Reset input (high-active, synchronous to In_Clk)
In_RstOut	out	1	N/A	Reset output (see clock-crossing principles, synchronous to In_Clk)
In_Data	in	Width_g	-	Input data
In_Valid	in	1	'1'	AXI4-Stream handshaking signal for In_Data
In_Ready	out	1	N/A	AXI4-Stream handshaking signal for In_Data

Output Data¶

Name	In/Out	Length	Default	Description
Out_Clk	in	1	-	Output clock
Out_RstIn	in	1	'0'	Reset input (high-active, synchronous to Out_Clk)
Out_RstOut	out	1	N/A	Reset output (see clock-crossing principles, synchronous to Out_Clk)
Out_Data	out	Width_g	N/A	Output data
Out_Valid	out	1	N/A	AXI4-Stream handshaking signal for Out_Data
Out_Ready	in	1	'1'	AXI4-Stream handshaking signal for Out_Data

Architecture¶

The architecture follows olo_base_cc_handshake: a request (InTransaction) is passed from the source domain to the destination domain together with the data, and an acknowledge (OutAck) is passed back once the data was accepted. The input logic only accepts new data after the acknowledge was received. On the output side, the data is held (OutLatched) until Out_Ready accepts it.

                   In_Clk domain               :           Out_Clk domain
                                               :
In_Data  ---------------------------------> +--:-------------------+
                                            | olo_ft_cc_simple     |--> Out_Data
In_Valid --> InTransaction ---------------> |  (data + request)    |--> OutTransaction --+
               ^                            +--:-------------------+                     |
               |                               :                                         v
In_Ready <-- InLatched[A,B,C] -> vote          :      Out_Valid <-- OutLatched[A,B,C] -> vote
               ^                               :                                         |
               | InAck                         :                                         | OutAck
               +------------ olo_ft_private_cc_toggle <----------------------------------+

Input side (In_Clk): InLatched is a triplicated register with voter. It is set when a word is accepted and cleared by the acknowledge. When neither happens, every copy reloads the voted value.
Forward path: olo_ft_cc_simple transfers the data together with the request. It also contains the reset crossing.
Output side (Out_Clk): OutLatched is a triplicated register with voter that holds the valid state while Out_Ready is low. The data itself is held by the output registers of olo_ft_cc_simple.
Acknowledge path: olo_ft_private_cc_toggle, the TMR toggle synchronizer that is also used inside olo_ft_cc_simple. It uses the already crossed resets, so no second reset crossing is required.

The latency in clock cycles is identical to olo_base_cc_handshake.

Fault Tolerance¶

Protection Concept¶

The request/acknowledge scheme is sensitive to upsets: in an unprotected implementation a single upset of the handshake state can drop or duplicate a word, or lock the handshake up (the input side waits for an acknowledge that never comes). Therefore all handshake state is protected:

State	Clock domain	Protection
InLatched	In_Clk	Three copies, voted hold (an upset copy is repaired at the next edge)
Forward data and request	both	olo_ft_cc_simple
OutLatched	Out_Clk	Three copies, voted hold (an upset copy is repaired at the next edge)
Acknowledge toggle synchronizer	both	olo_ft_private_cc_toggle
Reset crossing	both	olo_ft_cc_reset (inside olo_ft_cc_simple)

Limitations¶

TMR masks one upset per register and clock cycle. Two upsets in different copies of the same register within one clock cycle are not masked. Depending on the register, such a double fault can drop or duplicate a word or lock up the handshake until the next reset.
The voters and the combinational logic are not triplicated (same fault model as for the other olo_ft_cc\<...>_ entities).
See olo_ft_cc_simple for the protection scope of the reset crossing.

Synthesis Attributes¶

The same attributes as in olo_ft_cc_simple are used to disable vendor TMR insertion and to prevent the synthesis tool from merging the TMR copies.

Constraints¶

The same constraints as for olo_base_cc_handshake apply, see clock-crossing principles.

Note that the scoped constraints for automatic constraining in AMD Vivado are only provided for the olo_base clock crossings. Constrain the clock crossings of olo_ft entities manually.