Pull to refresh

Comments 47

Цены похожи на правду, зато посыл «Let's take a look at the Rolls-Royce in the chip industry.» — не очень. Оно скорее БелАЗы, чем Роллс-Ройсы)
… сбой в ней возможен только при одновременном попадании в два инвертора, которое относительно легко предотвратить
Вероятно, не «предотвратить», а «снизить до минимума вероятность»
Тогда уже просто «снизить вероятность», потому что «минимум вероятности» — штука весьма эфемерная) Но в практическом смысле там именно что «предотвратить». Впрочем, это на самом деле не так важно, потому что справедливо только для режима хранения данных, а в режимах записи и чтения DICE-ячейка намного более уязвима.
Почему для радиационно стойких процессоров используют специальный сокет Rad-pak? Чем плохи обычные?
image
Видимо этот корпус состоит из дополнительного экрана, поглощающего частично излучение. Внутри могут быть разные компоненты.
image
О, это тема многолетних срачей большого количества споров. Даже не знаю, с чего начать.
1) На фото не Rad-pak, а просто металлокерамический корпус. Rad-pak — это когда стенки и крышка корпуса сделаны в виде пирога из тяжелых металлов для снижения полной поглощенной дозы внутри корпуса (при этом обычно становится хуже с одиночными сбоями).
2) Сейчас микросхемы в обычных пластиковых корпусах вполне себе летают. В том числе со специально разработанными радстойкими чипами внутри.
3) Изначально смысл металлокерамики в том, что она надежнее. Например, в объеме пластика есть (и в процессе хранения набирается еще) вода, которая при термоциклировании с переходами через ноль по Цельсию имеет обыкновение разрушать корпус. Также старые пластики выделяют газ, что неприемлемо для ряда применений. А для BGA корпусов вместо шариков приходится делать пружинки, чтобы пройти тесты на вибростойкость.
4) Есть еще заморочки с несовместимостью современных пластиковых корпусов со свинцовым припоем, а бессвинцового припоя — с вакуумом. И так далее и тому подобное.
Спасибо за ответ, про корпуса в принципе понятно (Rad-pak это ведь больше именно про корпус?), но меня заинтересовал именно способ крепления. Зачем делают такую позолоченную квадратную рамку с дополнительными пластинами керамики на выводах? Эти выводы потом паяются на плату, или зажимаются в ответный разъем?

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

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

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

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

А вопрос не глупый ни разу. Нормальный и, более того, очень правильный вопрос. При проектировании спутников учитывается, сколько защиты даёт каждому конкретному чипу окружающая конструкция и, при необходимости, где-то стенки делаются толще или производится перекомпоновка, и даже пластинки из свинца бывают. Но это все только полной дозы касается, а основная проблема сейчас обычно не в ней.
А у меня другой глупый вопрос. Если у старых процессоров нет таких проблем с одиночными сбоями, почему не накидать на аппарат дофига их. То есть грубо говоря брать количеством, а не качеством. Все же процессоры не как гантели весят. Хотя тут скорее уже к объему вопросы…
Во-первых, производительность многопроцессорной системы с ростом количества чипов растет гораздо слабее, чем линейно.
Во-вторых, на тысячу старых процессоров вместо одного нового надо в тысячу раз больше электричества.
В-третьих, в таких количествах старые процессоры весят таки как гантели. Старые БЦВМ легко весили по 100-200 кг при производительности на пару порядков меньше нынешних пятикилограммовых.
А если электроника выключена, она тоже страдает от накопления дозы?
Нельзя ли положить на борт несколько запасных компьютеров и включать их по мере радиационного износа работающих?
Есть микросхемы, которые в выключенном состоянии страдают от полной дозы сильнее, чем во включенном.)
Зависимость дозовой деградации от электрического режима есть, но в выключенном состоянии доза все равно набирается. В принципе, отключение и нагрев могут дать какой-то полезный эффект, но брать на борт запасные компьютеры и не париться не выйдет, и это даже без учёта стоимости вывода дополнительной массы на орбиту.
Да, меня идея annealing-а на борту КА резервных комплектов (чего-либо, не только CPU) всегда интересовала. А если еще и УФ-источником определенной энергии обрабатывать, то наверное вообще шикарно жить можно (по крайней мере для некоторых марок флинтов это работает).
А возможен ли отжиг отключенной микросхемы на борту КА? РИТЭГ ведь много тепла выделяет. По идее, если нагреть до температуры, при которой еще на начинается заметная диффузия примесей, можно будет «обнулить» накопленный в диэлектрике заряд.
Теоретически — да. На практике я его не видел, но это вполне может быть, что это только я не видел, а системщики в курсе) Но наверняка как минимум есть нюансы, потому что с моей колокольни такое решение выглядит сложно реализуемым.
Базовые соображения такие:
1) При температурах, «когда ещё нет диффузии примесей» у вас уже распаяется плата.
2) На самом деле отжиг очень ускоряется уже в диапазоне 85-125 градусов.
3) Но нагрев в сочетании с подачей питания — это ускоренное старение микросхемы. Собственно, испытания на него так и делают. Поэтому нагреватели должны быть полностью отключаемыми.
4) Если и делать что-то такое, то разумеется, это должны быть не теплопроводы, а нагревательные резисторы в нужных местах. Греют же на спутниках аккумуляторы, в конце концов. Хотя может я чего-то не знаю, и можно сделать компактные отключаемые теплопроводы. И поставить на спутник РИТЭГ, которого там обычно нет)
5) Как нагреть одну конкретную микросхему и не нагреть все остальное? Делать намного больше расстояния между элементами на плате? Более того, если греть на протяжении суток и недель, то во-первых, никакого электричества не хватит, а во-вторых, нагреется равномерно если не весь аппарат, то весь блок, в котором стоит нагреваемый девайс.
6) Отвод избыточного тепла в космосе — это довольно сложная штука, которую тоже придется решать.
7) Я смог найти историю о том, что у Galileo в 2003 году подачей постоянного напряжения грели светодиоды внутри сломавшегося плёночного магнитофона, на который были записаны данные, чтобы отмотать пленку назад и перечитать часть информации.
А какова вообще будет интенсивность сбоев обычных незащищенных микросхем в открытом космосе? Ну то есть взяли айфон и полетели на марс — как часто будут случаться одиночные сбои и когда он совсем превратится в тыкву?

