[Fransc 0]

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

Имеется некий довольно большой проект. Среды проектирования FPGA ADVANTAGE + SYNPLIFY + ISE. Язык VERILOG. Процессора в данной системе нет. Проект содержит множество STATE DIAGRAM. Функции проекта - прием, формирование, хранение, пересылка данных. Интерфейсы относительно низкочастотные. Используемая ПЛИС VIRTEX2 (аппаратно не мажорированная). Использование в космической отрасли. Сами понимаете, требуется надежность. Сбои возможны, но не должны приводить к выходу из строя аппаратуры. Реализована схема переинициализации ПЛИС при превышении пороговых токов потребления напряжений питания ядра и IO (дергает PROG_B). Также реализована внешняя команда для переинициализации ПЛИС.

Как еще увеличить надежность проекта?

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

Еще по поводу реализации резервирования (мажорирования) в пределах ПЛИС... Вручную это реализовать как то муторно и сложновато. Какие то отдельные узлы резервировать... Нельзя ли это как то автоматизировать на уровне языка, директив, пакетов проектирования?

Выслушаю любые предложения. Может вообще не надо заморачиваться?

Заранее всем спасибо.

Алексей.

[serjj1333 0]

Чтобы при подвисании ПЛИС

Как она может зависнуть? Может возникнуть ошибка, например, в каком нибудь конечном автомате из-за неполного писания всех возможных состояний и переходов - зависнит автомат, а не прошивка. Но такую проблему нужно локализовать и дописать автомат а не резетить каждый раз всю систему... Может фильтр загудеть, но это проблема его устойчивости, т.е. алгоритмическая. ИМХО, если нет процессоров, то ПЛИС, если внешние условия не меняются, должна формировать резет для своей логики только 1 раз - по захвату внутренних PLL. А подвисания отдельных модулей в проекте - это проблема верификации этих модулей, необходимо доописать их состояния.

 

Может организовать какое то подобие WATCHDOG TIMER

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

 

Еще по поводу реализации резервирования (мажорирования) в пределах ПЛИС... Вручную это реализовать как то муторно и сложновато. Какие то отдельные узлы резервировать... Нельзя ли это как то автоматизировать на уровне языка, директив, пакетов проектирования?

директива generate?

Изменено 23 января, 2015 пользователем serjj

[Maverick_ 15]

Еще по поводу реализации резервирования (мажорирования) в пределах ПЛИС... Вручную это реализовать как то муторно и сложновато. Какие то отдельные узлы резервировать... Нельзя ли это как то автоматизировать на уровне языка, директив, пакетов проектирования?

у Xilinx была программа которая сама делала троирование с мажоритированием - Triple Module Redundancy (TMR).

Но как я понимаю, тогда ресурсы ПЛИС нужно умножать на три (грубая прикидка)...

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

Подумайте, а нужно ли это?

[curly07 0]

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

Может вообще не надо заморачиваться?

 

Алексей,

Virtex II снят с производства окончательно. По всем сусекам уже прошуршали. По миру их осталось очень мало. У самого производителя уже и кристаллы закончились.

А те, которые сейчас предлагают - трех-пятилетней давности, хорошо, если еще нормально "реболлинг" сделан.

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

Смотрите хотя бы на Virtex-5.

[topor_topor 0]

Как еще увеличить надежность проекта?

Возможно ли сделать какой то монитор целостности загруженной прошивки не применяя внешние схемы?

Еще по поводу реализации резервирования (мажорирования) в пределах ПЛИС... Вручную это реализовать как то муторно и сложновато.

1) Чтобы увеличить надёжность нужно иметь модель отказов.

Вы от чего защищаться будете: механического отказа пина ПЛИС, выхода напряжения питания вне пределов (STA упадёт), ошибок логики, SEU Mitigation ...?

До сих пор я только слышал - "Данных нет, но от всего"

 

тут начинать надо с внятно-разжовано-дохотчивого ТЗ (DO-254), качественной верификации на всех этапах (в т.ч. симуляций с имитацией SEU итд ), ну и конечно структурной защитой от сбоя (watch dog итд), так и защитой селов ПЛИС (TMR).

Но придумывать защиты не имея модели отказов - нет смысла... ну защитились вы от SEU вероятность которого 10-6, а у вас пин клока отвалится или осцилятор выйдет за пределы и всё....

 

Вот у Хilinx много про SEU Mitigation Multi-Level SEU Mitigation Solution

 

