Странная проблема конфигурирования Spartan-3, legacy input error Опции

[makc]

Начал наладку новой платы с тремя 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 установлены в значения по-умолчанию.

[bms]

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

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

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

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

[makc]

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

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

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

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

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

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

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

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

[bms]

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

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

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

[makc]

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

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

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

Вряд ли это связано с DCM - на загрузку конфигурации они не влияют.

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

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

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

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

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

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

[HardJoker]

контактов пришлось оставить на 8 и 12) и все стало нормально работать. Теперь думаю - поможет-ли использование специальных буферов для CCLK? По идее, должно помочь.

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