Jump to content

    

Поделитесь опытом в плане надежности

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

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

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

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

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

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

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

Алексей.

Share this post


Link to post
Share on other sites
Чтобы при подвисании ПЛИС

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

 

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

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

 

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

директива generate?

Edited by serjj

Share this post


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

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

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

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

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

Share this post


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

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

 

Алексей,

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

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

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

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

Share this post


Link to post
Share on other sites
Как еще увеличить надежность проекта?

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

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

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 но вам его не дадут :)

Share this post


Link to post
Share on other sites

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

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

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

Edited by x736C

Share this post


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

 

 

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

 

 

директива generate?

 

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

 

Алексей,

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

 

tri_counter.v

 

Share this post


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

 

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

 

Share this post


Link to post
Share on other sites
Вы про BQVR от т.н. BMTI?

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

Share this post


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

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

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

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

Алексей.

 

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

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

 

Share this post


Link to post
Share on other sites
Все остальное буквами писать долго... Увы...

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

Share this post


Link to post
Share on other sites
Лучше сразу книгу или статью. А мы бы благодарно почитали :)

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

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

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

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

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

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

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

 

Share this post


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

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

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

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

 

 

Share this post


Link to post
Share on other sites

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

 

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

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

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this