Tool/software:
I am developing a board that uses the DS320PR810 redriver. I have not figured out what would be the best final approach on how to configure the redrivers on the board,
so I kind of setup the board to be able to configure it in the 3 main ways:
- using pins to configure the redriver, in my case I use some dip switches, this method seems like the least configurable but the simplest
- using an external eeprom, this method seems like it offers more configuration options but from what I read, you can only configure the entire bank of channels so you can't seem to do per channel granular configuration but it still offers more configuration options than the pin mode, Still you need to write an eeprom and is more complicated to configure
- using an MCU, or microcontroller that supports the SMBus. this seems like it offers the most configuration options, allowing you to configure each individual channel, by writing the desired values in each channel's register
So in my case the micro controller is an STM32 which offers 2 SMBus connections.
From what I have read and understood so far, each register of the redriver has it's own address and as such can be treated as memory that you can write to using an MCU.
In the case of stm32 that I want to use to configure the redriver, it has the following function in it's api to write to memory through the smbus:
HAL_StatusTypeDef HAL_I2C_Mem_Write(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint16_t MemAddress,
uint16_t MemAddSize, uint8_t *pData, uint16_t Size, uint32_t Timeout);
As I see from the function's signature, I would need to configure the address of the redriver using the EQ pins to match the address of the device that I specify when I will call the function mentioned above, the "DevAddress" parameter.
Then there is another parameter in the function mentioned above, the MemAddress which would be the address of the channel register and the offset.
The MemAddSize parameter should be the size of the register, if it has 1 or 2 bytes. And finally the pData is the actual data that will be writter to the register.
I noticed that for some things, you just need to set a specific byte inside a register. I am thinking that to do this,
I would first need to read the register using:
HAL_StatusTypeDef HAL_I2C_Mem_Read(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint16_t MemAddress,
uint16_t MemAddSize, uint8_t *pData, uint16_t Size, uint32_t Timeout);
The actual data inside the register will get written in the pData. After I read it, I can change only one bit in the read data and write it back using the first function.
Since I have 2 redrivers, I would need to run the configuration steps 2 times with different device address and probably EQ settings for each channel.
One thing that I couldn't figure out exactly, is when the updated configuration takes effect? Do I need to reset the redriver after I finish configuring it? Or if I write to a register, the change immediately takes effect?
And secondly, is there enough time before the actual pcie link starts to be established to actually configure the redrivers? I calculated and it may take 10ms at most to configure the redrivers, most likely 5ms, and from what I have read, the pcie initialization begins after 120ms, so it leaves plenty of time to configure anything before that.
Also, in my design, since I have the possibility to configure the redrivers in all 3 main ways, I may decide to leave 4.7k pull-up resistors attached to the ALL_DONE pin of the redrivers. Can this cause any issues or is it alright?
This is my design:
In the case that the redrivers read from an eeprom, I connected ALL_DONE of the last redriver to the MCU to notify it when it finished loading from the eeprom. The MCU captures the PERST# signal of the PCIE express and passes it forwards to the PCIE connector. I am thinking that when the system requests a reset to the PCIE device, to also reset the redrivers and actually wait for them to finish loading before pulling the PERST# back up to re-enable the pcie device. I just connected the PD pins of the redrivers to the MCU, so that I can programatically pull them up or down
I think I would need to reset the redrivers too in case I use the MCU to configure them, but in that case I wouldn't need to wait for them anymore.
One more thing, I would need to configure the MCU to run the I2C/SMBus at 400khz that the redrivers support.
