Есть плата, на которой установлены в единой JTAG цепочке Spartan 2 (XC2S150) и загрузочная флэшка для него XCF01S, первым в цепочке Spartan, затем Flash. Кабель фирменный на LPT, Xilinx Parallel IV Download Cable.
Проблема заключается в том, что с помощью кабеля битстрим не удаётся корректно загрузить в Spartan - процедура загрузки отрабатывает до 100%, после чего выноcится приговор "Program Failed" и в окне сообщений пишется что-то типа "Pin Done not drive High". Однако пин Done подтянут к 3.3 В резистором 330 Ом, согласно рекомендациям Xilinx, на нем также висит светодиод через ключевой транзистор.
Что примечательно - таких проблем нет с флэшкой, которая вторая в цепочке, загрузка по JTAG в неё сгенерированного из битстрима файла всегда проходит правильно, после этого в процессе включения Spartan из неё отлично грузится, зажигая при этом светодиод Done.
Верификация битстрима из Spartan-a (при включении в проекте такой опции) показывает огромное количество ошибок (около 250 000 различий), причем число это одно и то же от проверки к проверке, и меняется только при изменении самого битстрима (коррекции проекта). Это говорит о том, что звоны и шумы тут, видимо, ни при чём.
Цепочку прозванивал, всё пропаяно хорошо, она нормально инициализируется, можно читать ID, статусы - всё ОК. А вот заливка битстрима не идёт. В чём может быть причина ?

Ваш случай: http://www.xilinx.com/support/answers/20047.htm

К сожалению, это не то. В моем случае пин DONE не поднимается, а там описан случай, когда DONE High, но FPGA не стартует (ноги в Z-состоянии).

1. Тоже возился на днях. Связка Spartan-IIE и XCS01S. Только кабель digilent. Та же фигня. Битстрим в ПЛИС с кабеля - фигу (DONE в '0'). С флэшки грузится.
Соображения такие:
1) Режим загрузки Boundary Scan со своими значениями M0...M2 введен неспроста... Если у вас отладочная плата, то джамперами установите этот режим (если не отладочная плата, то этот вариант пропускаем ).
2) У вас нога PROGRAM от ПЛИС с ногой CF флэшки соединена? Может здесь причина? В даташите написано, что при загрузке битстрима по житагу PROGRAM должна быть притянута к '1'. А нога CF как раз через житаг в ноль устанавливается. Посмотрите осциллом ногу PROGRAM во время загрузки битстрима с кабеля. Если в ноль где-то переходит, возможно, проблемма в этом (в этом случае TAP-контроллер сбрасывается со всеми вытекающими). Тогда попробуйте CF оторвать, а PROGRAM оставить на резисторе подтяжки.
3) В моей вышеупомянутой связке был косячок - сигнал CCLK был соединен с другой пиной ПЛИС. Эта пина оказалась DOUT (до загрузки ПЛИС выход). В итоге сигнал CCLK был кривоват - не опускался до 0В, а только до 1В. При этом ПЛИС не грузилась (хотя флэш и при таком клоке исправно выдавала данные ). И причем можно было с кабеля битстрим загрузить. Когда я этот косячок исправил - ПЛИС с кабеля грузится перестала. В связи с этим можно попробовать как-нибудь флэшку временно "парализовать" - оторвать от нее CCLK или еще как-нибудь. Может поможет.
И кстати, а зачем вам по житагу битстрим в ПЛИС грузить? Ресурс флэши жалеете? (это я так спрашиваю, из любопытства ). А то я не стал париться (ну не получилось, ну и ладно) - прошивал флэш, щупом коротил PROGRAM на '0' (чтоб питанием не щелкать - остальные узлы не тормозить)...

для отладки очень удобно и быстро

Вроде как Boundary Scan должен быть доступен всегда, независимо от установок M0...M2. Вот цитата из даташита: "Configuration through the boundary-scan port is always available, independent of the mode selection. Selecting the boundary-scan mode simply turns off the other modes."

Да, CF соединена с PROGRAM, но при загрузке по JTAG в FPGA там всегда 1, лог. 0 там проскакивает, если при заливке во флэшь выбрать опцию "Load FPGA", что вобщем-то логично - после заливки флэши инициируется загрузка битстрима в FPGA.

