Я привык считать, что вне зависимости от настроек компилятора (то есть даже в случае, когда установлена опция "PowerUp do not care") все триггеры ПЛИС после инициализации всегда находятся в детерминированном состоянии. То есть эта опция даёт свободу компилятору присваивать триггерам начальное значение 0 или 1 для оптимизации, однако триггер будет в любом случае инициализирован. Однако сейчас я в проекте наблюдаю следующее.

У меня есть FIFO, сгенерированное визардом. Сигнал SCLR не сгенерирован, "PowerUp do not care" включено. Ставлю SignalTap на внутренние счётчики FIFO, включаю power-up trigger в SignalTap. Нормально эти счётчики на момент инициализации имеют нулевое значение, но один раз на несколько сотен загрузок счётчик чтения инициализируется единицей. Соответственно счётчик чтения обгоняет счётчик записи, и FIFO становится неработоспособным.

Я конечно напишу об этом в Спортлото (то есть Альтере), но думаю, что они мне скажут генерировать sclr, и на этом вопрос закроется. Мне же интересно: получается что в принципе ПЛИС стартует в недетерминированном состоянии, вопреки документации. И у меня пол-года назад был похожий случай в другом проекте, когда я не инициализировал триггер явно, но заложился на его нулевое значение при инициализации, и в результате проект один раз из ста не работал. Кто что скажет?

Я скажу, что Вы живёте в каком-то сказочном мире, в котором отсутствуют переходные процессы и неопределённость при нарушении времён setup/hold.

Времянка естественно проверена. А если бы даже и нет (допустим, у меня неполностью описаны констрейны) я не вижу как введение сигнала sclr у сгенерированной мегафункции может чудесным образом исправить времянку.

На начальных этапах установки тактового сигнала (небось PLL используете?) "проверенная времянка" может и не выполняться. Вот и начинается лотерея вида "какой из двух счётчиков успел словить глитч и переключиться". Не знаю, что там у Вас за сигнал sclr, но видимо подразумевается сброс, который выполняется не раньше завершения всех переходных процессов и устаканивания тактов.

Это неплохая версия. Однако если она верна - то получается, что триггер может перекинуться от глитчей по частоте даже в том случае, если у него на enable ноль. А это у меня обеспечивается: вся машина состояний вокруг FIFO держится в сбросе как раз сигналом locked от PLL.

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

Мне тогда не очень понятно, почему Альтера разрешает конфигурацию, где у FIFO отсутствует вход сброса, раз такая конфигурация в большинстве практических случаев будет глючить.

Я думаю, что Альтере есть чем заняться помимо защиты пользователей от тривиальных ошибок.
Не могу я понять, к чему весь этот сыр-бор. Достаточно сделать правильный сброс системы и дёргать его перед началом работы - и всё и всегда будет работать. А в освободившееся от поиска глюков на ровном месте время можно сделать много полезных дел.

Сообщение отредактировал o_khavin - Mar 6 2014, 13:13

А глюкавость то в чем.
Если нет сброса, значит Вам безразлично переполнение, что при этом на выходе, значит сами разбираетесь с потоком
при помощи флагов и т.д.

Потому, что каждый HDL-разработчик это с пеленок знает, что все, что требует сброса, надо сбрасывать. Если Ваше FIFO требует сброса, то сбрасывайте - если у Вас используется глобальный сброс по DEVCLRn, то можете сбрасывать без входа у фифо.

Если бы это было видно на флагах - я бы внутрь FIFO бы не полез.


Совершенно верно. Однако я считаю, что если компонент позволяет конфигурацию без входа сброса - значит он сброса не требует. Как минимум в такой конфигурации.

А в части задач он и не требует сброса. Когда идут потоковые данные, и приход в начале пачки кривых данных из-за ненулевых начальных счетчиков на работоспособность системы не влияет. Так что не видно никаких проблем - если у Вас система такая, или используете DEVCLRn, генерируйте фифо без сброса, если нет, то со сбросом.

Я как то тоже так делал, и у меня не всегда сбрасывалось, и я удивлялся.
Также, изредка что-то не сбрасывалось.
Сброс был синхронный.
Потом рассудил, что после захвата частоты PLL для сброса нужен хотя бы 1 такт.
Хотя там вроде выставляется число тактов удержания locked (если не ошибаюсь), но все равно подглючивало.
Как только отказался от сброса на locked и перешел на внешний ресет все заработало, глюк исчез.

Псоле установки locked делаю счетчик на 64/128 тактов. По окончанию работы счетчика - снимаю общий сброс с ПЛИС. Счетчик сбрасывается непосредственно от locked.

Такая конструкция никогда не сбоила при любой загрузки ПЛИС при условии выполнения констрейнов на всем температурном диапазоне и даже больше (до минус 50 гоняли).

А вот система с одним locked нестабильна и вот почему - в железе иногда выводили его на пин и смотрели осциллографом - сигнал дрожал иногда! И посему часть логики сбрасывалась а часть - нет.

Я тут тоже недавно такт и LOCKED вывел от PLL наружу и несколько удивился. Оказывает LOCKED появляется несколько раньше чем устаканится период тактового сигнала. Правда у меня Virtex-6.
Я подсмотрел такое решение для сброса - сооружаем на одном SRL16 / 32 сдвиг LOCKED от PLL. А после - детектор фронта (или просто инвертор). Таким образом получается сигнал сброса с некоторой задержкой относительно LOCKED. По ресурсам проще чем счетчик, согласитесь.