TMDS1204EVM: Configuration Validation for Variable Cable Input to Static HDMI RX Channel

Hi,

Please see this app note on how to use the TMDS1204 adaptive equalization. It includes I2C script to configure TMDS1204 for the AEQ feature. 

You should use limited mode as it decouples the TMDS1204 TX from its RX. 

How do you implement the DDC bus in your design? Are you providing any snooping capability? Some function, such as TX termination control, the default is depending on the snooping, so you may have to manually set the control if snooping is disabled.

Thanks
David

Hey David,

Thanks for the SNLA419 reference - very helpful for understanding AEQ implementation.

I have a specific setup question regarding single lane BERT testing with the TMDS1204 EVM:

My Setup:

• BERT Pattern Generator → TMDS1204 EVM → Scope
• Single lane only (i.e. CLK lane, register 11h = 08h)
• PRBS-15 at 2.97 Gbps for signal integrity validation
• Testing variable input conditions (cable lengths, signal levels)

Questions:

AEQ Single Lane Compatibility: Any constraints using Adaptive EQ with only one lane enabled? Does AEQ need multiple active lanes or can it adapt effectively on single lane basis?

Manual vs Auto EQ for BERT: For single-lane BERT, is it better to use Auto EQ for varying conditions or manual/fixed EQ for repeatable measurements?

Manual EQ Optimization: If going manual route, what's recommended method to determine optimal EQ settings? Start with pin-strap EQ settings and iterate? Use eye diagram analysis at the output?

DDC Relevance: In BERT-to-scope setup (no actual HDMI display), is DDC snooping relevant? Currently disabling it (0A = 05h) since no HDMI negotiation occurs.

Any experience with TMDS1204 BERT testing, particularly AEQ behavior with single lanes and best practices for EQ config in measurement setups?

Thanks!

Hi,

For this particular test, I would recommend using TMD1204 I2C mode as you can make setting change on the fly without power cycling the TMDS1204. 

The adaption will only occur during the TXFFE0 portion of FRL link training when LTP5, LTP6, LTP7, or LTP8 is being received. So you have to create a LTP5, 6, 7, or 8 data pattern with the Bert. 

DDC is not relevant if you are using a Bert, but you will have to manually configure TMDS1204 into FRL mode. This is done by writing a non-0 value to register 0x31 bit[3:0].

The AEQ operates only on IN_D0 pins (pins 12 and 13). The EQ value determined by AEQ will be applied to the other FRL data lanes. So for single lane, you can't use CLK lane, you have to use lane 0. 

Once the AEQ is completed, you can read register 0x50 bit[3-0] for adapted EQ value and register 0x51 bit[3-0] for Eye stat value, 0x51 bit[6-4] for VOD range stat value.

You can use a sampling scope to measure the eye width and eye height at the TMDS1204 and plot it against the input channel insertion loss, source TX setting.

Thanks

David

Thanks David that was helpful. I had a few additional queries on some other things.

Could you please clarify the minimum and maximum end-to-end channel insertion loss supported by the TMDS1204 on both RX and TX sides? From the datasheet, I see up to 12dB RX EQ at 6GHz, but I'd like confirmation of:

• Maximum and minimum supported pre-channel loss (source-to-TMDS1204)
• Maximum and minimum supported post-channel loss (TMDS1204-to-sink)
• Any specific loss profile requirements or limitations

For our application using limited redriver mode with cable/loss variation, what is the correct I²C configuration sequence to enable adaptive EQ? Specifically:

• Required register settings for AEQ in limited mode
• Proper FRL mode entry sequence for AEQ operation
• Whether manual TXFFE control (0x0A[1:0]=01) is compatible with AEQ

Regarding FRL link training support, I want to confirm my understanding:

• Is link training support available for both RX and TX sides of the TMDS1204?
• Does Linear mode adjust TX EQ with respect to auto RX EQ convergence?
• Does Limited mode converge auto RX EQ but does not change TX EQ?

Hi,

Please see my inserted response below.

