Сообщество

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

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

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

Уважаемый amartology, честь и хвала, если у Вас есть библиотеки для дозы и тиристорного эффекта, работающие на любой архитектуре. Эти библиотеки могут быть использованы в одном кристалле с новым, имеющимся только у мультиклеточной архитектуры свойством СИСТЕМОТЕХНИЧЕСКОГО обеспечения отказоустойчивости, ДОПОЛНИТЕЛЬНО повышающим надежность аппаратуры. Многоядерные системы ничем подобным не обладают.

Просто и внятно формулирую вопрос и очень рассчитываю получить на него короткий и внятный ответ: как мультиклеточность помогает увеличить стойкость ИМС к полной поглощенной дозе и тиристорному эффекту?
Без ответа на этот вопрос я вижу только демагогию о мифических преимуществах мультиклета над не менее мифическими многоядерными системами, в то время как в существующих радстойких процессорах американской, европейской и российской разработки отказоустойчивость прекрасно достигается за счет резевирования.
Указанное вами "СХЕМОТЕХНИЧЕСКОЕ" обеспечение отказоустойчивости не является чем-то новым или уникальным для мультиклета. Radiation Hardening by Design на всех уровнях от транзисторов и библиотек элементов до архитектуры систем - это хорошо известная тема, по которой пишется значительное количество статей на русском и английском языках, в то время как вы пытаетесь или изобрести велосипед, или пустить заказчикам пыль в глаза, выдавая преимущества мультиклета в производительности за преимущества в радиационной стойкости.

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

Прочитал.
Теперь ответите на вопрос, как мультиклеточность помогает увеличить стойкость ИМС к полной поглощенной дозе и тиристорному эффекту?

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

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

Уменьшая или увеличивая роль каждой составляющей можно получать системы под разные требования и разной цены.

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

"Без специальных технологий производства ничего относительно долго не проработает в космосе. Дополнительными мерами можно только влиять на это время".
Это высказывание неверно. Правильное топологическое проектирование без модификации технологии позволяет добиться дозовой стойкости 1-10 Мрад, что намного больше любых космических требований. Такие результаты получены за последние десять лет в разных странах (в том числе в России) на десятке различных коммерческих технологий. То же самое касается тиристорного эффекта. Ссылки на соответствующие статьи нужны, или вы знакомы с работами коллег?

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

"Мультиклеточное ядро может если надо вообще отключить питание от неиспользуемых клеток." - вот это уже интереснее, это полезно при борьбе с тиристорным эффектом. Расскажите пожалуйста, как именно предполагается аппаратно организовать отключаемое питание отдельных клеток? И как предполагается защищать от одиночных сбоев схему управления отключаемым питанием?

"Специальная огранизация всей системы решает проблему аппаратной реализации отказоустойчивости, методы и варианты построения известны" - чем именно с точки зрения отказоустойчивости мультиклеточность лучше тройного резервирования (с холодным резервом по вкусу)? Как вы собираетесь решать проблему одиночных сбоев в огромной, судя по всему, управляющей части? Что будет, если несколько клеток в результате выполнения операции из-за одиночных сбоев выдадут два или три разных результата?

"Схемотехника базовых ячеек ИС и специальные технологии производства дают стойкость к физическим воздействиям" - дают, но не имеют отношения к мультиклеточности. Практика показывает, что в условиях достаточной защиты от дозы и тиристора при помощи топологии, мажорирования в сочетании с защитой кэша DICE или Хэммингом вполне достаточно для того, чтобы обеспечить долговременное функционирование ИМС на орбите. Почему бы не применить вместо мультиклета гораздо более простую резервированную систему? Усложнение управляющей логики ведет к росту количества сбоев в ней, и мультиклет имеет все шансы просто не заработать

Про уменьшение роли разных составляющих я не совсем понял. Разве стоимость разработки ASIC прямо зависит от архитектуры? Стоимость изготовления тестовых образцов, стоимость разработки радстойкой библиотеки и стоимость испытаний никак не различаются для мультиклета и резервируемой системы.

И последний вопрос - почему вы не публикуетесь в профильных журналах и не участвуете в профильных научных конференциях? Хотелось бы обсудить ваши разработки в рамках, например, "Стойкости-2013".

Давайте все-таки отделим одно от другого.
Мультиклет, ARM, MIPS, SPARC и т.д. - это архитектура вычислительных ядер. Противостоять сами по себе они не могут ни тиристорному эффекту ни накопленной дозе. Это, как я понимаю, не должно являться новостью.

