TPS53641: Fusion Digital Power Designer

Is there a design guideline for TPs53641 that describes the timing required and related information for making sure that user selections are adequately latched into device? would someone please explain as what could be going wrong that some of configurations don't get latched in, and shows as default value?

Hi Jahan,

We will have someone to take a look.

Thanks
Qian

Hello Qian,

Thanks. With VOUT_COMMAND to be at default value of Vboot, it very well could be that we don't have any SVID issue, but we just don't latch the controller with set values. The VOUT_MAX is to be set to 1.8V, but for the boards that are failing it shows default value of 3.04 Volt.
Your thought, and inputs is appreciated.

thanks, and regards,
-jahan

Hi Jahan,

The reason why >1.5V/ms slew rate of pin14(V3P3) is required because SVID address strapping purpose, so it is right if you slow down the slew rate then SVID communication issue is observed.
Also, for those values, like VMAX/VOUT COMMAND changes in SVID mode are normal, as CPU will write those value through SVID.
IOUT_OC/FAULT changes is due to resistor tolerance (1% or 5%), and plus ADC error, so you might see 1A difference while every power up. Please set the IMAX to IMAX+1A to prevent CPU from powering up due to insufficient ICC_MAX that CPU needs.

Thanks
Chasel

Qian,

One additional related question. How is the VOUT_COMMAND value is provided to TPS53641 by user. In failing boards, I see that the VOUT _COMMAD value (register0x21) has a value equal to VBOOT(1.7V), but in the passing board it has the correct, intended, value of 1.8V. On Power up, TPS53641 get all the setup from the values set by components connected to it's input pins. Which one provides the VOUT_COMMAND?

thanks,

-jahan

Hi Jahan,

While powering up, VOUT_COMMAND will be VBOOT, then VOUT_COMMAND will be the number which received by CPU if "SVID Control Vout is selected".

Chasel

Chasel Chan,

Thanks, I just saw your post, after I posted my question on VOUT_COMMAND. If I understand your comment, VOUT_MAX which is set to 3.040V (register 0x24, value of 0x00ff), and VOUT_COMMAD (register 0x21, VBOOT value) is set by CPU. These VOUT_MAX, and VOUT_COMMAND values are the default values. Under what condition would CPU writes these values instead of expected value of 1.8V.

Thanks again,

-jahan

Chasel,

One more input for your consideration and respond is that we have boards that they are good working boards some times, and fail sometimes.
the only failure is that for 1.8V it shows 1.7V (VBOOT). The behavior is seen on bench (no heat or over-current) ). These boards pass 3 out 10 times, and fails the rest.

Your inputs are appreciated.

thanks,

-jahan

Hi Jahan,

Please find my comments here.

1. Since for the failing boards, the VOUT_MAX is default value, and VOUT_COMMAND is also default value (VBOOT), could it be that CPU
didn't
get a chance to update the values, and therefore the controller just used the default values.

-In the SVID failing board, SVID address settings might not correct to be detected due to lower slew rate of 3P3, if the SVID address is not correct, CPU cannot change VOUT_MAX and VOUT_COMMAND thru SVID.

2. If there a why get the indication that CPU wrote these value of not? Any suggestion that could help me with figuring out what is causing
this?

-Please ensure 3P3 slew rate is >1.5V/ms.

One more input for your consideration and respond is that we have boards that they are good working boards some times, and fail sometimes.
the only failure is that for 1.8V it shows 1.7V (VBOOT). The behavior is seen on bench (no heat or over-current) ). These boards pass 3 out 10 times, and fails the rest.

-Please ensure 3P3 slew rate is >1.5V/ms.

Chasel

Chasel,

Thanks, seems it all boils down to 3P3V slew rate. Let me share with you the observation. I measured the slew rate at pin 14 (3P3V) of controller .
The P3V3 it goes from 0.0V to 0.7V within 3.3msec, and waits for 230msec in that level, and then changes from 0.7 to 3.28V with 720usec. I am
investigating what is the issue here, and will report the cause, and solution.

thanks,

-jahan

chasel,

I verified the previous measurement was not accurate. I verified the correct measurement shows 0V to 3.26 volt at pin14 (V3P3) has a ramp up delay of 840 Usec. This doesn't match with expected 1.5msec/volt which requires a min ramp delay of 2.14msec. I have seen reference schematic suggestions that shows recommended RC value of R = 2 ohm, and C = 1uF. This is what is used in this schematic, and doesn't provide the required timing. Would you please let me know where I can get TI's reference design that shows suggested correct components.

thanks,

-jahan

Chasel,

If you could kindly let me know of a recommendation schematic for TPS53641 that the values of R, and C for pin 14 (P3v3) is different than
R=2 ohm, and C= 1uF. the 1.5msec/1volt requirement for 3.3V suggests a ramp-up delay of 2.14msec. using a 1uF capacitor, requires a
resistor is k ohm value, not just 2 ohm. Please verify.

Hi Jahan,

