Здравствуйте.
В связи с необходимостью принятия решения о целесообразности применения ПЛИС возник такой вопрос: а как можно (и можно ли) определить, правильно ли она функционирует? Вот, например, загрузили в нее файл конфигурации, она заработала, а затем произошел сбой в конфигурационных данных (скачок питания, помеха и тд). Как выявить эту ситуацию? Для ОЗУ, например, можно посчитать контрольную сумму. А как для ПЛИС?
Буду благодарен за любые советы или ссылки.

Для Xilinx,например-это режим ReadBack (см. например XAPP176)

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

Мне кажется, что если есть высокие требования надежности, то стоит не заморачиваться на чтение конфигурации на ходу, а посмотреть в сторону Actel с их ProAsic. Ну и конечно использовать дублирование.

Я бы не сказал, что требования к надежности крайне высоки. Например, при выявлении неправильной работы не будет проблемой перезагрузить конфигурацию или перезапустить устройство. Но как выявить эту неправильную работу - вот в чем вопрос. Дублирование - это, конечно, хорошо, но, может, есть более простые методы?
Кстати, есть ли у кого информация о том, насколько вероятно искажение конфигурации ПЛИС? Может, я слишком усложняю себе жизнь и такие искажения маловероятны?
PS: К слову, сейчас пока смотрим в сторону FPGA от Altera, т.к. есть небольшой опыт их использования (ACEX)

to makc
<Readback это, конечно, хорошо. Но ведь в процессе самого чтения конфигурации тоже может возникнуть ошибка, т.е. конфигурация будет правильной, но считана будет неправильно... >
Все таки вероятность этого мизерна.

<Мне кажется, что если есть высокие требования надежности, то стоит не заморачиваться на чтение конфигурации на ходу, а посмотреть в сторону Actel с их ProAsic.>
Ну а я бы "по заморачивался" над тем, чтоб среду разработки и отладки не менять.

to DPL
Можно попробовать через JTAG контроллировать содержимое.

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

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

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

2 one_man_show:
Видимо, только так и придется поступать. Я надеялся, что есть способы определить сбой заблаговременно, пока он еще не проявил себя

2 vetal:
Спасибо, попробую посмотреть, что они пишут о сбоях.

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

Согласен, она может быть небольшой. Но это будет зависеть он нескольких факторов, в т.ч. частоты работы JTAG'a. И все-равно эта вероятность будет.



Ну почемуже сразу менять среду разработки? Ведь можно использовать практически один и тот же софт (Synplify) и разные PAR. Так что я не могу сказать, что это большая сложность. И, к тому же, нужно выбирать для определенной задачи походящий инструмент, если есть такая возможность.



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

to makc
<... Но это будет зависеть он нескольких факторов, в т.ч. частоты работы JTAG'a. ...>
Хотя это больше уже похоже на придерание к словам (моей стороны), но ошибка в JTAG цепи зависит от длинны линии (согласовывать или нет), а не от частоты работы (т.к. буфера не меняются), и от "экранированности" (наводок) линий. Вот с последним могут быть проблемы.
Ну еще, не вижу ничего страшного в том, что FPGA ошибочно перезагрузиться. Ведь автор заявляет, что ничего страшного в этом нет, хотя для меня это загадка

Никакого придирания к словам тут нет. Все верно, причины ошибок выделены верно. Но с ростом частоты вероятность ошибки будет расти, т.к. перечисленные факторы будут оказывать все большее влияние. К тому же нужно не забывать, что размер конфигурационной памяти большинства современных FPGA далеко не один килобит, а тысячи.



Для меня тоже.

<... Но с ростом частоты вероятность ошибки будет расти, т.к. перечисленные факторы будут оказывать все большее влияние. ...>
При нормально согласованной линии, влияние будет оказывать только наводимая ЭДС, а она от частоты работы JTAG не зависит.

Вот мы и пришли к закономерному выводу. Если все делать нормально (правильно), то проблем не будет. Но вот только одна есть проблема - даже если все правильно спроектировано, то это правильно спроектированное может быть неправильно изготовлено и это бывает довольно часто. Я думаю, что Вы с этим знакомы не по наслышке.

