Перейти к содержанию
    

Целостность конфигурации ПЛИС

26 minutes ago, DeadCadDance said:

Это значит что за миллиард часов произойдёт в среднем 9,5 сбоев

Это значит, что 1 отказ происходит в среднем за 12 тысяч лет

Тут такое дело, насколько мне не изменяет память, в Английской терминологии нет отдельного понятия: сбой, отказ, ошибка, критическая ошибка, опасный отказ, безопасный отказ. Все эти понятия обычно вкладываются в оодно слово failure. А где уже нужно/очень хочется, тогда уточняют, что тут просто сбой, а тут ошибка.

Соответственно в миллиард часов сбой, отказ, ошибка, критическая ошибка, опасный отказ, безопасный отказ будет происходить всреднем 9,5 раз. В этом случае маркетологи и вправду поимели половину мира.

Опять таки, можно оперировать разными понятиями и статистикой. Можно сказать, что девайс включили, а потом выключили на миллиард лет, а потом он сбойнул. Нужно понимать как производилось тестирование: на 100 MHz или на 1MHz. Вероятность обнаружить сбой во втором случае всего в 100 раз меньше. Что тестировалось? Весь тракт данных или отдельно каждый регистр. Пока компания не выдаст методику, по которой происходило тестирование и параметры, FIT будет означать количество тренирующихся в спортзале.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

12 минут назад, Nick_K сказал:

Тут такое дело, насколько мне не изменяет память, в Английской терминологии нет отдельного понятия: сбой, отказ, ошибка, критическая ошибка, опасный отказ, безопасный отказ. Все эти понятия обычно вкладываются в оодно слово failure.

Вот именно. А если оставить только отказы, то MTTF вообще миллионы лет будет

14 минут назад, Nick_K сказал:

Пока компания не выдаст методику, по которой происходило тестирование и параметры, FIT будет означать количество тренирующихся в спортзале.

Меня тоже такая "статистика" мягко говоря смущает.

Поэтому я спрашиваю тут народ, который имеет большой опыт работы с ПЛИС, о РЕАЛЬНОЙ, а не полученной математическим путём, статистике сбоев ПЛИС

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 minutes ago, DeadCadDance said:

Поэтому я спрашиваю тут народ, который имеет большой опыт работы с ПЛИС, о РЕАЛЬНОЙ, а не полученной математическим путём, статистике сбоев ПЛИС

Вот вам @RobFPGA ответил по реальной статистике. Я со своей стороны могу сказать, что спроектированная нами система эксплуатируется на ряде ЖД станций и безопасного отказа по вине ПЛИС за последние года 3-4 не было. В данном случае подразумевается глобальная проверка как элементов памяти, так и комбинационных схем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 минут назад, Nick_K сказал:

отказа по вине ПЛИС за последние года 3-4 не было

Тут ещё такое дело...

Что считать отказом.

 

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

Меня интересуют ВСЕ виды сбоев, а не только опасные

Изменено пользователем DeadCadDance

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 minutes ago, DeadCadDance said:

Что считать отказом.

У нас всё честно. Есть дублированная система из 2х девайсов. Циклически они запускают полную проверку элементов памяти и комбинаторики (понятное дело, что в алгоритмы проверки с самотестированием). После чего обмениваются полученными результатами (по сути некие дампы). Если один из "братьев" находит несовпадение хотя-бы в одном бите, он переходит в безопасный отказ. Никаких восстановлений, исправлений ошибок и т.п.

З.Ы. Забыл добавить, система раз в пол года меняется (железо) на такой же комплект, но после проверки в РЭА. Старый комплект везётся в РЭА, проверяется по новой и возвращается назад как резерв. По сути получается, что система не всё время 24/7 педалила, но комплекты старые остаются и не меняются на другие, соответственно надёжность системи можно оценить в половину времени.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

24 минуты назад, Nick_K сказал:

отказа по вине ПЛИС за последние года 3-4 не было

Тут ещё зависит что за приложение, в котором Вы используете ПЛИС.

Одно дело какие-то медленные процессы.

А другое дело когда плис молотит на Гигагерцах сложнейшую логику и сдвиг (или пропалание) сигнала даже на 1 мкс на любом из 400  I/O пинов означает катастрофу.

 

 

Изменено пользователем DeadCadDance

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 minute ago, DeadCadDance said:

А другое дело когда плис молотит на Гигагерцах сложнейшую логикк и сдвиг (или пропалание) сигнала даже на 1 мкс на любой из I/O означает катастрофу.

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

