Иногда попадаются грабли, когда FSM, синтезированная в режиме one-hot, улетает в какое-то неизвестное состояние, и на этом работа заканчивается. Если закодировать в compact - теряем в скорости, зато избавляемся от этой проблемы.
"When Others => stIdle" ситуацию не спасает - все равно при синтезе его соптимизируют
Как можно избавиться от неизвестного состояния в One-Hot?

Хе-хе... Можно, конечно, взять на работе несколько дней творческого отпуска и попытаться осилить вот это: http://alexandria.tue.nl/extra2/200413270.pdf
Но что-то мне не нравится эта идея.

Надо смотреть на конкретный код, но все это странно. Если кодирование one-hot, то состояние определается единственным битом. Пусть 4 состояния.
0001 - 1
0010 - 2 и т.д.

Допустим система как то попала в 0011. По левой единице FSM должен решить что состояние "1" (смотря как написано, естественно) и вести себя соответственно.

А может быть не правильно написан сам конечный автомат.
Возникают условия перехода сразу два состояния?

В такой ситуации можно дать только самые общие рекомендации. например сигнал сброса должен быть синхронным чтобы гарантировать одновременное "отпускание" всех триггеров автромата

Мы встречались с подобными эффектами, особенно при работе FSM на высоких частотах. У себя мы боролись с этим следующими методами:
1. Максимальное упрощение логики вычисления следующего состояния автомата и выделение этой логики в отдельные process;
2. Стробирование входных сигналов тактовой частотой работы FSM;
3. Задание constrain по периоду.

После использования вышенаписанного нам полегчало