2) Про прошивку Built-In Configuration SEU Detection

3) По поводу TMR, у xilinx есть TMRTool но вам его не дадут :)

[x736C 0]

Synplify Premier содержит пакет автоматизации. И Ментор тоже хвастается этим.

Кстати Xilinx советует защищаться от SEU уже от 10 тыс. метров.

UPD: В приведенном выше документе это и написано :)

Изменено 23 января, 2015 пользователем x736C

[Fransc 0]

Как она может зависнуть? Может возникнуть ошибка, например, в каком нибудь конечном автомате из-за неполного писания всех возможных состояний и переходов - зависнит автомат, а не прошивка. Но такую проблему нужно локализовать и дописать автомат а не резетить каждый раз всю систему... Может фильтр загудеть, но это проблема его устойчивости, т.е. алгоритмическая. ИМХО, если нет процессоров, то ПЛИС, если внешние условия не меняются, должна формировать резет для своей логики только 1 раз - по захвату внутренних PLL. А подвисания отдельных модулей в проекте - это проблема верификации этих модулей, необходимо доописать их состояния.

 

 

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

 

 

директива generate?

 

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

 

Алексей,

Virtex II снят с производства окончательно. По всем сусекам уже прошуршали. По миру их осталось очень мало. У самого производителя уже и кристаллы закончились.

А те, которые сейчас предлагают - трех-пятилетней давности, хорошо, если еще нормально "реболлинг" сделан.

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

Смотрите хотя бы на Virtex-5.

VIRTEXII делает Китай, в том числе и в радстойком исполнении с документами. А Virtex-5 и т.д. в нужных исполнениях купить официально невозможно.

[x736C 0]

Возможно я сильно ошибаюсь. Теоретически можно самому все автоматизировать, вынести что-то в модули, или написать на питоне скрипты.

 

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

И есть ли смысл мажори(ти)ровать счетчик, если можно это сделать с целым блоком.

 

tri_counter.v

 

[curly07 0]

VIRTEXII делает Китай, в том числе и в радстойком исполнении с документами. А Virtex-5 и т.д. в нужных исполнениях купить официально невозможно.

 

Вы про BQVR от т.н. BMTI?

 

[Fransc 0]

Вы про BQVR от т.н. BMTI?

Ну Вы все знаете... Да, про них.

[iosifk 3]

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

Еще по поводу реализации резервирования (мажорирования) в пределах ПЛИС... Вручную это реализовать как то муторно и сложновато. Какие то отдельные узлы резервировать... Нельзя ли это как то автоматизировать на уровне языка, директив, пакетов проектирования?

Выслушаю любые предложения. Может вообще не надо заморачиваться?

Заранее всем спасибо.

Алексей.

 

Расклад следующий. Если говорить о целостности прошивки, то можно по JTAG читать прошивку и делать частичную реконфигурацию. Но это должен быть внешний надежный компонент.

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

 

[x736C 0]

Все остальное буквами писать долго... Увы...

Лучше сразу книгу или статью. А мы бы благодарно почитали :)

[iosifk 3]

Лучше сразу книгу или статью. А мы бы благодарно почитали :)

Мне тут сделали замечание за "рекламу" моих статей... Но все же, в "Записках инженера" есть глава о "Мажоритаре"...

На самом деле, все зависит от того, сколько времени изделие должно работать "надежно".

И самое сложное - это спроектировать узел, обрабатывающий сигнал ошибки.

Если этот узел имеет низкую надежность, то и все остальное - тоже...

Далее, надо отделить "надежность" - это когда отказ не восстанавливается от "сбоя", когда отказ можно восстановить.

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

Вот, после того, как станет что-то понятно, что же нужно ТС, только после этого можно давать рекомендации...

 

[topor_topor 0]

И самое сложное - это спроектировать узел, обрабатывающий сигнал ошибки.

С Вами полностью согласен.

Хочу только добавить, что кроме логико-умозрительного доказательства способности системы противостоять сбоям и отказам, необходимы есчё и убедительные метрики фолт-кавереджа, полученные в соответствующем симуляторе "сбоев".

Только тогда можно утверждать что "вотч дог и троирование" действительно помогло.

 

 

[x736C 0]

Fransc, нашел такой документик. Прямо Ваш случай.

 

iosifk, странные замечания. Тут некоторые уважаемые модераторы свои фирмы и изделия рекламируют, ничего))

Много Ваших статей читал, и особенно о надежности.