Уважаемые специалисты!
Помогите, пожалуйста.

С одного устройства (передатчика) на другое передаются данные.
Второе устройство (приемник) их принимает и обрабатывает.
Идеальные условия — режим отладки, когда передатчик с приемником подключены напрямую.

Реальные условия — устройства взаимодействуют через реальный канал связи.
То есть условия, при которых обнаружилась следующая проблема в приемнике.

Примерная схема работы такая:
После подачи питания ПЛИС загружается из EPC2 и начинает работать не так, как она работала в идеальных условиях.
Cделал вывод, что написанная мной программа неполноценна и в реальных условиях работает неудовлетворительно.
Критерий качества — сигнал кадровой синхронизации приемника. При незначительных отклонениях принимаемого сигнала от нормы приемник не удерживается в синхронизме.
Сброс ПЛИС соответствующим уровнем на соответствующей ноге ничего не меняет.

После загрузки ПЛИС через программатор (EPC2 не трогаю) приемник становится «идеальным». Во всем диапазоне требуемых значений ослабления сигнал синхронизации постоянно положительный. Как и задумывалось (моделировалось).
Сброс ПЛИС опять же не меняет картины, по-прежнему все хорошо.

Выключаю-включаю питание, все повторяется.

Устанавливаю значение Power-Up Don’t Care — ON.
При этом эффект исцеления пропадает, приемник работает одинаково паршиво.

Оба файла .pof и .sof сгенерированы одномоментно из одного проекта.

Вопросы:
В чем может быть причина такой работы?
Какие галочки я забыл поставить или забыл попробовать поставить?
Может ли быть такое, что прошивки pof и sof алгоритмически или топологически отличаются между собой?


ПЛИС: ACEX1K100
САПР: Quartus II Version 7.2 Build 151 SJ FV
Проект полностью синхронный.
Схема включения:
Нажмите для просмотра прикрепленного файла
*R65 не запаян.
Что еще забыл указать, спросите, пожалуйста.

интересно, как Вы на Power-Up Don’t Care — ON вышли.
В зависимости от on или off у Вас количество регистров в проекте должно меняться. Те регистры, которые формируют длительность сигнала, или просто игнорируются и константу выдают (по включению питания).
Дело скорее всего в Вашей схеме загрузки.
С trst сами разбирайтесь. Вроде бы он на vcc должен быть.
Настораживает объединение сигналов confdone и initdone как монтажное И.
Ведь confdone - двунаправленный с открытым стоком. После него ПЗУ еще 11 клоков выдает. Значит его анализирует. А Вы его INITdone задавили (Если он в проекте активизирован, должен отдельно на резисторе на vcc (выход с открытым стоком)). А если нет, то вообще не понятно это соединение.
В любом случае pof и sof тут непричем. (Смотрите раздел конфигурации и описания этих пинов, отвечающих за конфигурацию и инициализацию кристалла)

Спасибо за ответ.

Там просто не видно, но две стрелки подписаны «н» и «м» и это просто тест-поинты. То есть они никак не связаны.
Схема включения типовая (вроде бы).

Усиленно смотрю раздел конфигурации.
Есть подозрения, что это может быть от того, что выключена была галка «Enable device-wide reset (DEV_CLRn)».
Сброс у меня на этот вывод заведен. Может поэтому сброс в обоих случаях ничего и не менял?!
Предполагаю, что в двух вариантах программирования ПЛИС POR мог срабатывать/не срабатывать по-разному.
В общем буду читать дальше.

«Enable device-wide reset (DEV_CLRn)» я никогда не использовал. не знаю.
Если с выходом в 1 configdone все в порядке, sof не причем. Одинаково должен вести себя проект, что при загрузке кристалла из ПЗУ, что по jtag.

Или проект не корректен по начальным установкам.
Если как Вы думаете, работоспособность зависит от Power-Up Don’t Care — ON, OFF (посмотрите задействованные ресурсы регистров при включенной выключенной опции), значит есть в проекте однократно вырабатываемые сигналы по включению питания. Посмотрите хелп в квартусе.
Но с другой стороны это не должно влиять на протокол обмена между устройствами.
/////////////
Проверил проект в хелпе на асех эта опция не влияет, на например циклон влияет


Итак со схемой загрузки все в порядке. pof, sof не причем. Опция наверно тоже.
Должно все одинаково работать. Наверно так оно и есть.
может это проект. Иссяк.

Скорее всего проект некорректен по начальным установкам. Хотя работает в идеальных условиях. И работает при программировании напрямую. Загадка для меня.
Power-Up sense никак не повлияло на ресурсы. Сравнивал по Resource Usage Summary. Да и нет таких однократных сигналов у меня в проекте.
В любом случае, большое спасибо за желание помочь. Проект подгорает.

POR тут не причем. Если nSTATUS поднялся, значит POR отработал. sof, pof тоже разницы нет. И как вы именно грузите через JTAG или по другому - неважно.