2 ohm with 1uF RC circuit only delay couple micro-second.. so please check 3.3V source. There is no other reference schematic than 2ohm//1uF.

Chasel

Chasel,

Thanks for input. As mentioned before, We have several boards that 1.8V voltage controled by TPS53641 is functioning intermittently. That is sometimes the output is 1.8V, and sometimes the output is at 1.7V (VBOOT). Pin 14(p3v3) rampup delay is all functioning board, and these boards are about 720uSec. As per suggestions, II made sure

the ramp up delay is around 2.2msec (1.5V/1msec). When I do htat the board continously fail. when I change back to recommended RC of R(2.2 ohm), and C(1uF), then it goes

back to state of sometimes passing, and sometimes failing.

I noticed that the SVID address for this controller is 0000, the resistor to GND for this address is 20K (1%). The data sheet requires 20K or less. therefore, I changed the resistor to  16.2K to make sure there is no possibility of address being wrong. 

Could you please check this ramp up values (R, and C) in recommended schematic? The recommended schematic that I have, and all working boards have R= 2.2 ohm, and C= 1uF.

I am certain the Address is now correct, and no possibility of being mis-interpreted to anything other than 0000.

What else could be the issue that causes the default values to be set instead of intended settings.

thanks,

-jahan

Hi Jahan,

1. 2.2msec is not the minimum delay requirement, it means controller need to get 3.3V within 2.2ms, so 3.3V slew rate need to be higher than 1.5V/ms
2. You mentioned P3V3 behavior in previous comments, is that still the case? Please try to have 3.3V from 0V to 3.3V within 2.2ms.
"The P3V3 it goes from 0.0V to 0.7V within 3.3msec, and waits for 230msec in that level, and then changes from 0.7 to 3.28V with 720usec."

Thanks
Chasel

Chasel,

Let me quickly review the status, thank you for responding to each item separately so that we can keep track of respective response to each of our question.

1. the 3.3 measurement of 0.7, and then to 3.3 was a mistake, that was quickly corrected, and I mentioned it in my following reply. We do have 3.3V to pin14 with a good slew rate. It is reaching 3.3V within 720usec,        which is within the 2.2ms, and I see the intended parameters latched in. Therefore your acknowledgement confirms that it is fine.

2. The SVID address to 1.8V controller is intended to be 0000 . I have made sure the resistor between ADDR pin of device, and GND is 16.2K (per sepc should be <20K for address 0000) is correct. Therefore the cpu should see the correct  device, but "All Config" table from Fusion shows the "VOUT_MAX" as 3.04V (device default value), and "VOUT_COMAND" as 1.7V (default value of VBOOT). This means CPU is not communicating with controller. Please let me know if there is any other condition that these value could be default value.

3. In each of our board we have 3 of such controller. one for 1.05V, one for 1.2V, and the last one for 1.8V. These three voltages should come up in sequence of 1.05V, 1.2V, and 1.8V. 1.05V is fine. In my investigation in failing boards for cause of CPU not writing to 1.8V contorller, I noticed that 1.2V controller, shows the current to 0.00, "VOUT_MAX" is 1.520V, and "VOUT_COMMAND" IS 1.2v (VBOOT value). This means the 1.2V controller is also not responding. Could you explain why VOUT_MAX is shown to be 1.520V instead of default value of 3.04V? . The same board works fine sometime, and it fails sometimes, so it can not be from setting values.

thanks,

-jahan

Hi Jahan,

Please find my comments.

1. the 3.3 measurement of 0.7, and then to 3.3 was a mistake, that was quickly corrected, and I mentioned it in my following reply. We do have 3.3V to pin14 with a good slew rate. It is reaching 3.3V within 720usec, which is within the 2.2ms, and I see the intended parameters latched in. Therefore your acknowledgement confirms that it is fine.

-Thanks for clarification.

2. The SVID address to 1.8V controller is intended to be 0000 . I have made sure the resistor between ADDR pin of device, and GND is 16.2K (per sepc should be <20K for address 0000) is correct. Therefore the cpu should see the correct device, but "All Config" table from Fusion shows the "VOUT_MAX" as 3.04V (device default value), and "VOUT_COMAND" as 1.7V (default value of VBOOT). This means CPU is not communicating with controller. Please let me know if there is any other condition that these value could be default value.

-No, 16.2k resistance should get 00h SVID address of '641.

3. In each of our board we have 3 of such controller. one for 1.05V, one for 1.2V, and the last one for 1.8V. These three voltages should come up in sequence of 1.05V, 1.2V, and 1.8V. 1.05V is fine. In my investigation in failing boards for cause of CPU not writing to 1.8V contorller, I noticed that 1.2V controller, shows the current to 0.00, "VOUT_MAX" is 1.520V, and "VOUT_COMMAND" IS 1.2v (VBOOT value). This means the 1.2V controller is also not responding. Could you explain why VOUT_MAX is shown to be 1.520V instead of default value of 3.04V? . The same board works fine sometime, and it fails sometimes, so it can not be from setting values.