Про стойкость на обычном КМОП процессе мы знаем. Знакомые нам предприятия производили на нем МС с использованием специальных библиотек стандартных ячеек. Как вы говорите, правильно топологически спроектированных. Достигли очень хороших результатов.

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

Что касается системного обеспечения отказоустойчивости, то на базе мультиклеточного МП можно реализовать троированную систему, с одним горячим/холодным резервом, N клеток, работающих параллельно и т.п. Тут все упрется в целесообразность и сложность системы.
Сейчас это все еще прорабатывается, собираются мнения тех, кто создает такие системы. У людей есть желание получить не просто отказоустойчивый МП, а систему приспособленную решать их задачи, уменьшать кол-во доп. компонентов на плате и т.д. Вот сейчас и идет процес накопления материала и понимания, что она должна из себя представлять.

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

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

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

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

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

micron_multiclet wrote:

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

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

"Реконфигурация мультиклеточного процессора ... может инициироваться аппаратно, если при работе в многоканальном режиме не совпадают данные записываемые в память. ... Каждая клетка автономно проводит самопроверку, после которой проводится проверка коммутационной среды". Как будет проводиться длительная самопроверка и реконфигурация при возникновении тиристорного эффекта? Как быть с некатастрофическими сбоями, которые не приводят к полному отказу клетки? В случае тиристора вполне достаточно кратковременного отключения питания для восстановления работоспособности.
Вообще доклад наверное хороший, но он очень далек от реалий обеспечения функционирования ИМС в космическом пространстве? Да и PACO сложно назвать профильной для этой области конференцией.

amartology wrote:

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

Ну, может быть немного не по теме, но всё-таки.

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

1. Подобный раздел можно сделать, как открытым для всех, так и открытым лишь для узкой категории лиц. Этот вопрос может разрулить местный Администратор, с красивым именем Nataly.
2. Конференция априори документирована, т.е в какой-бы момент не присоединился к конференции участник, он всегда сможет увидеть процесс обсуждения до него.
3. Люди участвуют в конференции находясь в своём родном часовом поясе - они находятся в своём, нормальном физиологическом состоянии, это ещё и означает то, что оппонент может вдумчиво аргументировать свои идеи и соображения.
4. Форум позволяет делиться материалами и документами, вставлять в текст сообщения изображения. Повторюсь, если требуется, то обсуждение можно сделать открытым для какой-либо определённой категории лиц.

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

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

На некоторые вопросы, которые задаете вы, amartology, мы пока сами для себя еще не ответили утвердительно.
До реализации отказоустойчивой системы нам надо отработать реконфигурацию системы, чем мы и занимаемся, определиться с программной моделью для нее, принципами арбитража процессов. Концепция ясна, но сейчас идет ее проработка "вглубь".
После того, как будет четко отработан механизм реконфигурации, можно будет делать систему управления отказоустойчивой. Как сделать это эффективнее - это предмет обсуждения, которое пока мы ведем внутри компании и с теми, кого знаем. Что-то, что мы понимаем, уже закладываем. Что-то еще предстоит понять.
У нас есть много вариантов организации отказоустойчивой системы с нашим ядром. Но то, как она будет выглядеть окончательно пока сказать трудно, это еще обсуждается.
С удовольствием бы познакомились со специалистами в области обеспечения устойчивости ИМС. Вариант организации профильного форума весьма заманчив. Есть что обсудить.

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

Про тиристорный эффект. Я пока не понимаю, как вычислитель может без какого-либо спец. детектора его обнаружить. Если только элемент словивший это не влияет на вычислительный процесс. Тогда можно выявить несовпадение данных в разных каналах или регистрировать неправильных ход программы. Дальше - фантазия программиста, что ему делать в этом случае. Можно всегда выключать питание от сбившейся клетки или группы, например. Или можно делать временное разделение и пересчитывать в разных комбинациях клеток. Дальше так же перевключать сбившиеся.

HEMAH wrote:

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

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

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

DmitryK_multiclet wrote:

