[Vadim 0]

Это самоуспокоение какое-то. Триггер НЕ ДОЛЖЕН попадать в метастабильное состояние.

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

[Kopart 0]

Это самоуспокоение какое-то. Триггер НЕ ДОЛЖЕН попадать в метастабильное состояние.

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

 

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

[sazh 8]

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

 

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

[DmitryR 0]

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

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

[Kopart 0]

А просматривать весь нетлист на предмет проскакивания там X - мало удовольствия.

А автоматический тестбенч?!

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

 

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

[arexol 0]

Такой пример. СИНХРОННЫЙ автомат имеет 6 состояний:а,б,в,г,д,е,ж. Каждому синтезатор присваивает код 000001,000010,000100,001000,010000,100000.

Входной управляющий сигнал привязан к 50МГц из которого формируется 1МГц (пробовал автомат и на 50 МГц - ничего не дало)

После запуска автомат бегает по определенным состояниям согласно алгоритму, но в какой-то момент (типа кто-то голове грохнул) автомат переходит в состояние 000000! (никаких конфликтов внутри нет). И все... стоим-с.

Асинхронными сбросами, управлением я уже давно не пользуюсь - на рассыпухе их наелся.

Бред какой-то. В какой-то момент становиться просто смешно, но потом становится очень грустно - не первый день сижу,

 

Симуляция показывает все ок.

 

Конечно

 

Может не в тему так как я на Альтере делаю

но была та же проблема - (я так и не разобрался в причинах её возникновения )

у меня автомат зависал на состоянии с безусловным переходом!!!

 

как я с бубном только не танцевал - и случайно "полечил" так сказать

поставил опцию для синтезатора чтоб не передокодировал состояния автомата

т.е если вершина 0101 то она не будет 0000100 при синтезе, а именно 0101

после чего зависания прекратились.

 

Сам понимаю как это выглядит ......

Но тем не менее блин заработало.

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

[Vadim 0]

Этого можно вообще в большинстве случаев полностью избежать, грамотно сделав схему clock enable принимающего триггера так, что он при нестабильных данных на входе не будет щелкать.

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

[dvladim 0]

Vadim

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

Такое можно пропробовать сделать на элементах с разной задержкой и xor, но это бессмысленно. Избавимся от метастабильности по данным, но получим по clken.

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

 

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

 

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