Altera - начальное состояние, Все ли триггеры инициализируются прошивкой? Опции

[DmitryR]

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

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

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

[DmitryR]

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

[sazh]

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

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

[DmitryR]

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

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

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

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

[SM]

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

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