Вобщем, более пристальное исследование показало вот что - если флэшка, из которой грузится FPGA и которая вторая в цепочке JTAG, пустая - загрузка битстрима в FPGA по JTAG проходит совершенно беспроблемно, верифицируется успешно через Readback и пин DONE поднимается. Но если во флэшке залит валидный битстрим для FPGA - загрузка по JTAG никогда не проходит - пин DONE падает, INIT_B в лог. нуле, по CCLK из FPGA прет клок порядка 4 МГц - видимо, FPGA впадает в бесконечный цикл загрузки битстрима по Master Serial, в этом состоянии попытка заливки битстрима по JTAG ничего не меняет и верификация (readback)показывает одно и то же большое число ошибок.
Создается впечатление, что после инициализации конфигурации по JTAG два битстрима мешают друг другу - один льется по Master Serial из флэшки, другой по JTAG.
Тем не менее решение проблемы нашлось ! В параметрах битстрима я увеличил скорость со стандартной 4 до 10, сгенерировал из него новый файл для флэшки, залил его во флэш - и о чудо - проблема разрешилась. Теперь загрузка по JTAG проходит без проблем, даже если во флэшке уже есть другой битстрим.
Решение найдено полуслучайным путем, возможно, эксперты в JTAG разъяснят причину такого поведения связки FPGA-Flash.

В альтере эта проблема разрешается одной галкой (или опцией командной строки) - Halt on-chip configuration controller. У вас думаю она разрешится поиском аналогичной опции.

А почему бесконечный? Вроде должно залить и остановиться?
Понятно, что в ЭТОМ состоянии по JTAG заливаться не обязана - предыдущая попытка конфигурации еще не кончилась.
JTAG надо пытаться заливать ПОСЛЕ того, как флэшка закончит свое черное дело
Видимо поэтому и проходит - флэшка успела залить все, что хотела

Потому что INIT_B, соединенный с флэшовым RESET-ом - в нуле, соответственно, флэшка в резете и ничего не отдает.
INIT_B, насколько я понял, из даташита, ведёт себя так - при включении (или PROGRAM=0) падает в ноль, инициируя и сбрасывая флэшку, затем, после очистки внутренней памяти FPGA, становится в единицу. После этого FPGA (в режиме Master Serial) начинает генерить клок CCLK и ждёт валидного заголовка битстрима, и ждать его может до бесконечности, генеря при этом клок. После заливки битстрима верифицируется его CRC, и если он неверный - INIT_B падает опять в ноль.
В моем случае, если во флэшке чисто - JTAG-битстрим корректно заливается, но если во флэшке что-то есть - видимо, заголовок из флэшки успевает "залететь" в FPGA раньше JTAG-ского, а вот что дальше - мне непонятно. Возможно, два битстрима каким-то образом мешают друг другу, в конце концов в FPGA не сходится CRC и INIT_B падает в ноль. Но зачем FPGA при этом продолжает генерить CCLK - загадка. Может кто из экспертов разъяснит.

И вообще - почему они друг другу мешают ? Неужели разработчики FPGA Xilinx не предусмотрели такой простой вещи - если с JTAG приходит команда "залить битстрим", не нужно при этом генерить CCLK и грузить из флэшки. Странно всё это, может, я чего-то неправильно понимаю ...

При включении Spartan будет грузить в себя прошивку в соотвествии с режимом на ногах M0-M2. И пока он не закончит эту загрузку (успешно или нет), он не будет ничего заливать через JTAG (насколько я помню).
Так что вот этого
быть не должно - если загрузка из флешки пошла - она должна закончится, и только ПОТОМ можно будет по JTAG'у загрузить что то другое
Потому что пытаются работать параллельно
Он этого и не делает.

А что бы из флешки не хваталось, что непопадя, есть специальный режим загрузки (по М?) - JTAG, при этом Spartan просто не производит загрузку при включении ВООБЩЕ.

Должна быть другая JTAG-команда - отключить весь внутренний контроллер конфигурирования вообще. По идее.... И скорее всего в регистре ISC_Config (IEEE 1532). Но ведь они все все скрывают, гады...

И будет она работать до ближайшего обнуления ноги Program, которая похоже этот 'внутренний контролер' ресетит

Ну по логике-то она и вход Program должна бы срубать, JTAG он "главнее всех", им можно вообще все пины вырубить нахрен