Десятки сбоев на мегабит в день (в Айфоне будет намного больше, там технология новее, чем у чипа на картинке). Плюс с какой-то разумной вероятностью произойдет катастрофический отказ (тиристорный эффект) — в произвольное время, эффект вероятностный.
По дозе стойкость разных микросхем внутри айфона может на три-четыре порядка различаться, какой-то из чипов наверняка не долетит.
Я это к чему — может быть не стоит гнаться за высокой производительностью спец.компьютеров? Оставить все критические задачи управления, связь и т.п. на компьютере из 90гг, а данные обсчитывать (фото там пожать для передачи или еще чего) на обычном процессоре, запертом для солидности в свинцовую коробочку. Вычислять неколько раз, проверяя, что результаты сходятся.
Свинцовая коробка не помогает от одиночных отказов и стоит (на орбите( дороже, чем специальный процессор. Но вы полностью правы идейно: сейчас вскидкт к разделению на особо стойкие супервизоры и все остальное попроще и подешевле. Особенно в миссиях, где запускается не один уникальный аппарат, а группировка, в которой допустимы отказы.
И именно в этой идеологии делается HPSC, уже на уровне чиплета (ну и добавляем сюда потенциально бесконечное число оных).
Так вы почитайте другие статьи автора или иные источники. Вот на МКС например, да и вообще на НОО, может год(ы) отработать без сбоев. Выше — будет сбоить часто. Значимая частота и на трансатлантических рейсах отмечается, другое дело, что есть «значимая» в вашем случае. Тут надежнее всего оперировать не временем и частотой на одном девайсе, а интенсивностью отказов на выборке, скажем так — у миллиарда марсианских людей хотя бы раз в день оно точно будет (я сейчас про одиночные сбои говорю).
Спасибо автору, статья офигенная! Даже боюсь спросить, сколько времени ушло на сбор всех этих фактов. Кажется, что я очень много прочитал про ERC32, но увидел много нового тут.

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


А это как-то мало помогает по моему опыту. Я тоже много чего читаю в своей области, знаю и могу вспомнить по необходимости прочитанное in general, и иногда даже конкретные цифры. Но если нужно написать некий очерк, то нужно же все это снабдить точными ссылками, точными датами и точными цифрами, и времени на это нужен вагон — ну, да, за две-три недели, условно в 10-20% фокуса, можно уложиться.
снабдить точными ссылками, точными датами и точными цифрами
Кстати для меня важная мотивация писать статьи — возможность превратить собственное обрывочное знание in general в хорошо структурированное и как следует осознанное, а то бывает неприятно выяснить, что со своим in general на самом деле много лет играл в испорченный телефон, однажды переврав самому себе что-то мельком услышанное. А так я во-первых стал точно уверен в том, что понимаю, что говорю, а во-вторых — под рукой будет одно место, где можно посмотреть, если в будущем нужно будет самому себе что-то напомнить.
Так и есть, еще одно, пусть и косвенное, проявление правила «хочешь что-то понять — попытайся объяснить это другому». Ну и записывать свои мысли полезно всегда, память все-таки не резиновая.

– ЦУП! У нас вышел из строя компьютер! Что делать??
– Играйте на запасном! Повторяю! Играйте на запасном!

1802 никому в команде разработчиков по-настоящему не нравился
Смотрю, вкусы разработчиков со временем не сильно меняются, я недавно практиковался с 1802 — зубодробительней набора инструкций еще поискать, даже 4-битный TMS1000 примерно того же времени создания показался мне более дружественным.
Практиковался с 1802? Я бы почитал про такое с удовольствием, из палеонтологического интереса)
Есть у меня хобби делать простенькие игры для разных древних железок, а на 1802 была одна из первых игровых приставок — RCA Studio II, вот с ней и игрался. Про нее, кстати, на Хабре есть палеонтологическая статья.
Спасибо большое, статья очень крутая. Но в ней, кстати, есть неточность по части радстойкости: космические 1802 были не только (и не столько) на технологии «кремний на сапфире», но и на объемной КМОП-технологии, и на GaAs. На Magsat и Galileo с вероятностью 99% были объемные чипы из первых серий.
Маленькое уточнение, арсенид-галлиевая серия у «Микрона» была К6500, а не К5600.
Да, конечно 6500. Видимо, опечатался. Спасибо большое!
Совершенно фантастическая по уровню написания и качеству материала статья!
Спасибо вам!
Достаточно подробный обзор. Спасибо! Для меня эта тема всегда была загадкой. А тут такое все по разложено.
Большое спасибо за подробный обзор!

В своё время узнал про Йиржи Гейзлера благодаря одному комментарию с заброшенной ветки формуа Altera. Там говорили про некий необычный стиль описания логики на VHDL по методу Jiri Gaisler. В сети, в целом, оказалось не так и много информации про этот стиль. В одной из презентаций говорится о том, что именно благодаря этому стилю на LEON потратили 2 человеко-года (2 man-years), а первый образец в железе вышел без багов. Выглядит впечатляюще. Однако я практически не встречал разработчиков, которые писали бы подобным образом. И это меня несколько удивляет. Как я понял, LEON'ы оказались весьма успешными. В то же время, один из методов разработки этого успешного продукта не получил распространения. Для себя я пока не нашел ответа, почему.
Спасибо за наводку!
Погуглил, интересный стиль. Некоторые такие элементы или ходы в описаниях встречал, но всё вместе не видел. Надо обдумать.
В то же время, один из методов разработки этого успешного продукта не получил распространения. Для себя я пока не нашел ответа, почему.

На форуме Xilinx есть обсуждение этого стиля, возможно одна из причин историческая — раньше синтезаторы не всегда хорошо оптимизировали такой код, а также имели проблемы с типом record.

Глянул также исходники от самого Jiri, где используется этот стиль. Для случаев с большими конечными автоматами и большим количеством переменных он кажется уже не таким и приятным, я бы даже сказал, громоздким, следить за изменением одной переменной по состояниям сложно. Возможно, это дело предпочтений и привычки.
На форуме Xilinx есть обсуждение этого стиля, возможно одна из причин историческая — раньше синтезаторы не всегда хорошо оптимизировали такой код, а также имели проблемы с типом record.

Спасибо, что нашли то обсуждение. Я как раз недавно пытался отыскать его снова, но не смог. Пользователь с ником 'mwaechter', он же 'Mathias Wächter', — это и есть тот человек, благодаря которому я узнал про этот стиль. К слову, Mathias оставил немало полезных комментариев по теме контроллеров аппаратных ядер PCIe в ПЛИС как на форумах Xilinx, так и на форумах Altera.
Действительно, у Jiri Gaisler мог быть более продвинутый синтезатор, у которого не было проблем с record. С другой стороны, тот же Mathias пишет, что они начали применять этот стиль с 2004 года. Прошло уже 16 лет. Впрочем, здесь я сравниваю разработчика ASIC и разработчика FPGA. У них могут быть совершенно разные инструменты синтеза.

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

Мне кажется, что некоторую роль играет то, как структурирован сам код. Я пробовал писать проект в подобном стиле и в целом доволен результатами. Проблемы были только во внешних интерфейсах. Нужно тщательно продумать, как группировать внешние сигналы в record, иначе получается неразбериха и туча портов. Но писать код было, на мой взгляд, намного легче. Если что-то изменялось прямо во время разработки, я легко мог внести изменения; тратил меньше действий на добавить/удалить сигнал, делал меньше ошибок, не получал случайных защёлок.
Вас понял, благодарю за интересную информацию, поэкспериментирую более детально с этими вещами.
Only those users with full accounts are able to leave comments. Log in, please.