PS: А что касается наведенной ЭДС - так ведь можно же заэкранироваться. Хотя, если говорить про JTAG, разведенный на плате, то это опять же вопрос правильного проектирования платы.

Как совершенно справедливо заметил one_man_show, "наличие сигналов PowerGood, мониторов питания и сторожевых таймеров в системах повышенной надежности считается аксиомой". А для чего это все? Вероятно, чтобы остановить|перезапустить систему в случае возникновения определенных отказов . Т.е., как ни крути, система должна быть готова к тому, что перезапуск возможен и должна быть спроектирована так, чтобы этот перезапуск существенно не повлиял на ее работу. В свете этого перезагрузка ПЛИС - это лишь одна из операций по восстановлению работоспособности.

Wse FPGA Altera kontrolirujut prawilnostj konfiguracionnyh dannyh w processe zagruzki (kontrolj CRC). Rjad mikroshem (naprimer, STRATIX II) kontrolirujut prawilnostj zagruzki periodicheski ( w dopolnenie k nachalnomu kontrolju), i w sluchae oshibki wystawljajut flag, kotoryj mozhet bytj ispolzowan dlja zapuska perekonfiguracii.

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

Спасибо. Не могли бы Вы подсказать документы, где об этом почитать подробнее? Может, Вы знаете что-то попроще STRATIX II, ведущее себя аналогично?


К сожалению, у нас нет специалистов, способных решать задачи подобным образом. Боюсь, не только у нас, но и вообще. Нам как-то привычнее формулировать задачу так: "сбой может возникнуть". Наша задача - минимизировать вероятность его возникновения, а в случае возникновения - своевременно выявить его и принять меры к недопущению|устранению последствий.

Берите PAPlus или AntiFuse и не мучайтесь. Прошиваете 1 раз с ключем безопасности, и ни каких вам конфигурационных сбоев.
С софтом проблемм нет, цены на кристаллы соизмеримые.

У актел так же есть семейства микросхем для работы в условиях плохого питания, сильных помех.

Prilagaemyj fajl Application Note AN357, wrode eta fumkcija estj w STRATIX, STRATIX II, STRATIX GX, CYCLONE.
Woobshe, nado smotretj datasheet konkretnyh mikroshem - no, wrode, ni w kakih drugih serijah ja etu fumkciju ne widel.
Hotja, dolzhen skazatj, ja nikogda ne ispolzowal etu funkciju, dazhe w STRATIX. Nikakih problem so sbojami konfiguracii zamecheno ne bylo (plata w sostawe Industrial PC, rabotaet kruglosutochno).

Благодарю за файл и информацию. У меня похожая область применения и режим работы, так что Ваш практический опыт будет мне полезен.

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

А это, к сожалению, очень далеко от реальности

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

Прошу прощения за резкозть!

В тему надежности :
мое руководство (а мы пытаемся "сесть" на ПЛИСы) прослышало, что Альтеровские ПЛИСы страдают спорадическими (чисто, внатуре случайными) отказами от раз-в-неделю до раз-в-месяц. Без всякой закономерности и непредсказуемо и потому - только Xilinx
А что народ бывалый по этому поводу думает ? Замечали таковое ?

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

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

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

==Что-то я не понял, каким образом можно описать выход из некорректного состояния. (Или имеется в виду ресет? )

Так же, как и из одного корректного состояния в другое корректное.
грамматика исправлена

Нет, не ресет в данном случае. Все как написал jojo: действительно при проектировании обеспечить переход из некорректных состояний в корректные
(читай - описать все состояния).


А вот это ИМХО точно нужно, покрайней мере для начальной установки.

