TPS549D22: TPS549D22 PMBUS issue

Yang Wu 

My apologies for the confusion, allow me to try and explain.

First, to answer your questions:

1) The TPS549D22 does not support READ_VOUT telemetry and can not support the external PMBus adjustment loop optional feature of the 1SG110HN2F43E2VG FPGA.

2) While I can not speak to all of the requirements of the 1SG110HN2F43E2VG FPGA, the TPS546D24A will support VOUT_MODE, VOUT_COMMAND, and READ_VOUT, and uses ULINEAR16 format, so it should be able to support the "Master Mode" external PMBus adjustment loop feature of the 1SG110HN2F43E2VG FPGA 

The default VOUT_MODE value is 97h, which sets the VOUT_COMMAND and READ_VOUT to Linear Format with an exponent "N" of -9, which is supported by the 1SG110HN2F43E2VG FPGA per Table 11, Page 29.  The EM2260 however uses ULINEAR16 with an exponent of -13.  To change the TPS546D24A to use an exponent of -13 you will need to update VOUT_MODE from 97h to 93h and store the updated value to NVM with the STORE_USER_ALL (Command Code 15h) command.

The note that you are referring to in the TPS546D24A datasheet specifically refers to writing to and reading from a secondary device within a multi-phase stack of TPS546D24A devices that are sharing the current of a single output.  That is not the case for the 1SG110HN2F43E2VG FPGA VOUT_COMMAND and READ_VOUT value.

For Example:

If you were using 2 TPS546D24A devices to generate a single higher current output, say 0.85V at 80A, and you write a value to the second device in the stack using the PHASE Command (Command Code 04h) you need to wait upto 4ms after writing the value to the second device on in the stack before reading that same value back.

As an example, if you wanted to adjust the READ_IOUT Offset value (IOUT_CAL_OFFSET) for the second device you would:

1) Set the PHASE command value to 01h to address the second device in the 2-device stack

2) Write the IOUT_CAL_OFFSET value to the new value

3) Wait 4ms

4) Read IOUT_CAL_OFFSET back from the second device.

The reason for this 4ms delay is the system PMBus is not interfacing directly with the second device in the stack, it is interfacing with the first device in the stack (Phase 00h) and that device is serving as a bridge to the second device using the two-wire BCX port on the stacked TPS546D24A devices.  The first device in the stack maintains a queue of commands passing over the BCX port, but to reduce read-back latency, READ commands are given priority over WRITE commands. 

If you write a value to PHASE 01h - 03h, and there is active communication already on the BCX bus, the write transaction will be placed in a queue to wait for the BCX bus to be available.  If you then read that same command value back before the write command has been passed to the PHASE 01h - 03h device, the READ transaction will be given priority over the WRITE transaction and the read-back will be performed before the Write and contain the wrong command value.

The FPGA's External PMBus control loop does not use this for several reasons.

1) It is communicating directly with Device 00h, whether that device is being used as a single device or a stack of multiple devices.

a) It will be using PHASE = FFh (Default) or PHASE = 00h not PHASE = 01h - 03h.  Communication using PHASE = FFh and PHASE = 00h do not use the BCX "back-channel" interface and are thus not affected by any command queuing or resulting latency.

2) It will not be reading back the same value it is writing. 

a) It is writing to VOUT_COMMAND (Command Code 21h) and reading from READ_VOUT (Command Code 8Bh) 

Hi Peter,

No need for apologize. I really appreciate your detailed analysis. 

I will figure out how it works with customer and contact you offline. 

thanks a lot.