Есть плата с FPGA Xilinx Spartan-3E-500, кристалл заполнен на 98%. Логика, зашитая в FPGA, управляется процессором ARM по параллельной ISA-подобной шине. "Прошивка" давно отлажена и обкатана на огромной серии плат и никаких проблем с ней никогда не было, всё работало без проблем.
Но вот выпущен очередной релиз плат (другим производителем, но топология та же) , с которыми происходят странные вещи. На 80% плат прошивка в FPGA через какое-то время (от 15 мин до нескольких часов) частично перестаёт выполнять свои функции, как бы "зависает". Со стороны процессора всё выглядит ОК - регистры пишутся-читаются, команды отдаются, но ... логика FPGA не работает, причём только часть - другая (существенно большая часть) продолжает исправно молотить и выполнять, что требуется.
Идентичный софт на идентичной плате другого производителя (с тем же блоком питания, если что ...) молотит без проблем сутками. Потребляемый ток всеми вариантами плат не отличается, перегревов нет, напряжения питаний в норме. Сигнал DONE наличествует как до, так и после сбоя.
Я теряюсь в догадках - что тут может быть, куда копать и что смотреть ?

глючащий модуль порты на выводы плиса имеет ?

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

в Chipscope то что видно?

Гонки, глитчи.
Не помню как точно называется, 10 лет в руки не брал, но в Xilinx Foundation был режим симуляции после разводки.
С учетом реальных таймингов.
Там все спорные места обычно сразу всплывают, даже если в первоначальной симуляции (до разводки) их не было.

Скорее всего здесь в ПЛИСе автомат ловит наводку по входам или CDC сделано не корректно... И этот автомат становится в неизвестное или не описанное состояние из которого не прописан выход... Ну и далее он там и остается до следующего сброса...
Обычное дело...

я про входные данные. если они есть, то 99% асинхра в интерфейсах вылезла

Чипскоп туда, видимо, не затолкнуть (98% заполнение), да и JTAG-a на плате нет. А на похожей плате, где JTAG есть - проблемы такой нет ...

Да, это я понимаю... Как отловить такие наводки ?
CDC да, есть небольшой грешок (1.25 вместо 1.2), но ведь работает всё это добро на таких же платах. Начинку FPGA делал не я, исходники есть, но оставлю это на крайний случай. Она тоже проверена временем и перенесена на плату в бинарном виде.


Из входных данных только управление по параллельной шине, подключенной к EBI процессора, в остальном, откисающий блок занимается тем, что перекачивает данные из SDRAM в последовательный ЦАП, управление простейшее - задаётся базовый адрес, длина, даётся команда старт взводом бита в регистре, всё - данные понеслись в ЦАП. В какой-то момент, вместо ожидаемых данных (клок+дата) тишина, после этого процессор может перезаписывать новый базовый адрес, взводить команду старт и всё что угодно - это ничего не помогает.
Действительно, складывается впечатление, что именно этот автомат попал в какую-то мертвую точку.
Но почему именно на этой серии плат - вот в чём основной вопрос ?
Что с ними может быть не так (бракованые ПЛИС, стабилизаторы питания, кондесаторы) ?

А спидгрейт у плис такой же как и всех других плат, или изменился?

вы же сами сказали, была переразводка. например один сигнал управления, раньше был позже другого, а тут они поменялись %)



иначе бы они старые прошивки не загрузили.

Это если поставили с более медленным спидргейтом. Я не про то. Если спидгрей стал быстрее, то при наличии где то в схеме асинхронного управления это тоже может привесит к подобному поведению.

хмм, если мне память не изменяет у них IDCODE будут разные и программатор, без хака, не даст прошить плисину.

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

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

Я бы взял старую плату и перепаял с нее ПЛИС на новую глючную плату. Если не заработает, то проблемы в новой плате (найти три отличия, помеху или еще что), а если все ОК будет, то претензии к модели, особенно если в дизайне много асинхронности.

Что касается вопроса, как он задан: у меня альтеры горели "частично", т.е. скажем в нее грузилась прошивка и работала, но один i/o банк при этом был всегда в закоротке; либо другой случай из жизни - прошивка грузится, но не работает и ПЛИС греется как утюг (предположительно - внутренняя закоротка в цепи питания нескольких банков i/o, но с живым житагом, памятью и интерфейсом конфигурации). Итого, гипотетически можно представить единичные случаи отказа отдельных узлов ПЛИС. Но не в вашем случае (80% плат).
Итого, скорее всего проблема в плате.