• Maximum and minimum supported pre-channel loss (source-to-TMDS1204)
  • Please refer to Section 8.2 and Table 8-2 for the supported channel loss on the source side
• Maximum and minimum supported post-channel loss (TMDS1204-to-sink)
  • Please refer to Section 8-3 and Table 8-6 for the supported channel loss on the sink side
• Any specific loss profile requirements or limitations
  • No

Before we dive deeper, I want to clarify something quick. The TMDS1204 supports both Adaptive EQ (AEQ) and Link Training Compatible Rx EQ. Which mode do you want to implement?

Thanks

David

Hey David,

We are looking to use the Link Training Compatible Rx EQ mode. Our use case involves compensating for channel/cable loss variation using adaptive equalization at the RX input (specifically, during HDMI2.1 FRL link training), with the TX output set to limited (static) mode for compliance and consistent downstream signal quality. Hope that clears up what we're trying to accomplish. 

Hi,

The Link Training Compatible Rx EQ mode is recommended in source application. Below is the TXFFE levels that this mode assumes the GPU is using. Can this requirement be supported by your source?

In your case, which you are trying to have adaptive equalization at the RX input to different channel/cable loss, this is more a sink application. In which case, you would want to use the TMDS1204  Adaptive EQ (AEQ) feature and put the TDP1204 into linear re-driver.

Please correct me if my understanding is not correct.

Thanks

David

Hey David,

So We’ve confirmed our system requires Limited Mode on the TX side—because we have a static TMDS1204 TX-to-RX channel and need consistent output for BERT measurements. Simultaneously, we need adaptive RX equalization at the TMDS1204 input to handle varying cable loss scenarios across different test fixtures.

Could you also clarify whether in Linear Mode the TMDS1204 TX EQ tracks the RX EQ convergence, and in Limited Mode the TX EQ remains fixed despite RX adaptation. We would also like clarification on if the difference between Linear and Limited modes is just that the TX changes with adaptation or it does not. 

Hi,

When TMDS1204 is in the linear mode, it does not have any TX control. So the output signal is almost a linear function of the input signal as long as the input signal is within the TMDS1204 input linearity range.

When TMDS1204 is in the limited mode, then the TX is decoupled completely from the RX. TX output can be remain fixed by setting TXFFE_SNOOP_CTRL bit in register 0xA to a value of 0x02(DDC snooping disabled), and TXFFE can then controlled through writes to CLK_TXFFE, D0_TXFFE, D1_TXFFE, and D2_TXFFE.

Thanks

David

Hey David,

Just had a few questions to clarify on some things regarding our validation setup.

For the supported reaches, mentioned in Tables 8‑2 and 8‑6, if I'm understanding correctly these values shouldn't change based on limited and linear mode correct?

Does the TMDS1204 allow static TX pre-emphasis/de-emphasis to be configured when HDMI 2.1 FRL is enabled in limited mode so we can tune a static channel or is that only not available in linear mode?

Hi,

For the supported reaches, mentioned in Tables 8‑2 and 8‑6, if I'm understanding correctly these values shouldn't change based on limited and linear mode correct?

Correct. these values do not change. In linear mode, the TMDS1204 RX EQ can compensate the pre-channel and a little bit of post-channel. In limited mode, the RX EQ compensate the pre-channel and the TX EQ compensate the post-channel. 

Does the TMDS1204 allow static TX pre-emphasis/de-emphasis to be configured when HDMI 2.1 FRL is enabled in limited mode so we can tune a static channel or is that only not available in linear mode?

TX output is only available in limited mode and can be remain fixed by setting TXFFE_SNOOP_CTRL bit in register 0xA to a value of 0x02(DDC snooping disabled), and TXFFE can then controlled through writes to CLK_TXFFE, D0_TXFFE, D1_TXFFE, and D2_TXFFE.

Thanks

David

Thanks for all of the information so far David, you've been very helpful with piecing this all together.
I did have one other question regarding the proper BERT sequence to trigger AEQ.

For context we’re driving TMDS1204 with a BERT acting as the HDMI 2.1 FRL source and need TI’s recommended minimal sequence to ensure the device’s AEQ runs and converges before TX measurements, without a full HDMI GPU in the loop. 

