ECP3 PCS Word Aligner for HDMI Receiver Issues

We are developing a video bridge using a Lattice ECP3 that makes use of Lattice's HDMI receiver reference design and the ECP3 SERDES/PCS hard IP block. The ECP3 SERDES/PCS block is configured to perform Word Alignment (WA) of the incoming HDMI serial data as described in Application Note RD1097

As specified in HDMI Specification 1.3a: "immediately preceding each Video Data Period or Data Island Period is the Preamble. This is a sequence of eight identical Control characters that indicate whether the upcoming data period is a Video Data Period or is a Data Island. ... The two Control signals for each of the three TMDS channels are encoded as follows:"

case (D1, D0):
0, 0: q_out[9:0] = 0b1101010100;
0, 1: q_out[9:0] = 0b0010101011;
1, 0: q_out[9:0] = 0b0101010100;
1, 1: q_out[9:0] = 0b1010101011;
endcase;

The ECP3 PCS WA is configured in such a way as to align the received serial data using the 10-bit control character preamble.

We find that the HDMI receiver occasionally reports a word alignment error (~once/hour) on one of the three HDMI data channels. Using Reveal, we have determined that the 10-bit parallel data being clocked into the FPGA fabric from the SERDES/PCS block becomes unaligned, and it's unclear to us whether the underlying HDMI hardware bus has an issue or if we are not configuring the PCS WA function properly.

As described in the SERDES/PCS Usage Guide, the WA circuit relies on an input word_align_en_ch signal. The PCS app note states the following:

"When the CHx_RXWA is set to ENABLED, the word_align_enable CH_01 ... is set to HIGH, enabling the word_align_en_ch(0-3)_c signal to be controlled by FPGA fabric. When the signal word_align_en_ch(0-3)_c is HIGH, the Word Aligner looks for incoming data for either COMMA_A or COMMA_B for alignment. Once it is aligned, it stays locked and aligned, and stops comparing incoming data.

If re-alignment is required, the word_align_en_ch(0-3)_c should be pulsed from HIGH to LOW, then to HIGH. Driving the signal to LOW clears up the Word Aligner internal status to unlock. Alignment does not start until the word_align_en_ch(0-3)_c signal is driven back to HIGH. When it is driven to HIGH, it constantly compares the incoming data to either COMMA_A or COMMA_B for alignment. When alignment is found, it stays locked and aligned, and stops comparing data.

After each alignment or re-alignment, the Word Aligner keeps aligning to that state, until the signal word_algin_en_ch(0-3)_c is pulsing to HIGH and either COMMA_A or COMMA_B character is found. Before that, when the signal is LOW, or pulsed to HIGH."

We confirm that Chx_RXWA is set to enabled for each channel in the SERDES/PCS configuration file generated by IPexpress.

It's interesting to note that the source for Lattice's HDMI reference design has the word_align_en_ch signal strapped high.

Our testing shows that setting word_align_en_ch high or low provides the same results. Regardless of the value for enable, the WA circuit aligns, occasionally loses alignment, and subsequently re-aligns. If the WA circuit operated as documented, then it should never achieve alignment with the word_align_en_ch strapped low.

Questions:

• How can we confirm that word_align_en_ch operates as documented? Are there any errata for this circuit?
• What is the minimum pulse time for word_align_en_ch, and is it referenced to a clock (or asynchronous)?
• What is the duration or number of preamble words required for the WA circuit to lock onto the incoming data stream?
• Does the PCS circuit provide a mechanism to the FPGA fabric to ascertain whether lock has been achieved?