На некоторые вопросы, которые задаете вы, amartology, мы пока сами для себя еще не ответили утвердительно.
До реализации отказоустойчивой системы нам надо отработать реконфигурацию системы, чем мы и занимаемся, определиться с программной моделью для нее, принципами арбитража процессов. Концепция ясна, но сейчас идет ее проработка "вглубь".
После того, как будет четко отработан механизм реконфигурации, можно будет делать систему управления отказоустойчивой. Как сделать это эффективнее - это предмет обсуждения, которое пока мы ведем внутри компании и с теми, кого знаем. Что-то, что мы понимаем, уже закладываем. Что-то еще предстоит понять.
У нас есть много вариантов организации отказоустойчивой системы с нашим ядром. Но то, как она будет выглядеть окончательно пока сказать трудно, это еще обсуждается.
С удовольствием бы познакомились со специалистами в области обеспечения устойчивости ИМС. Вариант организации профильного форума весьма заманчив. Есть что обсудить.

DmitryK_multiclet wrote:

По поводу отказоустойчивости, тут мы наблюдаем 2 направления:
- отказоустойчивость в отсутствии спец. факторов (для этого случая может быть и не самый подходящий термин), которая больше интересует, условно назовем, "народное хоз-во". Кому-то, например, дешевле медленнее считать, чем перезапустить весь процесс. Или пусть хоть как считает, в приемлемом отрезке времени, но выполнит правильно задачу управления.
- отказоустойчивость при наличии спец. факторов. Это как раз аэрокосмические применения. Тут важна и скорость вычислений и сопротивляемость воздействиям.
Про тиристорный эффект. Я пока не понимаю, как вычислитель может без какого-либо спец. детектора его обнаружить. Если только элемент словивший это не влияет на вычислительный процесс. Тогда можно выявить несовпадение данных в разных каналах или регистрировать неправильных ход программы. Дальше - фантазия программиста, что ему делать в этом случае. Можно всегда выключать питание от сбившейся клетки или группы, например. Или можно делать временное разделение и пересчитывать в разных комбинациях клеток. Дальше так же перевключать сбившиеся.

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

Обращаюсь к команде Мультиклет. В этом треде вы общаетесь с преподавателем, который защитил диссертацию по разработке сбоеустойчивых элементов СБИС. Фактически он защитник архитектуры серии процессоров Комдив специального применения.

Теперь попробую объяснить для armatology на пальцах, что такое системная устойчивость в Мультиклете. В серии процессоров Комдив есть микросхема с троичным резервированием. Фактически в ядре этой микросхемы стоит три дублирующих ядра. Команда загружается в три ядра одновременно, исполняется, затем результат сравнивается. Если выйдет из строя одно ядро, то гарантированный результат может быть получен по одинаковым результатам двух оставшихся ядер. Если два, то уже нет. В Мультиклете клетки позволяют исполнять код даже если выйдут из строя 3 из 4-х клеток. Т. е. даже на одной работающей клетке можно получить достоверный результат. Все, что я тут вам сказал относится к сравнению устойчивости архитектур Комдив и Мультиклет. Как видим архитектура Мультиклет более устойчивая чем Комдив, а следовательно имеет право на применение в специальных областях.

Теперь о топологии. Вы пытаетесь донести до команды Мультиклет, что для микросхем специального применения необходима не только системная устойчивость, но и её реализация в "железе". Т. е. необходимо применение специальных транзисторов, КНИ, дублирования транзисторов и т. п. технологии. Я вам отвечу на ваш вопрос. Это все относится не архитектуре, которую разрабатывает команда Мультиклет, а к её реализации в топологии. Реализовать защиту от космических лучей на основе топологии это задача уже не столько разработчиков архитектуры, сколько тех людей, которые будут создавать саму микросхему. Мультиклетовцы могут сделать заказ на производство микросхемы с защищенной топологией. Возможно даже и вам, ведь вы работаете в НИИ СИ РАН :).

Если мультиклеточный МП является частью одного из каналов отказоустойчивой системы и в нем деградируют клетки, то он будет работать до последнего. Для программы это будет не заметно, только потеря производительности. При этом мажоритирующий элемент, определяющий достоверность результатов каналов - внешний по отношению к МП.

Если мультиклеточный МП будет стоять сам по себе и являть собой отказоустойчивую систему, то он позволяет реализовывать программные методы обеспечения отказоустойчивости, программа может выполняться на "живых" клетках, а с неадекватными можно проводить реанимацию. Но когда останется 1 клетка - это уже аварийная ситуация, запаса больше нет. Программный метод может не сработать или контроль покажет, что вычислитель неадекватен и если не помогут методы восстановления работоспособности, то все ...

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

