• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 4 answers
  • Subscribers 33 subscribers
  • Views 484 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

DS250DF230: Maximum achievable copper trace length with Re-timer for 25G applications

DS250DF230: Maximum achievable copper trace length with Re-timer for 25G applications spice model

nandhakumar s
Prodigy 40 points
Part Number: DS250DF230

1. In Our design we are using two DS250DF230. Is it possible to provide a SPICE model for TINA?

 

  • 0
    Prodigy 40 points

    We are using this in the SFP28 where we will receive PTP + SYCNE. 

    Due to high trace length (500mm) we are using active cable method implementation in PCB itself ( two retimer per TX and two retimer per RX channel)

    From the datasheet, I understand that <500ps latency will be there per retimer , Since we are having two retimer. I am expecting 1nS latency.

    Since ours is a PTP steered system. We should expect this 1nS time delay in our PTP? or some more latency will also get added?

    Note:- retimer reference 30.72 Mhz is provided by the separate oscillator. this will not be in sync with the PTP

    (is this an issue ? do we need to steer the retimer reference clock as well as be ptp steered ?)

  • 0
    TI__Mastermind 19235 points

    The maximum copper trace length depends on the dielectric material used and channel performance. The retimer Rx EQ (DFE + CTLE) can typically compensate up to 35dB of insertion loss at 25Gbps.

    You may request download access to the DS250DF230 IBIS-AMI model files via the TI.com product page. See link below.

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

    Thanks,

    Rodrigo Natal

  • 0 in reply to Rodrigo Natal
    Prodigy 40 points

    thanks rodrigo,

    " We are using this in the SFP28 where we will receive PTP + SYCNE. 

    Due to high trace length (500mm) we are using active cable method implementation in PCB itself ( two retimer per TX and two retimer per RX channel)

    From the datasheet, I understand that <500ps latency will be there per retimer , Since we are having two retimer. I am expecting 1nS latency.

    Since ours is a PTP steered system. We should expect this 1nS time delay in our PTP? or some more latency will also get added?

    Note:- retimer reference 30.72 Mhz is provided by the separate oscillator. this will not be in sync with the PTP

    (is this an issue ? do we need to steer the retimer reference clock as well as be ptp steered ?)  "

    Please provide details for this query as well. If this is not clear please let me know

  • 0 in reply to nandhakumar s
    TI__Mastermind 19235 points

    See my inputs below.

    From the datasheet, I understand that <500ps latency will be there per retimer , Since we are having two retimer. I am expecting 1nS latency. Since ours is a PTP steered system. We should expect this 1nS time delay in our PTP? or some more latency will also get added?

    • This is a fair estimate, for the case where both retimer channels already have CDR lock to the data

    Retimer reference 30.72 Mhz is provided by the separate oscillator. this will not be in sync with the PTP. Is this an issue ?

    This is not an issue. The 30.72MHz calibration clock does not actually feed into the data path. it is mainly used by the retimer digital logic to serve as reference for the PPM check function. Each retimer channel will recover the clock from the input data and then this recovered clock serves as reference to the sampler.

    Regards,

    Rodrigo

  • 0 in reply to Rodrigo Natal
    Prodigy 40 points
    nandhakumar s said:
    Due to high trace length (500mm) we are using active cable method implementation in PCB itself ( two retimer per TX and two retimer per RX channel)

    As mentioned earlier we are using the active cable method in PCB, Currently, we are using one oscillator cascaded to all four retimer with the help of CAL_CLK_OUT.

    In this way, we need to route the lvcmos clock also along with high-speed signal.

    Can we have two seperate clocks for each retimer pair? as mentioned in the image. will this affect the system in any way?

  • 0 in reply to nandhakumar s
    Prodigy 40 points
    nandhakumar s said:
    Due to high trace length (500mm) we are using active cable method implementation in PCB itself ( two retimer per TX and two retimer per RX channel)

    As mentioned earlier we are using the active cable method in PCB, Currently, we are using one oscillator cascaded to all four retimer with the help of CAL_CLK_OUT.

    In this way, we need to route the lvcmos clock also along with high-speed signal.

    Can we have two seperate clocks for each retimer pair? as mentioned in the image. will this affect the system in any way?

    Please help us in this,

    Can you please verify our SCH if I have made any mistake in the 4 retimer solution in SFP?

    6787.retimer.pdf

  • 0 in reply to nandhakumar s
    TI__Mastermind 19235 points

    Regarding: "Can we have two seperate clocks for each retimer pair? as mentioned in the image. will this affect the system in any way?"

    • Yes, that's not an issue
  • 0 in reply to nandhakumar s
    TI__Mastermind 19235 points

    Schematic inputs below. No problem identified, just a comment on the high-speed I/O AC coupling caps.

    Checked and ok

    • VDD filtering and decoupling
    • CAL_CLK_IN -> 30.72MHz oscillator reference
    • ADDR pin strap options
    • SCL and SDA
    • EN_SMB -> 1kOhm pullup to VDD for normal operation in SMBus Slave Mode
    • READ_EN_EN -> floating with EN_SMB=1, for SMBus Slave Mode operation
    • ALL_DONE_N
    • INT_N
    • TEST0 floating
    • TEST1 -> 1kohm pulldown to GND

    Comment

    • High-speed inputs and outputs
      • External AC coupling caps implemented on retimer interfaces to host ASIC/FPGA. This is good
      • It looks like external AC coupling caps are implemented on some interfaces to SFP optical module. As the module already incorporates AC coupling caps, these external AC coupling caps are redundant