Теме UP! Как определить целостность конфигурации в ПЛИС Xilinx серии Spartan? ... Читая документацию (ug380) про конфигурацию spartan six
Тоесть на выходе мы имеем реальное текущее состояние ячеек. Конечно возлагание на внешнее устройство функций сравнивания прошивки и сброса ПЛИС, ограничивается надежностью этого устройства. Фактически мы можем похоронить заживо полностью рабочее устройство (в медицине такая практика была)... Вообще 100%-но гарантировать, что устройство исправно никто не может. Здесь важно определить степень параноидальности и выбрать самый оптимальный (надежный) вариант.
Мне интересно мнение разработчиков, которые проектировали системы повышенной безопасности (типа 10exp-12)... как они боролись с данной проблемой? Читая документацию Xilinx вижу как сильно они позаботились о загрузке правильной конфигурации. Неужели они не позаботились о ее целостности и сохранности? Если есть внутренние устройства CRC, WatchDog, Reset on error... неужели нельзя было сделать работу CRC циклическим для проверки целостности внутренней конфигурации (может это оно и есть? CONFIG POST_CRC_ACTION = [HALT | CONTINUE]) . Ведь бывают же случаи частичного разрушения кристалла, "зависания" (залипания) ПЛИС ... Или может быть такая ситуация, когда выгорела ножка ПЛИС, а конфигурация в полном порядке... как тогда быть, господа разработчики?

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

Насколько я понял, вопрос ТС находится в сфере обеспечения безопасности
в течении жизненного цикла прибора на ПЛИС. К сожалению уровень 10е-12
на сегодня не может обеспечить ни один известный полупроводник, а для
сложных микросхем этот уровень составляет 10е-5 ... 10е-7. Вторым вопросом
является принимаемая модель отказов с ее обязательными ограничениями.
Если рассматривать весь спектр отказов включая "отгоревшие ножки", то скорее
всего прийдется использовать 2х-3х избыточность, + учитывать отказы по общей
причине (т.е. раздельные блоки питания, ПЗУ и т.д.). Основной проблемой я вижу
степень соответствия исправной конфигурации и работоспособности прибора.
Т.е. сгоревший выходной полевик на ножке скорее всего не убьет конфигурацию -
что тогда будем считать прибор исправным?
Тогда нужен внешний арбитр, у которого в свою очередь целый веер своих глюков.
Есть правда теория динамических парафазных автоматов на базе одного кристалла,
но к сожалению провести достоверные натурные тесты для подтверждения даже
уровня 10е-10 пока мне не удалось.

М-да...это всё мне напоминает избитый философский вопрос кто же будет охранять охранника?


Так для этого и был поднят вопрос => Что оптимальнее?


Увы, если б можно было проводить Boundary scan (граничное сканирование) в процессе работы "модлуька" так чтобы это не мешало остальной работе - было бы очень кстати...

Чудес не бывает. Вам обязательно нужен внешний наблюдатель.

Хотя-бы по косвенным признакам. Вводите в систему тестовые циклы одновременно с рабочими.

А что вам мешает так и сделать? Без ганичного,- в лоб. В Альтере вставочки(доступные через ДЖИТАГ) легко делаются в любое место. Чисто организационный вопрос!

А почему бы вам не перейти на ACTEL? Одноразово прошили и останется только проблема контакта ножек и внешнего мира...

Да, я согласен, но как писалось выше то есть надежность собаки, которая охраняет охранника ниже или такая же.

Если ПЛИС будет проверять сама себя на отказ, кому надо такое устройство?

Читаем внимательнее вопрос и не оффтопим

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

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


Я не о том говорил. ПЛИС всё равно что обрабатывать. Я предложил забрасывать извне тестовую задачу. Внешний арбитр знает какой цикл рабочий а какой тестовый. Самому себя проверять-нонсенс!


Извините, увлёкся!...

Есть такая функция, мы её используем:
http://www.xilinx.com/support/documentatio...uides/ug332.pdf
Под заголовком "Post-Configuration CRC (Extended Spartan-3A Family Only)". Об этом писал уважаемый Igor_S:

здесь ранее писали про то, что альтеравские девайсы имеют блок CRC, но возникли два вопроса:
1)так как этот блок находится в плис, что как пролетит супер заряженная частица и нарушит его работу?
можно как-нибудь прочесть cfm у плис и сравнить с тем, что у неё в озу и на основании этого сделать вывод о правильности работы?
или есть только один вариант, через некоторое время постоянно передергивать питание, что бы происходило чтение в озу?

