La secuenciación de energía es un componente clave de la arquitectura de energía digital. En esta publicación, veremos algunas formas de diseñar secuencias y sus consecuencias. En particular, veremos cómo las opciones de diseño afectan la flexibilidad más adelante en el proceso de diseño.
Componentes de la conversión de energía
Eche un vistazo a nuestros bloques de construcción y herramientas de energía para ver qué tipo de problemas podemos causarnos a nosotros mismos y todos los culpables habituales, como FPGA, microcontroladores y lógica. Nuestra UPB tiene una interfaz sencilla.
Este convertidor de potencia simple tiene una sola interfaz PMBus VIN/VOUT, una señal de entrada (CONTROL) y dos señales de salida (POWER GOOD y FAULT/).
Control
La señal de CONTROL enciende y apaga la salida. Es activo alto y tiene un pullup interno.
poder bueno
La señal POWER GOOD es alta y está dentro del rango válido cuando la salida está alimentada.
obstáculo/
La señal FALLA/ es un drenaje abierto activo-BAJO que se afirma cuando falla un bloque de alimentación. Si hay una falla, se afirma ALERT/ y la falla se puede leer a través de PMBus. No todos los convertidores de potencia tienen y necesitan tanto POWER GOOD como FAULT/. En la mayoría de los casos FAULT/ puede ser un doble de acción POWER GOOD.
h2 Diseño Uno
Luego construye algo, rómpelo y construye otro, mejorando cada vez.
Considere un sistema con un controlador de bus intermedio (IBC) y los siguientes rieles:
- 48V
- 19V
- 5,0 V
- 3,3 V
- 1,2 V
- 0,8 V
Decidí estructurar los rieles como una jerarquía. Sin embargo, los potenciadores requieren una estructura de control diferente.
No tiene que preocuparse por si su jerarquía de poder es correcta o si su lógica es correcta para su diseño real. Es el efecto de esta estructura de “tipo” lo que es importante. Considere las ventajas y desventajas de esto.
Desde el punto de vista profesional, esto es simple desde el punto de vista conceptual y de implementación. Agregar un indicador LED o leer bien la potencia usando el FPGA o el GPIO de uP es muy fácil. Si algo sale mal, POWER GOOD le dice al sistema que el riel está caído.
Por el contrario, si ocurre una falla y el sistema debe apagar todas las fuentes de alimentación, la única opción es apagarlas en el mismo orden en que se encendieron. Esto significa que el riel más abajo se apaga por una pérdida de energía en lugar de por un pin de control.
Dado que no hay control de tiempo, se deben agregar circuitos adicionales para proporcionar demora entre rieles. Si agrega un retraso entre rieles, el retraso se aplica solo al encendido. Esto se debe a que si un riel alimentador pierde energía durante el apagado, el riel dependiente caerá antes de que POWER GOOD lo haga caer.
Si comete un error con esta construcción de “tipo”, tendrá que volver a diseñar la placa de circuito impreso y tendrá que cortar los cables en su diseño o beber una taza de café muy larga mientras espera. descomponer.
diseño 2
Centralice su lógica y obtendrá mejores resultados. Los dispositivos programables como FPGA y UPS pueden administrar toda la lógica.
Todas las líneas lógicas se enrutan a GPIO, por lo que el controlador tiene control total sobre el orden de secuencia de encendido y apagado y tiene control total sobre la sincronización. Si desea cambiar el código Verilog o C, siempre puede hacerlo. Mostré el PMBus del controlador, pero no dibujé todas las conexiones, pero el PMBus le permite al controlador controlar el nivel y el comportamiento de falla también.
Desde el punto de vista profesional, este diseño es flexible y no limitante.Si hay un error en la estructura de control, se puede corregir sin retransmisión.
Por el contrario, sería necesario cambiar Verilog o C y posiblemente sería necesario volver a probar y certificar el firmware. Este diseño también requiere mucho cableado. Cada POL requiere 5 líneas de control, que se enrutan individualmente al controlador. Suponiendo que tenemos un sistema de 20 rieles con PMBus en mente, necesitamos 42 pines GPIO.
Entonces, si bien este diseño es flexible, requiere muchos GPIO y mucho espacio de PCB.
diseño 3
Combinado con PMBus y un POL de potencia digital inteligente, la naturaleza del control de drenaje abierto se puede utilizar para simplificar el controlador.
Todos los pines CONTROL se enrutan juntos y todos los pines FAULT/ se enrutan juntos. Esto significa que solo se requieren 5 conexiones para un sistema de 20 rieles. Esta es una reducción de 8 veces en el número de pines de E/S.
Veamos cómo funciona esto. El pin CONTROL está activo alto. Esto está controlado por GPIO0 que está configurado para abrir drenaje. Dado que el pin CONTROL es de drenaje abierto, esto significa que POL también puede bajarlo.
Cuando se restablece el POL, baja el pin CONTROL hasta que esté listo para responder a las señales externas. Esto significa que si el controlador es demasiado rápido, no se encenderá hasta que todos los POL se hayan restablecido correctamente, y el restablecimiento de POL más lento determinará cuándo se enciende el sistema. Si el controlador es lento, encienda el control cuando suelte la línea CONTROL.
Quizás te estés preguntando acerca de las secuencias. ¿Hemos perdido el control de ella? No, porque PMBus tiene un comando TON_DELAY y su valor generalmente se almacena en NVM en POL. Se puede configurar en el controlador o almacenar en NVM usando una herramienta externa.
El pin FAULT/ también es de drenaje abierto, controlado por GPIO1, y es tanto una entrada como una salida. Esto significa que si algún riel falla, todos los rieles son notificados cuando el pin FAULT se baja. ALERT/ también se afirma cuando FAULT/ se baja. Entonces el controlador sabe que hay una falla. Todos sabemos que esa es la clave de este diseño.
Aquí puede elegir varias opciones para el manejo de fallas. PMBus puede responder a ALERT/ en la dirección de respuesta de alerta (ARA). ARA obtiene las direcciones de todos los POL defectuosos y consulta cada POL para obtener información sobre la falla. Luego puede usar un árbol de decisiones para cerrar los rieles en el orden que desee. Alternativamente, puede apagar todos los rieles a la vez y dejar que PMBus TOFF_DELAY administre el tiempo.
Muchos POL tienen una gestión de fallas mejorada y pueden responder directamente a las fallas (recuerde FAULT/ también es una entrada). Una respuesta típica es:
- rever
- apagado inmediato
- lámpara apagada
Dado que el POL tiene estas características avanzadas, el POL se puede programar con herramientas externas (a través de PMBus e interfaces y software externos), dejando gran parte de la carga fuera del código Verilog o C. Además, la respuesta a las fallas es mucho más rápida que la respuesta de ALERTA/manejo cuando se usa el pin FALLA/.
Diseño 3 compensaciones
Hay compensaciones cuando se usa POL endurecido. Si la lógica de falla es demasiado compleja para una línea/FALLA compartida, simplemente agregue un controlador. Si la lógica de la falla es simple, el comportamiento de la falla se puede configurar usando herramientas y no se requiere un controlador. Alternativamente, puede usar el controlador para telemetría y otras funciones, pero use el pin FAULT/ para el manejo de fallas. Si no puede manejar todos los casos, siempre puede agregar y modificar su código de manejo de fallas.
El pin CONTROL tiene una compensación similar. También puede usar PMBus en su lugar. En ese caso, el pin CONTROL continuará apagado y encendido hasta que todos los POL se hayan reiniciado por completo.
Se logra la máxima flexibilidad cuando se comparten los pines CONTROL y FAULT y hay un controlador para el PMBus. Este diseño permite una flexibilidad completa después de la fabricación de PCB.
poder bueno
En caso de que no lo sepas, no uso POWER GOOD. No necesita saber cuándo un riel es bueno antes de encender otro. Si todos los rieles están controlados por TON_DELAY y los rieles no están listos a tiempo, se producirá una falla. PMBus define un TON_MAX_FAULT_LIMIT. Esto define el tiempo que tarda el riel en subir y permanecer dentro de la tolerancia. Si el riel no está dentro de las especificaciones en este punto, fallará y evitará que el otro riel se encienda.
Los principios de diseño son: La ausencia de malas noticias son buenas noticias. Si su sistema necesita saber que todos los rieles están activos, todo lo que necesita es un temporizador simple configurado en el tiempo máximo definido por todos los TON_DELAY. Alternativamente, el controlador puede realizar una consulta de estado de PMBus, como el último POL.
Algunos dispositivos permiten reconfigurar el pin FAULT/ como un pin POWER GOOD. Esto le permite usar POWER GOOD si realmente lo necesita, pero pierde el pin de distribución de fallas. Por lo tanto, es posible que desee que su controlador responda a ALERT/ . O, en un sistema más simple, ALERT/ puede hacerse cargo del pin CONTROL y apagar todos los rieles en caso de falla.
En la práctica, normalmente no se requiere POWER GOOD. Sin embargo, FAULT/ generalmente se puede reconfigurar si es realmente necesario. Después de todo, siempre hay casos especiales. Probablemente siempre habrá espacio para ese “kit adaptador universal”.
vamos a revisar
Así que aquí hay un resumen rápido para aquellos que se saltaron todo el camino hasta el final.
Los primeros diseños usaban lo que yo llamo “secuencia de eventos”. El pin bueno POWER GOOD se conectó al CONTROL del siguiente POL. Sin embargo, no había capacidad de configuración ni control sobre el comportamiento de falla. El segundo diseño usó un controlador y todo el orden se hizo con ese comando, pero usó mucho GPIO y tienes que dejar que el controlador haga todo.
Un tercer diseño compartió CONTROL y FALLA/usando pines de drenaje abierto y tenía un controlador opcional. Este diseño era más flexible, tenía menos pines GPIO y era más fácil de enrutar. Este es el enfoque de diseño más común y la principal compensación es la decisión del controlador. Discutiré esta compensación con más detalle en una publicación futura.
Si comprende las limitaciones del Diseño 1 y el Diseño 2 y puede vivir dentro de ellas, entonces no hay nada malo con el Diseño 1 y el Diseño 2. Pero todos sabemos que las reglas del juego pueden cambiar repentinamente durante la certificación del sistema si surge un problema inesperado. Incluso si no cree que necesita Design 3, este es un buen seguro. Todo lo que puedo decir es que si yo fuera un ingeniero de energía y tuviera un gran equipo de ingenieros dependiendo del diseño, no me gustaría estar marginado cuando algo salió mal. Algo dice que retrasar el lanzamiento del producto no los hará muy felices.