Проблема с Altera - CONF_DONE Опции

[Yoo]

При заливке sof (Cyclone 2) выдаёт: Error: CONF_DONE pin failed to go high in device 1
При этом если отключить от ПЛИС на плате CLK(заведён на пользовательский IO), то всё проходит.
Вроде как пользовательские сигналы не должны влиять на программирование ПЛИС.

В чём проблема-то немогу понять?

[Alex11]

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

[sazh]

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

Скорее всего все дело в разводке JTAG в длизи клоковых дорожек.

Скорее всего все дело в разводке JTAG в близи клоковых дорожек.

[Igor_S]

Скорее всего все дело в разводке JTAG в длизи клоковых дорожек.

Что-то не очень верится, да и кстати - откуда информация, что грузится через JTAG? Уважаемый автор, поясните, пожалуйста режим конфигурации - JTAG, PS, AS...

Я один раз имел головную боль, исполльзовав один из User IO (FLEX10K, Max Plus) для аппаратного сброса (он был подключен к входу Manual Reset супервизора, который формировал общий сброс при отсутствии одного из питающих напряжений). Так при окончании конфигурации, на этом User IO, невзирая на то, что при конфигурации он в тристейте с включенным подтягивающим резистором, а после - в USER MODE - туда железно подавалась "1" - проскакивал "0". Все дело было в том, что:
- во время конфигурации, User IO находятся в тристейте путем дективации внутреннего глобального сигнала "Output Enable"
- в это же время, все выходные регистры удерживаются в "0" путем активации внутреннего глобального сигнала "RESET"

- После окончания конфигурации, в течении, по-моему, 16-ти периодам Configuration Clock (CCLK) - оба вышеописанных глобальных сигнала деактивируются. И вот тут-то и была засада - какой из них деактивируется первым? Это указывается в опциях проекта (как в MAX, так и в QUARTUS), что-то типа "RELEASE RESET BEFORE OE". В моем же случае, OE включался первым, разрешая работу выходного буфера, в ео время как выходной триггер продолжал удерживаться в "0" все еще активным сигналом RESET...

Не может здесь быть что-то подобное, гонки разрешенного буфера и выхода клок генератора?

[sazh]

Что-то не очень верится, да и кстати - откуда информация, что грузится через JTAG?
Я один раз имел головную боль, исполльзовав один из User IO (FLEX10K, Max Plus) для аппаратного сброса (он был подключен к входу Manual Reset супервизора, который формировал общий сброс при отсутствии одного из питающих напряжений). Так при окончании конфигурации, на этом User IO, невзирая на то, что при конфигурации он в тристейте с включенным подтягивающим резистором,

Если грузили *.sof, то наверно по jtag. А вот при загрузки из ПЗУ при включении питания уже наверно не было причин отключать внешний клок. При конфигурации User IO FLEX10K действительно в третьем состоянии, но у нее нет подтягивающих внутренних резисторов, так что это третье состояние скорее всего как ноль идентифицировалось внешним потребителем.
Насчет включения супервизора тоже не понял. При отсутствии одного из питающих напряжений он должен наверно подавать ресет с открытым стоком на вход плис n_config

[Igor_S]

Если грузили *.sof, то наверно по jtag. А вот при загрузки из ПЗУ при включении питания уже наверно не было причин отключать внешний клок. При конфигурации User IO FLEX10K действительно в третьем состоянии, но у нее нет подтягивающих внутренних резисторов, так что это третье состояние скорее всего как ноль идентифицировалось внешним потребителем.
Насчет включения супервизора тоже не понял. При отсутствии одного из питающих напряжений он должен наверно подавать ресет с открытым стоком на вход плис n_config

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

Да, скорее всего Вы правы насчет jtag - я не заметил упоминания про *.sof.