Contador de codificador FPGA que se ejecuta aleatoriamente

Capture la entrada en lugar del contador para ver si el problema es el rebote. Si tiene un alcance de almacenamiento, use el disparador de borde para obtener la captura. De lo contrario, intente agregar rebote entre Reg1 / Reg2 y entre Reg4 / 5.

Para implementar esto, use un registro de desplazamiento de 8 o 16 elementos alimentado desde A. sincronizado. Tome AND y el ~ OR de entre todos los bits del registro de desplazamiento, estos le darán "todo listo" y Señales "todo claro". Use esto como el ajuste y reinicio de un registro de salida, que alimentaría REG2. Lo mismo para B - > REG 5.

Si encuentra este problema, puede probar un reloj más bajo o extender el registro de desplazamiento. Por encima de las 16 etapas, probablemente sea mejor remodelar como un contador binario y un bit de último estado. En cada ciclo, si el estado es diferente del último, reinicie el contador y actualice el último estado. Si el contador se desborda sin borrarlo, ese es su activador para configurar / restablecer la salida.

Lo siento, hubiera respondido antes, pero estaba fuera de la ciudad con acceso limitado a Internet. Veo que Shuckc ya respondió esto, pero siento que tengo una solución que sería superior.

El problema con el rebote y / o filtrado A y B es que puede evitar que su decodificador funcione a la velocidad máxima (y, por lo tanto, que falten cuentas), agrega complicaciones, aumenta el tamaño de la lógica y, lo más importante, no es necesario .

Comience por mantener los seis registros que ya tiene en su esquema. Llamemos a la salida de Reg2 y Reg5 como A y B. La salida de Reg3 y Reg6 se llama A_prev, y B_prev-- que es básicamente el valor de A y B para el reloj anterior.

A continuación, creas una tabla de verdad más o menos así:

A_prev, B_prev, A, B, Count_En, Count_Dir
  0       0     0  0    0         0
  0       0     0  1    1         0
...etc...

Tendrá que completar toda la tabla de verdad usted mismo, pero tendrá la idea. Básicamente, observa el estado actual de A y B, junto con los valores anteriores para A y B, y decide si desea aumentar o disminuir su contador. Ahora creas algo de lógica para implementar esta tabla de verdad. Le recomiendo que también registre la salida de esta tabla de verdad, antes de enviar las señales al contador.

Esta tabla de verdad encaja en un par de LUT de 4 entradas (el componente básico de la mayoría de los FPGA). Esencialmente, esto es super pequeño. El registro de la salida de esta tabla de verdad también requiere una lógica prácticamente nula, ya que cada LUT en el FPGA tiene un Flip-flop en las salidas de los LUTS. Compare esto con hacer un poco de filtrado / rebote, lo que podría tomar 16 o 32 flip-flops y limita la utilidad de las LUT no utilizadas. Por lo tanto, esta lógica es 1/16 o 1/32 del tamaño de la versión filtrada / rebotada.

Si está utilizando un FPGA más nuevo que tiene una LUT de 6 entradas que se puede dividir en 2 LUT más pequeñas, este diseño utiliza incluso menos recursos lógicos.

El registro de la salida permite que su lógica se ejecute a más de 100 MHz en la mayoría de las FPGA modernas, o hace que sea mucho más fácil cumplir con sus limitaciones de tiempo cuando está a velocidades de reloj más lentas. Si bien esto no suena importante, no cuesta nada y mejora enormemente la robustez de este diseño y permite que sea reutilizado más fácilmente en proyectos futuros en los que su reloj principal sea más rápido.

Lo bueno de este diseño es que A_in o B_in pueden cambiar literalmente en cada borde de su reloj de 25 MHz. Si tiene un poco de ruido o rebote en sus entradas, es posible que su contador "vibre" de un lado a otro entre dos señales adyacentes, pero esto también podría suceder con una versión filtrada / desbocada.

La razón por la que este diseño no necesita filtrar / rebotar A y B es porque puede operar tan rápido como lo permita su reloj de 25 MHz. No se puede confundir con una entrada que cambia rápidamente o ruidosa, como podría hacerlo su diseño anterior.

Un motivo favorito mío es la decodificación en cuadratura mal implementada. Por lo general, es una mala implementación del software lo que hace que el decodificador pierda o salte pulsos, pero en ocasiones una implementación de hardware también lo hará. No estoy diciendo que filtrar / rebotar las entradas de cuadratura omitirá los pulsos, pero estoy diciendo que este enfoque es mejor en todos los aspectos, incluida la velocidad máxima que puede aceptar pulsos.