What exact FRL training patterns and order (e.g., LTP5–LTP8) and minimum dwell time at TXFFE0 are required so AEQ completes, and are BERT‑generated equivalents acceptable if full FRL framing isn’t present?

Hi,

The TMDS1204 will perform adaptive equalization when FRL link training begins. It will also re-adapt each time the data rate changes. The adaption will only occur during the TXFFE0 portion of FRL link training when LTP5, LTP6, LTP7, or LTP8 is being received. So for the Bert, you will want it to output one of the LTP link training pattern.

Also the AEQ is only supported in HDMI2.1 mode. So you want to make sure the register 0x31 is set to the "Not 0h".

The time from start of FRL link training to AEQ complete for 6Gbps, 8Gbps, 10Gbps, and 12Gbps is max of 0.5ms. You can also poll AEQ_STATUS Register (Offset = 50h) bit 7 to make sure AEQ is completed.

Thanks

David

Hey David, 

I had a few additional questions regarding the patterns required for AEQ to complete.

Is there an officially supported way to trigger AEQ without exact LTPs (e.g., treating PRBS31 as “pattern 0” when 0x1D=0xF8), or is a brief LTP5–LTP8 burst strictly required to guarantee AEQ completion?

If a workaround exists to emulate LTPs with a non‑FRL‑aware generator (file format, sequence, or SCDC trick), could you share any guidance or confirm that only FRL‑aware sources (e.g., protocol generators) can reliably supply LTP5–LTP8 for AEQ?

Thanks again for all the help!

Hi,

You can use a Bert to generate the LTP pattern with specific TX FFE settings, it does not have to be a FRL aware generator. 

Once the Bert is sending out the LTP pattern, you can force TMDS1204 into FRL mode by write a non-0 value to register 0x31.

You can then start the AEQ with a write of 0x40 to register 0x1E. 

Register 0x50 can be polled for the completion of AEQ and the adapted EQ value.

Register 0x51 can be read for the VOD range and the eye status.

You can run this loop multiple times to see if you are getting a consistent adapted EQ value with a given channel.

Thanks

David 

Hey David,

Just wanted clarification but for AEQ to operate properly does IN_D0 have to be connected or can other lanes work too?

I followed your suggestions above but I'm always polling 0x80 for 0x50h and 0x41 for 0x51h and not seeing any improvements. I've attached my aardvark batch script below to see if I've possibly overlooked anything. I'm not sure if the order of register writes might also be playing a role in my issues. I set register 0x1Dh to it's most permissive setting and used a PRBS-15 pattern as well to see if I was able to get anything to converge for the AEQ but still no improvements. I've tried different length HDMI cables as well from 0.5m to 5m and didn't see any changes on the EQ levels. Thanks for the help.

<aardvark>
<configure i2c="1" spi="0" gpio="0" tpower="0" pullups="0"/>
<i2c_bitrate khz="100"/>

<i2c_write addr="0x5E" count="2" radix="16">09 80</i2c_write>

<sleep ms="1000"/>

<i2c_write addr="0x5E" count="2" radix="16">0A 83</i2c_write>
<i2c_write addr="0x5E" count="2" radix="16">0D E3</i2c_write>
 
<i2c_write addr="0x5E" count="2" radix="16">31 36</i2c_write>
<i2c_write addr="0x5E" count="2" radix="16">0E 3F</i2c_write>

<i2c_write addr="0x5E" count="1" radix="16">50</i2c_write>
<i2c_read addr="0x5E" count="1" radix="16"/>
<i2c_write addr="0x5E" count="1" radix="16">51</i2c_write>
<i2c_read addr="0x5E" count="1" radix="16"/>

<i2c_write addr="0x5E" count="2" radix="16">12 03</i2c_write>
<i2c_write addr="0x5E" count="2" radix="16">14 03</i2c_write>
<i2c_write addr="0x5E" count="2" radix="16">16 03</i2c_write>
<i2c_write addr="0x5E" count="2" radix="16">18 03</i2c_write>

