Таймер и какая-то FSM синхронизируются от 100МГц. Таймер имеет нано-, микро-, мили- и секундные поля.

Как лучше считать на лету значение таймера в FSM, чтобы не нарваться на гонки, т.е. на еще незавершившийся в таймере переходной процесс?
Простейшее решение, перед считыванием приостановить таймер на время достаточное для завершения гонок, считать код в FSM, и опять включить. Но здесь есть как бы небольшие потери для таймера, а как без потерь?

Вопрос все же более теоретический…

А в чём тут собственно проблема? Таймер - это обычный двоичный счётчик. Довольно большой разрядности, но это не так уж и страшно на частоте 100 МГц.
FSM и этот счётчик работают на одной и той же частоте, соответственно временной анализ учитывает пути между выходом таймера и входом FSM. Всё синхронно,
тут не может быть никаких гонок. Могут не соблюдаться немного тайминги, но это лечится известными способами.Гонки возникают при асинхронщине, а тут всё должно быть шито-крыто.

Этот вопрос решён практически давным-давно: для того, чтобы было "без потерь" необходимо использовать Synchronous counter, а не Asynchronous (ripple) counter.
Для ускорения работы синхронных счётчиков большой разрядности в FPGA применяются специализированные схемы быстрого переноса.

P.S. Асинхронщина для FPGA противоестественна. Конечно, можно делать асинхронные схемы - но т.к. они противоестественны, то в большинстве случаев себе дороже.

Есть еще решение - двойная буферизация, т.е. будете иметь значение счетчика с опозданием на два такта, но это есть вариант обычно для синхронизации двух процессов на разных частотах. Но для Вас тоже должно подойти.
На счет гонок на частоте 100МГц - тоже оччень сомневаюсь, хотя...