dsmv 0 15 марта, 2010 Опубликовано 15 марта, 2010 · Жалоба Всем доброго времени суток. Предыдущая тема про метастабильность ушла в теоретическую область. Поэтому новый эксперимент хочу описать в отдельной теме. Итак. Метастабильное состояние это реальность данная нам в ПЛИС. Хотелось бы узнать, как это влияет на сигнал сброса для конечного автомата. Я написал небольшой компонент, который содержит два автомата - проверяемый (первый) и проверяющий (второй). Первый автомат работает на внешней тактовой частоте. Второй автомат - на фиксированной частоте 125 МГц. Сброс на первый автомат может подаваться четырьмя способами: 1. Асинхронный 2. Пересинхронизация на одном триггере. 3. Пересинхронизация на двух триггерах. 4. Пересинхронизация на двух триггерах с дополнительным разрешением через один такт. Состояние автомата кодируется двухразрядной шиной. Исходное состояние "00". Сразу после снятия сигнала сброс, автомат должен перейти в состояние "11"; В случае ошибки - он перейдёт в состояние "01" или "10"; Второй автомат запускается по команде от программы, выполняет 32769 циклов сброса первого автомата. И подсчитывает число правильных и неправильных переходов. Программа считывает результат и отображает его. Модуль AMBPEX8. ПЛИС XC4VSX35-11 Результаты такие: 1. Асинхронный сброс - всегда работает неправильно - как и следовало ожидать. 2. Пересинхронизация на одном триггере - Сбои начинаются на частоте 530 МГц. 3. Пересинхронизация на двух триггерах - Сбои начинаются на частоте 583 МГц 4. Пересинхронизация на двух триггерах с дополнительным разрешением через один такт - на частоте 614 МГц Здесь надо понимать, что вероятность сбоя есть всегда. Эти значения частоты при которой сбой происходит как минимум 1 раз в 10 секунд. А за 10 секунд автомат должен сработать около 32769 * 10 * 10 = 3276900 раз Также надо обратить внимание, что эти частоты выше, чем гарантированные рабочие частоты для этой микросхемы. Но вывод можно сделать такой: Асинхронный сигнал надо защёлкивать на двух триггерах. Текст компонента прилагается. cl_fsm_mt.vhd P.S. Никаких специальных требований к разводке компонента я не задавал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrew_b 16 15 марта, 2010 Опубликовано 15 марта, 2010 · Жалоба Сдаётся мне, тема открыта не в том разделе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dsmv 0 15 марта, 2010 Опубликовано 15 марта, 2010 · Жалоба Сдаётся мне, тема открыта не в том разделе. Возможно, но просто вся эта тема родилась из вопроса о стиле описания конечного автомата. А это здесь :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 15 марта, 2010 Опубликовано 15 марта, 2010 · Жалоба если практическая область, то почему не приводите констрейны и результаты STA для проекта? в плане асинхронного сброса интересно removal / recovery (у ксайлинса это как-то хитро делается) для асинхронных тактов это, ес-сно, бессмысленно но если синхронный сигнал подаете на асинхронный сброс, то хорошо бы такой анализ включить (UCF директива ENABLE=xxxxx, если не ошибаюсь) ---------------------- ну и формирование сброса на логике - тоже не очень правильный путь, особенно если нужна запредельная частота. возможно, что при подключении цепи сброса непосредственно к выходу триггера частоты получаться повыше ну и при жестких констрейнах пути для каждого бита станут "поровнее" хотя для совсем чистой практики - если STA проект забраковал, то все - пишите письма Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dspx 0 15 марта, 2010 Опубликовано 15 марта, 2010 · Жалоба Мне тоже кажется, что на таких частотах не выполнились требования СТА. Имхо, на ПЛИС при переходе одноразрядного сигнала из домена в домен , метастабильность устраняется на 2-х триггерах. Это классика, которую можно на практике даже не проверять. Даже тулзы для верификации эйсиков автоматом проверяют кросс-доменный сигнал на эту конструкцию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 16 марта, 2010 Опубликовано 16 марта, 2010 · Жалоба в этом случае (как мне показалось) демонстрируется явление не связанное с "физическим" свойством элементов типа метастабильности, а перекос шины (который на практике встречается гораздо чаще). то есть они присутствуют оба и какое из них доминирует - мне не понятно. если метастабильность явление вероятностное и против него можно только применять синхронизаторы, то с "перекосом" можно и нужно бороться средствами проектирования. возможно в запредельных частотах будет фиолетово, но все-таки мне кажется, что применив правильный подход для дизайна можно будет слегка приподнять тактовые частоты ----------------- тулзы для АЗИКов не проверяют ибо нет способа - все такие пути объявляются false path и их работоспособность на совести разработчика, причем далеко не всегда нужны синхронизаторы - из "верхнего" алгоритма может быть гарантировано известно время, когда сигнал на переходе стабилен и его можно защелкнуть "чужим" тактом Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dsmv 0 16 марта, 2010 Опубликовано 16 марта, 2010 · Жалоба в этом случае (как мне показалось) демонстрируется явление не связанное с "физическим" свойством элементов типа метастабильности, а перекос шины (который на практике встречается гораздо чаще). то есть они присутствуют оба и какое из них доминирует - мне не понятно. Я как раз хотел проверить именно влияние метастабильности. Мне кажется - это удалось. При прочих равных условиях явление метастабильности вносит дополнительную задержку. Изменение типа формирования сброса меняет вероятность попадания в метастабильность. Что мы и видим. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 18 марта, 2010 Опубликовано 18 марта, 2010 · Жалоба Хочу спросить у автора (так как не разбираюсь в VHDL) - у вас внутри первого (проверяемого) автомата сигнал сброса используется как синхронный или асинхронный? Если сброс асинхронный, то в первом случае нет условий для возникновения метастабильного состояния. Если частота сигналов выше предельной, то, может быть, уже нужно говорить, что сигналы просто не успевают переключиться из-за ограниченной скорости нарастания? Наверное, нет смысла использовать микросхему в недопустимом режиме работы, только если для выяснения ее предельных возможностей :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dsmv 0 18 марта, 2010 Опубликовано 18 марта, 2010 · Жалоба Хочу спросить у автора (так как не разбираюсь в VHDL) - у вас внутри первого (проверяемого) автомата сигнал сброса используется как синхронный или асинхронный? Если сброс асинхронный, то в первом случае нет условий для возникновения метастабильного состояния. Сигнал сброса выбирается сигналом rst_mode. 00 - выбирается rst_m0 - асинхронный сброс 01 - выбирается rst_m1 - синхронный, при этом используется только один триггер для пересинхронизации асинхронного сброса 10 - rst_m2 - синхронный - два триггера 11 - rst_m3 - синхронный - два триггера и ещё сигнал разрешения rst_mode устанавливается программой и не меняется в процессе эксперимента. Асинхронный сброс я завёл только для демонстрации того, что так делать нельзя. Сбои происходят на любой частоте. А вот с пересинхронизацией действительно получаются интересные результаты. Если частота сигналов выше предельной, то, может быть, уже нужно говорить, что сигналы просто не успевают переключиться из-за ограниченной скорости нарастания? Наверное, нет смысла использовать микросхему в недопустимом режиме работы, только если для выяснения ее предельных возможностей :) Конечно это эксперимент. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 19 марта, 2010 Опубликовано 19 марта, 2010 · Жалоба Насколько я понял из кода, signal rst_m0 : std_logic; -- асинхронный сброс ... rst <= rst_m0 when rst_mode="00" else ... if( rising_edge( aclk ) ) then ... if( rst='1' ) then stp <= "00" after 1 ns; то внутри сигнал сброса использовался как синхроннный с тактами aclk. Т.е. эксперимент был верный. Только лучше, вместо выявления предельной работоспособности по частоте, определить количество ошибок на максимальной рабочей частоте, для разных схем синхронизации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dsmv 0 19 марта, 2010 Опубликовано 19 марта, 2010 · Жалоба Только лучше, вместо выявления предельной работоспособности по частоте, определить количество ошибок на максимальной рабочей частоте, для разных схем синхронизации. На частоте 400 МГц c пересинхронизацией на одном триггере ошибок не зафиксировано в течении 1.5 часов. Вот только говорит ли это о чём-нибуть ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 22 марта, 2010 Опубликовано 22 марта, 2010 (изменено) · Жалоба На частоте 400 МГц c пересинхронизацией на одном триггере ошибок не зафиксировано в течении 1.5 часов. Вот только говорит ли это о чём-нибуть ? А в течение 6-ти часов? :) И второму автомату задать частоту, например, 333 MHz... И фронты ему завалить конденсатором! :) Хотя... это ж в одной ПЛИС? Тогда... нагрузить выход от второго автомата на кучу триггеров (только это, наверное, не поможет). Придумал - вывести наружу, завалить конденсатором, а потом уже - на вход первого автомата. То-то он "порадуется"! Изменено 22 марта, 2010 пользователем ViKo Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться