Я извиняюсь, а куда ДОЛЖЕН попадать триггер, если время клокового перехода и время изменения данных совпадут?

В "физическом" мире может набежать задержка, что изменение на входе D тригерра произойдет одновременно с фронтом тактовой. И что - делаем растарт?

Первопричина статистически возможна - соответственно требуется устранять последствия. А как - только с помощью адекватной модели метастабильности!

Или кристалл на более быстрый меняем, или конвейер внедряем.

Этого можно вообще в большинстве случаев полностью избежать, грамотно сделав схему clock enable принимающего триггера так, что он при нестабильных данных на входе не будет щелкать. В остальных случаях этому триггеру запрещается переходить в X - в Xilinx например в таких случаях при нарушении setup/hold он не изменяет состояния. Но повторяю, наличие таких триггеров (или если он сваливается в случайное состояние) очень затрудняет поиск ошибки. Даже если он сделал X на пол-периода и следующий уровень это ошибочно щелкнул - вы можете не увидеть этой ошибки на выходах устройства (сделается этот X and 0 где-то и пропадет). А просматривать весь нетлист на предмет проскакивания там X - мало удовольствия.

А автоматический тестбенч?!
А просто напечатать строчку в файл или рабочую область со временем, когда он равнялся "X"?!

Это намного проще и НАДЕЖНЕЕ, чем предугадать ВСЕ возможные ситуации. И опыт тут ТОЛЬКО статистически уменьшит вероятность такой ситуации (сделать схему, которая не попадает в такие ситуации).

Может не в тему так как я на Альтере делаю
но была та же проблема - (я так и не разобрался в причинах её возникновения )
у меня автомат зависал на состоянии с безусловным переходом!!!

как я с бубном только не танцевал - и случайно "полечил" так сказать
поставил опцию для синтезатора чтоб не передокодировал состояния автомата
т.е если вершина 0101 то она не будет 0000100 при синтезе, а именно 0101
после чего зависания прекратились.

Сам понимаю как это выглядит ......
Но тем не менее блин заработало.
Причём такая лажа именно на одном проекте - до этого проекта я даже не предпологал что такое может быть.

Чего избежать? Одновременного прихода клока и данных, когда заранее известно, что данные расположены в другом клоковом домене? Наладив телепатическую связь между FPGA и источником входных данных?

Такое можно пропробовать сделать на элементах с разной задержкой и xor, но это бессмысленно. Избавимся от метастабильности по данным, но получим по clken.
Поясню, пример: вход триггера = 0, выход = 1, передний фронт клока возникает одновременно с переходом clken в активное состояние (или неактивное). Вот тут-то и появится метастабильность.

Важно понять, что при согласовании 2х доменов с неизвестной фазой, метастабильность будет хоть на 1 триггере. И в любом случае придется делать что-то вроде "запрос/ответ" при передаче данных. От того куда метастабильный триггер перебросится зависит КОГДА данные будут получены.

В прошлом посте я показал пример описания триггера. Надо добавить, что этим описанием нужно заменить в нетлисте только те триггеры, на которых метастабильность допускается.