Комментарии 63
Американскую инженерную школу, помимо хитрых технических решений, отличает и встраивание в устройства развитых средств диагностики (в этом устройстве — вплетенные практически в оконечный механизм — ток, приводящий в действие молоточки, прямым своим действием устанавливает бит «удар сделан»). Это позволяет, потеряв немного при выпуске устройств за счет небольшого усложнения конструкции, многократно выиграть в эксплуатации и поддержке на стоимости диагностики и ремонта (труд квалифицированного персонала дорогой!), а также выявить большое количество неисправностей с помощью формальных диагностических карт (так как входной информации для них становится достаточно).
Спасибо, прочитал статью с большим удовольствием (хотя перевод хромает в достаточно типичных местах)
Спасибо, прочитал статью с большим удовольствием (хотя перевод хромает в достаточно типичных местах)
Не знаю — отличительный ли это признак именно американской школы… Как-то довелось мне чинить трактор (кажется — Valtra), так там руководство пользователя страниц на 800 А4 со схемами, с указанием куда чем потыкать (вольтметр/омметр) на каких режимах (выключен/заведён), и специальные диагностические разъёмы, и куча датчиков, и инженерный режим для встроенного компьютера… короче, имхо, это просто признак профессиональной техники от хорошего производителя.
Развитые средства диагностики — это, отчасти, следствие из особенностей коммерческого применения вычислительной техники в те времена. IBM тогда не продавала свои мэйнфреймы, а отдавала в аренду их машинное время, и арендная плата начислялась пока на них работали программы заказчика. Соответственно, простои техники (к слову, и сбои в операционной системе тоже) вели к прямым убыткам, отсюда требования быстрой диагностики и ремонта «в полевых условиях».
я бы сказал наоборот — для ремонта советского АЦПУ (редкий плавающий дефект) мне было достаточно вешать логический пробник на разные сигналы. Аналогично — с лентопротяжкой, правда она более-менее стянутая у DEC была. Впрочем, это было третье поколение, а тут — второе.
Мне вспомнилось как много лет назад, в радиокружке, преподаватель ремонтировал огромный цветной телевизор. Вроде как в качестве мощных ключевых элементов стояли тиристоры. Так вот, наши инженеры написали туда столько защит, что чих в одном из блоков вызывал срабатывание защиты по всем другим. Как сказал тогда препод, пока он их все не вырезал диагностировать было нечего. Это я к тому, что далеко не всегда защита=средству диагностики, по статье у меня сложилось мнение что это была защита и ремонт она скорее усложнила.
Защита <> Диагностика. В аналоговых схемах, понятное дело, это сделать непросто, но по-правильному, если сработала защита по причине X в модуле Y, и отключились зависимые от Y модули A,B,C — то должен предоставляться и способ это узнать — то есть диагностический сигнал должен однозначно указать, что модули A,B,C отключены из-за неполадки X в модуле Y, а не просто сами по себе. Вот тогда это — правильная реализация. Если же этого нет, то успех починки отдаётся на откуп опыту конкретного мастера, который, отключая защитные механизмы, может спалить ещё несколько модулей ). Это — не американская, а сермяжная школа. Вспомните газовщиков, проверяющих спичкой утечку в соединениях труб, или «автоэлектриков», проверяющих наличие 12 вольт «на искру»
Надо было по гарантии поменять просто.
А если серъёзно, то я не перестаю умиляться когда вспоминаю, что многие подобные аппараты того времени шли с полной принципиальной схемой. И это даже когда продавалось обычным пользователям.
А если серъёзно, то я не перестаю умиляться когда вспоминаю, что многие подобные аппараты того времени шли с полной принципиальной схемой. И это даже когда продавалось обычным пользователям.
Иметь полную документацию — бесценно… Сейчас это — одна из причин успеха opensource (помимо бесплатности при покупки и возможности допилить напильником как тебе надо). Мечтаю, чтобы и обычную технику потихоньку начали продавать с полной документацией, например — можно на 1% снизить налоги с производителей, которые выкладывают полную техническую документацию на свой товар (схему ротора двигателя, припуски, марки металлов, толщину и тип провода обмоток… ну вообщем всё про готовое изделие, но без тех.карт производства — всё-таки это их информация)… чтобы лет через 5, когда будут 3д принтера по металлу, можно было без проблем скачать чертёж треснутого суппорта и распечатать, а не искать токаря/фрезеровщика/сварщиа, готовых эту деталь воспроизвести руками.
К слову, там явно не на токарном резали а обычным надфилем.
Полная документация хороша для вот таких устройств, на рассыпухе, как в статье. А, например, если устройство будет выполнено на микрочипах, которые еще надо шить, и которые не достать вот так просто, то по сути, документация будет полезна только для сервисов производителя. Да и они уже давно выкидывают целиком платы со сгоревшими деталями и ставят новые.
Почему? Документация позволяла прямо в ВЦ выявить отказавшую микросхему или ТЭЗ. А меняли, само собой, по возможности ТЭЗами.
Смысла нет менять микросхему, если на ТЭЗ одна микруха + чуть-чуть рассыпухи. Логичней сразу ТЭЗом.
Смысла нет менять микросхему, если на ТЭЗ одна микруха + чуть-чуть рассыпухи. Логичней сразу ТЭЗом.
Это, если вы инженер, обслуживающий ВЦ.
Там человек, выше, предлагал обычную технику с полной документацией продавать. 99% пользователям это не нужно. Вот вы обычный пользователь ПК, сгорит у вас встроенная в материнку сетевуха, толку будет от документации?
Угу, я программист. На этой самой СМ-1600 был системщиком. Но что делать, если дефект плавающий и при электронщиках не вылезает? Логический пробник в руки, описания схем — и ловить.
Более сложный ремонт — замена микросхемы, тут нужен datasheet, чтобы проверить совместимость. А без неё — только оригинальную ставить.
P.S. ну да, АСУТП и embeded — это близко к железу.
сгорит у вас встроенная в материнку сетевуха, толку будет от документации?Ну самый простой ремонт — отключить от неё питание и CS и поставить внешнюю. Для этого и нужна дока — чтобы не выпаивать всю микросхему, а откусить пару выходов.
Более сложный ремонт — замена микросхемы, тут нужен datasheet, чтобы проверить совместимость. А без неё — только оригинальную ставить.
P.S. ну да, АСУТП и embeded — это близко к железу.
Я другой вам пример приведу. Вот у вас комп перестал работать. То ли материнка, то ли проц, то ли блок питания. И без второго блока питания и второго проца вы сейчас не поймете, что же сгорело. А если есть технологические карты напряжений — то можно с китайским мультиметром за 200 рублей сделать первичную диагностику. И с шансом 90% все ограничится одной покупкой.
Нет, нельзя. Во-первых, все напряжения могут быть в норме, но ничего не работает. Например, обрыв внутри кристалла диода или транзистора. Но, если какой DC/DC преобразователь выйдет из строя, то может помочь. Второе, иногда бывает, что комп стартует и через 0.1 сек выключается. Мультиметром такое не измерить.
Чуть внимательнее читать надо, я недаром про 90% написал. :-) Фактически, на наших собственных платах, хватает двух светодиодов. Один из них показывает наличие питания на процессоре, второй висит на GPIO и мигает, если проц стартовал. Я бы даже сказал, что это дает не 90%, а 98% диагностики. Но у нас довольно простые платы.
Второе, иногда бывает, что комп стартует и через 0.1 сек выключаетсяА это очень характерная картинка. Светодиод питания в момент перегрузки тускнеет, а на светодиоде от GPIO вместо ровного тик-так — дает нечто рваное.
Мультиметром такое не измерить.Мультиметр, светодиод — ну в общем подручные средства. Собственно и китайский осциллограф у многих есть.
Я видел про 90%, но считаю, что просадки по питанию значительно реже этих цифр. А по поводу светодиодов — я с вами согласен. На одной из моих ПК матерей было 3 аварийных светика: cpu, memory, еще что-то. Было очень удобно, определять, что отвалилось. Без всякой документации.
90% — это то, что можно легко диагностировать мультиметром и светодиодами. То есть комп не включается, POST не идет. Значит сгорел или БП или мать или проц. Эту ситуацию берем за 100%. Вот 90% от неё — простые поломки типа БП выдает не все напряжения или отключается при большом токе. Или не работает преобразователь питания на плате. Или срабатывает защита по питанию на плате. Или сгорел проц.
просадки по питанию значительно реже этих цифрЭто специфика GPS. Приемник в режиме быстрого поиска сигналов (до первого решения) потребляет мощность чуть ли не в десяток раз больше, чем в нормальном режиме.
Мечтаю, чтобы и обычную технику потихоньку начали продавать с полной документациейДа вобщем-то даташиты и так на большинство существующих в природе микросхем и пассивных элементов находятся в открытом доступе, но сейчас это не спасёт отца русской демократии. Сейчас платы от бытовой техники — многослойные, микросхемы BGA в тонюсеньких корпусах посажены на бессвинцовый припой и всё это зачастую залито
перемещались вертикально для выбора символов, поэтому любые ошибки смещения или синхронизации изменяли вертикальное положение символов, приводя к уродливому волнистому тексту
«Узнаю
Просто супер.
А ведь не давно то это был отличный мейнфрейм как я понмаю это как сервер.
В 60 году можно было починить отдельный транзистор )
Интересно чинить транзистор не пробовали?
А ведь не давно то это был отличный мейнфрейм как я понмаю это как сервер.
В 60 году можно было починить отдельный транзистор )
Интересно чинить транзистор не пробовали?
Нижний левый транзистор вышел из строя и был заменён
видимо аппарат стоял где-то в пыльном и сыром помещении — вся плата в какой-то грязи, а блестящие корпуса транзисторов помутнели.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за информацию!
А «затвор» — это у полевого транзистора. Latch — так и переводится, как защелка.
ПС. Что такое «циановый»?
Я еле выучил «коралловый» (само слово, не цвет), а тут еще один непонятный оттенок.
ПС. Что такое «циановый»?
Я еле выучил «коралловый» (само слово, не цвет), а тут еще один непонятный оттенок.
Циан — не оттенок, а один из базовых цветов, вместе с жёлтым и маджентой! Это всякие там красный и синий — непонятные оттенки в системе CMYK! :)))
А если серьёзно, то мадженту хотя бы можно назвать пурпурным цветом, а вот для циана слова нет, разве что «сине-зелёный»… Но если говорят «сине-зелёный», мне трудно это визуализировать, а вот циан — сразу понятно.
А если серьёзно, то мадженту хотя бы можно назвать пурпурным цветом, а вот для циана слова нет, разве что «сине-зелёный»… Но если говорят «сине-зелёный», мне трудно это визуализировать, а вот циан — сразу понятно.
Круто. Взяли и починили один бит. Прикладная некромантия. Только читать было тяжеловато из-за кучи сносок; лучше бы их прямо в текст вставили.
Теперь я знаю, какие такие карты переставлял Ковекс и потом лопал Маззи!
Спасибо, классный детектив. Убийца — транзистор — это сильно!
Спасибо, классный детектив. Убийца — транзистор — это сильно!
Спасибо! Были фичи в наше время — разбор принципиальных схем и документации! Недавно ко дня программиста нашел ролики про наши ЕС ЭВМ на Байконуре! У нас там мужиков 20 было, которые легко «чинили» железо! Здорово! Удачи автору!
Самая смешная из историй про железо — это исторяи про ЕС 1035 с заводским номером 3. Там при сравнении вещественных сравнивались только мантиссы. Соответственно 2.0 было равно 16.0. Коллега, который это нашел в своей программе, очень долго удивлялся, когда понял, что ошибка в процессоре. Не меньше удивлялся и завод-изготовитель.
Ну, я не знаю, чему удивлялся изготовитель. Мы регулярно получали обновления прошивок на ЕС-1061 и 1046 (правда, это наверное было чуть позже), и ловили ошибки в них. Чем 1035 лучше — не ясно.
Тому, что тесты эту ошибку не поймали. Да и вообще, не написанный кусок кода — это такой epic fail.
Тесты? Вообще говоря, микропрограммы, которые грузились в ЕС второго поколения, писались непонятно на чем, там система команд была не S/370 вовсе. Я не уверен, что там был хоть какой-то инструментарий для тестирования. В лучшем случае — ассемблер. А тесты, которые делаются ручками — ну так что от них можно ждать?
В нашем же случае ошибка вообще была более сложная — там повторно срабатывал таймер, вызывая неожиданное прерывание, при обработке которого VM/SP зацикливалась (и все это в процессе IPL). На такие асинхронные процессы с инструментарием для тестирования и сегодня далеко не все хорошо.
В нашем же случае ошибка вообще была более сложная — там повторно срабатывал таймер, вызывая неожиданное прерывание, при обработке которого VM/SP зацикливалась (и все это в процессе IPL). На такие асинхронные процессы с инструментарием для тестирования и сегодня далеко не все хорошо.
А что вас так тесты удивили? На любую ЭВМ тех времен в комплекте шел большой набор тестов, в том числе и тесты процессора. Они проверяли в том числе правильное исполнение всех команд процессора.
Просто тесты эту ситуацию тоже прощелкали. Что 2.0 с 3.0 верно сравнивается — проверили, что 3.0 с 2.0 — тоже, что 2.0 с 2.0 — тоже, а вот 2.0 и 16.0 — фантащиии у авторов тестов не хватило.
Само собой, это тесты на процессора, а не автотесты микроцессорного кода. То есть писались на обычном ассемблере.
P.S. А обычное применение тестов было забавное. Приходит @удак с претензиями в ВЦКП — «ваша ЭВМ неверно считает». Ноль проблем — запускаем тесты. По тестам все ОК — ну и потраченное машинное время ему в счет. :-) А тесты (контрольные примеры в той терминологии) были на все, включая компиляторы. Это 1983 год, я тогда пару месяцев оператором ЕС-1022 работал.
P.P.S. Интересно, а вы не пробовали в своей ситуации тест ПДП (DMA) запускать? Он не говорил в чем ошибка, но зато прилично нагружал всё систему. Он как раз мог показать, что баг имеется.
Просто тесты эту ситуацию тоже прощелкали. Что 2.0 с 3.0 верно сравнивается — проверили, что 3.0 с 2.0 — тоже, что 2.0 с 2.0 — тоже, а вот 2.0 и 16.0 — фантащиии у авторов тестов не хватило.
Само собой, это тесты на процессора, а не автотесты микроцессорного кода. То есть писались на обычном ассемблере.
P.S. А обычное применение тестов было забавное. Приходит @удак с претензиями в ВЦКП — «ваша ЭВМ неверно считает». Ноль проблем — запускаем тесты. По тестам все ОК — ну и потраченное машинное время ему в счет. :-) А тесты (контрольные примеры в той терминологии) были на все, включая компиляторы. Это 1983 год, я тогда пару месяцев оператором ЕС-1022 работал.
P.P.S. Интересно, а вы не пробовали в своей ситуации тест ПДП (DMA) запускать? Он не говорил в чем ошибка, но зато прилично нагружал всё систему. Он как раз мог показать, что баг имеется.
>А что вас так тесты удивили?
Тем, что тестировали они весьма примитивные вещи. Только плиз, не надо мне тут ля-ля…
>Они проверяли в том числе правильное исполнение всех команд процессора.
Нет, не проверяли. Кто вам сказал такую ерунду?
>Это 1983 год, я тогда пару месяцев оператором ЕС-1022 работал.
В 1983 я уже работал системным программистом.
Тем, что тестировали они весьма примитивные вещи. Только плиз, не надо мне тут ля-ля…
>Они проверяли в том числе правильное исполнение всех команд процессора.
Нет, не проверяли. Кто вам сказал такую ерунду?
>Это 1983 год, я тогда пару месяцев оператором ЕС-1022 работал.
В 1983 я уже работал системным программистом.
Ну дайте пруф, что не проверяли. За 35 лет, конечно, я мог что-то подзабыть, но мне помнится, что тест процессора (судя по документации) проверял каждую машинную команду. Бегло, а ля «фальшивый цитрус», но проверял.
Со своей стороны — вот вам ссылка на книжку по тестам процессора.
Со своей стороны — вот вам ссылка на книжку по тестам процессора.
Пруф на то, чего не делали? Как вы себе это представляете? Ну и я тоже с ЕС уже с 1996 не работал, вообще-то. Но тем не менее…
Если вы видели спецификацию на систему команд S/360, то должны помнить, что это книжонка страниц на 600. Она у нас издавалась, кажется из-во Мир. Это сложная достаточно система команд, CISC архитектуры. С арифметикой-то проблем нет, а вот дальше…
Попробуйте прикинуть для смеху, как вы будете тестировать команды типа условных переходов, вроде BC. Или BALR какой-нибудь. Намек — как проверить что-то типа условного перехода (а-ля if в языке более высокого уровня), если вы подозреваете, что он может не работать на уровне железок?
И сколько кода у вас получится на одну команду, чтобы реально что-то проверить. Или сохранение регистров в память. Или ввод-вывод (включающий разного рода асинхронщину, потому как каналы же). Все такие тесты могут быть только косвенными, и потому заведомо неполными.
Написать полный тест на систему такой сложности и сегодня почти не реально.
Да, и текста книжки по вашей ссылке кстати нет, похоже.
Если вы видели спецификацию на систему команд S/360, то должны помнить, что это книжонка страниц на 600. Она у нас издавалась, кажется из-во Мир. Это сложная достаточно система команд, CISC архитектуры. С арифметикой-то проблем нет, а вот дальше…
Попробуйте прикинуть для смеху, как вы будете тестировать команды типа условных переходов, вроде BC. Или BALR какой-нибудь. Намек — как проверить что-то типа условного перехода (а-ля if в языке более высокого уровня), если вы подозреваете, что он может не работать на уровне железок?
И сколько кода у вас получится на одну команду, чтобы реально что-то проверить. Или сохранение регистров в память. Или ввод-вывод (включающий разного рода асинхронщину, потому как каналы же). Все такие тесты могут быть только косвенными, и потому заведомо неполными.
Написать полный тест на систему такой сложности и сегодня почти не реально.
Да, и текста книжки по вашей ссылке кстати нет, похоже.
Пруф на то, чего не делали? Как вы себе это представляете?Легко. Или перечь поставляемой документации на процессор, в котором нет описания контрольного примера. Или (хуже) ГОСТ на документацию к процессору, позволяющий его выпустить без описания контрольного примера.
Другой момент, что у системщиков этой книжки могло не быть, она должна была быть у электронщиков (или своих или приходящих).
Если вы видели спецификацию на систему команд S/360, то должны помнить, что это книжонка страниц на 600.600 страниц — это учебник. Само описание системы команд — станиц 250-350.
Попробуйте прикинуть для смеху, как вы будете тестировать команды типа условных переходов, вроде BC.Знаете, если бы это было сложно — не было бы написано ни одного программного эмулятора. :-) А тестируется оно просто. Ассемблеры я подзабыл с годами, так что не пинайте сильно. То, что ниже — это некоторая пародия на PDP-11, увы уже не все мнемоники помню.
CLR R0
MOV #1, R1
TST R1
JPL $1
INC R0
$1:
MOV #2, R2
CMP R2, R1
JPL $1
INC R0
$2:
Если у нас в R0 — 0, то все хорошо. Если 1 — не работает выставление битов одной из команд процессора, если 2 — или не работает условный переход или вообще не выставляется бит PL.
Тут проблема лишь в выдергивании себя за волосы. То есть надо примерно 30 работающих команд, чтобы тест мог хоть что-то выводить. Если не путаю, первые фазы теста можно было проходить пошагово с инженерного пульта.
Все такие тесты могут быть только косвенными, и потому заведомо неполными.Конечно, не совсем полными. Вы зря не погуглили про "фальшивый цитрус". Это как раз хороший пример типичного качества теста. Дело в том, что цель данного теста — не проверка правильности реализации команд, а проверка работоспособности процессора.
А проверка правильности реализации команд — это чуть иной тест. Если не путаю, то у Брукса написано, что именно так процессор и разрабатывали. Писали тесты, если они не проходили — быстро делали заплату красными проводами, потом с завода приходили уже исправленные платы с обычным монтажом.
Ну и при написании эмуляторов CPU используются довольно подробные тесты.
Да, и текста книжки по вашей ссылке кстати нет, похоже.Можете заказать по МБА из публички или ленинки. Там есть главное — выходные данные.
Кстати, насколько я помню, на СМ-1600 был один тест, загружавшийся в память микрокоманд. Увы, не знаю, было ли подобное на ЕС ЭВМ. А вот книжку с текстом микрокода для СМ-2М я сам листал. Была одна веселая история с этой машиной.
Давайте начнем с простого: тесты не гарантируют отсутствия багов. Они показывают только их наличие. Надеюсь, это не нужно доказывать? В этом смысле я и имел в виду, что полноценная проверка невозможна — все равно все кейсы покрыть тестами нельзя, даже теоретически. Это не процессоров касается — это универсальный принцип.
Что же до практики, то ваш пример все упрощает. Вот смотрите, тупой код команды условного перехода S/360:
… нечто, что выставит биты CC в PSW, обычно это сравнение
BC , LABEL… переход
… условие не выполнилось
…
LABEL… условие выполнилось
…
Сколько тест кейсов вы видите в этом примере, с учетом того, что мы исходим из возможной неработоспособности любой команды? Я вижу примерно столько:
1. До команды BC в PSW был такой condition code, какой мы ожидали (в принципе, установка напрямую кажется достижима только командой LPSW, т.е. немного необычными средствами — все остальные команды выставляют биты косвенно, и как мы предполагаем, тоже могут не работать)
2. До команды BC в PSW был НЕ такой condition code, какой мы ожидали (команда сравнения не сработала).
3. Команда BC сработала как надо, в соответствии с CC и маской, произошел переход на метку LABEL.
4. Команда BC сработала как надо, в соответствии с CC и маской, НЕ произошел переход на метку LABEL.
5. Команда BC не сработала как надо, в соответствии с CC и маской, НЕ произошел переход на метку LABEL, хотя должен был.
6. Команда BC не сработала как надо, в соответствии с CC и маской, произошел переход на метку LABEL, хотя не должен был.
7. Команда BC не сработала как надо, переход произошел непонятно куда (в произвольное место памяти + смещение в регистре).
И как пить дать, это еще не все.
То есть, на мой взгляд, тут куча случаев. Даже безусловный переход производится по адресу вида базовый регистр + смещение, и может работать неправильно кучей способов: не то смещение, не тот регистр, не то значение адреса. И наконец, отсутствие перехода, хотя маска и предполагает, что он безусловный, или наоборот, переход по маске 0, которого быть не должно.
Что же до асинхронных событий, то все еще веселее. Представим, что мы хотим написать тест на известный нам баг — когда таймер генерирует лишние прерывания. Мы можем настроить таймер, и дождаться прерывания от него, но мы не можем как следует убедиться, что прерывание будет ровно одно — потому что этого теоретически нужно ждать бесконечно.
Ну т.е. мораль тут простая — я не говорю, что тесты никто не писал, и они ничего не проверяли. Я говорю, что тесты в ряде мест примитивные, а полноценно проверить процессор, работая на нем же, просто нельзя. Это слишком сложно и дорого, а местами даже теоретически невозможно. Можно и нужно проверить туже арифметику, или операции работы со строками. Память наконец.
Что же до практики, то ваш пример все упрощает. Вот смотрите, тупой код команды условного перехода S/360:
… нечто, что выставит биты CC в PSW, обычно это сравнение
BC , LABEL… переход
… условие не выполнилось
…
LABEL… условие выполнилось
…
Сколько тест кейсов вы видите в этом примере, с учетом того, что мы исходим из возможной неработоспособности любой команды? Я вижу примерно столько:
1. До команды BC в PSW был такой condition code, какой мы ожидали (в принципе, установка напрямую кажется достижима только командой LPSW, т.е. немного необычными средствами — все остальные команды выставляют биты косвенно, и как мы предполагаем, тоже могут не работать)
2. До команды BC в PSW был НЕ такой condition code, какой мы ожидали (команда сравнения не сработала).
3. Команда BC сработала как надо, в соответствии с CC и маской, произошел переход на метку LABEL.
4. Команда BC сработала как надо, в соответствии с CC и маской, НЕ произошел переход на метку LABEL.
5. Команда BC не сработала как надо, в соответствии с CC и маской, НЕ произошел переход на метку LABEL, хотя должен был.
6. Команда BC не сработала как надо, в соответствии с CC и маской, произошел переход на метку LABEL, хотя не должен был.
7. Команда BC не сработала как надо, переход произошел непонятно куда (в произвольное место памяти + смещение в регистре).
И как пить дать, это еще не все.
То есть, на мой взгляд, тут куча случаев. Даже безусловный переход производится по адресу вида базовый регистр + смещение, и может работать неправильно кучей способов: не то смещение, не тот регистр, не то значение адреса. И наконец, отсутствие перехода, хотя маска и предполагает, что он безусловный, или наоборот, переход по маске 0, которого быть не должно.
Что же до асинхронных событий, то все еще веселее. Представим, что мы хотим написать тест на известный нам баг — когда таймер генерирует лишние прерывания. Мы можем настроить таймер, и дождаться прерывания от него, но мы не можем как следует убедиться, что прерывание будет ровно одно — потому что этого теоретически нужно ждать бесконечно.
Ну т.е. мораль тут простая — я не говорю, что тесты никто не писал, и они ничего не проверяли. Я говорю, что тесты в ряде мест примитивные, а полноценно проверить процессор, работая на нем же, просто нельзя. Это слишком сложно и дорого, а местами даже теоретически невозможно. Можно и нужно проверить туже арифметику, или операции работы со строками. Память наконец.
Да, вы правы. Вы абсолютно не гарантированы от того, что вследствие квантовой флуктуации ваш стул внезапно разовьет первую космическую скорость и размажет ваше тело о потолок. Всего лишь шансы на это малы. Точнее теоретически малы. Согласно главенствующей в данный момент теории. А верная ли она — поймем, когда (и если) увидим раздавленных стулом о потолок. :-) Но, боюсь, что в ближайший миллиард лет мы таковых не увидим. :-)
Более того — механизмы дешифрации исполнительного адреса, обращения к регистрам и так далее — общие для многих команд. Фактически, если тест завелся — то больше половины процессора исправно. Поэтому тест проверяет специфические модули профессора, работающие на отдельных командах.
И назначение сдаточного теста — сказать, исправен процессор или нет. А если неисправен, то диагностика неисправного ТЭЗа идет многими методами, а не только по тесту.
Мы в linux такие вещи на своих платах регулярно контролируем, выводя на экран счетчики прерываний. Если где-то прерываний слишком много — ну значит надо с осциллографом посмотреть, что там со фронтом импульсов.
Просто не надо ЭВм тестировать как черный ящик. Она тестируется как белый или серый ящик — и сразу становится все просто.
А как на самом деле — можете почитать в errata. Ошибки в SoC есть, но их количество — примерно соответствует забытым тестам. И ошибок, которые нельзя найти тестированием — нет. В периферии, да, для тестирования нужны ещё и дополнительные схемы. А в процессоре — все тестируется изнутри.
В итоге выяснилось, что часть микросхем памяти там была нормальной, а часть — Ереванского завода (маркировка «дымок»). Ну и при интенсивном обращении к памяти срабатывало то, что отзывались эти микросхемы не совсем синхронно.
Впрочем, это общая рекомендация — заменить все микросхемы Ереванского завода. :-) Ещё полезная штука — нагреть помещение до 50-60 градусов и заменить все, что выгорит. Одна машинка (вроде электроника-60) после такого ремонта годы работала без сбоев.
Ну а теперь тезисы.
Ну и как автор мелкого эмулятора процессора одного из ПЛК добавлю, что мой эмулятор работает настолько верно, насколько полно я сделал тесты для него.
Сколько тест кейсов вы видите в этом примереПоскольку тест сдаточный, то вариантов всего два: процессор исправен и процессор неисправен. При этом, если тест показал, что процессор исправен — есть небольшие шансы, что произошла парная ошибка. «Небольшие» в данном контексте означает, что вам будет очень трудно доказать электронщикам или сервису, что проблема на их стороне.
мы исходим из возможной неработоспособности любой команды?Garbage in — garbage out. Мы какое поколение рассматриваем? Первое-второе или третье? Если первое и монтаж накруткой — то да, может отвалиться любой проводок. Если третье, то у нас 4-8 триггеров на одной микросхеме. И они или все вместе работают или нет.
Более того — механизмы дешифрации исполнительного адреса, обращения к регистрам и так далее — общие для многих команд. Фактически, если тест завелся — то больше половины процессора исправно. Поэтому тест проверяет специфические модули профессора, работающие на отдельных командах.
И назначение сдаточного теста — сказать, исправен процессор или нет. А если неисправен, то диагностика неисправного ТЭЗа идет многими методами, а не только по тесту.
тест на известный нам баг — когда таймер генерирует лишние прерывания.А это не процессор. Это контроллер прерываний. Он больше к подсистеме ввода-вывода относится. А таймер — так вообще, обычно считается периферией. Рабочие гипотезы — или импульс от таймера на прерывание слишком длинный или идет дребезг, который контроллер прерываний считает двумя импульсами.
Мы в linux такие вещи на своих платах регулярно контролируем, выводя на экран счетчики прерываний. Если где-то прерываний слишком много — ну значит надо с осциллографом посмотреть, что там со фронтом импульсов.
мы не можем как следует убедиться, что прерывание будет ровно одно — потому что этого теоретически нужно ждать бесконечно.Да ну? Все просто. Настраиваем прерывания 1 раз в мс, смотрим, что за час их 3.6 миллиона.
Просто не надо ЭВм тестировать как черный ящик. Она тестируется как белый или серый ящик — и сразу становится все просто.
полноценно проверить процессор, работая на нем же, просто нельзя.Матиндукцию в школе проходили? Из вашего утвердждения следует, что первую ЭВМ проверить было невозможно. Вторую — нельзя было проверить, потому что не проверена первая. И по матиндукции — проверенных ЭВМ нет. :-)
А как на самом деле — можете почитать в errata. Ошибки в SoC есть, но их количество — примерно соответствует забытым тестам. И ошибок, которые нельзя найти тестированием — нет. В периферии, да, для тестирования нужны ещё и дополнительные схемы. А в процессоре — все тестируется изнутри.
Память наконец.А вот память тестами не очень хорошо проверяется. Процессор — работает более-менее последовательно, а память — параллельно. Была такая машина (СМ-1420, если не путаю), которая регулярно сбоила во время сборки большой программы. Тесты памяти — на ура, тест ПДП (DMA) — изредка сбоил.
В итоге выяснилось, что часть микросхем памяти там была нормальной, а часть — Ереванского завода (маркировка «дымок»). Ну и при интенсивном обращении к памяти срабатывало то, что отзывались эти микросхемы не совсем синхронно.
Впрочем, это общая рекомендация — заменить все микросхемы Ереванского завода. :-) Ещё полезная штука — нагреть помещение до 50-60 градусов и заменить все, что выгорит. Одна машинка (вроде электроника-60) после такого ремонта годы работала без сбоев.
Ну а теперь тезисы.
- Процессоры тестируются как белый или серый ящик.
- Верификационные тесты процессоров — это совсем иное, чем сдаточные тесты. Они нужны лишь на этапе разработки процессоров (и программных эмуляторов процессоров). Тем не менее, именно эти тесты и обеспечивают соответствие процессоров (и эмуляторов) их спецификациям.
Ну и как автор мелкого эмулятора процессора одного из ПЛК добавлю, что мой эмулятор работает настолько верно, насколько полно я сделал тесты для него.
Кажется я понял, что вы хотели сказать. Тесты процессора показывают наличие ошибки, но, действительно, плохо подходят для дифференциальной диагностики. Они показывают наличие бага, а не его причины.
И прежде всего, это потому, что причины лежат в сфере напряжений и контактов. То есть помехи по питанию, плохой контакт в шлейфе — дают чудеса самого разного рода.
Ну как пример. М-6000 стала портить записи на дисках (прежде всего — портить блин с самой ОС). Для начала — усилили резервное копирование, потом начали разбираться. Выяснилось, что операция (чтение или запись) устанавливается в бите С (переполнения). А дальше идет длинная операция позиционирования головки. И если бит С за это время изменится — чтение превратится в запись.
Сделали тест, поймали ошибку на тесте.
После такой диагностики починка заняла меньше двух часов. А причина — конденсатор в цепи питания, потерявший емкость.
Так что назначение процессорных тестов — сказать, верно работает процессор или неверно. А что именно сломалось — да, это определяется не тестами.
И прежде всего, это потому, что причины лежат в сфере напряжений и контактов. То есть помехи по питанию, плохой контакт в шлейфе — дают чудеса самого разного рода.
Ну как пример. М-6000 стала портить записи на дисках (прежде всего — портить блин с самой ОС). Для начала — усилили резервное копирование, потом начали разбираться. Выяснилось, что операция (чтение или запись) устанавливается в бите С (переполнения). А дальше идет длинная операция позиционирования головки. И если бит С за это время изменится — чтение превратится в запись.
Сделали тест, поймали ошибку на тесте.
После такой диагностики починка заняла меньше двух часов. А причина — конденсатор в цепи питания, потерявший емкость.
Так что назначение процессорных тестов — сказать, верно работает процессор или неверно. А что именно сломалось — да, это определяется не тестами.
Ну вот вам к примеру "ГОСТ 16325-88 Машины вычислительные электронные цифровые общего назначения. Общие технические требования " Гляньте пункты 1.5 и 7.6. Но это я так, просто бегло погуглил.
Очень приятная статья. Ламповая такая.
Спасибо!
Спасибо!
Транзистор внутри напоминает наши серии МПхх. Интересно, наши их копировали или «музыкой навеяло»?
МП красивше. Или фото не очень.
Внутри неисправного германиевого транзистора IBM 083В исходной статье не указано, как удалось найти подходящий для замены? А если не удалось, то чем заменили? Ведь германиевые транзисторы практически не производятся, а уж конкретный тип, я уверен, не найти наверняка.
Сдернули с другой, может даже не рабочей, платы.
Наверняка, методом выпаивания из другой железяки. Вот, например, видео о восстановлении телетайпа модели 19: www.youtube.com/watch?v=-LD872EWKaE (одно из; как раз про визит к товарищу, у которого запчасти есть).
К слову, очень рекомендую посмотреть канал Mark Curious Verdiell, упоминаемого в статье. Экстремально лампово!
Очень интересная статья! Хоть практической пользы от нее сейчас нет, это как метко сказали в комментах, прикладная некроманития. Но процесс захватывающий! Найти поломку вплоть до отдельной детали!
А сейчас как принтера чинят? Перезагрузи принтер, перезагрузи комп, обнови драйвера, выкини принтер поставь новый.
А сейчас как принтера чинят? Перезагрузи принтер, перезагрузи комп, обнови драйвера, выкини принтер поставь новый.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ремонт принтера от мейнфрейма IBM 1401 эпохи 60-х