¿Mi FPGA para control de motor está condenada al humo mágico? Review de lógica de transiciones

Wine

Hola comunidad. Estoy diseñando un controlador de motor BLDC con una FPGA (Artix-7) y un driver externo. El problema es que mi máquina de estados para la conmutación de fases tiene una transición que, bajo ciertas condiciones de ruido en el sensor Hall, podría activar dos pares de MOSFETs al mismo tiempo (corto). He intentado agregar un 'dead-time' en el código, pero siento que la lógica aún es frágil. Adjunto lo esencial del código:

if (hall == 3'b001) begin phase_a_hi = 1; phase_b_lo = 1; phase_c_hi = 1; // error? end else if (hall == 3'b010) begin ...

¿Alguien ve un fallo en la arquitectura? ¿Debería usar una máquina de Moore en lugar de Mealy? ¿O es mejor pasar a un microcontrolador con más capas de seguridad? Agradezco cualquier review constructivo.

Surfing

Primero que nada, el código que muestras es peligroso: estás asignando phase_c_hi = 1 junto con phase_b_lo en el estado hall=001. Eso significa que tienes el high-side de C y el low-side de B activos, pero si también activas A_hi, estás creando un camino entre Vcc y GND a través de dos fases. Revisa tu tabla de conmutación, porque para un BLDC en pasos de 60 grados, nunca deben estar activos dos high-sides al mismo tiempo. Te recomiendo usar una look-up table y un registro de salida separado del cálculo combinatorio. Algo como:

always @(posedge clk) begin case (hall) 3'b001: pwm_out <= 6'b100010; // A-Hi, B-Lo 3'b010: pwm_out <= 6'b010001; // B-Hi, C-Lo ... endcase end

MusicFan

Estoy de acuerdo con el comentario anterior, pero además veo que estás usando bloqueantes (=) en lugar de no bloqueantes (<=). En un always combinacional para lógica pura está bien, pero para una máquina de estados secuencial, deberías usar siempre <= para evitar carreras. Y sobre la pregunta de Moore vs Mealy: en control de potencia, yo siempre uso Moore porque las salidas dependen solo del estado, no de las entradas directamente. Así filtras glitches del sensor. También añade un filtro digital a las señales Hall (contar 3 ciclos estables) antes de usarlas. Eso te ahorrará muchos dolores de cabeza.

TechFan

Sí, pero no te olvides del dead-time. Aunque la lógica esté bien, si el driver no tiene interlock, necesitas generar un tiempo muerto entre la activación del high-side y el low-side de la misma fase. En FPGA, puedes hacer un contador que retrase la señal de encendido del low-side después de apagar el high-side. Yo lo implementé así:

always @(posedge clk) begin
  if (pwm_hi) begin
    dead_cnt <= DEAD_TIME;
    hi_en <= 1;
  end else if (dead_cnt != 0) begin
    dead_cnt <= dead_cnt - 1;
    lo_en <= 0;
  end else lo_en <= 1;
end

Pero mejor revisa la hoja de datos del driver; algunos ya tienen protección integrada.

Wine

Gracias por las respuestas. Tienes razón, en el código de ejemplo puse mal esa línea, pero en el código real no tengo dos high-sides activos. El problema es que en la transición de un estado a otro, debido a que las señales Hall cambian en momentos ligeramente distintos, mi máquina Mealy reacciona a un estado intermedio y genera una salida no válida. Me gusta la idea de usar Moore, pero me preocupa que agregue latencia. ¿Alguien ha usado una máquina de estados con codificación one-hot y ha aplicado un registro de salida para evitar glitches? ¿Es suficiente?

Blues

La latencia de un ciclo de reloj es despreciable a 10 kHz de conmutación. Usa Moore y sincroniza las salidas con un registro. Además, te recomiendo que no hagas la lógica de transición solo con el valor actual del Hall, sino que compares el estado anterior y el siguiente para asegurar que solo avanzas a estados adyacentes. Por ejemplo, si el Hall cambia de 001 a 011 (que no es un paso válido), puedes mantener el estado anterior hasta que se estabilice. Algo así:

if (hall != hall_prev) begin if (is_valid_transition(hall_prev, hall)) state <= next_state; else state <= state; // ignorar end

Eso te da robustez sin necesidad de filtros complejos.

BoardGames

Perdón, pero no estoy de acuerdo con ignorar estados inválidos. Si el motor está girando rápido, los sensores Hall pueden cambiar en desfase y un estado aparentemente inválido podría ser real si estás en alta velocidad. Mejor hacer un filtro de consenso: si dos de los tres sensores indican el mismo cambio, entonces aceptas la transición. Eso es más robusto. Además, en lugar de bloquear el estado, puedes forzar que todas las salidas estén en alta impedancia (o apagadas) durante un tiempo muerto fijo si detectas un patrón inválido. Así proteges el hardware.

Wine

Muy buenos puntos. Creo que voy a implementar una máquina de Moore con estados codificados en one-hot, un registro de salida para evitar glitches, y un pequeño filtro de ventana que requiere que el Hall esté estable durante 2 ciclos. También pondré un watchdog que si detecta un estado imposible, apaga todos los PWM y activa una señal de error. Gracias a todos, me habéis ahorrado de comprar repuestos. Cuando lo pruebe, subiré los resultados.