Сброс - вот тут стоит посмотреть поподробнее. Здесь стоит посмотреть как схема выходит в рабочий режим. После загрузки конфигурации последним отпускается сброс для всех триггеров (тоже самое что и DEV_CLRn) и это событие никак не привязано к мастер клоку - который у вас 50 МГц. Попробуйте сделать синхронизацию сброса внутри ПЛИС к вашему клоку (пара триггеров для подавления метастабильности). Можно попробовать замаскировать клок сигналом INIT_DONE.
Можете еще поэкспериментировать с опцией Clear before Tri-States, но это, ИМХО, вряд ли чтото даст.

Спасибо за ответ. Попробую.
Сброс у меня в проекте везде синхронный.
Нет только пары триггеров для подавления метастабильности, как-то я это упустил.
Правда, насколько я понимаю, на частичной работоспособности это не должно сказываться,
так как он перекладывается на глобальный сброс таким образом:

у Вас установлена опция Auto-restart configuration after error? и есть ли подвязка цепей: TCK (83) к земле (через 1ком); и TMS(85), TDI(86) к питанию (через 10 ком)

1. Опция установлена.
2. Цепи JTAG подтянуты через 1 кОм. TCK к земле, остальные к питанию.

Нашел причину.
Присваивал значение шине wire и ей загружал регистры.
В спешке ступил.
Только так и не понял, почему результат «Power Up Care» не записывался во флеш или из флеш не попадал в ПЛИС. Ну и ладно.
Всем ответившим большое спасибо.
Тема закрыта.

Проблема, как оказалось, уже возникала.
http://www.fpgarelated.com/usenet/fpga/show/80025-1.php
Человек настаивает на баге Квартуса.
Вывод: неправильный стиль программирования.

Если вы не против то чуть приоткрою %) wire это не ошибка, это признак. Где то есть ситуация, когда ваш синхронизатор зависает и не может выбраться из патового состояния. Power Up Care как то влиял на вероятность этой ситуации.

Это не объясняет отличия в загрузке.

Есть еще такой нюанс.
При включении питания сигнал сброса выглядит, как ступенька _/ ,
тогда, как при загрузке через JTAG сигнал сброса п-образный \_/.
Если сигнал сброса асинхронный по спаду, тогда, может быть, это может сыграть.
Но у меня он синхронный во всем проекте. Поэтому не знаю, в чем дело.


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

Что значит Присваивал значение шине wire и ей загружал регистры.
приведите описание было - стало.
В квартусе можно по включению питания в FPGA установить регистры в любое состояние. Нет необходимости во внешнем ресете.
Более того, Вы так ничего и не сказали о протоколе обмена между передатчиком и приемником.
Там наверняка вообще не нужен никакой ресет.

Какое имеет отношение протокол обмена? Там сброс не нужен, я про это ничего и не говорил.
В первом сообщении написал, что сброс вообще никак не влиял на работу схемы. Влиял только лишь способ загрузки.
Вводной, которую я дал, вполне достаточно.
Я только лишь искал причину в сбросе. Потому что это единственное, что отличает загрузку из EPC2 и по JTAG. По крайней мере другого отличия я не нашел и мне не подсказал никто.
Об этом и спрашивал.

////После подачи питания ПЛИС загружается из EPC2 и начинает работать не так, как она работала в идеальных условиях.
Cделал вывод, что написанная мной программа неполноценна и в реальных условиях работает неудовлетворительно.
Критерий качества — сигнал кадровой синхронизации приемника. При незначительных отклонениях принимаемого сигнала от нормы приемник не удерживается в синхронизме.

И причем здесь загрузка.
Вот и спрашиваю, что реально сделали, что стала полноценной.

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

К сожалению, пока не стала полноценной. Занимался другим.

Пошли по кругу. Ох уж эти асехы. Наверно срок годности истек.

Вот и я об этом подумал.
Зачем я выбрал когда-то это старье.
Правда, это было три-четыре года назад, долгое время проект был в замороженном состоянии.
Ладно, спасибо в любом случае.

в своих проектах встречал такое поведение, как раз из-за того что синхронизаторы, в некоторых случаях, ставило раком.



как я понял вы интуитивно нашли способ "лечения" вопроса и порекомендовал вам еще раз проверить логику работы вашего синхронизатора. ИМХО где-то есть неучтенная логическая ветка, которая стреляет в некоторых условиях.

Пока не приступал к решению, занимался другим.
Спасибо за наводку, вашу рекомендацию учел, все перепроверю.

Может кому-нибудь будет интересно, в чем все-таки было дело.
Оказалось, действительно, в разнице сигнала сброс, о которой писал в сообщении #12.
Проблема всплывала везде, где сбросом в регистры устанавливалось что-то отличное от нуля.
Не смотря на синхронный сброс, важен был спадающий фронт, который появлялся только при JTAG-программировании.

Вылечилось заменой
на

Теперь всё!

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

Опять 25))

К сожалению, ни одной статьи не смог найти, не считать метастабильность, которая тут не причем.

не может быть что вы не были здесь

ЗЫ. смотреть статью "Synchronous Resets? Asynchronous Resets? I am so confused! How will I ever know which to use?"

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