<i2c_write addr="0x5E" count="2" radix="16">13 01</i2c_write>
<i2c_write addr="0x5E" count="2" radix="16">15 01</i2c_write>
<i2c_write addr="0x5E" count="2" radix="16">17 01</i2c_write>
<i2c_write addr="0x5E" count="2" radix="16">19 01</i2c_write>

<i2c_write addr="0x5E" count="2" radix="16">1D F8</i2c_write>
<i2c_write addr="0x5E" count="2" radix="16">1E 40</i2c_write>

<i2c_write addr="0x5E" count="2" radix="16">20 00</i2c_write>
<i2c_write addr="0x5E" count="2" radix="16">09 06</i2c_write>

<i2c_write addr="0x5E" count="2" radix="16">1E 40</i2c_write>

<sleep ms="2000"/>

<i2c_write addr="0x5E" count="1" radix="16">50</i2c_write>
<i2c_read addr="0x5E" count="1" radix="16"/>
<i2c_write addr="0x5E" count="1" radix="16">51</i2c_write>
<i2c_read addr="0x5E" count="1" radix="16"/>

</aardvark>

Hi,

Are you doing the AEQ testing on the TMDS1204EVM or your design? Can we try the following script? After you execute the script, can you read back the register and make sure the write is successful?

// (address, data)
// Initial power-on configuration.
(0x0A, 0x07), // Rate snoop and TXFFE snoop disabled
(0x0B, 0x23), // 3G and 6G slew rate control
(0x0C, 0x00), // HDMI clock tx slew rate control
(0x0D, 0xA3), // Linear mode, DC-coupled TX, 0dB DCG, Term fixed at 100Ω, disable CTLE bypass
(0x0E, 0x97), // HDMI14, 2.0 and 2.1 CTLE selection
(0x12, 0x03), // Clock lane VOD and TXFFE
(0x13, 0x00), // Clock lane EQ.
(0x14, 0x03), // D0 lane VOD and TXFFE.
(0x15, 0x0Y), // D0 lane EQ. Set "Y" to desired value.
(0x16, 0x03), // D1 lane VOD and TXFFE.
(0x17, 0x0Y), // D1 lane EQ. Set "Y" to desired value.
(0x18, 0x03), // D2 lane VOD and TXFFE.
(0x19, 0x0Y), // D2 lane EQ. Set "Y" to desired value.
(0x31, 0x36), // FRL
(0x1D, 0xF3), // AEQ config
(0x1E, 0x40), // Enable AEQ
(0x09, 0x06), // Take out of PD state. Should be done after initialization is complete.

Thanks

David

Hey David, 

I had to make a few modifications since I'm using lane swap mode and AC-coupled mode. So I changed 0Ah to 0x87 and 0Dh to 0xE3 but rest of script remained the same. Upon readback of the registers all of them reported back whatever I wrote to them earlier except 31h register which still returns 0x00.

Currently we're still validating the AEQ testing on the TMDS1204EVM and plan on integrating it with our design once we had observed performance of AEQ with different HDMI cable lengths and how the signal looks on the scope.

"2025-10-30 14:57:24.553","I2C","W","M","---","100","0X5E","2","0A 87"
"2025-10-30 14:57:24.559","I2C","W","M","---","100","0X5E","2","0B 23"
"2025-10-30 14:57:24.588","I2C","W","M","---","100","0X5E","2","0C 00"
"2025-10-30 14:57:24.591","I2C","W","M","---","100","0X5E","2","0D E3"
"2025-10-30 14:57:24.615","I2C","W","M","---","100","0X5E","2","0E 97"
"2025-10-30 14:57:24.618","I2C","W","M","---","100","0X5E","2","12 03"
"2025-10-30 14:57:24.645","I2C","W","M","---","100","0X5E","2","14 03"
"2025-10-30 14:57:24.650","I2C","W","M","---","100","0X5E","2","16 03"
"2025-10-30 14:57:24.680","I2C","W","M","---","100","0X5E","2","18 03"
"2025-10-30 14:57:24.684","I2C","W","M","---","100","0X5E","2","13 00"
"2025-10-30 14:57:24.721","I2C","W","M","---","100","0X5E","2","15 01"
"2025-10-30 14:57:24.726","I2C","W","M","---","100","0X5E","2","17 01"
"2025-10-30 14:57:24.769","I2C","W","M","---","100","0X5E","2","19 01"
"2025-10-30 14:57:24.773","I2C","W","M","---","100","0X5E","2","31 36"
"2025-10-30 14:57:24.821","I2C","W","M","---","100","0X5E","2","1D F3"
"2025-10-30 14:57:24.838","I2C","W","M","---","100","0X5E","2","1E 40"
"2025-10-30 14:57:24.891","I2C","W","M","---","100","0X5E","2","09 06"

