WEBENCH® Tools/TPS53641: Fusion Digital Power Designer

Hi Jahan,
The option you need is not an NVM bit of TPS53641, so you need to switch to "PMBus control Vout" in each power cycle if you need that function.

Thanks.

The reason for changing to "PMBus Control Vout" is to avoid Xeon processor hanging upon seeing SVID's ALERT signal asserted, whichhappens on
power up. If I have to change to "PMBus Control Vout" after CPU is already hung, then doing this is not useful. I want to avoid CPU from hanging.

SVID_ALERT asserted after power up is correct behavior and CPU will issue get register to 10h to clear it. You don't need to change anything for this behavior.

I agree with your comment, but I see CPU is hung, Vout is the same as VBoot, not the expected Vout. I can not find any reason why it is hung. All control voltage levels around TPS53641 is the same as a good working board. I want to by-pass CPU control to PMBus to see if I can find what is the issue for CPU hang.

Ok, got your point, I'm not sure which platform you design for, but you can check CATERR# pin of CPU to see if that is related to SVID protocol, if CATERR# is asserted, you can decode SVID signal to see what happened (any NAK or REJ command or something), if you did not see any unusual in SVID command, then you will need to go back to check schematic settings, please make sure you select the right VR mode (like VR12.5 (10mV) or VR12.0 (5mV)... etc.

If everything is ok, then the issue might not be related to VR, you need to check other portion.
Only one board has this issue? or every one?

Any suggestion on which schematic settings? About 10% boards. the confusing issue is some boards work fine, and after a few days, the cpu
doesn't boot up, with SVID Alert asserted, and vout set to VBoot.
Thanks for suggestion of CATERR#. I will look into this. Regarding your comment on VR mode, we are using VR12.5, but where do I select this VR mode?

VR MODE is set by SLEW-MODE pin, and looks like you did the right option. Actually it is hard to me to easier have suggestions on this case especially the board is working fine originally...
I will suggest you to decode SVID signal as the first step.

I verified in Fusion Advanced configuration that VR Mode is set VR12.5. I have been told by TI that Intel has a ITP tool that helps with identifying the cause of cause hang. Have not been successful in my search for such tool. I will decode the SVID clk, Alert, data to see if any indication. Any suggestion on what could contribute to this failure, as capturing the parameters from Fusion and comparing it with good board, show no difference.

No, I don't have any other suggestion at this moment

Chasel,

using PMBUS interface (Fusion Digital Power Designer), can I access  TPS53641's Primary status register to see what has caused the SVID Alert to be asserted?  I guess what I am

asking if there are ways thru Fusion that I could see why the VRs output ist at VBOOT value and not at the required output value. 

Note that in this design two phases of TPS53641 are used to connected to two identical VRs (CSD95372BQ5M), each to generate 1.8V. the VBOOT values is at 1.7V.

thanks,

-jahan

Jahan,
No register inside TPS53641 would be able to get regarding SVID_ALERT#.
Please find the condition that cause SVID_ALT# asserted in intel SVID doc.. As this is public forum, I cannot disclose the information here.