Загрузка ACEX1K из EPC2, pof и sof — в чем различие? Опции

[x736C]

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

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

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

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

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

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

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

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

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


ПЛИС: ACEX1K100
САПР: Quartus II Version 7.2 Build 151 SJ FV
Проект полностью синхронный.
Схема включения:

*R65 не запаян.
Что еще забыл указать, спросите, пожалуйста.

Сообщение отредактировал x736C - Aug 17 2009, 14:59

[x736C]

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

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

Код

reg          rst;
reg    [1:0] init;
always @ (posedge clk) begin
    if      (~reset)    init <= 0;
    else if (~&init)    init <= init + 1;
    rst <= &init; end

на

Код

always @ (posedge clk) begin
    if      (~reset)    init <= 0;
    else if (~&init)    init <= init + 1;
    rst <= init != 2'd2; end

Теперь всё!

[des00]

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

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

[x736C]

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

Опять 25))

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

[des00]

Опять 25))

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

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

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

[x736C]

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