2)предположим, что придумана какая-то система резервирования, которая в случае отказа, допустим перепрошивает плис.
как (и возможно ли это) убедиться в том, что если отказ возникнет, система действительно сработает?

Как итог всему выше сказанному могу только написать:"Вероятность чего-либо всё равно остается от неё никуда не деться. У нас существует целый отдел, который занимается вопросами вероятности отказа разрабатываемых приборов. Полностью безотказной работы устройства вы не добьётесь НИКОГДА!!!
Поэтому опирайтесь исключительно на цифры. У разных частей ПЛИС вероятность отказа разная даже внутри кристалла, для регистров - она своя, для блочной памяти - своя. Если надо заказчику вероятность 10е-11, то разрабатывайте систему защиты от отказов в соответствии с требованиями!".

Если не определились с семейством ПЛИС, то посмотрите FLASH ПЛИС Actel. В отличии от Альтеры и Xilinx у них конфигурация не сбивается от помех или скачков питания. Даже от радиции она не сбивается. И не надо будет ломать голову над этой проблемой.

Как отмечалось выше у Xilinx есть функция проверки CRC конфигурации кристалла. Т.е. внутренний сторож проверяет сохранность конфигурации, сравнивая текущее CRC кристалла с эталонным, которое считывается при загрузке. При не совпадении CRC выдается ошибка (выход типа open drain) и если я не ошибаюсь, то имеется возможность перезапука.
Данная опция есть у SPARTAN 3A и выше.

А простой монитор сигнала DONE не спасет? Вот еще можно почитать на тему: http://www.xilinx.com/support/documentatio...es/xapp1088.pdf .

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

Когда я спрашиваю взрослых людей, много лет занимающихся разработкой ответственной техники, о том, как практически убедиться в эффективности своих мер по повышению надежности, то они ничего внятного ответить не могут. Элементная база устаревает морально и снимается с производства быстрее, чем желаемый срок ее надежного функционирования. Как можно в таких условиях что-то исправить на основе измеренной на практике статистики, а не придуманной теоретиками?! Я уже не говорю о том, что при нашем "порядке" две партии изделий с интервалом год могут и не собрать совершенно одинаково, детали другой партии или вообще замены на другого производителя, платы другой партии, монтаж на оборудовании, отработавшем еще год без обслуживания, другие паяльные материалы.

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

Прочитал 3 страницы, но почему то ответа я не нашёл. Все же как можно контролировать целостность ? Нужна отдельная плис ? Или реализовать внутри конкретной плис ? Или все же как то возможно через jtag ?

методика проведения испытаний на надёжность аднака надо....
если устройство супернадёжно то тогда ставят на испытание N штук + меры увеличивающие старение (обычно термоцеклирование)...
да - испытывать дорого и сложно, отсюда и цена.... бывает и по несколько месяцев 10 приборов непрерывно надо в термокамере держать...


Всякие теоретико-логико-математико доказательства тож используются ...особенно буржуями чтобы туфту прорекламировать и впарить... называют это safety а не reliability...


-------
Что касается reliability

Считаю постановку вопроса о том как бороться с проблнемами некорекной.
Вначале нужно определить какие факторы воздействуют, а потом построить модель отказов и уш только потом - придумывать способы повышения надёжности....
У кого тут есть какая инфа? По вероятностям отказа, по влиянию внешних факторов....

Вот мне кажется, что надёжность пайки пинов раз в 1000 хуже, чем вероятность некоректного всасывания прошивки... так-что лутше просто пины дублировать, чем о высоких материях думать (CRC, TRM итп)
Опять-же, надёжность источника питания (DC-DC) наверняка раз в 100 ниже вероятности отказа ПЛИС...Так-что и тут не о CRC надо думать....

--------
Что касается safety

Тут нужно придумать способ определения того, работает ли устройство правильно сейчас или нет...
думаю однозначного ответа трудно найти, и в этой области просто море патентов (способов) как этого добится...