В добавок ко всему, то что Вы упомянули - не критическая система принятия решения. Которая по сути сама обрабатывает данные и сама принимает решения, а всё что извне - это мракобесие и 100% доверия оному нет. Если есть критические внешние устройства - это уже совсем другие дела. Это пол системы, или комплекс по мониторингу, или устройство защиты, или ещё какое-то чудо инженерной мысли, цель которого выявлять, когда включат тумблер и не приведи Маск коефициент дребезга у него будет больше положенного.

Упомянутая мною система работает на 100MHz.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 01.12.2019 в 16:04, Nick_K сказал:

Ну тут Вы загнули уже. В жизни не видел критических систем с гигагерцовыми клоками. Может на Атомных где-то и то сомневаюсь. Обычно все критические системы отличаются надёжностью и относительно медлительностью

А как же системы ведения цели? Есть и другие системы где требуется жесткий реалтайм с маленьким циклом.

У нас, к примеру, время главного цикла 20 мкс

Изменено пользователем DeadCadDance

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 12/7/2019 at 9:03 AM, DeadCadDance said:

А как же системы ведения цели? Есть и другие системы где требуется жесткий реалтайм с маленьким циклом.

У нас, к примеру, время главного цикла 20 мкс

Согласен, погорячился. Не бывает критических безопасных систем с гигагерцовыми клоками. В случае ведения цели или других "военных" вопросов именно термин безопасность отходит на второй план. Там главное безотказность, что можно достичь... десятичным мажоритированием или ещё каким-то интересным резервированием. Там ведь главное, чтобы оно не потерялось, а то что будет сбой (а он скорее всего будет, потому что мир не идеален + противник может использовать системы подавления), так это особо не колышит. Главное восстановить работу "сбойного" узла, до гипотетического появления сбоя на другом узле.

Короче говоря это всё демагогия.

А вот с точки зрения Вашего этого цикла, то 20 микросекунда - это как-бы и много и в то же время мало. Смотря что нужно достичь, что проверить, где сравнить состояния и т.д. Если это несколько каналов с загруженными Виртексами - то увы этого времени для дублированной системы, не хватит даже для обмена сервисными пакетами или проведения самотестирования, как одно их состояний главного цикла. Тут можно много гадать, но реально, как я понимаю, подойдёт только эксперимент. Реальный с прогоном. А тут таким особо никто не занимается :wink:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

9 часов назад, Nick_K сказал:

тут таким особо никто не занимается

Понял.

Спасибо за ответ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 час назад, Koluchiy сказал:

а вот на тему целостности прошивки есть вполне себе штатные алгоритмы, проверяющие ее целостность. Можно их повключать и собирать статистику.

"Гладко было на бумаге, а реально откуда не возьмись выросли буераки"©

Теоретически много чего возможно. Только на практике мало чего РЕАЛЬНО полезно и работает

Изменено пользователем DeadCadDance

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 12/1/2019 at 1:46 PM, DeadCadDance said:

Что считать отказом.

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

Меня интересуют ВСЕ виды сбоев, а не только опасные

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

On 12/8/2019 at 10:05 AM, Nick_K said:

А вот с точки зрения Вашего этого цикла, то 20 микросекунда - это как-бы и много и в то же время мало. Смотря что нужно достичь, что проверить, где сравнить состояния и т.д. Если это несколько каналов с загруженными Виртексами - то увы этого времени для дублированной системы, не хватит даже для обмена сервисными пакетами или проведения самотестирования, как одно их состояний главного цикла. Тут можно много гадать, но реально, как я понимаю, подойдёт только эксперимент. Реальный с прогоном. А тут таким особо никто не занимается

У нас дублированная система на виртексах и ДСП с циклом 20мкс. Обмен диагностическими словами в 20мкс укладывается спокойно и распознавание проблем и переход на резерв происходит за 3 цикла максимум. Так как управляющее слово на объект уходит каждые 100мкс - это не успевает вызвать негативную реакцию системы.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 11/30/2019 at 12:56 PM, DeadCadDance said:

Тоже такая мысль пришла, когда почитал отчёты производителей (интел, ксайлинкс, актель) по надёжности, из которых вытекает, что среднее время работы до первого сбоя у ПЛИС составляет сотни, тысячи и десятки тысяч лет :dash2:

Это не ложь, это просто статистика :)  К химии и физике эти теоретические параметры надежности отношения не имеют. Наработка на отказ равная 10 млн. часов (1141 год) означает, что если включить одновременно 1141 ПЛИС, то за год работы примерно одна выйдет из строя. И под отказом, вроде как, понимается не сбой, а полный отказ микросхемы.

Изменено пользователем lembrix

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 17.12.2019 в 17:26, lembrix сказал:

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

Если хотя бы один битик в CRAM "перевернулся" из-за прилетевшего из космоса нейтрона - это отказ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...