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.

DS280MB810: Register settings for improving communication error

Part Number: DS280MB810
Other Parts Discussed in Thread: DS280DF810

Hi Team

We are evaluating communication test (25G) with the setups by using QSFP28+DS280MB810+SWLSI.

Almost QSFP28s have no problems for communication test. In this case, register settings are below,

REG_0x03: 0xC0, REG_0x04: 0x91, REG_0x06: 0xC0, REG_0x0F: 0x00 for all channel. (CTLE Boost Settings are below)

But one QSFP28 cannot be made error free. Changing CTLE Boost Settings from above becomes getting worse.

It is known that changing REG_0x0F: BG_SEL_IPP100[0/1], BG_SEL_IPH200_v0/1[0/1] will improve the situation. But it is not enough.

What is the pre-driver and driver in BG_SEL_IPH200?  Boost1 and Boost2 ?

If we see improvement in these registers, what can we infer is wrong with this QSFP28 compared to other QSFP28s?   Insufficient bandwidth?, insufficient amplitude?

Also, could you let us know if there are any other registers that could be improved?

How about REG_0x08: BG_SEL_IPTAT25?

Best Regards,

Mizobuchi

  • Hi Mizobuchi,

    I am discussing this with the team and will get back to you with more details this weeks.

    Thanks,

    Drew

  • Hi Drew-san

    I am waiting for your response.

    We need to use DS280MB810 to develop our Ethernet switch for 25G.

    So, we have to resolve this issue as soon as possible

    Thanks

    Kenji Mizobuchi

  • Hi Mizobuchi-san,

    I understand that this is a high priority request and am working to get you more information regarding the impact of the bias currents.

    It is known that changing REG_0x0F: BG_SEL_IPP100[0/1], BG_SEL_IPH200_v0/1[0/1] will improve the situation. But it is not enough.

    Did you try adjusting BG_SEL_IPP100[2] in reg 0x04 in addition to BG_SEL_IPP100[1:0]?

    What is the pre-driver and driver in BG_SEL_IPH200?  Boost1 and Boost2 ?

    These are bias currents for the pre-driver and driver within the redriver.  These are separate from boost which is part of the CTLE stage.

    Is there a system block diagram you could share? Looking at your redriver settings, it appears the redriver is implemented in a low insertion loss application.  Can you share details about insertion loss in your application?

    You mention one QSFP28 has errors.  Is there any difference in layout when comparing this QSFP28 to other QSFP28 in your system that could help us understand what is unique about this QSFP28?

    Thanks,

    Drew

  • Hi Drew-san

    Did you try adjusting BG_SEL_IPP100[2] in reg 0x04 in addition to BG_SEL_IPP100[1:0]?

    =>Yes, but there was not much change.

    Is there a system block diagram you could share? Looking at your redriver settings, it appears the redriver is implemented in a low insertion loss application.  Can you share details about insertion loss in your application?

    => Our system block diagram is simple. RX side: QSFP28 ->impedance line(max44mm)->DS280MB810->impedance line(max80mm)->SWLSI. So we think that insertion loss is under 2dB. 

    Another thing, You have re-timer IC with cross-point SW. But power consumption is very high..

    You mention one QSFP28 has errors.  Is there any difference in layout when comparing this QSFP28 to other QSFP28 in your system that could help us understand what is unique about this QSFP28?

    => There is a DSP chip in this QSFP28. And this QSFP28 has breakout function. 

  • Hi Mizobuchi-san,

    Thanks for the additional details.

    To clarify, the QSFP28 module with DSP chip performs worse than other modules?

    Thanks,

    Drew

  • Hi Drew-san

    Yes, the QSFP28 module with DSP chip performs worse than other modules.

    Thanks,

    Kenji Mizobuchi

  • Hi Mizobuchi-san,

    Thanks for the clarification.  Do you have any control of transmitter settings on DSP in the QSFP28 module?

    I discussed with a colleague and the primary impact to increasing the bias currents you mentioned are (1) increased swing of internal signals in the device and (2) improved linearity as long as current increase is not excessive (>20%).  We'd recommended not exceeding a 20% increase in bias currents as this may impact long term reliability.

    Since you're having issues with QSFP28 module that has DSP, I wonder if you're running into either over equalization or linearity issues.  If there is some way to adjust DSP TX settings, this might have positive impact.

    Also, can you clarify what SWLSI is?  Is this a SERDES ASIC?

    Thanks,

    Drew 

  • Hi Mizobuchi-san,

    We don't expect BG_SEL_IPTAT25 to have significant impact on performance since this is only a 5% increase in current, but it is worth trying.

    Are you using the device in straight mode or cross mode?

    You might also try adjusting ch_reg_0x10[3:2] and ch_reg_0x17[5:0].  Both of these control internal bias currents, higher values result in larger bias currents.

    Please let us know how this impacts performance.

    Thanks,

    Drew

  • Hi Drew-san

    Do you have any control of transmitter settings on DSP in the QSFP28 module?

    =>Yes, but now we are confirming if user can change the setting on DSP in the QSFP28 module. 

        Does the comment of transmitter settings on DSP above mean DSP setting for RX side of QSFP28 ?

    I discussed with a colleague and the primary impact to increasing the bias currents you mentioned are (1) increased swing of internal signals in the device and (2) improved linearity as long as current increase is not excessive (>20%).  We'd recommended not exceeding a 20% increase in bias currents as this may impact long term reliability.

    =>Does the comment of the bias currents above mean BG_SEL_IPP100[1/0] or BG_SEL_IPH200_v1[1/0] or BG_SEL_IPH200_v0[1/0] ?

       About (1) increased swing of internal signals in the device, can this effect also be obtained by increasing the RX output amplitude of QSFP28 ?

       About (2) improved linearity as long as current increase is not excessive (>20%), I made a wrong comment before about BG_SEL_IPP100[2] in reg 0x04.

      When we try adjusting BG_SEL_IPP100[2] in reg 0x04 in addition to BG_SEL_IPP100[1:0] (>20%), output amplitude of DS280MB810 became almost 0. Is this expected behavior?

      We confirmed that increasing BG_SEL_IPP100[1/0] up to 15% improve the communication error.

    As additional information,

    About driver bias current, we confirmed that increasing BG_SEL_IPH200_v0[1/0]  up to 37.5% gradually reduce the communication error.

    About pre-driver bias current, it seems that increasing BG_SEL_IPH200_v1[1/0]  up to 37.5% gradually increase the communication error. There are still some things that are not clear.

    What is the function difference between driver and pre-driver ?

    And we confirmed that BG_SEL_IPTAT25 is not effective.

    Also, can you clarify what SWLSI is?  Is this a SERDES ASIC?

    =>SWLSI is industrial 25G Ethernet switch LSI which provides SERDES function.

    Are you using the device in straight mode or cross mode?

    =>We will check it. Does the mode have something to do with characteristics of communication ?

    You might also try adjusting ch_reg_0x10[3:2] and ch_reg_0x17[5:0].  Both of these control internal bias currents, higher values result in larger bias currents.

    => Thank you for your information. But ch_reg_0x10[3:2] and ch_reg_0x17[5:0] are not listed in the data sheet. Could you please provide us with detail information regarding the settings ?

    Thanks,

    Kenji Mizobuchi

  • Hi Drew-san

    Are you using the device in straight mode or cross mode?

    => We are using the device in cross mode.

    Thanks,

    Kenji Mizobuchi

  • Hi Drew-san

    When we use the device in cross mode, one side (input and output) is open.

    Thanks,

    Kenji Mizobuchi

  • Hi Drew-san

    We checked ch_reg_0x10[3:2] and ch_reg_0x17[5:0].

    Initial value were below, Is this value is correct ?

    ch_reg_0x10: 0x00

    ch_reg_0x17: 0x14

    We tried adjusting ch_reg_0x10[3:2] and ch_reg_0x17[5:0], but not so effective.

    Thanks,

    Kenji Mizobuchi

  • Hi Mizobuchi-san,

    Initial value were below, Is this value is correct ?

    ch_reg_0x10: 0x00

    ch_reg_0x17: 0x14

    Yes, this matches my expectations.  We are looking to see if there are any other registers you might be able to try adjusting.

    We tried adjusting ch_reg_0x10[3:2] and ch_reg_0x17[5:0], but not so effective.

    Can you expand a bit on your observations?  Did they have any negative impact on BER, or just no significant positive impact?

    Thanks,

    Drew

  • Hi Mizobuchi-san,

    Can you also try adjusting ch_reg_0x10[5:4] and ch_reg_0x10[1:0]?

    Thanks,

    Drew

  • Hi Drew-san

    Our trials are below,

    1. Fixing ch_reg_0x17=0x14, adjusting ch_reg_0x10=0x00, 0x04, 0x08, 0x0C => no positive and negative impact for frame error. it means that almost no changes for frame error.

    2. Fixing ch_reg_0x10=0x00, adjusting ch_reg_0x17=0x00, 0x0F, 0x14, 0x1F, 0x2F, 0x3F => no positive and negative impact for frame error. it means that almost no changes for frame error.

    Is there usually any impact?

    Thanks,

    K. Mizobuchi 

  • Hi Mizobuchi-san,

    I appreciate the additional details on impact of ch_reg_0x10[3:2] and ch_reg_0x17[5:0].  In a typical customer application, it's not necessary to adjust these bias currents, so it's challenging to say if there is usually any impact based on my experience.

    Looking forward to hearing if adjusting the other bias currents in ch_reg_0x10[5:4] and ch_reg_0x10[1:0] has any impact.  Beyond this, I'm not aware of any other adjustments that can be made to the device.

    Thanks,

    Drew

  • Hi Drew-san

    We checked ch_reg_0x10[5:4] and ch_reg_0x10[1:0] . The results are below,

    ・ch_reg_0x10[1:0]: As the value increases, the errors increase.(value 0x01, 0x02, 0x03)

    ・ch_reg_0x10[5:4]: As the value increases, the errors increase.(value 0x10, 0x20, 0x30)

    ・ch_reg_0x10[3:2]: Even if the value is increased, there is almost no change in the error.(value 0x04, 0x08, 0x0C)

    ・ch_reg_0x17[5:0]: Even if the value is increased, there is almost no change in the error.(value 0x00 - 0x3F)

    Do these four settings have different functions?

    Thanks,

    K.Mizobuchi

  • Hi Drew-san

    The connection diagram(Cross-over mode) of SWLSI, DS280MB810, and QSFP28 is shown below.

    ・Is there anything you notice about the connection?

    ・The error tends to be particularly large on CH1. Is there a cause that affects CH1 in DS280MB810? power noise etc ?

    Thanks,

    K.Mizobuchi

  • Hi Mizobuchi-san,

    Thanks for sharing your block diagram.  I don't see anything unusual with your application.

    I'm not aware of any performance discrepancy on CH1 compared to the other channels.  My hypothesis is that this is related to either system specific signal integrity behavior (variation in PCB on CH1) or some sort of device specific channel-to-channel performance variation.

    Thanks as well for sharing your observations related to the different settings in registers 0x10 and 0x17.  Yes, these settings all have different functions.  Settings in register 0x10 are related to bias currents for some internal buffers that support the device crosspoint.  The setting in register 0x17 is related to one of the biases for CTLE.

    My current hypothesis is that due to DSP in QSFP28 module and low insertion loss between module and redriver, this is causing a signal integrity issue.  One other thought would be is it possible to adjust either the transmitter settings of the DSP or the receiver settings of the SWLSI?

    Thanks,
    Drew

  • Hi Drew-san

    We attached bypass capacitor layout drawing of DS280MB810.

    If there is something wrong with the capacitors value or placement, could you please give us some advice?

    Thanks,

    K.Mizobuchi

  • Hi Mizobuchi-san,

    The schematic looks good.  Are there any GND or power planes implemented in your layout for the bypass capacitors?  For reference, please see below how the layout was handled for DS280MB810 EVM.

    Thanks,
    Drew

  • Hi Drew-san

    Our board has 14 layers. 6 layers of the 14 layers are GND planes for DS280MB810 as shown below,

    and 1 layer of the 14 layers is the 2.5V power supply planes for DS280MB810 as shown below.

    Thanks,

    Kenji Mizobuchi

  • Hi Drew-san

    We would like to know each channel input amplitude of DS280MB810, but in the datasheet, DS280MB810 has no input amplitude monitor and eye scan function. Do you have any idea to confirm the input amplitude of DS280MB810 ?

    And we started to evaluate re-timer DS280DF810, too.

    Thanks,

    Kenji Mizobuchi

  • Hi Mizobuchi-san,

    I don't see any issues with your decoupling capacitor layout.

    Unfortunately, as you noted, DS280MB810 does not have any input amplitude monitor or eye scan.  The only similar indicator I can think of is the signal detect indicator.  However, this only indicates if a signal is present, but does not provide a good measurement of amplitude.

    Regarding DS280DF810, are you evaluating it in the same system, or is this a separate application?  Please let us know if you have any questions about it.

    Thanks,

    Drew 

  • Hi Drew-san

    Regarding DS280DF810, are you evaluating it in the same system, or is this a separate application? 

    Yes, we are evaluating in the same system. 

     We measured the HEO and VEO by using DS280DF810.

    Does VEO mV =Reg_0x28 x3.125 mean differential value ?

    Does VEO mean Eye height not amplitude ?

    Our measurement  value of HEO was 0.5 to 0.65UI

    Our measurement value of VEO was 240 to 300mV

    Is this value a bad value?

    Thanks,

    K. Mizobuchi

  • Hi Mizobuchi-san,

    You are correct, VEO refers to the differential measurement of the eye height.

    For our retimers, we have empirically observed that we generally have good bit error rate performance if we can observe a HEO/VEO of at least 0.4UI/200mVppd based on the internal eye monitor.

    With HEO of 0.5UI and VEO of 240mV, I anticipate that you would observe good BER performance. Is this consistent with your observations?  If needed, you can use the retimer's PRBS generator/checker for additional testing.  Note that the PRBS generator requires CDR lock in order to generate a pattern.

    Thanks,

    Drew

  • Hi Drew-san

    Thank you for your comment.

    Now, we are evaluating DS280DF810. But as expected, power consumption is very high.

    So, it is important for us to reduce power consumption.

    According to the data sheet, Address 0x3D Bit 7 Disable pre- and Post-cursor FIR _lower power is described.

    How effective is it?

    Could you please let us know if there are any other registers that have the effect of reducing power consumption?

    And

    In our usage, we only use 4 out of 8 channels, is there a way to reduce the power consumption of unused channels as much as possible?

    (for example, disable CTLE, DFE, CDR, output driver etc)

    Thanks,

    K.Mizobuchi

  • Hi,

    Drew was out today, but he will be back tomorrow (Tuesday USA time.) He will get back to you on these open questions.

    Regards,

    Rodrigo Natal

  • Hi Rodrigo-san

    We got it.

    Hi Drew-san

    We try to reduce power consumption of DS280DF810 based on DS2x0DFxx0_SNLU182G_Programmers_Guide_Confidential.pdf.

    We think that key point is disable the function of unused channel. We want to use 7.33 Disable Unused Channels.

    But We use "Cross-over mode". So, we do not know how to set the registers. Our cross-over mode is below,

    Based on the above cross over mode, could you please tell us how to select commands to disable each function of channels that are not used?

    Is it possible to disable the CDR function of unused CHs? For example, always keep the reset state?

    Thanks,

    K.Mizobuchi

  • Hi Mizobuchi-san,

    Based on the above cross over mode, could you please tell us how to select commands to disable each function of channels that are not used?

    First, configure all 8 channels for A-->B and B--> A channels crossing mode. This can be done by following Table 7-42 in the programming guide. Next, disable channels 1, 3, 5, and 7 following the procedure in table 7-48. Assuming channels crossing mode was configured correctly, ch1 register set will control ch1 transmitter blocks and ch0 receiver blocks. Same applies for channels 3, 5, and 7.

    Is it possible to disable the CDR function of unused CHs? For example, always keep the reset state?

    It's not possible to disable the CDR block.

    According to the data sheet, Address 0x3D Bit 7 Disable pre- and Post-cursor FIR _lower power is described.

    How effective is it?

    Disabling pre- and post-cursor FIR will save a very small, almost negligible amount of power.

    Could you please let us know if there are any other registers that have the effect of reducing power consumption?

    You could disable the DFE to save some more power. Note that not using DFE could have some affect on the signal conditioning performance of the retimer. To disable DFE, follow the procedure in table 7-26 of the programming guide. Power consumption saved is shown in the specifications section of the datasheet.

    Best,

    Lucas

  • Hi Lucas-san

    First, configure all 8 channels for A-->B and B--> A channels crossing mode. This can be done by following Table 7-42 in the programming guide. Next, disable channels 1, 3, 5, and 7 following the procedure in table 7-48. Assuming channels crossing mode was configured correctly, ch1 register set will control ch1 transmitter blocks and ch0 receiver blocks. Same applies for channels 3, 5, and 7.

    We tried the method above, but it doesn't seem to be working correctly.

    In state of crossing mode, when ch0 was disabled, the transmit signal of ch0 appeared to be disabled. In other words, the transmitter blocks of ch0 appear to be disabled. On the other hand, when ch1 was disabled, the transmit signals of ch0 and ch1 appeared to be disabled. In other words, the transmitter blocks of ch0 and ch1 appear to be disabled. Same results were obtained for ch2 and ch3, ch4 and ch5, ch6 and ch7.

    Our register setting are shown below. Could you please confirm if this is the correct settings?

    case1  disabling ch0 in state of crossing mode

    write 0xfc 0x01     Select CH0 for read operation
    write 0xff 0x03      Select CH registers and enable broadcast mode to write to all CH
    write 0x00 0x04    Reset CH registers, self cleaning
    write 0x0a 0x0c    Assert CDR reset
    write 0x2f 0x54    Select 25.78125 standard rate mode (default)
    write 0x31 0x00   Set No Adaption
    write 0x1e 0xe9   DFE tap disable. PFD frequency detector enable
    write 0x3d 0x00   FIR disable. CTLE. Pre- Post-disable.
    write 0x3f 0x40    POST-CUESOR(0x3F):0negative
    write 0x3e 0x40   PRE-CUESOR(0x3E):0 negative
    write 0x95 0x08   EQ enable 1000
    write 0x96 0x06   EQ_EN_FANOUT, EQ_SEL_XPNT

    write 0xfc 0x01    select target CH0
    write 0xff 0x01     select each register
    write 0x15 0x18   Power down the driver
    write 0x14 0x44   Force signal detect status to 0
    write 0x13 0xF0   Power down signal detect block

    write 0x0a 0x00  Release CDR reset

    case2  disabling ch1 in state of crossing mode

    write 0xfc 0x01   Select CH0 for read operation
    write 0xff 0x03    Select CH registers and enable broadcast mode to write to all CH
    write 0x00 0x04  Reset CH registers, self cleaning
    write 0x0a 0x0c  Assert CDR reset
    write 0x2f 0x54   Select 25.78125 standard rate mode (default)
    write 0x31 0x00  Set No Adaption
    write 0x1e 0xe9  DFE tap disable. PFD frequency detector enable
    write 0x3d 0x00  FIR disable. CTLE. Pre- Post-disable.
    write 0x3f 0x40   POST-CUESOR(0x3F):0negative
    write 0x3e 0x40  PRE-CUESOR(0x3E):0 negative
    write 0x95 0x08  EQ enable 1000
    write 0x96 0x06  EQ_EN_FANOUT, EQ_SEL_XPNT

    write 0xfc 0x02  select target CH1
    write 0xff 0x01     select each register
    write 0x15 0x18   Power down the driver
    write 0x14 0x44   Force signal detect status to 0
    write 0x13 0xF0   Power down signal detect block

    write 0x0a 0x00  Release CDR reset

    Thanks,

    K.Mizobuchi

  • Hi Mizobuchi-san,

    I see multiple issues with your register write sequences.

    Case 1:

    • I don't recommend holding the CDR in reset while configuring the cross point and powering down the channel. You should release CDR reset by writing reg 0x0A=0x00 before configuring the cross point.
    • When configuring the cross point, I don't recommend broadcast writing to all channels. You should follow the procedure exactly as its given in Table 7-42 in the programming guide. This includes issuing a CDR reset to channel A after configuring channel A, then configuring channel B, then issuing a CDR reset to channel B.
    • Assuming cross point was configured in channels crossing mode correctly, I expect that disabling channel 0 will mute the transmit signal of ch0. Ch0 register set will correspond to the transmitter blocks of ch0 and the receiver blocks of ch1.

    Case 2:

    • If you follow the recommendations I gave for case 1 and follow the procedure in Table 7-42 exactly as it's given, I expect that disabling channel 1 will mute the transmit signal of only ch1 and power down the signal detect block of only ch0.

    Can you try again following my recommendations and share your results?

    Note that Thursday and Friday are US National holidays and my team will not be in office. We can continue supporting on Monday.

    Best,

    Lucas

  • Hi Lucas-san

    Thank you for your advice.

    We will try again following register sequence.

    [for all registers]
    write 0xfc 0x01 Select CH0 for read operation
    write 0xff 0x03 Select CH registers and enable broadcast mode to write to all CH
    write 0x00 0x04 Reset CH registers, self cleaning
    write 0x0a 0x0c Assert CDR reset
    write 0x2f 0x54 Select 25.78125 standard rate mode (default)
    write 0x31 0x00 Set No Adaption
    write 0x1e 0xe9 DFE tap disable. PFD frequency detector enable
    write 0x3d 0x00 FIR disable. CTLE. Pre- Post-disable.
    write 0x3f 0x40 POST-CUESOR(0x3F):0negative
    write 0x3e 0x40 PRE-CUESOR(0x3E):0 negative
    write 0x0a 0x00  Release CDR reset

    [Channel A crossing mode]
    write 0xfc 0x55 select target CH(s)_Channel A (0,2,4,6): 01010101=55
    write 0xff 0x01 Select CH registers
    write 0x95 0x08 Set EQ_enable to 1
    write 0x96 0x00 set EQ en _local to 0
    write 0x96 0x04 set EQ en_fanout to 1
    write 0x96 0x04 set EQ xpnet_slave to 0
    write 0x96 0x06 set EQ sel_xpt to 1
    write 0x96 0x06 set EQ xpnet_slave to 0
    write 0x0a 0x0c Assert CDR reset
    write 0x0a 0x00 Release CDR reset

    [Channel B crossing mode]
    write 0xfc 0xAA select target CH(s)_Channel B (1,3,5,7): 10101010=AA
    write 0xff 0x01 Select CH registers
    write 0x95 0x08 Set EQ_enable to 1
    write 0x96 0x00 set EQ en _local to 0
    write 0x96 0x04 set EQ en_fanout to 1
    write 0x96 0x04 set EQ xpnet_slave to 0
    write 0x96 0x06 set EQ sel_xpt to 1
    write 0x96 0x06 set EQ xpnet_slave to 0
    write 0x0a 0x0c Assert CDR reset
    write 0x0a 0x00 Release CDR reset

    [for disable ch0,ch2,ch4,ch6 transmitter block and disable ch1,ch3,ch5,ch7 receiver block ]
    write 0xfc 0x55 select target CH(s)_Channel A (0,2,4,6): 01010101=55
    write 0xff 0x01 Select CH registers
    write 0xff 0x01 Select CH registers
    write 0x15 0x18  Power down the driver
    write 0x14 0x44  Force signal detect status to 0
    write 0x13 0xF0  Power down signal detect block

    Thanks,

    Kenji Mizobuchi

  • Hi Lucas-san

    We tried the register sequence above.

    But it doesn't seem to be working correctly. 

    After setting [Channel A crossing mode] and [Channel B crossing mode], when ch0 was disabled, the transmit signal of ch0 appeared to be disabled. In other words, the transmitter blocks of ch0 appear to be disabled, not the transmitter block of ch1. On the other hand, when ch1 was disabled, the transmit signals of ch0 and ch1 appeared to be disabled. In other words, the transmitter blocks of ch0 and ch1 appear to be disabled. It is not correct behavior.

    Is there something wrong with the above settings?

    First, configure all 8 channels for A-->B and B--> A channels crossing mode. This can be done by following Table 7-42 in the programming guide. Next, disable channels 1, 3, 5, and 7 following the procedure in table 7-48. Assuming channels crossing mode was configured correctly, ch1 register set will control ch1 transmitter blocks and ch0 receiver blocks. Same applies for channels 3, 5, and 7.

    Has this behavior been confirmed by TI?

    Thanks,

    Kenji Mizobuchi

  • Hi Mizobuchi-san,

    I am reviewing and will have more details tomorrow.  Thanks for your patience.

    Thanks,

    Drew

  • Hi Drew-san

    First, configure all 8 channels for A-->B and B--> A channels crossing mode. This can be done by following Table 7-42 in the programming guide. Next, disable channels 1, 3, 5, and 7 following the procedure in table 7-48. Assuming channels crossing mode was configured correctly, ch1 register set will control ch1 transmitter blocks and ch0 receiver blocks. Same applies for channels 3, 5, and 7.

    We investigated the above again. We found out the following.

    It seems that it is the same whether choosing crossing mode or straight mode for setting register channels.

    When controlling ch1 transmitter block,  need to control ch1. When controlling ch0 receiver block, need to control ch0. Same applies for another channels.

    Please check it.

    Thanks,

    K.Mizobuchi

  • Hi Mizobuchi-san,

    I reviewed your configuration sequence and it looks good.

    Our expectation was that signal detect behavior would be paired to the output channel, as described below.  However, it's possible that since forcing signal detect disable/power down is not commonly expected for device configuration, this functionality may not be controlled by the "TX" channel in crosspoint configuration.  If this is the case, I think your observations make sense.  I'll check and see if this is reproducible on our end.

    Thanks,

    Drew