"2025-10-30 14:57:36.400","I2C","W","M","---","100","0X5E","1","0A"
"2025-10-30 14:57:36.441","I2C","R","M","---","100","0X5E","1","87"

"2025-10-30 14:57:36.446","I2C","W","M","---","100","0X5E","1","0B"
"2025-10-30 14:57:36.493","I2C","R","M","---","100","0X5E","1","23"

"2025-10-30 14:57:36.497","I2C","W","M","---","100","0X5E","1","0C"
"2025-10-30 14:57:36.543","I2C","R","M","---","100","0X5E","1","00"

"2025-10-30 14:57:36.548","I2C","W","M","---","100","0X5E","1","0D"
"2025-10-30 14:57:36.601","I2C","R","M","---","100","0X5E","1","E3"

"2025-10-30 14:57:36.608","I2C","W","M","---","100","0X5E","1","0E"
"2025-10-30 14:57:36.657","I2C","R","M","---","100","0X5E","1","97"

"2025-10-30 14:57:36.663","I2C","W","M","---","100","0X5E","1","12"
"2025-10-30 14:57:36.717","I2C","R","M","---","100","0X5E","1","03"

"2025-10-30 14:57:36.720","I2C","W","M","---","100","0X5E","1","14"
"2025-10-30 14:57:36.778","I2C","R","M","---","100","0X5E","1","03"

"2025-10-30 14:57:36.780","I2C","W","M","---","100","0X5E","1","16"
"2025-10-30 14:57:36.845","I2C","R","M","---","100","0X5E","1","03"

"2025-10-30 14:57:36.849","I2C","W","M","---","100","0X5E","1","18"
"2025-10-30 14:57:36.897","I2C","R","M","---","100","0X5E","1","03"

"2025-10-30 14:57:36.901","I2C","W","M","---","100","0X5E","1","13"
"2025-10-30 14:57:36.947","I2C","R","M","---","100","0X5E","1","00"

"2025-10-30 14:57:36.951","I2C","W","M","---","100","0X5E","1","15"
"2025-10-30 14:57:37.002","I2C","R","M","---","100","0X5E","1","01"

"2025-10-30 14:57:37.006","I2C","W","M","---","100","0X5E","1","17"
"2025-10-30 14:57:37.062","I2C","R","M","---","100","0X5E","1","01"

"2025-10-30 14:57:37.066","I2C","W","M","---","100","0X5E","1","19"
"2025-10-30 14:57:37.115","I2C","R","M","---","100","0X5E","1","01"

"2025-10-30 14:57:37.118","I2C","W","M","---","100","0X5E","1","31"
"2025-10-30 14:57:37.165","I2C","R","M","---","100","0X5E","1","00"

"2025-10-30 14:57:37.171","I2C","W","M","---","100","0X5E","1","1D"
"2025-10-30 14:57:37.223","I2C","R","M","---","100","0X5E","1","F3"

"2025-10-30 14:57:37.229","I2C","W","M","---","100","0X5E","1","1E"
"2025-10-30 14:57:37.282","I2C","R","M","---","100","0X5E","1","40"

"2025-10-30 14:57:37.286","I2C","W","M","---","100","0X5E","1","09"
"2025-10-30 14:57:37.335","I2C","R","M","---","100","0X5E","1","06"

