HotRIO master rx

This module receives HotRIO packets from the PCS and checks the parity bits. The module outputs the received packet (separated into address, payload and sideband) and several event detection flags.

As a master receiver, it accepts packets from any address, so that the master node may process the answers received from all slave nodes in the chain.

The module supports two clock architecture options: single-clock synchronous and CTC. The first is selected by setting ctc_g = false, the second by setting ctc_g = true.

If the logic is driven by a single clock, it must be synchronous with all input signals. The output signals produced will be synchronous to the same clock. With a typical PCS configuration, this means that HotRIO packets will be received in the domain of the channel-based RX clock of the PCS module.

If CTC is used, the hotrio_ctc module performs a clock domain crossing from the clock used to receive the PCS data to the one used to transmit it. The hotrio_slave state machine is still fully included in a single clock domain, that of clk_i. When operating in this mode, clk_rx_i must provide the receiver clock to the module.

Detailed portlist

Generics

Name	Description	Type	Default
ctc_g	set to true if retrieved data is used in a different 125 mhz clock domain from that of the cdr	boolean	false

Input signals

IN ports

Name	Description	Type
clk_i	system clock of the design	std_logic
clk_rx_i	cdr clock from pcs if ctc_g = true, otherwise leave at default	std_logic := '0'
rstn_i	active low reset, synchronous to `clk_i`	std_logic
pcs_data_i	byte from pcs	std_logic_vector(7 downto 0)
pcs_kchar_i	special character flag from pcs	std_logic

Output signals

OUT ports

Name	Description	Type
hotrio_address_o	address of the last received hotrio packet	std_logic_vector(7 downto 0)
hotrio_payload_o	payload of the last received hotrio packet	std_logic_vector(79 downto 0)
hotrio_sideband_o	sideband bits of the last received hotrio packet	std_logic_vector(5 downto 0)
time_o	64-bit utc timestamp retrieved during the past four microseconds. valid when `pulse_4us_o` is high	std_logic_vector(63 downto 0)
pulse_4us_o	high for one cycle once every 4 us, when hotrio_4u, hotrio_m or hotrio_s is received	std_logic
pulse_1ms_o	high for one cycle once every millisecond, when hotrio_m or hotrio_s is received	std_logic
pulse_1s_o	high for one cycle once every second, when hotrio_s is received	std_logic
sync_o	high when the state machine is synchronized with markers in the rx stream	std_logic
new_packet_o	high for one cycle when new data becomes available in this module's hotrio interface	std_logic
packet_valid_o	high for one cycle at the same time as `new_packet_o` if parity check succeeded on the received packet	std_logic
cnt_packets_received_o	number of hotrio packets received since last reset	std_logic_vector(15 downto 0)
cnt_err_kchar_o	number of wrong and/or misplaced k-characters received since last reset	std_logic_vector(15 downto 0)
cnt_err_parity_o	number of hotrio packets received with parity errors since last reset	std_logic_vector(15 downto 0)
cnt_err_ctc_o	number of ctc fifo overrun/underrun events since last reset. leave open if ctc_g = false	std_logic_vector(15 downto 0)
cnt_ctc_events_o	number of ctc adjustment events since last reset. leave open if ctc_g = false	std_logic_vector(15 downto 0)

Dependencies

Name	Motivation
globals	Types definition and HotRIO constants
hotrio_utils	Auxiliary module containing common logic used both in hotrio_master_rx and hotrio_slave
pulse_stretcher	Used to stretch 1-cycle pulses to a larger duration
signal_cdc	Used to detect edges and to cross clock domains in the CTC mechanism

Implementation details

This module is implemented as a state machine that controls the flags and the hotrio_* outputs and interacts with three auxiliary modules from hotrio_utils:

• hotrio_ctc performs clock tolerance compensation, allowing communication between nodes connected to different oscillators.

• hotrio_marker_check detects valid HotRIO frame markers.

• hotrio_parity_check computes the parity of received packets and compares it with the parity bits of the corresponding control byte.

The state machine consists on six states: SYNC, MARKER, PROTOCOL, MARKER_ADDRESS, PAYLOAD and CONTROL.

The state machine starts in the SYNC state. In this state, the module waits for a HOTRIO_4U marker as defined in the global package. While in this state, the sync_o is kept to zero. If a k-character is received in states other than SYNC, MARKER or MARKER_ADDRESS, a check is implemented that flags an error on cnt_err_kchar and the SYNC state is selected. This will not be specified in the description of the various states as it’s the same for every one.

The MARKER state is used when the state machine is synchronized with the incoming data. It checks the received marker and if it matches drives the corresponding pulse output. If a non-HotRIO marker is received, the cnt_err_kchar counter is incremented and the SYNC state selected.

The PROTOCOL state receives the byte after the frame marker, shifting it into the time_o output according to the HotRIO time communication mechanism. This state is always followed by MARKER_ADDRESS.

In the MARKER_ADDRESS state, the address of the frame is received. An additional frame marker may also be received instead, allowing the state machine to read frames in which CTC has inserted a second header sequence.

The PAYLOAD state is used to receive the payload of the HotRIO packet byte-by-byte. A counter is used to keep track of the bytes received, the number of bytes in a HotRIO packet is defined in the global package as HOTRIO_BYTES_IN_PACKET.

The last state is CONTROL. In this state, the control byte is received. This byte contains the parity bits of the HotRIO packet that are checked against the generated bits to detect errors. The hotrio_packet output is updated with the received data even if an error has been detected. The packet_valid flag is asserted if the packet is valid, however, the new_packet flag is asserted in any case.

Note

The diagram of the state machine doesn’t contain the state transitions in case of error from all the states to SYNC. Moreover, the transitions names don’t correspond to the real signals names.