-Default VOUT_MAX is FFh, and it is respect to VID table, I believe your setting of DDR is 5mV DAC which is VR12.0(5mV), and the maximum VID is 1.52V, so that's the reason why you found 1.52V in 1.2V rail.

If the 3V3 slew rate is confirmed within requirement, please check the following items.

1. Is the SVID pull up termination well-populated and follow daisy chain routing? Please check PDG for further information.
2. Is the SVID routing follow PDG to avoid routing thru high noise switching area and put DIO between CLK and ALERT#?
Does the board pass intel test plan? If this is not related to address problem, it might be SVID miscommunication issue due to bad signal integrity.

Thanks
Chasel

chasel,

thanks for your kind responses to my quesitons.

I am looking into signal integrity of SVID signals, and your recommendation also confirms this. I have two questions regarding your response.

1.  would you kindly explain your response regarding resistor 16.2K for SVID address 0000. You mentioned it " should get 00h SVID address of '641". I don't understand  where 641 comes from. Please explain a bit more. I want to make sure I am doing the right value.

2. I understand, and verified with VID table that for 1.2V, the value of 1.52V is correct default value, based on DDR of 5mv DAC. What is the value of 3.04 comes from? We are using VR12.5, and value of 3.04 is shown for 1.8V which is core voltage VCCIN.

Thanks again, 

-jahan

Hi Jahan,

1. '641 = TPS53641. :)
2. 3.04V is the maximum voltage in 10mV VID.

Thanks
Chasel

chasel,

Thanks for your response. I verified that all SVID interface to TPS53641 (Alert#, Clk, Data) from signal integrity point of view are good, and CPU should be able to communicate with controller. A closer look at the TPS53641's FUSION data (All Config) shows that the current usage for 1.2V
controller is 0.00A. According to Intel, CPU will quit if the ICCmax Requirement for the SKU is not met. the question is if the controller is enabled, then under what condition(s), would the controller read 0.00A of current, knowing that the VR is set to have VBOOT of 1.2, VOUT_COMMAND is 1.2V. Note that we do see 1.2V at output of VR.
What signals should I watch for to make sure the VR is responding with Currernt.
This is what is under "On/off Configuration" of Fusion's All Config report:
ON-OFF_CONFIG code= 0x02, value =0x17
Operation code= 0x01, value = 0x00
READ_IN code= 0x89, value = 0.00A
READ_IOUT code=0x8C, value = 0.00A
READ_PIN code =0x97, value = 0.00W
READ_POUT code =0x96, value = 0.00W
READ_VIN code = 0x88, value = 11.909V
READ_VOUT code = 0x68, value = 1.19V

thanks,

-jahan

Hi Jahan,
Did you have chance to use intel VRTT to verify SVID communication? It would be good if you can use VRTT to double check SVID communication. What we usually do is to enable digital IMON reading at static tab and make the reading frequency at maximum.

You can see READ_IOUT (0x8C) which is the same with SVID IMON reporting.
Thanks
Chasel

Chasel,

I don't have access to VRTT, I need to solve the issue with what I have now (scope, logic analyzer). I briefly looked at the demo on youtube, and it seems I need tools for using VRTT. Would you please be more descriptive of your comments as I don't understand your comments about the enable digital IMON reading at static tab, and make the reading frequency at maximum.
What is the intention here. How can I see why the VR is not producing any current, but the voltage is correct. What could cause this. Please kindly
explain.

thanks,

-jahan

Hi Jahan,

READ_IOUT is 0A might be possible while no load or light load because there might have negative from CSP, it is normal.

Here is the snapshot of what I'm mentioning.

There are lots of discussion, if you can make sure TPS53641 is able to latch correct VR address (00h) while every powering up, then you need to check if SVID protocol is working all the time. If you don't have VRTT, then you need to decode the signal thru scope or decoder.

Thanks

Chasel

Chasel,

We have verified that ICCMAX is the register that causes the SVID transcation failure. would you kindly provide the guide line for how i can verify the ICC max voltage that I provide is correct. The same board sometime passes and sometime fails. Would you kindly describe how I can verify the voltage at F-IMAZversus the intended current. I am also not clear on functionality of IMON. what is the correlation between F-IMAX, and IMON.

In our design we have IMAX = 55, Iout OC Warn Limit = 55.0A, and Iout OC Fault Limit = 68A. Is it correct to have IMAX, and Warn value to be the same?

for checking ICC-MAX, does the cpu reads the IOUT_OC-FAULT_RESPONSE (0x47) versus the IOUT_OC_FAULT_LIMIT(0x46)?

When it passes the IOUT_OC_FAULT_LIMIT shows 68A or 0x0044 for register 0x46

when it fails the IOUT_OC_FAULT_LIMUT shows .67A or 0x0043 for register 0x46.

When it passes the OUT_OC_WARN_LIMIT is 55A or 0x0037 for register 0x4A

When it fails the OUT_OC_WARN_LIMIT is54A or 0x0036 for register 0x4A

thanks,

-jahan

Thanks for your inputs