[dsmv 0]

Всем доброго времени суток.

 

Предыдущая тема про метастабильность ушла в теоретическую область. Поэтому новый эксперимент хочу описать в отдельной теме.

 

Итак. Метастабильное состояние это реальность данная нам в ПЛИС.

Хотелось бы узнать, как это влияет на сигнал сброса для конечного автомата.

Я написал небольшой компонент, который содержит два автомата - проверяемый (первый) и проверяющий (второй).

 

Первый автомат работает на внешней тактовой частоте.

Второй автомат - на фиксированной частоте 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 14]

Сдаётся мне, тема открыта не в том разделе.

[dsmv 0]

Сдаётся мне, тема открыта не в том разделе.

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

А это здесь :laughing:

[yes 5]

если практическая область, то

почему не приводите констрейны и результаты STA для проекта?

 

в плане асинхронного сброса интересно removal / recovery (у ксайлинса это как-то хитро делается)

для асинхронных тактов это, ес-сно, бессмысленно

но если синхронный сигнал подаете на асинхронный сброс, то хорошо бы такой анализ включить (UCF директива ENABLE=xxxxx, если не ошибаюсь)

 

----------------------

 

ну и формирование сброса на логике - тоже не очень правильный путь, особенно если нужна запредельная частота.

 

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

ну и при жестких констрейнах пути для каждого бита станут "поровнее"

 

хотя для совсем чистой практики - если STA проект забраковал, то все - пишите письма

[dspx 0]

Мне тоже кажется, что на таких частотах не выполнились требования СТА. Имхо, на ПЛИС при переходе одноразрядного сигнала из домена в домен , метастабильность устраняется на 2-х триггерах. Это классика, которую можно на практике даже не проверять. Даже тулзы для верификации эйсиков автоматом проверяют кросс-доменный сигнал на эту конструкцию.

[yes 5]

в этом случае (как мне показалось) демонстрируется явление не связанное с "физическим" свойством элементов типа метастабильности,

а перекос шины (который на практике встречается гораздо чаще). то есть они присутствуют оба и какое из них доминирует - мне не понятно.

 

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

 

возможно в запредельных частотах будет фиолетово, но все-таки мне кажется, что применив правильный подход для дизайна можно будет слегка приподнять тактовые частоты

 

-----------------

 

тулзы для АЗИКов не проверяют ибо нет способа - все такие пути объявляются false path и их работоспособность на совести разработчика, причем далеко не всегда нужны синхронизаторы - из "верхнего" алгоритма может быть гарантировано известно время, когда сигнал на переходе стабилен и его можно защелкнуть "чужим" тактом

[dsmv 0]

в этом случае (как мне показалось) демонстрируется явление не связанное с "физическим" свойством элементов типа метастабильности,

а перекос шины (который на практике встречается гораздо чаще). то есть они присутствуют оба и какое из них доминирует - мне не понятно.

 

Я как раз хотел проверить именно влияние метастабильности. Мне кажется - это удалось.

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

Изменение типа формирования сброса меняет вероятность попадания в метастабильность. Что мы и видим.

[ViKo 1]

Хочу спросить у автора (так как не разбираюсь в VHDL) - у вас внутри первого (проверяемого) автомата сигнал сброса используется как синхронный или асинхронный? Если сброс асинхронный, то в первом случае нет условий для возникновения метастабильного состояния.

Если частота сигналов выше предельной, то, может быть, уже нужно говорить, что сигналы просто не успевают переключиться из-за ограниченной скорости нарастания? Наверное, нет смысла использовать микросхему в недопустимом режиме работы, только если для выяснения ее предельных возможностей :)

[dsmv 0]

Хочу спросить у автора (так как не разбираюсь в VHDL) - у вас внутри первого (проверяемого) автомата сигнал сброса используется как синхронный или асинхронный? Если сброс асинхронный, то в первом случае нет условий для возникновения метастабильного состояния.

 

Сигнал сброса выбирается сигналом rst_mode.

00 - выбирается rst_m0 - асинхронный сброс

01 - выбирается rst_m1 - синхронный, при этом используется только один триггер для пересинхронизации асинхронного сброса

10 - rst_m2 - синхронный - два триггера

11 - rst_m3 - синхронный - два триггера и ещё сигнал разрешения

 

rst_mode устанавливается программой и не меняется в процессе эксперимента.

 

Асинхронный сброс я завёл только для демонстрации того, что так делать нельзя. Сбои происходят на любой частоте.

А вот с пересинхронизацией действительно получаются интересные результаты.

 

Если частота сигналов выше предельной, то, может быть, уже нужно говорить, что сигналы просто не успевают переключиться из-за ограниченной скорости нарастания? Наверное, нет смысла использовать микросхему в недопустимом режиме работы, только если для выяснения ее предельных возможностей :)

 

Конечно это эксперимент.

[ViKo 1]

Насколько я понял из кода,

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]

Только лучше, вместо выявления предельной работоспособности по частоте, определить количество ошибок на максимальной рабочей частоте, для разных схем синхронизации.

 

На частоте 400 МГц c пересинхронизацией на одном триггере ошибок не зафиксировано в течении 1.5 часов.

Вот только говорит ли это о чём-нибуть ?

[ViKo 1]

На частоте 400 МГц c пересинхронизацией на одном триггере ошибок не зафиксировано в течении 1.5 часов.

Вот только говорит ли это о чём-нибуть ?

А в течение 6-ти часов? :)

И второму автомату задать частоту, например, 333 MHz...

И фронты ему завалить конденсатором! :)

Хотя... это ж в одной ПЛИС? Тогда... нагрузить выход от второго автомата на кучу триггеров (только это, наверное, не поможет).

Придумал - вывести наружу, завалить конденсатором, а потом уже - на вход первого автомата. То-то он "порадуется"!

Изменено 22 марта, 2010 пользователем ViKo