No seré yo el infeliz que vaya a recomenzar aquí una batalla "Atmel-micropic", aunque seria interesante ver como esta el asunto. Abro el tema en otra parte del foro ¿ok?

Nunca he usado un timer, ¿el timer es solo "up", o es "up-down"?

Puedes seleccionar flanco de bajada o de subida si es a eso a lo que te refieres, y cuenta los flancos en un registro de 8 o 16 bits con las respectivas interrupciones, útil si tu enconder te da una señal pulsatoria.

No es eso.
El encoder incremental se hace de la siguiente manera:
Se pone un disco con marcas en el borde. Entonces dos sensores apuntan a esas marcas PERO un sensor esta ligeramente adelantado respecto al otro.
Entonces al detectar un paso 0 a 1 , el segundo sensor estará a 0 si el motor gira en un sentido y a 1 si gira en sentido opuesto.
Entonces un sensor se conecta al reloj y el otro a la señal up-down del contador.
Si el flanco se produce con el segundo sensor a 1, se incrementa el contador, pero si se hace estando a 0 se produce un decremento.
Como puede haber problemas de rebotes (se trata de mitigar con un triger smith y filtro pasa bajo), se pone un reset de contador al paso por 0, lo cual implica un tercer sensor 🙁
Con un poco de lógica y empleando dos contadores se podría hacer con un microcontrolador, sin embargo con un FPGA habria que implementar ADCs que es mas dificil.

Creo que entiendo lo que quieres decir, la finalidad es sumar cuando va en un sentido y restar a esa suma cuando se produce un giro en sentido contrario para saberr siempre la posición de la rueda.

No necesitas los contadores de los pics, ya que estos solo añaden un 1 al registro del timer cuando detectan un flanco de subida o de bajada, aunque con dos pines del micro y llevando tú la cuenta es sencillo hacerlo. No sé si habrá algún micro con un modulo hard para hacer esto, quizás algunos de los pics pensados para motores te de la opción.

Lo que no veo es lo del paso por cero que dices, supongo que te refieres a la posición cero del encoder, que se puede llevar por soft.

Los puertos de algunos pic llevan un trigger smichdt dentro, para evitar los rebotes lo suyo sería como dices un disparador con histerésis, no sé si un filtro pasobajo es necesario, depende de los sensores o encoders que estes usando, si los haces o son los de un motor. Pero en cualquier caso si se puede hacer con un microcontrolador, cuales son los motivos para usar una FPGA?

Las FPGA se usan porque, muchas veces, los encoder proporcionan frecuencias de pulsos demasiado altas para el micro. Un encoder de 1000 pulsos por vuelta a 3000 rpm de motor da pulsos a 180 Mhz!!! En estos casos es necesario usar contadores y registros de captura y comparación por hardware, que interrumpen al micro cuando se alcanzan los valores programados.
Yo monté un sistema para leer encoders contando con dos contadores ascendentes de un i8254 (no tenía descendentes). Un contador cuenta cuando el encoder gira a derechas y el otro cuando gira a izquierdas. Esto se hace poniendo en un contador la señal A del encoder al enable y la B al clock y en el otro la B al enable y la A al clock. De esta forma cuando gira en un sentido A>B está activo solo el primer contador y cuando gira en el otro B>A solo el segundo. Luego el micro lee los valores de los dos encoder y los resta. De esta manera tienes el valor real de pulsos en un sentido - pulsos en el otro.
Esto lo utilicé en Dixi: http://heli.xbot.es/fd/dixi.htm
Es una tecnología un poco antigua pero sirve como ejemplo, actualmente hay muchos micros con módulos para encoder de varios canales, "capture compare", muchos PWM etc.