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.

UCD90160 Propagation delay: PMBUS Control De-assertion to 1st Rail EN de-assertion

Other Parts Discussed in Thread: UCD90160

Do you have an estimate of the propagation delay from the instant PMBUS Control is de-asserted externally to when the UCD90160 will de-assert the enable signal on the first power rail (assuming TOFF_DELAY=0 and ignoring the external capacitance on the EN line)? Is this logic flopped or is it purely combinatorial logic?

In my system it is critical that I control power down sequencing but the only advanced warning I receive is when the input 12V rail starts to droop. So I have a very small window from when I detect 12V below some threshold (say ~10V) and when the 12V rail reaches the limit of the secondary regulators (~6-7V) in order to sequence my rails down (I don't have the ability to place a huge cap on my board to survive longer so I need to shutdown quickly). My plan is on power loss to put the board in a low power state immediately and kill all non-essential rails right away. So I'm hoping to get an estimate of how long it will take to de-assert the initial non-essential rails.

Also, is there a way to speed up the ADC monitoring of the key rails during power down? If I only have ~3 rails that have shutdown dependencies can I assume that the cycle time of the ADC is only 3.89us * 3 in this situation? Or does the ADC always cycle through all rails even if they are not dependencies for the shutdown? Alternatively, can I rely on the accuracy of the TOFF_DELAYs in this situation (ex: 200us will be +/-20%) to sequence down the rails (assuming I hard shunt the rails appropriately externally)?

Thank you!

Josh

  • Hi Josh,

    Everything is firmware in UCD90160. It takes time to process the tasks. For this reason, the time delay can vary from configuration to configuration. I can only give a ball-park number.

    The CONTROL to EN delay is about 500us worst case if there are 16 rails. If you have only 3 rails, we estimate roughly 200us worst case.

    The ADC to EN delay is also about 500us in worst case. This is the case regardless the number of rails.

    The EN status of all rails are processed from high# to low#. So high # rails has faster response.

    Turn on delay has 500 us resolution.

    Regards,
    Zhiyuan
  • Thanks Zhiyuan. This is very helpful.

    Can you confirm the turn off delay resolution? Is this the same as the turn on delay resolution? Also, just to confirm on the ordering of processing for the ENs, will pin 35 (GPIO18) be processed before pin 34 (GPIO17)? Or is it based on the Rail numbers assigned in the firmware (where rail 5 is processed before rail 4 regardless of which pin each is assigned to)?

    Thank you
    Josh
  • Turn on delay and turn off delay resolutions are both 500us.

    The EN processing is based on Rail# not Pin# (Rail 5 is before Rail4).

    Regards,
    Zhiyuan
  • Thank you!