Interface forum

I have further design questions. I added you as a friend and sent some questions.

I am trying to place the redriver between a COM HPC module (host) with an Intel processor and an NVME drive. The redriver will be placed on a carrier or mother board. The HPC module has caps in the TX direction and the NVME in the RX direction. TX and RX with reference to the host. If I were to tie them direct, no caps are needed on the host.

I am assuming I do not need caps on either sides of the redriver?

I plan to use the master mode. Just confirming that the EEPROM address is 0xA0/A1 (Write/read) or 0x50 (7 bit address)

In that mode, I tied EN_SMB to 13K to GND. RX_DET, VOD, GAIN are defaulting to L2 or open to GND. Is that okay?

EQ_ADDR0/1 are don't care?

A host microprocessor will program the EEPROM first on a brand new board. Is it okay to share the I2C lines between the redriver and host? If the processor deasserts READ_EN_N, I assume it can program the device and the redriver won't interfere? The host will connect to the EEPROM via TCA9546APWR and once the EEPROMs are programmed, the host will be disconnected from the EEPROM. Is that okay? Otherwise I have to put some type of an analog switch between the redriver and the EEPROM

How do I transport the side band signals such as reset, wake etc? Through a general purpose buffer?

Thanks,

Divakar

Hi Divakar,

Sorry for missing this.  Here are the settings levels for the DS160PR410 for reference. 

Here is the typical application section of the datasheet.  The DS160PR410EVM may also be a good reference.  The schematic is in the User's Guide.
DS160PR410EVM-RSC Evaluation Module (EVM) (Rev. B)

I am assuming I do not need caps on either sides of the redriver? 
Based on what you have said, there are already caps on either side of the redriver.  No need for duplicates.

I plan to use the master mode. Just confirming that the EEPROM address is 0xA0/A1 (Write/read) or 0x50 (7 bit address).
It must be 0xA0 according to the datasheet.

In that mode, I tied EN_SMB to 13K to GND. RX_DET, VOD, GAIN are defaulting to L2 or open to GND. Is that okay?
EN_SMB = L1 - I2C or SMBus Master Mode
RX_DET = L2 - RX detection is asserted after 1x valid detection
VOD=L2 - 0dB
GAIN=L2 - 0dB

EQ_ADDR0/1 are don't care?
In I2C or SMBus Mode (EN_SMB = L1 or L3), the pins are used to set the I2C or SMBus address of the device.  You can set it how you would like.

A host microprocessor will program the EEPROM first on a brand new board. Is it okay to share the I2C lines between the redriver and host?
If the processor deasserts READ_EN_N, I assume it can program the device and the redriver won't interfere?
The host will connect to the EEPROM via TCA9546APWR and once the EEPROMs are programmed, the host will be disconnected from the EEPROM. Is that okay? Otherwise I have to put some type of an analog switch between the redriver and the EEPROM.
I'm not sure about this.  I wouldn't recommend sharing them.  I have assigned this question to a PCIe expert that may help.

How do I transport the side band signals such as reset, wake, etc? Through a general purpose buffer?
These are low speed signals and do not need signal conditioning.  You can use a buffer if you'd like, but I would think they'd be fine without it.  You can refer to our EVM.

I replied to the post because it was originally related to product selection.  For better support, I have assigned this to a PCIe expert.

Regards,

Nicholaus

David,

CAPS

No. First of all I have two sets of re-drivers. You have drawn only one.  

TX or From Host towards NVME

Host side has the caps but the NVME does not. Do I need to add the caps from redriver towards NVME?

RX or From NVME to Host

NVME has the caps but the host does not. Do I need to add caps from redriver towards Host?

In otherwords, do I need to add caps at the outputs of both TX and RX redriver my circuit has? The input sides have it so I need not add it.

Did I get it right?

EEPROM:

I will send an illustration as I am not 100% clear.

Hi Divakar,

Thank you for clarifying your setup's present AC coupling capacitors.

Based on this description, you will need to add AC coupling capacitors between the redriver's TX in each direction, as the redriver needs to be AC coupled on both its RX and TX. That is, between the redriver and NVMe (TX side of the system) and between the redriver and host (RX side of your system). I've illustrated the required location of these caps below.

Let me know if you have an updated illustration of your EEPROM / I2C topology.

Best,
David

Thank you David,

I added the 0.22 uF caps to the outputs of the redrivers.

The EEPROM illustration is shown below. Now, I read through your "Understanding EEPROM doc.." SNLA320 for this chip. Please look at section 2.3, In some ways I am doing exactly that except I am going through an I2C switch. I have to as my host I2C bus master is accessing other devices with address 0x50. The EEPROM clearly shows the 7-bit address as 0x50 in the diagram, which was one of my questions.

Reading sections 2.3 and 2.4, I am assuming that on a brand new board, I can de-assert READ_EN_N from the host processor which means the redriver won't access the EEPROM. During that time the host shall go and program it. I wanted to validate this. Otherwise I have to insert an analog switch between the redriver and the EEPROM to block access when my host takes over. After programming, the host will take itself off the bus.

Can you sugges a PCIe clock buffer to drive it to the retimer? It goes through a short cable. For my SM bus, I plan to use TCA9517ADGKR. For other signals such as reset, waken, PCI_CLKREQn etc, I will use a regular buffer. 

One more. I have AT24C02C in stock while TI recommends AT24C02D. I don't think this should be an issue . 

Hi Divakar,

Ramgopal Divakar said:

Reading sections 2.3 and 2.4, I am assuming that on a brand new board, I can de-assert READ_EN_N from the host processor which means the redriver won't access the EEPROM. During that time the host shall go and program it. I wanted to validate this. Otherwise I have to insert an analog switch between the redriver and the EEPROM to block access when my host takes over. After programming, the host will take itself off the bus.

Your assumption is correct. While READ_EN_N is held high, the device would not attempt to read EEPROM. In fact, on our DS160PR410EVM-RSC, the EEPROM and DS160PR410 devices are located on the same shared I2C bus, which I have not seen any issues with when programming the EEPROM with the SigCon Architect GUI profile for this device while the DS160PR410 devices are connected to that shared I2C bus.

AT24C02C appears to be an earlier revision of AT24C02D with the same functionality, so I do not see an issue.

The DS160PR410 does not require a PCIe reference clock for operation, as it is a redriver. Are you looking for a clock buffer for your host and endpoint devices in your system?

Best,
David

Thanks for clarifying the EEPROM.

Yes, I have to pass PCIe clock and other side bands between host to NVME around the redriver. I would need to buffer the clock at the very least. 

Hi Divakar,

Got it, thank you for letting me know.

I am going to re-assign this thread to our clocking team, which should be able to help with your request for a PCIe 4.0 clock buffer.

Best,
David

Thanks,

when done, can I send you the schematic separately to get it checked?

Hi Divakar,

Sure, I can check over the PCIe redriver portion of the schematic when it is ready. You can send it to me via private message if you'd like.

Best,
David