...acechando al glitch

El glitch suele pasar por ser uno de los principales quebraderos de cabeza al que se deben enfrentar los diseñadores de sisrtemas digitales

Si a esto además le unimos el hecho de que desde ahora estamos describiendo los circuitos a nivel alto y que el sintetizador se encarga del resto, implementando un circuito desde una descripción en la que el nivel más bajo suelen ser los componentes diseñados y acoplados usando VHDL estructural, podemos estar seguros que, el glitch, normalmente ¡jugará en campo contrario!

Veamos, sino, este ejemplo

Ejemplo: diseño de un contador

Este ejemplo muestra el código correspondiente a un contador. El código, en sí, es totalmente normal y, en principio no hay lugar a ninguna sospecha

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity comptador is port

( clk, reset:in std_logic;
tc: out std_logic;
q: out std_logic_vector(3 downto 0));

end comptador ;
architecture rtl of comptador is
signal actual:std_logic_vector(3 downto 0);
begin

process(clk, reset)
begin

if reset='1' then actual<=(others=>'0');
elsif clk'event and clk='1' then actual<=actual+1;
end if;

end process;
q<=actual;
tc <= '1' when actual = 15 else '0';

end rtl;

La siguiente gráfica muestra el resultado de la simulación con Modelsim

Sin embargo, ¿qué ocurre cuando pasamos a sintetizar el circuito?

La gráfica siguiente muestra el resultado de la síntesis realizada con Altera. Podemos comprobar como ¡se introducen glitchs debidos a retardos de simulación!
La gráfica inferior es una ampliación de la zona de glitch en la señal tc (terminal counter). Si se considera que tc es una señal que a menudo se utiliza como trigger de otra circuitería digital, ¡la duración del glitch, aunque no es suficientemente grande (en este caso es de 0.3 ns), ya me ha ocasionado en alguna ocasión más de un problema!

¡Y es que es curioso la transición que se efectúa para pasar del estado B al C. Resiguiendo la simulación (gráfico inferior) podemos observar que desde que se sucede el flanco de reloj, la salida q, que muestra el estado del contador, pasa del estado B

...al estado A = 1010 (dura cerca de 0.1 ns)
...después vuelve al B = 1011
...para finalizar al C = 1100

y es en esta última transición que, por un momento, tc=q3·q2·q1·q0 realiza la transición 1·0·1·1 -> 1·1·1·1 -> 1·1·0·0, motivo por el que, durante décimas de ns, pasa a ser igual a 1 ¡y se activa!

¿Qué recomendaciones hay que dar sobre los glitchs?

Hay que cuidar que no se produzcan, bajo ningún motivo, sobre señales fundamentales de control: reset, reloj, etc.

Caso de que se quiera mantener la señal tc con las mismas características como se diseñó el ejemplo anterior, entonces sólo quedaría modificar el código.
Para ello pueden ser interesantes dos soluciones

- Modificar de forma que tc se activase por flanco de bajada

- Introducir una señal de estado 'vieja' para mantener el estado anterior de forma que tc fuera igual a (viejo=14)and(actual=15)

- Trabajando con una variable interna al proceso: