Начал наладку новой платы с тремя Spartan-3 TQ-144 speedgrade 4 в последовательной цепочке. Конфигрурирует их микроконтроллер из подсоединенной к нему Flash-памяти. Конфигурирование ведется в режиме Slave Serial.

Суть проблемы в следующем: в некоторых случаях конфигурирование завершается неудачей (нет сигнала Done), в ряде случаев Done появляется, но одна из ПЛИС (вторая в цепочке и тольно она одна) не отвечает на запросы (она подключена к шине микроконтроллера и на чтение не отвечает). При этом в результате чтения регистра статуса ПЛИС через JTAG после обнаружения описанной ошибки конфигурирования выяснились два интересных симптома:
1. ПЛИС-2 (вторая в цепочке) выдает сигнал Done, но при этом у нее бит регистра статуса GHIGH = 0, в то время как должен быть 1 (GWE тоже 0).
2. ПЛИС-2 (вторая в цепочке) не выдает сигнал Done, а в ее регистре статуса установлен в 1 бит legacy input error, значение которого не совсем понятно.

Я изучил формы и уровни сигналов CCLK, DATA, PROG, DONE - все в пределах нормы. Частота CCLK - менее 1МГц. Пауза после перехода PROG из 0 в 1 около 10 мс, т.е. более чем достаточно для успешного начала конфигурирования.

В связи с вышеизложенным возникает вопрос - чем может быть вызвано появление "legacy input error" и нулевое значение GHIGH после конфигурации? Может-ли это быть связано (хотя по описанию ПЛИС связи нет) с использованием блоков DCM в проектах? Что еще можно попробовать и куда посмотреть?

PS: Настройки bitgen в ISE установлены в значения по-умолчанию.

См. XAPP452: Legacy input error. This error occurs when serial data is loaded too fast.

Да, это я видел. Вот только ясности это не добавляет, т.к. как я уже написал выше, частота на CCLK у меня не более 1МГц, в то время как она может быть до 50МГц. Или под "too fast" понимается не частота CCLK, а что-то другое?

А Вы учли тот момент, что после загрузки самой конфигурации в выбраном Вами режиме нужно ещё дать N-клоков для того чтобы запустить процесс "startup"?

И ещё, несмотря на то, что конф. клок у Вас 1 МГц - проблемы могут быть всё равно, если Вы его вывели на все кристаллы из одной точки. Где-то здесь на форуме уже встречался товарищ с такой же ошибкой. Тоже удивлялся, что частота низкая, а загрузка идёт со сбоями. Проблема решилась тем, что он клок завёл на каждый ПЛИС отдельно, т.е. поставил буфер и размножил синхросигнал - сделал всё по правилам.

Люди часто не правильно понимают эту штуку, думают раз частота низкая - проблем не будет. Но важна ведь не частота, а ЧИСТЫЙ ФРОНТ на всех частотах! И на низких и на высоких. Раньше подобных проблем действительно не было - кристаллы были медленные и попросту не успевали реагировать на быстрый "дребезг" на фронтах. Сейчас входы у ПЛИС-ов очень быстрые, реагируют даже на такие "пички" на фронтах, которые не каждым осциллом увидишь.

Если у Вас клок "один передатчик - 4-ре приёмника", то проблема почти наверняка в этом (если конечно протокол загрузки верный).
Клок должен быть "один передатчик - один приёмник" и правильно согласованным к тому же. Очень много знаю пострадавших, которые пренебрегли этим несложным правилом.

Да, это есть. В другом устройстве такой же алгоритм конфигурирования работает нормально.



Да, потолковал с разработчиком ПП, посмотрел трассировку - там все от одного источника. Цепь получается довольно длинная...



Да, один передатчик и три приемника. Однако вот что странно: зацикливаю вызов функции загрузки кристаллов и наблюдаю, что первые два раза все кристаллы в цепочке успешно конфигурируются, а последующие попытки ни к чему не приводят (Done в нуле). При этом такое поведение стабильно, т.е. наблюдалось более десяти раз и каждый раз первые две попытки - успешно, остальные - нет. Если предположить, что проблема в "грязных" фронтах тактового сигнала конфигурирования ПЛИС, то почему стабильно первые два раза они "чистые", а потом становятся "грязными"?

В проектах ПЛИС используются блоки DCM. Может-ли проблема конфигурирования быть связана с ними (при учете того, что параметр STARTUP_WAIT для DCM = FALSE)?

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

Вряд ли это связано с DCM - на загрузку конфигурации они не влияют.
Всё-таки рекомендую Вам распараллелить клоки. При некорректной прокладке клоков, как в Вашем случае, можно наблюдать и не такие чудеса. Я например однажды наблюдал обратную ситуацию - первые два-три раза ПЛИС стабильно НЕ ГРУЗИЛСЯ, а потом сколько угодно раз грузился нормально (даже если выключать/включать питание). Путём несложных экспериментов выяснили, что такая работа - это результат прогрева платы! Неправильно расстрасированный клок ведёт себя как угодно, поведение его непредсказуемо. Незначительно меняются паразиты - немного меняется форма фронта (т.к. паразиты меняются в том числе и с прогревом микросхем и c изменением питаня). Иногда этих изменений достаточно, чтобы что-то перестало грузится.

И ещё, надеюсь Вы не забыли, что конфигурационный интерфейс у спартана-3 сидит на питании 2,5В? Как согласованны логические уровни контроллера и ПЛИС-а?

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

Причина установлена. См. ниже.



Могут повлиять, но если поставить у них специальный атрибут - STARTUP_WAIT.



На этой плате ничего распараллелить уже не получится. Не хочется изголяться и вешать сопли в виде навесного монтажа.

В общем, проблема оказалась в следующем: на этой плате помимо указанных трех ПЛИС в одной конфигурационной цепочке, есть еще одна ПЛИС, прогружаемая из XCF. Она загружается первой и спустя некоторое время ее начинает использовать хост (ПЛИС реализует интерфейс с шиной PCI и т.п.). При этом часть ее выходов используется в качестве 32-х разрядной шины, которая начинает работу в ответ на действия хоста. И именно работа этой 32-х разрядной шины нарушала процесс конфигурирования цепочки ПЛИС. Этим и объясняются первые две успешные попытки конфигурирования (хост еще не запустился и не начал работу) и все остальные со сбоями (хост начал свое черное дело). IOB этой 32-х разрядной шины были настроены на ток 12 мА и, судя по всему, одновременное переключение большого количества контактов приводило к помехам на CCLK, что, в свою очередь, вызывало все описанные странные сбои. CCLK при этом имеет довольно большую длину, хотя и располагается на другой стороне платы от проводников указанной шины. Для выхода из сложившейся ситуации я сейчас перевел большую часть IOB этой шины на ток 4 мА (несколько контактов пришлось оставить на 8 и 12) и все стало нормально работать. Теперь думаю - поможет-ли использование специальных буферов для CCLK? По идее, должно помочь.



Это я знаю и разработчик схемотехники при разработки принципиальной схемы учел указания в соответствующем XAPP.

Не помешает ферритовая бусина (600 Ом на 100 MHz) на выходе буфера... и не забыть резистор нагрузки на конце цепи CCLK.

С какой целью?

Это из разряда тяни-толкай. Кто окажется сильнее. Если будете ставить буфер, ставьте посередине. Помеха на половинной длине шины будет меньше.
Также поможет экранирование.
Возможно у вас помехи накладываются, так что следует избавляться и от собственных помех. Как было замечено - терминированием. Раз у вас такие проблемы с помехами, поставьте делитель, если нет особой борьбы за энергопотребление.

По поводу "бусины", мне тоже непонятно зачем? Для согласования передатчика, обычно, используют резистор, включенный последовательно.

Тут не только тяни-толкай, но и еще время фронта имеет значение. И у буфера оно будет меньше, чем у выхода GPIO у микроконтроллеров. При этом я не думаю, что наводки были настолько велики (осциллографом их засечь не удалось), что могли привести к появлению лишнего импульса на этой линии. Скорее всего, искажался фронт. Поэтому буфер и видится решением проблемы, причем буфер, поставленный как можно ближе к микроконтроллеру (чтобы сократить длину линии, где возможны искажения).



В том то и дело, что фактически линия CCLK отделена от линий упомянутой шины полигоном земли (она на нижней стороне платы, а шина на стороне компонент - верхней). Поэтому экранирование тут, как мне кажется, не поможет.



Единственное объяснение - в качестве фильтра, который сможет погасить все паразитные (ВЧ) искажения в линии. Но на сколько это будет эффективно я не могу сказать.

А... ну да, знакомая проблема...
Использование специальных буферов для CCLK ситуацию однозначно улучшит, только не ставьте в клок никаких там бусинок - Боже упаси! Не надо никаких дополнительных реактивных элементов в цепи клока, иначе проблем станет только больше. Ставьте согласующие резисторы - самое простое и надёжное решение.
И рекомендую обратить внимание на цепи питания всех этих ПЛИС-ов, т.к. очень странно, что работа 32-х разрядной шини вызывает такие фатальные проблемы... Это говорит о том, что проект вообще говоря имеет ошибки (например повышенный шум питаний из-за плохой развязки). Корректно разведенные цепи (и клоки и данные), правильно согласованные и имеющие качественное питание никаких таких проблем иметь вообще не должны. У меня в одном проекте живут и ПЛИС-ы и DIMM-модули памяти и скоростные АЦП/ЦАП-ы, контроллер и плюс ко всему этому земля поделена на аналоговую и цифровую, питаний - тоже несколько. Проект молотит на скорости в 180 МГц. И всё это дружно работает, никто никому не мешает. Кстати сказать там нет ни одной ферритовой бусинки в цепи клоков и ни одного экрана, если всё сделано правильно ничего "эдакого" не требуется.

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

Успехов!

Вообще говоря, это единственная проблема, которая была обнаружена в ходе многодневного тестирования. При этом на самой этой шине не было ни одной ошибки. Цепи питания ПЛИС спроектированы в соответствии с рекомендациями Xilinx, причем с запасом (рассчитывали на больший ток потребления).

Хочу добавить, что теоретически существует еще и такой ход. PCI стандарт допускает, что можно переключать не сразу всю шину, а только половину, при этом не выставляя готовность. И на следующем такте переключать вторую половину шины, и соответственно, уже выставляя готовность. Это позволит уменьшить число одновременно переключаемых пинов. Но, работает при условии, что есть время для дополнительного клока, т.к. на 4 клок начинает работать PCI мост...
Удачи!