Hi,

Is HPD_IN high or low in this particular case?

With register 0x0A set to 0x07, RATE snoop is disabled. You should able to write to register 0x20h or 0x31h.

Are you able to write 0x02 to register 0x20h or 0x06 to register 0x31?

If register 0x31 is 0x00, then TMDS1204 is not in FRL mode and AEQ will not start.

Thanks

David

I believe HPD_IN is low since we're relying on HPD_PWRDWN_DISABLE and STANDBY_DISABLE bits to bring the TMDS1204EVM out of standby and allow signal flow through to the Scope from BERT. Let me try modifying 0x20h and 0x31h with those values.



Does the above chart have any relevance to our situation?

Hi, 

With EN high and HPD_PWRDWN_DISABLE/STANDBY_DISABLE bits being set to 1, TMDS1204 should be in active mode as circled below.

With RATE_SNOOP_CTRL bit set to 1 to disable DDC snooping, you should able to write to register 0x20 or 0x31 to configure TMDS1204 either in HDMI1.4 (both 0x20 and 0x31 == 0x00), HDMI2.0 (0x20 = 0x02 and 0x31 = 0x00), or HDMI2.1 (0x20 = 0x00 and 0x31 = non-zero value).

Thanks

David

Hey David,

We've been troubleshooting AEQ adaptation on our TMDS1204 bench setup and have tried multiple register configurations and lane mappings without success (0x50 remains 0x80). 

For context on our situation:

We're using a Wilder HDMI 2.1 TPA with a 12 Gb/s PRBS-15 pattern from a BERT.
We've enabled AEQ (0x1D=F3 → 0x1E=40) and confirmed register writes take effect.
We've tried multiple 0x0A values (0x07, 0x83, 0x87) and adjusted lanes, but 0x50 stays 0x80 and per-lane EQ codes (0x13/0x15/0x17/0x19) don't change.

We need guidance on the following areas:

Question 1: Power State & HPD_IN
We understand from the datasheet (Table 7-21) that Normal operation requires HPD_IN = High and valid signal detect. So setting 0x09h register to 0x06 should be sufficient in satisfying this requirement correct?

Question 2: Lane Mapping & AEQ D0
Per the implementation guide, AEQ operates only on internal D0. We've tested: Swap disabled (0x0A bit7=0): driving physical D0 pair and also Swap enabled (0x0A bit7=1): driving physical CLK pair. We changed which TPA pair we connect to, but 0x50 and EQ codes still don't change. Are we approaching this correctly or is there a detail we might've overlooked?

Question 3: Pattern Type & Link Training
We're applying continuous 12 Gb/s PRBS-15. I would appreciate some guidance on how to properly generate LTP patterns using our BERT with our desired TXFFE settings. Currently we're only able to generate PRBS-15 or PRBS-31 patterns since we do not have an option that states LTP or similar so this might be the biggest blocker. I'm using the Keysight M8070B and M8045A for reference. 

Thanks again for all the help so far.

Hi,

Let me set the AEQ experiment in the lab. But for the Bert, you should able to use its pattern generator to input the LTP5 pattern. And then Data OUT to set the Bert TX equalization.

Thanks

David

Hey David, 

Just following up but any updates on this by chance?

Thanks again!

Hi Mahdi, 

David is currently out of office. He has looped in me on this, and we are setting this up. We will update you next Tuesday on this test. 

Best,
J

Hi Mahdi, 

We tried replicating the LTP5 pattern on the BERT, but AEQ was also not done properly. Upon further reading, AEQ requires all four LTP (LTP5, 6, 7, 8) patterns on all four lanes to properly run. 
And we were able to confirm this by running the AEQ with a HDMI source and Wilder EDID controller to induce LTP5,6,7,8 patterns on the HDMI source. 
Unfortunately, it seems like to validate AEQ you may have to input all four LTP patterns into the BERT. 

To input LTP patterns into the BERT, we used pattern generator to input the data portion of the LTP5, but we were not able to complete AEQ with the inputted pattern. 

Please let me know your thoughts. 

Best,
J