• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 4 answers
  • Subscribers 63 subscribers
  • Views 698 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

TPS53659: Skylake processor FIVR issue

TPS53659: What is PG deasserted timing when pin13 used as VCCIO input?

Jan Bob
Intellectual 280 points
Part Number: TPS53659

Dear Experts,

We found PG will be de-asserted until Vout=0V when pin13 used as VCCIO input both rail A &B.

Is it a right reaction? I feel very strange...

How can PG low and VCCIO(pin13) low at the same time?

  • 0
    TI__Genius 11095 points
    Hi Jan, this is the expected response. The TPS53659 responds to VCCIO fault, essentially as a SetVID command to 0V. The VRRDY signal is deasserted only when the VR power conversion is disabled.
  • 0 in reply to Matt Schurmann
    Intellectual 280 points

    Hi Matt,

    According our waveform, PG will drop before EN deassert.

    Does it mean VR will "SetVID command to 0V" , and then "conversion disabled" , finally "PG be deasserted".

    Those actions start automatically according to VCCIO fault (or drop) instead of EN deassert?

  • 0 in reply to Jan Bob
    TI__Genius 11095 points

    Hi Jan, 

    Based on the waveforms, Purple=VCCIO, Green=VR_RDY, Blue=VR_Enable. Is that correct?

    The VR_RDY is being de-asserted due to the VCCIO_UV fault condition. When the controller detects this fault, it ramps the output voltage down (as a SetVID-slow) and de-asserts VR_RDY once it is done. It de-asserts VR_RDY to alert the system/CPU the VR has shutdown, for any reason (incl. faults or simply being disabled). The VR_EN is an input to the TPS53659 and is not controlled by TPS53659. And it is expected that during a fault condition, the TPS53659 will pull the VR_RDY low regardless of the state of the VR_EN pin. 

  • 0 in reply to Matt Schurmann
    Intellectual 280 points

    Hi Matt,

    There is no VCCIO in our waveform.
    Purple=VCCIN, Green=VR_RDY, Blue=VR_Enable.
    Here are some background.
    We connect VCCIO_PG to Pin13. So VCCIN will ramp up when EN assert and ramp down when VCCIO_PG deassert. (EN will deassert 1ms later than VCCIO_PG deassert)
    So VCCIN will ramp down when VCCIO_PG deassert in every time system turn off.
    Detail can refer to e2e.ti.com/.../2737093

    Intel have defined the timing of "EN deassert to PG deassert" must under 1.5uS in VR13 PWM spec.
    If we consider "VCCIO_PG" as "EN deassert" , "EN to PG" timing is over intel spec (because including Vout discharge time).
    Would you have any suggest method to meet Intel timing spec.? or is there any explanation if we can not meet this spec?
    Thanks for you feedback.

  • 0 in reply to Jan Bob
    TI__Genius 11095 points

    Hi Jan, 

    From the waveform, the pin 13 appears to be configured for the VCCIO UV function. This is why the controller is actively ramping VCCIN down, and not just tri-stating all PWM. The other possible function of pin 13 would be as BVR_EN (that is it would only be an enable pin for the 2nd channel).

    The TPS53659 treats VCCIO_UV and VR_EN deassertion differently. VCCIO_UV is considered a fault condition, which causes TPS53659 to ramp the output voltage down (rate set by SetVID-slow), and de-assert the VR_RDY when the output voltage reaches 0V. In theory, since VR_EN is an input to the device, VCCIO_UV and VR_EN my not be correlated, and it could stay high forever after a VCCIO UV. But since the VR is no longer regulating, it deasserts the VR_RDY. 

    The spec of 1.0us + 0.5us from VR_EN deassertion to VR_RDY deassertion would only apply to VR_EN deassertion. However, this would also cause a tristate PWM behavior, and not ramp down the output voltage. 

    TPS53659 treats VR_EN deassertion and VCCIO fault differently. 

  • 0 in reply to Matt Schurmann
    Intellectual 280 points

    Hi Matt,

    1. If VCCIO falls to =0.65V, then VCCIN must drop to 1.2V within 500us or there is a risk to the Processor FIVR shorting out.  

    2. The spec of 1.0us + 0.5us from VR_EN deassertion to VR_RDY deassertion

    These two requirement are Intel VR13 defined.

    Would you mean TPS53659/8 can not meet these two requirements at the same time?

  • 0 in reply to Jan Bob
    TI__Genius 11095 points

    Hi Jan, 

    TPS53659 and TPS53658 are meeting the VR13 defined specs. 

    1- When the VR_EN is pulled low, VR_RDY does de-assert within 1.5us.

    2- When the VCCIO falls to 0.65V, the device actively ramps down the output voltage below 1.2 V in less than 500us. The defined behavior of TPS53659/58 is to SetVID-Slow to 0.0V, and de-assert VR_RDY when VCCIN reaches 0V. 

    In the waveform you have posted at the beginning of this thread, first the VCCIO UV fault triggers, which causes the response I mentioned in #2. Then, the VR_EN is de-asserted (VR_EN is driven externally), but the VR_RDY is already low. 

    In the previous e2e thread, this is exactly the behavior what I suggested, to sequence the VR_EN after the VCCIO ramp down, in order to meet #2.