This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DS250DF230: How to set VOD from TX driver FIR?

Part Number: DS250DF230

Tool/software:

Hi. 

I am using DS250DF230 in a SOC to SFP+ applicaiton at 10.3125Gbps, 25MHz clock reference.

I have a CLI command developed to adjust the VOD of the channel which does not work. In the examples below, I have a fiber loopback, the VOD sent on CH1 is received on CH0.

The command programs an index from an array taken from programming manual section 7.11. I will place explanations on each command, starting with ";".

; select VOD table index 20 meaning {  0, 20,  0, 0.985, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 20 

// see 7.11 table
typedef struct rtmr_out_drive_s {
int8_t precursor;
int8_t maincursor;
int8_t postcursor;
float vod;
float rpre;
float rpst;
} rtmr_out_drive_t;

pc-sh# rtmrctrl -c 1 -a 20 -d -v

[main] - INFO: access I2C bus
Change TX output drive index
[i2c_rmw][R] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xfc VAL = 0x02
[i2c_rmw][R] REG = 0x3d VAL = 0x94
[i2c_rmw][W] REG = 0x3d VAL = 0x94
[i2c_rmw][R] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xfc VAL = 0x02
[i2c_rmw][R] REG = 0x3d VAL = 0x94
[i2c_rmw][W] REG = 0x3d VAL = 0x94
[i2c_rmw][R] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xfc VAL = 0x02
[i2c_rmw][R] REG = 0x3f VAL = 0x00
[i2c_rmw][W] REG = 0x3f VAL = 0x00
[i2c_rmw][R] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xfc VAL = 0x02
[i2c_rmw][R] REG = 0x3e VAL = 0x00
[i2c_rmw][W] REG = 0x3e VAL = 0x00
[i2c_rmw][R] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xfc VAL = 0x02
[i2c_rmw][R] REG = 0x3d VAL = 0x94
[i2c_rmw][W] REG = 0x3d VAL = 0x94
[i2c_rmw][R] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xfc VAL = 0x02
[i2c_rmw][R] REG = 0x3f VAL = 0x00
[i2c_rmw][W] REG = 0x3f VAL = 0x00
[i2c_rmw][R] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xff VAL = 0x01
[i2c_rmw][W] REG = 0xfc VAL = 0x02
[i2c_rmw][R] REG = 0x3e VAL = 0x00
[i2c_rmw][W] REG = 0x3e VAL = 0x00
PRE_CURSOR : 0
MAIN_CURSOR : 20
POST_CURSOR : 0
VOLTAGE_DIFF : 0.985 [V]
PRE_RATIO : 0.000 [dB]
POST_RATIO : 0.000 [dB]

; we check the result

pc-sh# rtmrctrl -c 1 -r 0x3e

[READ] REG = 0x3e VAL = 0x00

pc-sh# rtmrctrl -c 1 -r 0x3d

[READ] REG = 0x3d VAL = 0x94

pc-sh# rtmrctrl -c 1 -r 0x3f

[READ] REG = 0x3f VAL = 0x00

; we check the eye opening but this one is not changed, stays the same as before

pc-sh# rtmrctrl -s

Display statistics
[TOP]

REFCLK_DET : true

[SFP_RX/RTMR_CH0_RX]

[CH0] SIG_DET : true
[CH0] CDR_LOCK : true
[CH0] SIG_DET_EVT : false
[CH0] CDR_LOCK_EVT : false
[CH0] SIG_DET_LOSS_EVT : false
[CH0] CDR_LOCK_LOSS_EVT: false
[CH0] EYE_OPEN_H : 0.6875 [UI]
[CH0] EYE_OPEN_V : 475 [mV]
[CH0] CDR_PPM_CHECK_OK : true
[CH0] CDR_EQ_ADAPT_OK : true
[CH0] CDR_SIG_AMP_FAIL : false
[CH0] CDR_DATA_RATE_OK : true

[SOC_RX/RTMR_CH1_RX]

[CH1] SIG_DET : true
[CH1] CDR_LOCK : true
[CH1] SIG_DET_EVT : false
[CH1] CDR_LOCK_EVT : false
[CH1] SIG_DET_LOSS_EVT : false
[CH1] CDR_LOCK_LOSS_EVT: false
[CH1] EYE_OPEN_H : 0.90625 [UI]
[CH1] EYE_OPEN_V : 562.5 [mV]
[CH1] CDR_PPM_CHECK_OK : true
[CH1] CDR_EQ_ADAPT_OK : true
[CH1] CDR_SIG_AMP_FAIL : false
[CH1] CDR_DATA_RATE_OK : true


pc-sh#

Question is:

Is there any other register that needs to be written to executed VOD change?

I have also tried after VOD update to do a CDR reset and then read the eye opening. Same result (or very close as the equalizer does not have every time after a CDR reset same H and V)

  • Hi Aurel,

    Are you using the retimer eye opening monitor on CH0 to measure whether VOD changes on CH1 are taking effect?  If so, I believe this is not a good procedure while using a fiber loopback.  Typically, optical modules have limiting amplifiers.  This would negate any impact of TX VOD.

    Do you have any ability to look at the electrical output from the retimer?  Alternatively, do you have an electrical loopback module?

    Also, I looked over your register R/W sequence and did not see any issues.  However, one thing I noticed is that you're setting the sign of pre/post cursor to positive instead of default (negative).  A negative value indicates additional pre/post emphasis and is most commonly used.  If you're using non-zero pre/post values in the future, you may need to set the sign to negative.

    Thanks,
    Drew

  • Thanks Drew for very fast answer.

    a) Yes I use eye monitor and you are right. I will search for copper loopback.

    b) I have inserted in code the 7.11 table from programming manual.I I find the cursor sign to be >= 0 then sign is set positive else sign is set negative. Let me know if procedure is ok.

    typedef struct rtmr_out_drive_s {
    int8_t precursor;
    int8_t maincursor;
    int8_t postcursor;
    float vod;
    float rpre;
    float rpst;
    } rtmr_out_drive_t;

    vector<rtmr_out_drive_t> rtmr_out_drive = {
    { 0, 0, 0, 0.205, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 0
    { 0, 1, 0, 0.260, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 1
    { 0, 2, 0, 0.305, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 2
    { 0, 3, 0, 0.355, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 3
    { 0, 4, 0, 0.395, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 4
    { 0, 5, 0, 0.440, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 5
    { 0, 6, 0, 0.490, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 6
    { 0, 7, 0, 0.525, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 7
    { 0, 8, 0, 0.565, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 8
    { 0, 9, 0, 0.610, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 9
    { 0, 10, 0, 0.650, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 10
    { 0, 11, 0, 0.685, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 11
    { 0, 12, 0, 0.720, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 12
    { 0, 13, 0, 0.760, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 13
    { 0, 14, 0, 0.790, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 14
    { 0, 15, 0, 0.825, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 15
    { 0, 16, 0, 0.860, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 16
    { 0, 17, 0, 0.890, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 17
    { 0, 18, 0, 0.925, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 18
    { 0, 19, 0, 0.960, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 19
    { 0, 20, 0, 0.985, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 20
    { 0, 21, 0, 1.010, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 21
    { 0, 22, 0, 1.040, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 22
    { 0, 23, 0, 1.075, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 23
    { 0, 24, 0, 1.095, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 24
    { 0, 25, 0, 1.125, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 25
    { 0, 26, 0, 1.150, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 26
    { 0, 27, 0, 1.165, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 27
    { 0, 28, 0, 1.190, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 28
    { 0, 29, 0, 1.205, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 29
    { 0, 30, 0, 1.220, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 30
    { 0, 31, 0, 1.225, RTMR_DB_FLOAT_NA, RTMR_DB_FLOAT_NA}, // 31

    { 0, 18, -1, 0.960, RTMR_DB_FLOAT_NA, 2.1}, // 32
    { 0, 17, -2, 0.960, RTMR_DB_FLOAT_NA, 2.5}, // 33
    { 0, 16, -3, 0.960, RTMR_DB_FLOAT_NA, 3.1}, // 34
    { 0, 15, -4, 0.960, RTMR_DB_FLOAT_NA, 3.8}, // 35
    { 0, 14, -5, 0.960, RTMR_DB_FLOAT_NA, 4.7}, // 36
    { 0, 13, -6, 0.960, RTMR_DB_FLOAT_NA, 5.8}, // 37
    { 0, 12, -7, 0.960, RTMR_DB_FLOAT_NA, 7.2}, // 38
    { 0, 11, -8, 0.960, RTMR_DB_FLOAT_NA, 9.0}, // 39
    { 0, 10, -9, 0.960, RTMR_DB_FLOAT_NA, 11.6}, // 40
    { -1, 18, 0, 0.960, 1.0, RTMR_DB_FLOAT_NA}, // 41
    { -2, 17, 0, 0.960, 1.6, RTMR_DB_FLOAT_NA}, // 42
    { -3, 16, 0, 0.960, 2.4, RTMR_DB_FLOAT_NA}, // 43
    { -4, 15, 0, 0.960, 3.3, RTMR_DB_FLOAT_NA}, // 44

    { 0, 26, -1, 1.165, RTMR_DB_FLOAT_NA, 1.1}, // 45
    { 0, 25, -2, 1.165, RTMR_DB_FLOAT_NA, 1.3}, // 46
    { 0, 24, -3, 1.165, RTMR_DB_FLOAT_NA, 1.8}, // 47
    { 0, 23, -4, 1.165, RTMR_DB_FLOAT_NA, 2.2}, // 48
    { 0, 22, -5, 1.165, RTMR_DB_FLOAT_NA, 2.7}, // 49
    { 0, 21, -6, 1.165, RTMR_DB_FLOAT_NA, 3.3}, // 50
    { 0, 20, -7, 1.165, RTMR_DB_FLOAT_NA, 3.9}, // 51
    { 0, 19, -8, 1.165, RTMR_DB_FLOAT_NA, 4.7}, // 52
    { 0, 18, -9, 1.165, RTMR_DB_FLOAT_NA, 5.7}, // 53
    { 0, 17,-10, 1.165, RTMR_DB_FLOAT_NA, 6.9}, // 54
    { 0, 16,-11, 1.165, RTMR_DB_FLOAT_NA, 8.4}, // 55
    { 0, 15,-12, 1.165, RTMR_DB_FLOAT_NA, 10.1}, // 56

    { -1, 26, 0, 1.165, 0.7, RTMR_DB_FLOAT_NA}, // 57
    { -2, 25, 0, 1.165, 1.2, RTMR_DB_FLOAT_NA}, // 58
    { -3, 24, 0, 1.165, 1.5, RTMR_DB_FLOAT_NA}, // 59
    { -4, 23, 0, 1.165, 2.0, RTMR_DB_FLOAT_NA}, // 60
    { -5, 22, 0, 1.165, 2.6, RTMR_DB_FLOAT_NA}, // 61
    { -6, 21, 0, 1.165, 3.2, RTMR_DB_FLOAT_NA}, // 62
    { -7, 20, 0, 1.165, 4.0, RTMR_DB_FLOAT_NA}, // 63

    };

  • Hi Aurel,

    I don't see any issue with what you've implemented.

    If you're trying to verify TX FIR filter functionality, I have a potential suggestion:

    • Use the DS250DF230 PRBS gen/checker to check for bit errors in link
    • Change DS250DF230 TX FIR to values that you would expect bad performance with.  Observe if BER degrades.

    Thanks,

    Drew

  • Thanks Drew. I will experiment and come back.

  • Hi Aurel,

    Thanks, looking forward to your results.

    Thanks,

    Drew

  • Hi Drew.
    I was playing with PRBS feature and observed the followings, outside of VOD adjustment.
    The setup I have is still optical (I did not get yet the copper loopback).

    My setup looks like this:

    - CH1 RX received from SOC TX
    - CH1 TX transmits to SFP VCSEL
    - optical loopback
    - SFP VCSEL receives to CH0 RX
    - CH0 Transmits to SOC RX
    - CH0 RX works in adapt mode 2 (both CTLE and DFE enabled)
    - All register actions are per datasheet

    Ive seen followings:

    a) CH0 EQ OK (reg 0x02.CDR_STATUS[6]) sometimes does not come up (1)
    I see follwing behaviors:
    - majority of the time goes up in 2700-3600ms from CDR reset deassert (after reg programming)
    - sometimes is lazier, 4700ms
    - rarely does not come up, regardless time duration
    Question:
    is this due to adapt mode 2 and the fact that loopback provides a very clean channel?
    Is this known issue?

    b) looks like PRBS checker enable/disable perturbs the CDR Ive fixed this with CDR reset after this action
    is this correct?

    c) is there any recommended procedure for automatic setup for diverse SFPs like 300m VCSEL, 10km laser or 30km laser?

    Thanks!

  • Hi Aurel,

    Question:
    is this due to adapt mode 2 and the fact that loopback provides a very clean channel?
    Is this known issue?

    I know what auto-adaptation completion include DFE adaptation can take a couple seconds.  Our programming guide description of bit 6 describes bit 6 as only pertaining to CTLE, but I'm wondering if it might include DFE adaptation.

    Questions:

    - If you use adapt mode 1, do you still observe similar timing?

    - Do you see any correlation between the CTLE/DFE values and the time it takes for 0x02[6] to be set?  Also, what ctle/dfe values are you typically seeing the retimer adapt to?

    b) looks like PRBS checker enable/disable perturbs the CDR Ive fixed this with CDR reset after this action
    is this correct?

    Looking at our sequence for PRBS checker (Table 7-35 of programming guide), I don't see any mention of CDR reset being required.  However, if you sometimes need CDR reset to improve robustness of configuration after enabling/disabling PRBS checker, this is not particularly concerning to me.

    c) is there any recommended procedure for automatic setup for diverse SFPs like 300m VCSEL, 10km laser or 30km laser?

    What is your insertion loss between DS250DF230 and the SFP module? For low loss channels with optical modules, sometimes we recommend trying adapt mode 0 or 1 as they may require less time to adapt.

    Thanks,

    Drew

  • In Adapt Mode 1, adapt time (0x02[6]clear to set) is always 1500 ms and DFE always has the below coeffs.

    scan time 1500 ms
    [CH0] SFP channel status ok
    [CH0] SFP channel adapt time 600 ms
    [CH0] DFE_TAP_1 : -3
    [CH0] DFE_TAP_2 : 0
    [CH0] DFE_TAP_3 : 0
    [CH0] DFE_TAP_4 : 0
    [CH0] DFE_TAP_5 : 0

    In Adapt Mode 2 we see multiple combinations. Adapt time is always the same for a certain combination of DFE coeffs.

    [2024-11-01 17:47:23.480] scan time 4200 ms
    [2024-11-01 17:47:23.480] [CH0] SFP channel status ok
    [2024-11-01 17:47:23.480] [CH0] SFP channel adapt time 3300 ms
    [2024-11-01 17:47:23.480] [CH0] DFE_TAP_1 : -2
    [2024-11-01 17:47:23.480] [CH0] DFE_TAP_2 : 7
    [2024-11-01 17:47:23.480] [CH0] DFE_TAP_3 : 0
    [2024-11-01 17:47:23.480] [CH0] DFE_TAP_4 : 0
    [2024-11-01 17:47:23.480] [CH0] DFE_TAP_5 : 0

    [2024-11-01 17:47:28.631] scan time 4400 ms
    [2024-11-01 17:47:28.631] [CH0] SFP channel status ok
    [2024-11-01 17:47:28.631] [CH0] SFP channel adapt time 3500 ms
    [2024-11-01 17:47:28.631] [CH0] DFE_TAP_1 : 0
    [2024-11-01 17:47:28.631] [CH0] DFE_TAP_2 : 0
    [2024-11-01 17:47:28.631] [CH0] DFE_TAP_3 : 0
    [2024-11-01 17:47:28.631] [CH0] DFE_TAP_4 : 0
    [2024-11-01 17:47:28.648] [CH0] DFE_TAP_5 : 0

    [2024-11-01 17:48:07.028] scan time 3700 ms
    [2024-11-01 17:48:07.028] [CH0] SFP channel status ok
    [2024-11-01 17:48:07.028] [CH0] SFP channel adapt time 2800 ms
    [2024-11-01 17:48:07.045] [CH0] DFE_TAP_1 : -1
    [2024-11-01 17:48:07.045] [CH0] DFE_TAP_2 : 3
    [2024-11-01 17:48:07.045] [CH0] DFE_TAP_3 : 1
    [2024-11-01 17:48:07.045] [CH0] DFE_TAP_4 : 0
    [2024-11-01 17:48:07.045] [CH0] DFE_TAP_5 : 0

    [2024-11-01 17:48:12.068] scan time 4300 ms
    [2024-11-01 17:48:12.068] [CH0] SFP channel status ok
    [2024-11-01 17:48:12.085] [CH0] SFP channel adapt time 3400 ms
    [2024-11-01 17:48:12.085] [CH0] DFE_TAP_1 : 0
    [2024-11-01 17:48:12.085] [CH0] DFE_TAP_2 : 5
    [2024-11-01 17:48:12.085] [CH0] DFE_TAP_3 : 0
    [2024-11-01 17:48:12.085] [CH0] DFE_TAP_4 : 0
    [2024-11-01 17:48:12.085] [CH0] DFE_TAP_5 : 0

    [2024-11-01 17:48:51.377] scan time 4400 ms
    [2024-11-01 17:48:51.377] [CH0] SFP channel status ok
    [2024-11-01 17:48:51.393] [CH0] SFP channel adapt time 3500 ms
    [2024-11-01 17:48:51.393] [CH0] DFE_TAP_1 : -1
    [2024-11-01 17:48:51.393] [CH0] DFE_TAP_2 : 0
    [2024-11-01 17:48:51.393] [CH0] DFE_TAP_3 : 0
    [2024-11-01 17:48:51.393] [CH0] DFE_TAP_4 : 0
    [2024-11-01 17:48:51.393] [CH0] DFE_TAP_5 : 0

    [2024-11-01 17:48:56.481] scan time 4300 ms
    [2024-11-01 17:48:56.481] [CH0] SFP channel status ok
    [2024-11-01 17:48:56.481] [CH0] SFP channel adapt time 3400 ms
    [2024-11-01 17:48:56.481] [CH0] DFE_TAP_1 : 0
    [2024-11-01 17:48:56.481] [CH0] DFE_TAP_2 : 6
    [2024-11-01 17:48:56.481] [CH0] DFE_TAP_3 : 0
    [2024-11-01 17:48:56.497] [CH0] DFE_TAP_4 : 0
    [2024-11-01 17:48:56.497] [CH0] DFE_TAP_5 : 0

    [2024-11-01 17:49:45.229] scan time 3400 ms
    [2024-11-01 17:49:45.229] [CH0] SFP channel status ok
    [2024-11-01 17:49:45.244] [CH0] SFP channel adapt time 2500 ms
    [2024-11-01 17:49:45.244] [CH0] DFE_TAP_1 : -3
    [2024-11-01 17:49:45.244] [CH0] DFE_TAP_2 : 2
    [2024-11-01 17:49:45.244] [CH0] DFE_TAP_3 : 1
    [2024-11-01 17:49:45.244] [CH0] DFE_TAP_4 : 0
    [2024-11-01 17:49:45.245] [CH0] DFE_TAP_5 : 1

    [2024-11-01 17:50:29.130] scan time 3900 ms
    [2024-11-01 17:50:29.130] [CH0] SFP channel status ok
    [2024-11-01 17:50:29.130] [CH0] SFP channel adapt time 3000 ms
    [2024-11-01 17:50:29.130] [CH0] DFE_TAP_1 : -3
    [2024-11-01 17:50:29.146] [CH0] DFE_TAP_2 : 4
    [2024-11-01 17:50:29.146] [CH0] DFE_TAP_3 : 0
    [2024-11-01 17:50:29.146] [CH0] DFE_TAP_4 : 0
    [2024-11-01 17:50:29.146] [CH0] DFE_TAP_5 : 0

    ; this is when 0x02[6] does not set

    [2024-11-01 17:49:36.382] scan time 5000 ms
    [2024-11-01 17:49:36.382] WARNING: unexpected status pending, check stats
    [2024-11-01 17:49:36.382] [CH0] ERROR: SFP channel adaptation
    [2024-11-01 17:49:36.382] [CH0] DFE_TAP_1 : -6
    [2024-11-01 17:49:36.382] [CH0] DFE_TAP_2 : 0
    [2024-11-01 17:49:36.382] [CH0] DFE_TAP_3 : 2
    [2024-11-01 17:49:36.398] [CH0] DFE_TAP_4 : 0
    [2024-11-01 17:49:36.398] [CH0] DFE_TAP_5 : 0

  • I dont find the place to read CTLE coeffs. Please help.

    Also, is the HW reset clearing everything in the device? Do I need to assert other things in reg 0 to fully clone a POR device state?

    Thanks!

  • ; this is when 0x02[6] does not set

    scan time 5000 ms
    WARNING: unexpected status pending, check stats
    [CH0] ERROR: SFP channel adaptation
    [CH0] DFE_TAP_1 : 0
    [CH0] DFE_TAP_2 : 5
    [CH0] DFE_TAP_3 : 5
    [CH0] DFE_TAP_4 : 0
    [CH0] DFE_TAP_5 : 0
    [CH1] SOC channel status ok
    [CH1] SOC channel adapt time 700 ms
    [CH1] DFE_TAP_1 : -3
    [CH1] DFE_TAP_2 : 0
    [CH1] DFE_TAP_3 : 0
    [CH1] DFE_TAP_4 : 0
    [CH1] DFE_TAP_5 : 0
    WARNING: unexpected status, try to recover

    I have attached a register by register comparison betwen pass ( 0x02[6] gets set) and fail ( 0x02[6] is never set) cases. CTLE_STATUS maybe is important (is not described in datasheet)

    0x27 1a vs 17 = HEO value
    0x28 b0 vs 96 = VEO value
    0x29 60 vs 40 = 11 - +/-400mV vs 10 - +/- 300mV eyemon
    0x37 04 vs 13 = CTLE_STATUS ?????

  • Hi Aurel,

    Thanks for sharing your register dumps.  I'll review these and get back to you with feedback on Monday.

    Also, do you have access to our programming guide?  If not, please request access using the link below.  This guide has information about common register read/write sequences.

    https://www.ti.com/drr/opn/DS250DF230-DESIGN

    Thanks,
    Drew

  • Yes, I have it and the SW is done according to this doc.

  • Hi Drew. Ive implemented a recovery procedure. If the 0x02[6] is never set, I reset CDR on CH0. With this, I got 4 set failures from 200 test cycles.

    The DFE_TAP pattern looks similar in all cases, see below what was encountered:


    [2024-11-01 22:49:33.901] [CH0] ERROR: SFP channel adaptation
    [2024-11-01 22:49:33.917] [CH0] DFE_TAP_1 : -6
    [2024-11-01 22:49:33.917] [CH0] DFE_TAP_2 : 0
    [2024-11-01 22:49:33.917] [CH0] DFE_TAP_3 : 3
    [2024-11-01 22:49:33.917] [CH0] DFE_TAP_4 : 0
    [2024-11-01 22:49:33.917] [CH0] DFE_TAP_5 : 0

    [2024-11-01 23:00:36.044] [CH0] ERROR: SFP channel adaptation
    [2024-11-01 23:00:36.060] [CH0] DFE_TAP_1 : -6
    [2024-11-01 23:00:36.060] [CH0] DFE_TAP_2 : 0
    [2024-11-01 23:00:36.060] [CH0] DFE_TAP_3 : 1
    [2024-11-01 23:00:36.060] [CH0] DFE_TAP_4 : 0
    [2024-11-01 23:00:36.060] [CH0] DFE_TAP_5 : 0

    [2024-11-01 23:06:44.992] [CH0] ERROR: SFP channel adaptation
    [2024-11-01 23:06:44.992] [CH0] DFE_TAP_1 : -5
    [2024-11-01 23:06:44.992] [CH0] DFE_TAP_2 : 0
    [2024-11-01 23:06:44.992] [CH0] DFE_TAP_3 : 2
    [2024-11-01 23:06:45.007] [CH0] DFE_TAP_4 : 0
    [2024-11-01 23:06:45.007] [CH0] DFE_TAP_5 : 1

    [2024-11-02 00:02:01.621] [CH0] ERROR: SFP channel adaptation
    [2024-11-02 00:02:01.621] [CH0] DFE_TAP_1 : -6
    [2024-11-02 00:02:01.621] [CH0] DFE_TAP_2 : 0
    [2024-11-02 00:02:01.637] [CH0] DFE_TAP_3 : 2
    [2024-11-02 00:02:01.637] [CH0] DFE_TAP_4 : 0
    [2024-11-02 00:02:01.637] [CH0] DFE_TAP_5 : 0

  • Hi,

    Looking at your register comparison, CTLE is set to 0x00 in the case where 0x02[6] is set, and set to 0xFF in the case where 0x02[6] is not set.  Register 0x8F has the adapted CTLE boost value.

    In the case where 0x02[6] is not set, this implies that all CTLE values were swept and a suitable value was not identified.  This is surprising given that CTLE 0 works well.

    Can you try manually setting the CTLE value to 0 see if this resolves or improves your issue?  This can be done by setting channel register 0x2D[3] = 1, then setting channel register 0x03 = 000.

    Thanks,

    Drew

  • Hi Drew. See my inline comments mixed with terminal data:

    ; here we just timeout waiting for EQ_ADAPT; we see different DFE_TAP values

    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    scan time 5000 ms
    WARNING: unexpected status pending, check stats
    [CH0] ERROR: SFP channel adaptation
    [CH0] DFE_TAP_1 : -3
    [CH0] DFE_TAP_2 : 3
    [CH0] DFE_TAP_3 : 2
    [CH0] DFE_TAP_4 : 0
    [CH0] DFE_TAP_5 : 0
    [CH1] SOC channel status ok
    [CH1] SOC channel adapt time 700 ms
    [CH1] DFE_TAP_1 : -3
    [CH1] DFE_TAP_2 : 0
    [CH1] DFE_TAP_3 : 0
    [CH1] DFE_TAP_4 : 0
    [CH1] DFE_TAP_5 : 0
    WARNING: unexpected status, try to recover

    ; we check SOC RX side to understand how CH0 TX works, looks ok, RtmrEth(Link1Lane0).RxBlockLock and RtmrEth(Link1Lane0).CdrLock became true

    pc-sh# soc -e

    RtmrEth(Link1Lane0).RxBlockLock : false
    RtmrEth(Link1Lane0).CdrLock : true
    EphyEth(Link2Lane0).RxBlockLock : true
    EphyEth(Link2Lane0).CdrLock : true
    ExpifEth(Link2Lane1).RxBlockLock : false
    ExpifEth(Link2Lane1).CdrLock : false
    Xcvr1(Link3Lane0).CdrLock : false
    Xcvr1(Link3Lane1).CdrLock : false
    Xcvr1(Link3Lane2).CdrLock : false
    Xcvr1(Link3Lane3).CdrLock : false

    pc-sh# soc -e

    RtmrEth(Link1Lane0).RxBlockLock : true
    RtmrEth(Link1Lane0).CdrLock : true
    EphyEth(Link2Lane0).RxBlockLock : true
    EphyEth(Link2Lane0).CdrLock : true
    ExpifEth(Link2Lane1).RxBlockLock : false
    ExpifEth(Link2Lane1).CdrLock : false
    Xcvr1(Link3Lane0).CdrLock : false
    Xcvr1(Link3Lane1).CdrLock : false
    Xcvr1(Link3Lane2).CdrLock : false
    Xcvr1(Link3Lane3).CdrLock : false

    ; we read 8f for confirmation (=0xff)

    pc-sh# rtmrctrl -c 0 -r 0x8f

    [READ] REG = 0x8f VAL = 0xff

    ; we check status on CH0, ALL indicators are ok except EQ_OK (CDR_EQ_ADAPT_OK), the eye is decent (0.812UI and 500mV typical)

    pc-sh# rtmrctrl -s

    Display statistics
    [TOP]

    REFCLK_DET : true

    [SFP_RX/RTMR_CH0_RX]

    [CH0] SIG_DET : true
    [CH0] CDR_LOCK : true
    [CH0] SIG_DET_EVT : false
    [CH0] CDR_LOCK_EVT : false
    [CH0] SIG_DET_LOSS_EVT : false
    [CH0] CDR_LOCK_LOSS_EVT: false
    [CH0] EYE_OPEN_H : 0.6875 [UI]
    [CH0] EYE_OPEN_V : 496.875 [mV]
    [CH0] CDR_PPM_CHECK_OK : true
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_SIG_AMP_FAIL : false
    [CH0] CDR_DATA_RATE_OK : true
    [CH0] CDR_EQ_LCK_ERROR : false

    [SOC_RX/RTMR_CH1_RX]

    [CH1] SIG_DET : true
    [CH1] CDR_LOCK : true
    [CH1] SIG_DET_EVT : false
    [CH1] CDR_LOCK_EVT : false
    [CH1] SIG_DET_LOSS_EVT : false
    [CH1] CDR_LOCK_LOSS_EVT: false
    [CH1] EYE_OPEN_H : 0.90625 [UI]
    [CH1] EYE_OPEN_V : 575 [mV]
    [CH1] CDR_PPM_CHECK_OK : true
    [CH1] CDR_EQ_ADAPT_OK : true
    [CH1] CDR_SIG_AMP_FAIL : false
    [CH1] CDR_DATA_RATE_OK : true
    [CH1] CDR_EQ_LCK_ERROR : false

    ; trying the suggestion, in 0x3 is already 0 so I think 0x2d 0x08 0x08 is immediatiately action, see eye change


    pc-sh# rtmrctrl -c 0 -w 0x2d 0x08 0x08


    pc-sh# rtmrctrl -s

    Display statistics
    [TOP]

    REFCLK_DET : true

    [SFP_RX/RTMR_CH0_RX]

    [CH0] SIG_DET : true
    [CH0] CDR_LOCK : true
    [CH0] SIG_DET_EVT : false
    [CH0] CDR_LOCK_EVT : false
    [CH0] SIG_DET_LOSS_EVT : false
    [CH0] CDR_LOCK_LOSS_EVT: false
    [CH0] EYE_OPEN_H : 0.8125 [UI]
    [CH0] EYE_OPEN_V : 506.25 [mV]
    [CH0] CDR_PPM_CHECK_OK : true
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_SIG_AMP_FAIL : false
    [CH0] CDR_DATA_RATE_OK : true
    [CH0] CDR_EQ_LCK_ERROR : false

    [SOC_RX/RTMR_CH1_RX]

    [CH1] SIG_DET : true
    [CH1] CDR_LOCK : true
    [CH1] SIG_DET_EVT : false
    [CH1] CDR_LOCK_EVT : false
    [CH1] SIG_DET_LOSS_EVT : false
    [CH1] CDR_LOCK_LOSS_EVT: false
    [CH1] EYE_OPEN_H : 0.90625 [UI]
    [CH1] EYE_OPEN_V : 562.5 [mV]
    [CH1] CDR_PPM_CHECK_OK : true
    [CH1] CDR_EQ_ADAPT_OK : true
    [CH1] CDR_SIG_AMP_FAIL : false
    [CH1] CDR_DATA_RATE_OK : true
    [CH1] CDR_EQ_LCK_ERROR : false


    pc-sh# rtmrctrl -c 0 -r 0x03

    [READ] REG = 0x03 VAL = 0x00

    pc-sh# rtmrctrl -c 0 -r 0x2d

    [READ] REG = 0x2d VAL = 0x38

    pc-sh# rtmrctrl -c 0 -w 0x03 0x00 0x00


    pc-sh# rtmrctrl -s

    Display statistics
    [TOP]

    REFCLK_DET : true

    [SFP_RX/RTMR_CH0_RX]

    [CH0] SIG_DET : true
    [CH0] CDR_LOCK : true
    [CH0] SIG_DET_EVT : false
    [CH0] CDR_LOCK_EVT : false
    [CH0] SIG_DET_LOSS_EVT : false
    [CH0] CDR_LOCK_LOSS_EVT: false
    [CH0] EYE_OPEN_H : 0.8125 [UI]
    [CH0] EYE_OPEN_V : 506.25 [mV]
    [CH0] CDR_PPM_CHECK_OK : true
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_SIG_AMP_FAIL : false
    [CH0] CDR_DATA_RATE_OK : true
    [CH0] CDR_EQ_LCK_ERROR : false

    [SOC_RX/RTMR_CH1_RX]

    [CH1] SIG_DET : true
    [CH1] CDR_LOCK : true
    [CH1] SIG_DET_EVT : false
    [CH1] CDR_LOCK_EVT : false
    [CH1] SIG_DET_LOSS_EVT : false
    [CH1] CDR_LOCK_LOSS_EVT: false
    [CH1] EYE_OPEN_H : 0.90625 [UI]
    [CH1] EYE_OPEN_V : 575 [mV]
    [CH1] CDR_PPM_CHECK_OK : true
    [CH1] CDR_EQ_ADAPT_OK : true
    [CH1] CDR_SIG_AMP_FAIL : false
    [CH1] CDR_DATA_RATE_OK : true
    [CH1] CDR_EQ_LCK_ERROR : false

    ; starting PRBS to see if ok; unfortunately, PRBS checker has in code a CDR reset which ussually recovers the equalizer


    pc-sh# rtmrctrl -c 1 -a 1 -g

    Enable PRBS generator

    pc-sh# rtmrctrl -c 0 -a 1 -k

    Enable PRBS checker
    [CH0] PRBS_INVERTED : false
    [CH0] PRBS_DETECTED : true
    [CH0] PRBS_SEQUENCE_OK : true
    scan for CDR alarms
    [CH0] CDR_LOCK : false
    [CH0] CDR_LOCK_LOSS_EVT: true
    [CH0] CDR_PPM_CHECK_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_LCK_ERROR : true
    [CH0] CDR_LOCK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_LCK_ERROR : true
    [CH0] CDR_LOCK_EVT : true
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    [CH0] CDR_EQ_ADAPT_OK : false
    scan time 4200 ms
    [CH0] SFP channel status ok
    [CH0] SFP channel adapt time 3300 ms
    [CH0] DFE_TAP_1 : 0
    [CH0] DFE_TAP_2 : 5
    [CH0] DFE_TAP_3 : 0
    [CH0] DFE_TAP_4 : 0
    [CH0] DFE_TAP_5 : 0
    [CH1] SOC channel status ok
    [CH1] SOC channel adapt time 0 ms
    [CH1] DFE_TAP_1 : -3
    [CH1] DFE_TAP_2 : 0
    [CH1] DFE_TAP_3 : 0
    [CH1] DFE_TAP_4 : 0
    [CH1] DFE_TAP_5 : 0

    pc-sh#

  • Hi Aurel,

    Thanks for sharing your results.  I'm working on reviewing these and will get back to you shortly.

    Thanks,

    Drew

  • Hi Aurel,

    Thanks for sharing.  It looks like CH0 eye improves when CTLE is set to 0x00 instead of 0xFF.

    Do you observe bit errors when CH0 CTLE is set to 0xFF?  Also, do you observe bit errors when CH0 CTLE is set to 0x00?

    Thanks,

    Drew

  • Hi Drew. Will delay a bit this investigation some other priorities jumped in )next week).

    Just FYI, I have tested two DUTs with 150/300m 50/125um fiber and tested the EQ adapt. I dont see the issue in this configuration, maybe is related to loopback and how the sfp/retimer/soc work together in loopback. I will look into this but later.

  • Hi Aurel,

    I'm speculating that it may be possible that there is a higher likelihood of over-equalization for a loopback module.

    Let me know when you have other updates.

    Thanks!

    Drew