Целостность конфигурации ПЛИС, Как определить в процессе работы Опции

[DPL]

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

[Hoodwin]

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

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

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

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

[Torpeda]

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

методика проведения испытаний на надёжность аднака надо....
если устройство супернадёжно то тогда ставят на испытание 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 при этом)