Zveruga wrote:

Обращаюсь к команде Мультиклет. В этом треде вы общаетесь с преподавателем, который защитил диссертацию по разработке сбоеустойчивых элементов СБИС. Фактически он защитник архитектуры серии процессоров Комдив специального применения.

False. Я ни слова не сказал про КОМДИВы и не стал представляться именно потому, что говорил безотносительно собственной работы. LEON3 и RAD6000 построены на SPARC и PowerPC, но защита от одиночных сбоев у них организована сходным образом - при помощи мажорирования. И, кстати, что думают коллеги из Мультиклет про процессор MAESTRO?

И, уважаемый Zveruga, я нигде ничего не преподаю. Раз уж взялись на ixbt копаться в моем грязном белье, по крайней мере пишите никнейм без ошибок и не ленитесь проверять данные.

Zveruga wrote:

Теперь попробую объяснить для armatology на пальцах, что такое системная устойчивость в Мультиклете. В серии процессоров Комдив есть микросхема с троичным резервированием. Фактически в ядре этой микросхемы стоит три дублирующих ядра. Команда загружается в три ядра одновременно, исполняется, затем результат сравнивается.

Вообще нет. У нас не целые ядра мажорируются.

Zveruga wrote:

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

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

Zveruga wrote:

Теперь о топологии. Вы пытаетесь донести до команды Мультиклет, что для микросхем специального применения необходима не только системная устойчивость, но и её реализация в "железе". Т. е. необходимо применение специальных транзисторов, КНИ, дублирования транзисторов и т. п. технологии. Я вам отвечу на ваш вопрос. Это все относится не архитектуре, которую разрабатывает команда Мультиклет, а к её реализации в топологии. Реализовать защиту от космических лучей на основе топологии это задача уже не столько разработчиков архитектуры, сколько тех людей, которые будут создавать саму микросхему. Мультиклетовцы могут сделать заказ на производство микросхемы с защищенной топологией. Возможно даже и вам, ведь вы работаете в НИИ СИ РАН :).

Я пытаюсь донести до команды Мультиклет, что им надо хорошенько подумать, как они собираются защищать схемы управления и детектировать сбои и отказы. Эти проблемы относятся именно к архитектуре, а не к ее топологической реализации. То, что было заявлено как преимущество архитектуры, без проблем достигается и без ее применения, а вот дальше я вижу довольно много проблем, которые могут очень сильно снизить применимость Мультиклета в космосе. И я пытаюсь донести до коллег важность этих проблем. Они, кстати, скорее всего, не решатся просто использованием библиотеки спецстойких элементов, потому что организация защиты от одиночных сбоев в рамках библиотечных элементов - задача нетривиальная, а последствия того, что управляющая схема посыплется, довольно печальны и, самое главное - непонятно, как процессор будет понимать, что у него проблемы не внутри отдельных ядер, а в схеме, которая их коммутирует и определяет работоспособность.

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

Про Maestro каких-то конкретных мыслей нет пока. Как они будут обеспечивать работоспособность десятков ядер - предстоит еще понять.

DmitryK_multiclet wrote:

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

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

Вот отсюда-то и растет вопрос "как вы собираетесь контролировать то, что клетки будут корректно проводить арбитраж в условиях воздействия > одиночных сбоев".

Может применить в "живучем" процессоре (тот, что ядро L1) реконфигурируемую архитектуру с одним битом четности всех шин и вычислителей в каждой клетке? Тогда остальные клетки смогут "видеть" работоспособные клетки по достоверности результата. Правда это увеличит энергопотребление.

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

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

"В рамках рабочей поездки состоялась встреча представителей «Мультиклет» и «СПУТНИКС», итогом которой стало соглашение об использовании процессора MULTICLET P1 для проведения испытаний на радиационную стойкость в космических условиях в бортовой аппаратуре в составе спутника, который будет выведен на орбиту в 2014 г".
А почему на спутник сразу? На пятнадцать (да даже и на пять) лет вы его все равно не запустите там облучаться, а менее длительные испытания все равно неинтересны никому. Почему бы не испытать в лабораторных условиях, где можно аккуратно посмотреть показатели стойкости?

