bogaev_roman 0 16 февраля, 2017 Опубликовано 16 февраля, 2017 · Жалоба Да, вероятность этого события не равна нулю. Но при двух и более синхронизаторов эта вероятность очень близка к нулю. Обсуждали недавно в Вашей же теме https://electronix.ru/forum/index.php?showt...p;#entry1472599 Для частоты 500МГц сбой для двух триггеров раз в 10^7 лет Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flip-fl0p 4 16 февраля, 2017 Опубликовано 16 февраля, 2017 · Жалоба Обсуждали недавно в Вашей же теме https://electronix.ru/forum/index.php?showt...p;#entry1472599 Для частоты 500МГц сбой для двух триггеров раз в 10^7 лет Именно ! Вот только как отследить возникновение метастабильности в схеме ? К примеру проект проходит по временным ограничениям. Моделирование показывает всё нормально. А периодически проект "ломается". Тут либо у меня где-то возникает метастабильность. Но скорее всего я не все возможные условия протестировал.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shivers 0 16 февраля, 2017 Опубликовано 16 февраля, 2017 · Жалоба Именно ! Вот только как отследить возникновение метастабильности в схеме ? К примеру проект проходит по временным ограничениям. Моделирование показывает всё нормально. А периодически проект "ломается". Тут либо у меня где-то возникает метастабильность. Но скорее всего я не все возможные условия протестировал.... Моделируйте нетлист с задержками. Триггера пересинхронизации периодически будут сыпать в лог ошибками нарушения setup/hold. Потом начните чистить лог - убирайте известные Вам триггера пересинхронизации. В логе останутся триггеры с нарушениями CDC, которые Вы забыли или пропустили. Либо, есть специальные тулы для анализа CDC - они помогают автоматически выявить все триггеры пересинхронизации в проекте. Я с ними не работал, называются вроде бы Spyglass и Comformal CDC. В остальном могу только посоветовать увеличивать покрытие проекта тестами, пока не найдете ошибку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Builder 0 16 февраля, 2017 Опубликовано 16 февраля, 2017 · Жалоба Так, ушли в сторону, обсуждать стандартные рекомендации, там и так всё понятно. Для новичком прикрепляю то, что уже было ранее на форуме. Вопрос был не в том, нужно ли 2, нужно, во всех рекомендациях так указывается, и объясняется почему, в этом случае вероятность ошибка крайне мала, в отличии от случая, когда один стоит. Иногда и 3 могут рекомендоваться, но тут нужно технологию чипа знать, что бы посчитать вероятность, оправдано ли 3. Причем во всех рекомендациях указано, что два регистра ставятся без логики между ними, тоже в принципе понятно - меньше вносим новых задержек, меньше вероятность повлиять на второй триггер, в худшую сторону. Вопрос был в том - насколько корректен код SM и почему, когда у него перед вторым триггером стоит простая логика. Я понимаю, что вроде как логику маппер скорее всего поставит от триггера родную - та что перед триггером, т.е. вероятность ухудшить ситуацию небольшая. Но это не гарантируется, и нужно ещё разобраться, насколько это ухудшает ситуацию. Не правильнее ли ставить два триггера и уже со второго что-то считать, как сделано в сообщении #13 (я у себя примерно так-же делаю). Да, так лишний может быть так (в среднем пол такта), но зато голова не болит, всё ли правильно работает. Или я что-то не понимаю... async_signals.pdf an042.pdf design_rules_for_stable.pdf CummingsSNUG2001SJ_AsyncClk_rev1_1.pdf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 16 февраля, 2017 Опубликовано 16 февраля, 2017 (изменено) · Жалоба Имеете ввиду что все же вероятность провала остается и чем чаще мы ее испытываем тем больше шансов все же ее поймать? Разумеется, это азы теории вероятностей. Если у Вас миллион устройств, к примеру, необходимо учитывать общую вероятность сбоя, вызванного метастабильностью. Изменено 16 февраля, 2017 пользователем x736C Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 16 февраля, 2017 Опубликовано 16 февраля, 2017 · Жалоба Разумеется, это азы теории вероятностей. Если у Вас миллион устройств, к примеру, необходимо учитывать общую вероятность сбоя, вызванного метастабильностью. То есть именно это вы имели ввиду по серийностью, понятно... Вопрос был в том - насколько корректен код SM и почему, когда у него перед вторым триггером стоит простая логика. В целом второй триггер продолжает выполнять свою функцию. Он защелкивает состояние первого, интерпретируя его в случае метастабильности. Второй триггер остается единственным потребителем сигнала первого(пусть и измененного), это его основная функция, так что схема вполне корректна. Я поставил бы 3 триггера в этой ситуации, просто чтобы вопросов небыло%). Добавление логики не всегда ухудшает ситуацию, надо понимать что проблемы не в задержках, а в попадении на определенный момент. В случае если первый триггер все же схватит кривое состояние, то дальше вопрос выйдет он на устойчивое положение до следующего клока, когда сигнал с него потребит второй триггер. Логика может сработать как "усилитель" которая задавит кривой сигнал в какое-то устойчивое положение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Builder 0 17 февраля, 2017 Опубликовано 17 февраля, 2017 · Жалоба В целом второй триггер продолжает выполнять свою функцию. Он защелкивает состояние первого, интерпретируя его в случае метастабильности. Второй триггер остается единственным потребителем сигнала первого(пусть и измененного), это его основная функция, так что схема вполне корректна. Я поставил бы 3 триггера в этой ситуации, просто чтобы вопросов небыло%). Добавление логики не всегда ухудшает ситуацию, надо понимать что проблемы не в задержках, а в попадении на определенный момент. В случае если первый триггер все же схватит кривое состояние, то дальше вопрос выйдет он на устойчивое положение до следующего клока, когда сигнал с него потребит второй триггер. Логика может сработать как "усилитель" которая задавит кривой сигнал в какое-то устойчивое положение. Понятно, как-то повлияет, но для количественной оценки нужно знать константы микросхемы и задержки, из которых по формулам, аналогичным app Altera, что прикрепил, оценивать как влияет. Причем это влияние сильно не линейно, в app показано, что доли наны очень сильно влияют на время сбоя, на несколько порядков. Но вопрос - стоит ли так делать в общем случае, остался открыт. Не в проекте лишний триггер и так погоды не делают - оставил два на входе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 17 февраля, 2017 Опубликовано 17 февраля, 2017 · Жалоба я триггеры не экономлю и делаю в общем случае так. 2 на входе - пересинхронизация, если нужна логика выделения фронта - это уже следующий этап пути данных и еще один триггер. Логически разделяю прием и выделение фронта. Так и в поддержке потом меньше вопросов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dimidrol 0 17 февраля, 2017 Опубликовано 17 февраля, 2017 · Жалоба Вы не знаете, будут они рядом стоящие, или не рядом. Только если обконстренить, что хлопотно очень. Если встречали в рекомендации по метастабильности такой вариант - покажите где. Ничего хлопотного, прямо в коде синхронизатора вставить ограничение ASYNC_REG. Для VHDL это будет: attribute ASYNC_REG : string; attribute ASYNC_REG of data_pipe: signal is "TRUE"; Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
