Spartan 6 FPGA IO cambia el estado sin tener en cuenta el diseño

Navega tus respuestas
1

Hola, he hecho la placa Spartan 6 y ahora estoy tratando de que funcione, he logrado que la programación del flash SPI funcione, así que puedo cargar flujos de bits, pero tengo un problema que algunos de los pines IO no permanecer en el estado deseado.

Por ejemplo, tengo 4 IO usadas para controlar los relés de los atenuadores (usados en el módulo del osciloscopio) y cuando configuro el estado de reinicio, lo retiene durante 40 nanosegundos y luego vuelve a cero. Incluso tengo un protocolo de comunicación en el que Puedo establecer el estado de E / S programáticamente a través del software y cambiar el estado, pero nuevamente solo por 40 ns y luego volver al cero lógico.

En la simulación, todo funciona como se esperaba, también la temporización par estática muestra que se cumplieron mis limitaciones de tiempo (reloj de 60MHz del FT24 FTDI y 150MHz del oscilador ADC). He revisado tres veces mi UCF si no he usado pines incorrectos, pero es lo mismo.

Estaba pensando que de alguna manera estoy reiniciando el diseño (uso FTDI para eso) en FPGA, pero no es el caso porque me enganché el alcance en el pin de reinicio de mi diseño y no se activó. También otras cosas en mi diseño funcionan, por ejemplo, puedo establecer con éxito voltajes de referencia de valores de ADC (controlados por DAC) a través de la interfaz en serie (que es lenta - 100kHz), de modo que el restablecimiento que acabaría con el estado IO después de 40 ns también detendría la configuración de DAC.

¿Sabe qué podría obligar a FPGA a ignorar los estados de IO del conjunto de diseño?

// editar: agregar código:

esta es la parte que establece los IO: (el led1 parpadea levemente cuando esto sucede) 

              when SET_ATTENUATORS =>
                led1 <= '0';
                adc1relatt <= commandData(71);
                adc2relatt <= commandData(63);
                state <= IDLE;

y este es el estado IDLE: 

             when IDLE =>
                ft245rw <= '0';
                ft245strobe <= '1';
                ft245dataWaitIn <= '0';
                if (to_boolean(ft245busy) and (ft245oe = '0')) then
                    state <= READ_COMMAND;
                    ft245strobe <= '0';
                else
                    state <= IDLE;
                end if;

y este es el estado de configuración del voltaje de referencia: 

              when SET_VREF0 =>
                led1 <= '0';
                dacVrefTopA <= commandData(72-1 downto 64);
                dacVrefBotA <= commandData(64-1 downto 56);
                dacVrefTopB <= commandData(56-1 downto 48);
                dacVrefBotB <= commandData(48-1 downto 40);
                if to_boolean(dacBusy) then
                    dacStrobe <= '0';
                    state <= SET_VREF1;
                else
                    state <= SET_VREF0;
                    dacStrobe <= '1';
                end if;
            when SET_VREF1 =>
                if to_boolean(dacBusy) then
                    state <= SET_VREF1;
                else
                    state <= IDLE;
                end if;

En este estado, el led1 también parpadea levemente (debería permanecer encendido, no parpadea), sino que también se restablece el estado de cambio de LED, lo que no podría suceder, ya que el reinicio también restablecería el módulo DAC, lo que evitaría El módulo de configuración de DAC establece valores de DAC (lo hace con éxito).

    
pregunta Bruno Kremel

3 respuestas

1

Finalmente encontré que el problema era que había estado cargando el mismo diseño una y otra vez ... Así que pensé que había diseñado esa luz en el led pero no había ninguna ... Ahora funciona como se esperaba. porque pensé que los archivos * .MCS se generan solo una vez, no tengo que generar un archivo MCS a partir de un archivo BIT cada vez que cambio el flujo de bits ... ahora está funcionando, mi problema ahora es que algunos paquetes no van intactos a través de FT245 .. Haré un protocolo de reconocimiento simple para arreglar eso.

    
respondido por el Bruno Kremel
0

Aquí hay uno que he visto ...

El cambio de un pin IO causó que se tomara mucha corriente repentinamente (no muy diferente a una bobina de relé). La fuente de alimentación se apagó (solo durante 1 ms), regresó y el FPGA se reconfiguró a su estado inicial, incluido el pin IO ahora inactivo.

(Cuando comencé a depurar remotamente, no vi la luz de límite actual en el parpadeo de la PSU ... todo se aclaró una vez que fui al laboratorio :)

    
respondido por el Martin Thompson
0

Entonces, ¿estoy asumiendo que commandData es un registro SPI de un microcontrolador? Si esta es una nueva placa (y no una placa de desarrollo probada conectada a algún otro circuito), comenzaría haciendo algunas comprobaciones de cordura. Por ejemplo, ¿tienes pines de repuesto? ¿Puede combinatoriamente (es decir, fuera de la máquina de estado) hacer algo como: 

test_pin_0 <= commandData(0);
test_pin_1 <= commandData(1);

también asigne de forma combinatoria adc1relatt y adc2relatt como prueba (es decir, fuera de la máquina de estado; ni siquiera lo incluya en un proceso, solo conecte el pin al comando Registro de datos): 

adc1relatt <= commandData(71);
adc2relatt <= commandData(63);

esto mostrará o ignorará la posibilidad de un error de circuito (E / S incorrecta en UCF, controlador FPGA quemado, otra cosa que carga el pin hacia abajo).

Eso al menos aislará la parte de la máquina de estado de su código. Por ejemplo, es posible que su reloj no funcione y que su máquina de estado esté atascada en un estado inesperado. Es posible que no pueda ver esto simplemente usando los comandos SPI, ya que están sincronizados externamente.

También, noté que dijiste que el LED parpadea levemente incluso cuando el pin que está encendido está asignado a '0'. ¿Qué sucede cuando se asigna a '1'? ¿Cómo tiene el LED conectado, es polaridad positiva o invertida? Además, ¿hay una resistencia limitadora de corriente? Finalmente, ¿qué dice el .UCF sobre el estándar de E / S y el nivel de la unidad?

Finalmente, si esos estados son parte de la misma máquina de estados, tiene un bloqueo implícito en su señal led1 en el estado IDLE (a menos que tenga un valor predeterminado en otro lugar), ya que el valor no está definido en este estado. Es poco probable que este sea el problema, pero por razones de salud, ponga un valor predeterminado al principio del proceso o asigne un valor explícitamente en cada estado.

    
respondido por el Zuofu

Lea otras preguntas en las etiquetas

Cómo alimentar un auto de control remoto usando energía solar ¿Cómo puedo decidir si puedo usar una Raspberry Pi para mi aplicación?