olo_ft_cc_status

Back to Entity List

Status Information

VHDL Source: olo_ft_cc_status

Description

This component is a TMR-hardened clock crossing for slowly changing status or configuration information that does not have exact sample rates (e.g. buffer fill levels, counter snapshots or configuration registers). A single-event upset (SEU) on any flip-flop of the crossing is masked: it neither corrupts the transferred data nor stops or disturbs the continuous transfer.

It is the fault-tolerant counterpart of olo_base_cc_status with the same interface and the same behavior. The value at the destination clock domain is always correct in terms of "the exact same value was present on the input clock domain in one clock-cycle". The exact timing of the sampling points at which the data is transferred is generated by the entity itself, so it is unknown to the user. As a result, the entity does not guarantee to show transient states of the data signal in the source clock domain to the destination clock domain in cases of fast changing signals.

For the entity to work correctly, the data-rate must be significantly lower (6 + 2 * SyncStages_g x lower) than the slower clock frequency. Of course the signal can change more quickly but the clock crossing will skip some values in this case.

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

Generics

Name	Type	Default	Description
Width_g	positive	-	Width of the data-signal to clock-cross
SyncStages_g	positive	2	Number of synchronization stages. Range: 2 ... 4

Interfaces

Name	In/Out	Length	Default	Description
In_Clk	in	1	-	Source 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 (synchronous to In_Clk)
Out_Clk	in	1	-	Destination 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 (synchronous to Out_Clk)

Architecture

The architecture follows olo_base_cc_status: a valid pulse (token) is passed around between the two clock domains continuously. Data is transferred from In_Clk to Out_Clk together with the token, and the token is passed back once it arrived in the output clock domain. After reset, the input side generates the first token.

                 In_Clk domain                :          Out_Clk domain
                                              :
In_Data --------------------------------> +---:--------------------+
                                          | olo_ft_cc_simple       |--> Out_Data
Started[A,B,C] -> vote --+                |   (data + token)       |
                         v                |   :                    |
            +--> VldIn[A,B,C] -> vote --> +---:--------------------+
            |                                 :            |
            |                                 :            | token arrived
          VldFb <---- olo_ft_private_cc_toggle <-----------+

• Token generation (In_Clk): Started and VldIn are triplicated registers with voters. VldIn issues the first token after reset (while Started is still low) and then forwards every token that comes back.
• Forward path: olo_ft_cc_simple transfers the data together with the token. It also contains the reset crossing.
• Feedback path: the token is passed back with 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_status.

Fault Tolerance

Protection Concept

The token-passing scheme is particularly sensitive to upsets: in an unprotected implementation a single upset of the token state can either lose the token (the output is never updated again until the next reset) or duplicate it (two tokens circulate and the data-rate assumption of the forward crossing no longer holds). Therefore all token state is protected:

State	Clock domain	Protection
Started, VldIn	In_Clk	Three copies with voter, next value computed from the voted values
Forward data and valid	both	olo_ft_cc_simple
Feedback toggle synchronizer	both	olo_ft_private_cc_toggle
Reset crossing	both	olo_ft_cc_reset (inside olo_ft_cc_simple)

Because the status crossing re-transfers the data with every token, the output data is refreshed continuously.

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. If such a double fault loses the token, the crossing stops updating 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_status 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.