Как варианты:
1) Self Checking Design (напр. кодирование внутренних сигналов с битом чётности).
Он кстати требует Self Checking Checker схемы и такие есть.
2) Проверка на системном уровне. Кстати - самое популярное решение.
Напр. наша ПЛИС делает сжатие данных. Встраиваем микроконтроллер который периодически прогоняет тестовый пакет данных с известным результатом через нашу ПЛИС.
Напр. ПЛИС конвертит формат данных - включаем loopback на удалённом конце и прогоняем PRBS пакеты.
3) можно встроить DFT структуры и прогонять ATPG внешним микроконтролером.
4) Можно встроить BIST тесты внутри цифры и переодически их запускать (напр. тесты памяти).




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

Такч-то "переодический отказ раз в месяц" - это не поломка ПЛИС.
Если у вас с питанием, волновым согласованием внешних линий передачи итп. всё 100% ОК и это именно ПЛИС, то тут скорее проблемы дизайна из-за:
- Cross Domain Clocking ошибки (приводят к метастабильностям)
- либо некоректно заданы STA констрейны (вот скважность осцилятора вы как в STA констрейнах учли? А как девиацию напряжения питания в STA учли? итд...) ...тоже кстати к метастабильности приводят...

Боротся с этим (ошибками в ДНК ) можно только верификацией (UVM вам поможет) и натурными испытаниями (и не забываем о functional coverage при этом)

На верное не правильно выразился. Точнее не до рассказал. Xilinx Virtex есть я так понимаю порт ICAP он позволяет контролировать построчно и исправлять конфигурацию. Только как с ним работать внутри самой плис ? Или отдельно ставить ? Если можно внутри то как описать его работу(на каком языке? Есть пример?)
Вот примерно так. Я представляю. Спасибо.

Ох, "искусственный интеллект" никак сам себя не может научиться оценить, как м большинство людей со своим естественным плохо рефлексируют и хорошо брешут, в отличие от оценок остальных наружу ?
Я бы лично (в целях минимизации) использовал только прозвучавшую здесь несколько раз идею о периодически вклинивающихся тестах из Центра -- на что заточена данная прошивка, то ей и командовать с известными исходными данными/выходом (пусть рандомно выбираемыми), сравнивать полученные результаты.
Плохо, если "Центра" нет и принимать решение должен тот же самый "мозг", в котором мы не уверены на 100%, тут надо читать психиатрические форумы, причём древние, без демократических извратов, та наука развивалась ведь дольше и на более сложном материале
Абстрагируясь от типа и конкретики данного кристалла, для каждого самописного блочка можно встраивать самодиагностику и сводить всё воедино, но только для покупных ядер это потребовать достаточно проблематично, и вдруг глюканёт ячейка на объединении сигналов... Склифосовский, короче
Вообще, parity биты незря сейчас заложены во всех ПЛИС-памятях -- их первым делом будет крушить при пролёте *-частиц и других проблемных ситуациях с вероятностью обнаружения 1/2, гораздо менее вероятны остальные типы глюков. Другое дело, что нет жёсткого их (parity) образования и хранения/сравнения в каждой логической ячейке после конфигурирования -- экономически невыгодно со всех сторон в открытой продукции.
Перегрузка конфигурации на лету может быть не очень удобной -- после этого Центр должен перегрузить и себя целиком, ибо "горячее включение" ПЛИС может потребовать её такой перенастройки и перевстраивания в систему, что мало не покажется. Тут лучшее решение -- энергонезависимая конфигурация на флэши, которую здесь много раз пропагандировали. Но раз те ПЛИС не хочется использовать, то других плюсов у них нет, в основном минусы ?
Вообще, надо разрабатывать свои защищённые СБИС и наворачивать там, что угодно.
Практика -- критерий истины, как учили М-Э-Л-s ещё 25 лет назад, так что соломку стелить лучше там, где уже были падения, заранее "теоретически" бояться не стоит, по статистике падежей и надо ориентироваться и бороть проблему.
Боюсь, что "хороших" в этом отношении кристаллов нам никогда не продавали и не продадут, а своё когда наладится, тогда заживём !

В Xilinx tcnm блок ICAP. Не могу понять как проверить его работу ? Судя по описанию он именно представляет доступ к конфигурационной памяти....