DmitryR 0 6 марта, 2014 Опубликовано 6 марта, 2014 · Жалоба Я привык считать, что вне зависимости от настроек компилятора (то есть даже в случае, когда установлена опция "PowerUp do not care") все триггеры ПЛИС после инициализации всегда находятся в детерминированном состоянии. То есть эта опция даёт свободу компилятору присваивать триггерам начальное значение 0 или 1 для оптимизации, однако триггер будет в любом случае инициализирован. Однако сейчас я в проекте наблюдаю следующее. У меня есть FIFO, сгенерированное визардом. Сигнал SCLR не сгенерирован, "PowerUp do not care" включено. Ставлю SignalTap на внутренние счётчики FIFO, включаю power-up trigger в SignalTap. Нормально эти счётчики на момент инициализации имеют нулевое значение, но один раз на несколько сотен загрузок счётчик чтения инициализируется единицей. Соответственно счётчик чтения обгоняет счётчик записи, и FIFO становится неработоспособным. Я конечно напишу об этом в Спортлото (то есть Альтере), но думаю, что они мне скажут генерировать sclr, и на этом вопрос закроется. Мне же интересно: получается что в принципе ПЛИС стартует в недетерминированном состоянии, вопреки документации. И у меня пол-года назад был похожий случай в другом проекте, когда я не инициализировал триггер явно, но заложился на его нулевое значение при инициализации, и в результате проект один раз из ста не работал. Кто что скажет? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
o_khavin 0 6 марта, 2014 Опубликовано 6 марта, 2014 · Жалоба Кто что скажет? Я скажу, что Вы живёте в каком-то сказочном мире, в котором отсутствуют переходные процессы и неопределённость при нарушении времён setup/hold. :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitryR 0 6 марта, 2014 Опубликовано 6 марта, 2014 · Жалоба Я скажу, что Вы живёте в каком-то сказочном мире, в котором отсутствуют переходные процессы и неопределённость при нарушении времён setup/hold. :) Времянка естественно проверена. А если бы даже и нет (допустим, у меня неполностью описаны констрейны) я не вижу как введение сигнала sclr у сгенерированной мегафункции может чудесным образом исправить времянку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
o_khavin 0 6 марта, 2014 Опубликовано 6 марта, 2014 · Жалоба Времянка естественно проверена. А если бы даже и нет (допустим, у меня неполностью описаны констрейны) я не вижу как введение сигнала sclr у сгенерированной мегафункции может чудесным образом исправить времянку. На начальных этапах установки тактового сигнала (небось PLL используете?) "проверенная времянка" может и не выполняться. Вот и начинается лотерея вида "какой из двух счётчиков успел словить глитч и переключиться". Не знаю, что там у Вас за сигнал sclr, но видимо подразумевается сброс, который выполняется не раньше завершения всех переходных процессов и устаканивания тактов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitryR 0 6 марта, 2014 Опубликовано 6 марта, 2014 · Жалоба На начальных этапах установки тактового сигнала (небось PLL используете?) "проверенная времянка" может и не выполняться. Вот и начинается лотерея вида "какой из двух счётчиков успел словить глитч и переключиться". Не знаю, что там у Вас за сигнал sclr, но видимо подразумевается сброс, который выполняется не раньше завершения всех переходных процессов и устаканивания тактов. Это неплохая версия. Однако если она верна - то получается, что триггер может перекинуться от глитчей по частоте даже в том случае, если у него на enable ноль. А это у меня обеспечивается: вся машина состояний вокруг FIFO держится в сбросе как раз сигналом locked от PLL. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 6 марта, 2014 Опубликовано 6 марта, 2014 · Жалоба если у него на enable ноль. Это если эта енабля заведена на жестко на соответствующий физический вход триггера. А если разрешение рулит через мультиплексоры на логике, то увы... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitryR 0 6 марта, 2014 Опубликовано 6 марта, 2014 · Жалоба Мне тогда не очень понятно, почему Альтера разрешает конфигурацию, где у FIFO отсутствует вход сброса, раз такая конфигурация в большинстве практических случаев будет глючить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
o_khavin 0 6 марта, 2014 Опубликовано 6 марта, 2014 (изменено) · Жалоба Мне тогда не очень понятно, почему Альтера разрешает конфигурацию, где у FIFO отсутствует вход сброса, раз такая конфигурация в большинстве практических случаев будет глючить. Я думаю, что Альтере есть чем заняться помимо защиты пользователей от тривиальных ошибок. Не могу я понять, к чему весь этот сыр-бор. Достаточно сделать правильный сброс системы и дёргать его перед началом работы - и всё и всегда будет работать. А в освободившееся от поиска глюков на ровном месте время можно сделать много полезных дел. Изменено 6 марта, 2014 пользователем o_khavin Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sazh 3 6 марта, 2014 Опубликовано 6 марта, 2014 · Жалоба Мне тогда не очень понятно, почему Альтера разрешает конфигурацию, где у FIFO отсутствует вход сброса, раз такая конфигурация в большинстве практических случаев будет глючить. А глюкавость то в чем. Если нет сброса, значит Вам безразлично переполнение, что при этом на выходе, значит сами разбираетесь с потоком при помощи флагов и т.д. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 6 марта, 2014 Опубликовано 6 марта, 2014 · Жалоба Мне тогда не очень понятно, почему Альтера разрешает конфигурацию, где у FIFO отсутствует вход сброса, раз такая конфигурация в большинстве практических случаев будет глючить. Потому, что каждый HDL-разработчик это с пеленок знает, что все, что требует сброса, надо сбрасывать. Если Ваше FIFO требует сброса, то сбрасывайте - если у Вас используется глобальный сброс по DEVCLRn, то можете сбрасывать без входа у фифо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DmitryR 0 6 марта, 2014 Опубликовано 6 марта, 2014 · Жалоба А глюкавость то в чем. Если нет сброса, значит Вам безразлично переполнение, что при этом на выходе, значит сами разбираетесь с потоком при помощи флагов и т.д. Если бы это было видно на флагах - я бы внутрь FIFO бы не полез. Потому, что каждый HDL-разработчик это с пеленок знает, что все, что требует сброса, надо сбрасывать. Если Ваше FIFO требует сброса, то сбрасывайте - если у Вас используется глобальный сброс по DEVCLRn, то можете сбрасывать без входа у фифо. Совершенно верно. Однако я считаю, что если компонент позволяет конфигурацию без входа сброса - значит он сброса не требует. Как минимум в такой конфигурации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 6 марта, 2014 Опубликовано 6 марта, 2014 · Жалоба Однако я считаю, что если компонент позволяет конфигурацию без входа сброса - значит он сброса не требует. Как минимум в такой конфигурации. А в части задач он и не требует сброса. Когда идут потоковые данные, и приход в начале пачки кривых данных из-за ненулевых начальных счетчиков на работоспособность системы не влияет. Так что не видно никаких проблем - если у Вас система такая, или используете DEVCLRn, генерируйте фифо без сброса, если нет, то со сбросом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alevnew 0 13 марта, 2014 Опубликовано 13 марта, 2014 · Жалоба А это у меня обеспечивается: вся машина состояний вокруг FIFO держится в сбросе как раз сигналом locked от PLL. Я как то тоже так делал, и у меня не всегда сбрасывалось, и я удивлялся. Также, изредка что-то не сбрасывалось. Сброс был синхронный. Потом рассудил, что после захвата частоты PLL для сброса нужен хотя бы 1 такт. Хотя там вроде выставляется число тактов удержания locked (если не ошибаюсь), но все равно подглючивало. Как только отказался от сброса на locked и перешел на внешний ресет все заработало, глюк исчез. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
warrior-2001 0 13 марта, 2014 Опубликовано 13 марта, 2014 · Жалоба Как только отказался от сброса на locked и перешел на внешний ресет все заработало, глюк исчез. Псоле установки locked делаю счетчик на 64/128 тактов. По окончанию работы счетчика - снимаю общий сброс с ПЛИС. Счетчик сбрасывается непосредственно от locked. Такая конструкция никогда не сбоила при любой загрузки ПЛИС при условии выполнения констрейнов на всем температурном диапазоне и даже больше (до минус 50 гоняли). А вот система с одним locked нестабильна и вот почему - в железе иногда выводили его на пин и смотрели осциллографом - сигнал дрожал иногда! И посему часть логики сбрасывалась а часть - нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dimidrol 0 13 марта, 2014 Опубликовано 13 марта, 2014 · Жалоба Я тут тоже недавно такт и LOCKED вывел от PLL наружу и несколько удивился. Оказывает LOCKED появляется несколько раньше чем устаканится период тактового сигнала. Правда у меня Virtex-6. Я подсмотрел такое решение для сброса - сооружаем на одном SRL16 / 32 сдвиг LOCKED от PLL. А после - детектор фронта (или просто инвертор). Таким образом получается сигнал сброса с некоторой задержкой относительно LOCKED. По ресурсам проще чем счетчик, согласитесь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться