Я привык считать, что вне зависимости от настроек компилятора (то есть даже в случае, когда установлена опция "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 отсутствует вход сброса, раз такая конфигурация в большинстве практических случаев будет глючить.

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

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

Потому, что каждый 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. По ресурсам проще чем счетчик, согласитесь.

У меня сделано так.

После того, как PLL захватила, формируется сброс в течение двух тактов.
upd. Не двух, а "как повезет", от одного до двух. Если мало, можно добавить в последовательность.

А почему бы сигнал locked с PLL не использовать для асинхронного сброса? Всегда так делаю, проблемы не возникает. Все всегда работает:



Сигнал nRESET идет прямо с выхода locked PLL

На временном пост-фиттерном моделировании (встренным моделятором) в квартусе 9.2SP2 и ниже видел такое странное дело, когда при вставшем в единицу LOCKED частота у PLL еще тактов 10-15 могла немного, совсем чуть-чуть, гулять. Может это были глюки симулятора или отображения сигналов, но глазом при различных масштабах зума времянки это было заметно. Поэтому при сбросе от LOCKED лучше делать небольшой счетчик, который либо отложит сброс схемы ненадолго, либо подольше подержит схему в сбросе.

Значит у Вас ещё впереди много неизведанного.

Моделирую в ModelSim, там все нормально. Скорее всего, глюк кокого-то из этих симуляторов. Но у меня ни в одном проекте еще не было проблем с начальным сбросом схемы. Тьфу-тьфу-тьфу

Вы точно уверены что именно в этой ПЛИС тригеры 0 после включения и стабилизации частоты?
Вроде надо спец опцию компилятора для этого включать.... и не все семейства такую опцию имеют....

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

Понятно, значит дело в полосе захвата клока pll-кой. Тогда, все логично, так и должно быть )

Но тогда почему такого поведения нет в моделсиме, как писал dima32rus? Кстати, у меня в моделсиме такое поведение тоже не наблюдается (правда, в моделсиме я провожу только функциональное моделирование).

Встроенный моделятор квартуса это совсем другое дело, по сравнению со всякими там HDL-симуляторами....

Прикладываю скриншот из моделсима для Gate Level Simulation. Как видно, нестабилен только самый первый такт после утановки сигнала nRESET (locked PLL). Дальше тактовая частота уже не гуляет. Совсем.

Можно пруф? Что именно симулятор Квартуса такого симулирует отличающегося от других HDL-симуляторов? Там какой-то секретный HDL используется? Мне почему то казалось, что один и тот же HDL-код должен одинаково вести себя во всех симуляторах, которые написаны с применением стандарта. А если не ведёт, то надо пинать ногой писателя этого симулятора.
Скорее уже, в самой модели PLL-и может быть какой-нить параметр, который отвечает за упрощённое моделирование процесса в целях ускорения симуляции. Мне подобное встречалось, к примеру, в моделях DDR-памяти (уменьшение фактической глубины памяти на несколько порядков) и, если не изменяет память, в моделях примитивов Xilinx-а.

И в альтеровской ПЛЛ такое вроде есть, но я бы в любом случае не полагался на результаты моделирования PLL. Ибо симуляционнаяL вряд ли будет полностью идентичной тому, что реализовано в кремнии. Это все-таки не цифровая логика с задержками.

Там вообще HDL никакой не используется. Там, грубо говоря, моделируется схема, получившаяся после разводки ПЛИС. Отсюда и его ограничения, что нельзя подключать тестбенчи, а надо задавать входные воздействия буквально руками, и отсюда же точность времянок и симуляции поведения железа куда лучше, чем vo+sdo+моделятор.

P.S. хотя, для описания их внутренних блоков, наверное, действительно, какой-то секретный HDL используется. Но мы этого никогда не узнаем, оно все там в бинарном виде совершенно не дешифрируемом.

P.P.S. По точности симуляции симуляция квартуса vs симуляция HDL - примерно как FastSPICE симуляция ASIC vs HDL.

Пруф в студию.

Вам надо, сами и ищите. Мне сейчас некогда бесполезной и в реальности никому не нужной работой заниматься. Сорри.

Да уж, вежливость зашкаливает.

Как и адекватность просьбы. Я, по-вашему, должен за альтеру что-то там доказывать? Мне это не интересно и не нужно.

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

А я и не собирался особо утруждаться в ответ на такие провокации. Какой еще ответ может быть на вопрос, ответ на который могут дать только разработчики этого симулятора, и никто иной? Там все закрыто наглухо. Кому же реально интересно доказательство этого - спросит никак не у пользователей форума, а у технической поддержки альтеры. Правда, я почти уверен, их ответ будет по сути близок к моему...

А почему тогда Altera отказались от встроенного симулятора в пользу того-же ModelSim'а? По идее, нужно наоборот...

Так вроде его вернули в последних версиях, не? Где-то здесь читал, что он на самом деле не выпилен и его можно хитрым образом включить.

Да реально бестолковый он. В нем можно толком только что-то очень простое отсимулировать, задавая в графическом редакторе диаграммы входных сигналов. Мышиная возня, а не симуляция. Вот если бы они бы добавили к нему HDL ко-симуляцию, чтобы задавать воздействия тестбенчем, и подключать модели внешних навесов, например памяти, вот тогда бы... Но предпочли пойти более простым путем.

Так у PLL(Altera) есть "Gated Lock", как раз тот самый счетчик. В MagaWizard - это пункт Inputs/Lock -> Lock Output -> Hold 'locked' output low for * cycles after the PLL initializes.

Что касается встроенного симулятора в Quartus 13.0 он присутствует.