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.

DS100BR111: DS100BR111

Part Number: DS100BR111

Tool/software:

We are having issues with the initial bring-up of new PCB assemblies with this device.  We would like TI to review the hardware and software (EEPROM image) design to see if you see anything that might be a problem.  We would also like to understand debug capabilities - how to use the SigGen Architect for debug and/or are other tools available?  Do we do all of this through this forum?  Or is there a different process for this kind of detailed technical assistance?

Thanks much,

Kevin

  • Hi Kevin,

    Yes you can share schematics, register configurations, EEPROM files, etc. on this forum and my team and I can help support. We can help answer detailed debug questions here as well. Let me know if you have any concerns about sharing files or receiving support on public forum and I can share other options.

    Best,

    Lucas

  • Lucas:

    Attached is a screenshot from the page of the schematic that shows the DS100BR111 ICs.  It shows that we have two ICs sharing a single EEPROM.  It also shows we originally had the I2C slave addresses strapped to 0xB0 & 0xB2; however, during initial board bring-up we discovered these addresses conflict with another device on the I2C Bus (the information available for the other device was misleading in it's I2C slave bus address usage).  Since we could not physically change the I2C slave address of the other device on the initial boards, we modified the I2C slave address of the DS100BR111 ICs - changed them to 0xC8 & 0xCA as shown in the red-lined mark-ups.

    You will also notice we have the boards assembled with a pull-up on the ENSB pin to allow initial programming of the EEPROM per https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1440603/ds100br111-ds100br111/5529246#5529246. The pull-up resistors are removed after the EEPROMs are programmed.  Note that we did try a board with the pull-up removed and a blank EEPROM and it did render the bus useless as explained in the answer to the older forum question.  This verified that this process was required for these initial boards.  We plan on addressing this on the next release of the boards.

    Also attached is the EEPROM image we used for the final configuration (0xC8 & 0xCA slave addresses).  An I2C bus monitor shows that it appears that the ICs are properly reading the EEPROM data during power-up.  The image was created based on configuring the ICs for 10G-KR mode and with Vod_Level=1, DE_level=0 and EQ_level=4 which is per our SI analysis.  I also included an Excel file we used to help determine the EEPROM image.  Note that I tried using the SigGen Architect software to create a .hex image file, but the image seemed to be missing a required byte (see Excel file).

    Can you please review this information and provide feedback?  We are also looking for further guidance on the SigGen Architect usage for debug and/or if there are other debug tools available.

    Thanks much,

    Kevin

    Tracewell_DS100BR111_Usage_Data.zip

  • Hi Kevin,

    Thank you for your detailed explanation.

    Here is my feedback on your schematic. Note that you are still responsible for ensuring your design will work as intended.

    • INA+/-, INB+/-: Please confirm that input signals are AC coupled.
    • OUTA+/-, OUTB+/-: Looks good, externally AC coupled.
    • ENSMB: Looks good, pulled high for SMBus slave mode to program EEPROM. Then pull-up resistor is depopulated for SMBus master mode.
    • SDA/SCL: Please confirm an external 2k to 5k pull-up resistor is included on I2C_FLEX_3V3_SDA and I2C_FLEX_3V3_SCL nets.
    • AD0-3: Looks good, 8-bit SMBus addresses are 0xC8 and 0xCA.
    • READEN#: Pulled to GND on redriver 0xC8. 0xCA READEN# tied to 0xC8 DONE# through 1k resistor. I recommend replacing R117 with a 0-ohm resistor to prevent risk of voltage drop from DONE# to READEN#.
    • DONE#: Looks good, left floating on redriver 0xCA.
    • TX_DIS: Looks good, pulled low for normal operation.
    • LOS: Looks good, pulled 4.7k to 3.3V for open drain output.
    • SD_TH: Looks good, left floating for default setting. Can be modified with register values.
    • VDD_SEL: Looks good, pulled low for 3.3V mode.
    • VDD: Looks good, 0.1uF decoupling cap connected to each pin.
    • VIN: Decoupling slightly differs from datasheet recommendation. I don't expect this to be an issue.
    • GND: Looks good.
    • EEPROM: I reviewed the M24C16-DFCU datasheet. This EEPROM appears to be compatible with DS100BR111.

    I reviewed your EEPROM hex file and noticed 3 bytes are used for address headers, however the base header bit 5=0 for EEPROM <= 256 bytes. This bit needs to be asserted to use 3 byte address headers, and can be asserted regardless of actual EEPROM image size. Therefore I recommend changing byte 0x00=0x41 to 0x00=0x61.

    I see that the following settings are programmed with this EEPROM configuration. If all of these settings are correct, then I see no further issues with the EEPROM hex file.

    • Override DEM 
    • EQ=0x03, 11.5dB @ 5GHz (both channels)
    • DEM=0dB (both channels)
    • 10G-KR mode (both channels)
    • VOD=800mVpp (both channels)

    The DS100BR111 device profile of SigCon Architect GUI is split into 3 different pages.

    • Repeater Page: Allows for simple configuration of various repeater blocks.
    • Low Level Page: Allows for direct register reads/writes.
    • EEPROM Page: Can be used to generate/load EEPROM hex files in conjunction with the register configuration in the Low Level Page. I recommend double checking any files generated with the EEPROM page as it's possible there are some bugs.

    Let me know if you have any additional questions about SigCon Architect. This is the only tool we have available to assist with debug. You can additionally ask any debug questions on E2E forum and my colleagues or I will help support.

    Best,

    Lucas

  • Lucas:

    • AC coupling on input signals: I'm working with our design partner to confirm where they placed capacitors in their design.
    • The pull-up resistance on the I2C signals is within the 2k to 5k range.
    • Understood on R117 - will change out with a 0-ohm resistor.
    • EEPROM image: there are only 2-bytes for the address headers in the image that I provided - CRC = 0x00 & EE Addr = 0x23 - repeated 16 times (0xB0 thru 0xCE).  I know the EEPROM capacity is actually >256B, but we are using <256B for the image which is why I set bit 5 of the base header to 0 - the DS100BR111 will only use the first 256 bytes of the EEPROM (0xA000 thru 0xA0FF).  Again, testing (I2C bus monitoring) showed that the devices are reading in the values correctly.  I can provide the bus monitoring data if you want.
    • SigZGen Architect: it seems this is used only to configure the device - it does not provide operating status (e.g. signal detect)?  Do you know if live adjustments can be made and immediately effect the links?  Or do we need to force 10G-KR training between the end-points after adjustments?

    Thanks much,

    Kevin

  • Hi Kevin,

    Thank you for pointing this out on the EEPROM image. That was my mistake, I now see that 2-byte address headers are used. I don't see any issues with your EEPROM hex file.

    Regarding SigCon Architect:

    • DS100BR111 does not have any register which shows signal detect or LOS status. Therefore SigCon Architect cannot show this status. However DS100BR111 includes a LOS pin which can be probed to check if a signal is detected on channel A. Register 0x01[2] can be used to select channel A or channel B status for LOS pin.
    • Yes, live adjustments can be made which will immediately affect the link. DS100BR111 is transparent to 10G-KR link training and does not actively participate. It simply passes training signals between each end to properly complete training. Any changes made to redriver configuration will immediately take effect.

    Best,

    Lucas

  • Lucas,

    The issue turned out to be AC coupling - misunderstanding on where these were located in our partner's design.  We were able to rework an assembly to add in caps in the inputs of one IC and the link came up.

    Thanks for the help,

    Kevin