Уважаемый amartology, мы были бы Вам весьма признательны за примеры SoC, обладающих свойствами динамической реконфигурации или живучести. Нам ничего подобного найти не удается даже у самых "космических" производителей. Более того, специалисты ЕКА письменно проявляют заинтересованность в этих продуктах. На этом основании мы считаем продукты уникальными не только для нас.
Что касается испытаний на спутнике, то может быть Вы знаете, есть такое направление в космонавтике, называется коммерческие запуски, когда срок службы аппарата не превышает 2- 3 лет. В этом случае акценты по свойствам меняются. Мы будем пробовать в этом запуске бюджетный пластиковый корпус, поскольку цены на КнС в таких запусках неприемлемы.

"живучесть процессора, т.е. возможность непрерывного исполнения программы при отказах его отдельных клеток"
SoC, обладающий свойством живучести - любой троированный процессор, сохраняющий в случае отказа одного из троированных блоков работоспособность с потерей сбоеустойчивости. В случае, если имеется четвертое ядро, включенное как "холодный резерв", то процессор может сохранять работоспособность при отказе дух ядер из четырех. В этом отношении в вашей работе нет ничего принципиально нового, за исключением того, что минимальное число ядер - одно. При этом реализовать возможность работы троированной системы при отказе двух ядер из трех тоже несложно, если научить ее распознавать отказавшие ядра.
Если я не ошибаюсь, динамически реконфигурировать можно процессоры архитектуры Tilera. Разрабатываемый сейчас в "Миландре" процессор "Обработка-13" содержит два ядра, которые можно включить параллельно либо в дублированную систему. Думаю, что там реконфигурация вполне может быть доступна программно.
И самый интересный вопрос: динамически реконфигурируемая FPGA с залитым в нее процессорным ядром считается? Вот пример такой работы: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=5474072

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

Конечно, вопросы позиционирования новых продуктов очень важны, поэтому попробую ответить подробно, хотя и не в первый раз, даже здесь на форуме. Правда, хочу сразу оговориться, что мы не разделяем Вашу позицию о том, что "нет ничего нового под луной", это противоречит и смыслу патентования.
Системы с простым n-кратным резервированием обсуждать нет смысла, поскольку это стандартный прием и может быть реализован с любым процессором.
В отношении схемотехники - процессоров с библиотеками с троированной логикой (как и для систем с резервированием) применялся и применяется термин "отказоустойчивые", и в нашем Multiclet L1 также планируются такие библиотеки (их прототипные характеристики с апробацией на ускорителях по тиристорному эффекту и дозе Вы можете увидеть в сравнительной табл. на сайте). Фактически, одна клетка процессора Multiclet L1 в этом плане не отличается от целого процессора ВАЕ. В ДОПОЛНЕНИЕ к этому наш процессор, в силу особенностей архитектуры, обладает возможностью постепенной деградации, именно это в приведенном Вами определении мы и назвали "живучестью", поскольку это новое свойство системы, системотехническое (не схемотехническое), которым предыдущие процессоры не обладают, и с целью терминологической точности такое определение оправдано. В самом деле, живучесть - это не резервирование, а возможность ПАРАЛЛЕЛЬНОГО процессора выполнять свою задачу при отказе его компонент, без перепрограммирования (повторного решения задачи распараллеливания) и без перезагрузки программного кода. Поскольку в нашем случае используется не резервирование, а другой подход, называемый повторным счетом. Этот подход реализовать на параллельной системе, состоящей из традиционных процессоров, невозможно, так как при отказе одного из них требуется перекомпиляция (повторное решение задачи распараллеливания).
Относительно динамической реконфигурации. Да, действительно, под общее определение 3-го класса попадают и конструкты с ПЛИС и наш СнК Multiclet R1, однако все же это разные подходы внутри одного класса, причем СнК обладает преимуществами. Во-первых, система управления не такая жесткая, и программист может задавать любые варианты выполнения программ, даже в ходе их выполнения. Во-вторых, такой процессор, фактически является прототипом 4-го, пока не существующего, класса, в котором динамическая реконфигурация будет осуществляться автоматически, без вмешательства программиста. Здесь будут задействованы известные элементы искусственного интеллекта, обучение (с учителем, самообучение) и распознавание.
Проведение испытаний, о которых Вы пишете, является для некоторых потребителей обязательным, поэтому все это у нас есть в плане для Multiclet L1. И это никак не противоречит тому, что мы уже обсуждали для коммерческих запусков, дело же не в том, является структура государственной или нет, просто требования экономичности и срока эксплуатации противоречат друг другу и требуют принятия оптимальных решений.