Принципы самотестирования

[levon]

Вот тема, в которой можно обсудить внутреннее устройство и методы диагностирования/самодиагностирования, примененные в машинах VAX

[Dale]

levon, прежде всего, нужно учитывать, что VAX-11 - это супермини-ЭВМ, а не настольная персоналка. Процессор занимал отдельную стойку и был выполнен на нескольких печатных платах довольно большого формата. Соответственно, делался он не на базе микропроцессора, а из большого количества микросхем, хотя многие из них и высокой степени интеграции. Поэтому разработчики не былы ограничены архитектурой серийных микропроцессоров, а обладали полной свободой действий. Поэтому далеко не все из их идей можно будет непосредственно применить в разработках на интегральных микроконтроллерах вроде Atmel.

Во-первых, в процессоре VAX-11 имелся отдельный блок консольно-диагностического процессора (КДП). Он был сделан на базе МП Intel8085. Его задачей, как видно из названия, было:

• минимальная диагностика ЦП после включения;
• загрузка памяти микропрограмм (VAX-11 был микропрограммируемым, поэтому в принципе систему команд можно было бы изменить, если бы кто-то придумал вариант получше; кроме того, пользователь мог определить до трех собственных инструкций процессора и использовать их в своих программах);
• инициализация и запуск ЦП.

Если ЦП успешно запустился, КДП переходит в режим обслуживания консольного терминала. Он принимает команды оператора, выдает на экран консоли ответы системы, обеспечивает доступ к накопителю на кассетной магнитной ленте или флоппи-диске, а также позволяет в любой момент остановить ЦП, посмотреть/изменить содержимое ячеек ОЗУ и т.п.

[levon]

Dale, кое-что по vax я почитал и примерно прикинул, что это такое. Более конкретно сформулирую вопрос. Есть у меня система, в которой устройства сделаны на однокристаллках обычных. Тот же атмел. И систему эту приходится делать дублированной полностью, потому что интенсивность отказов высокая, в том числе и доля отказов ПО есть. А с vax я хочу посмотреть, подойдет ли, может, какой-нибудь алгоритм тестирования (начального или циклического), чтобы получше работало все. Так яснее или нет?

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

[Dale]

(продолжение)

Если запустить ЦП по какой-то причине не удается, нужно переходить к полной диагностике. Для этого вместо дискеты или касссеты с микропрограммами системы команд устанавливается специальный диагностический носитель.

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

Начинается все с минимального самотестирования КДП. Проверяется контрольная сумма ПЗУ, затем выполняется тест ОЗУ. Сам микропроцессор серьезному тестированию не подвергается.

Затем производится тщательное тестирование памяти микропрограмм, к которой у КДП есть непосредственный доступ.

Следом тестируется секвенсор, который интерпретирует микрокоманды. При этом используется некоторая аппаратная избыточность. Например, некоторые регистры выполнены сдвиговыми. Поэтому КДП может загрузить и прочитать их в последовательном режиме побитно, сдвигая после чтения каждого бита. Это довольно серьезно снижает количество проводов между КДП и ЦП, поскольку многие регистры имеют большую разрядность: 32, 48, 64. Последовательный доступ позволяет уменьшить число проводов до 3: вход, выход, сдвиг.

[levon]

А более конкретно, то есть, каким образом минимальное ядро тестировалось, и как сами тесты строились, вы не знаете?

Такой способ "расширения круга" я уже где-то встречал, и причем журналы это были где 2000-2001 года. В АиТ, вроде. А придумали это, видимо, задолго.

[Dale]

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

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

Сначала КДП загоняет в них тестовые последовательности: все 0, все 1, шахматный код, бегущий 0, бегущая 1. Тем самым убеждаемся, что все триггеры регистра исправны и нет замыканий между отдельными разрядами.

[Dale]

Кстати, я пока рассказываю обзорно, в общих чертах. Если интересуют какие-то детали, спрашивайте по ходу, я уточню.

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

[Dale]

Затем проверяется работа секвенсора в целом.

В уже проверенную память микропрограмм загружается тестовое микрослово, затем КДП генерирует для секвенсора единственный такт и убеждается, что это самое слово попало по назначению (помним, что регистры секвенсора мы можем загружать и читать через сдвиг).

Проверяется также механизм ветвлений, для этого подгружается микрокод с ветвлением, КДП генерирует такт, после чего проверяет содержимое регистра микроадреса.

[levon]

А какие еще регистры проверяются первым шагом? То есть, мы обеспечиваем этими регистрами себе, скажем так, центр, от которого потом распространяется тестирование?


И, видимо, каждый отдельно проверяется в какой-то последовательности, а есть ли какие-то приоритеты? То есть один регистр важней, и его мы проверим раньше, а потом другой?

(продолжение)

сначала проверяется минимальное ядро,

А что там тогда являлось этим ядром?

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

[Dale]

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

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

Как я уже перечислил, сначала тестируются: микропрограммная память, регистр микрокоманды, счетчик микроадреса, логика ветвлений. Это минимальное ядро, которое тестируется непосредственно КДП.

Если эти тесты успешно прошли, начинается второй этап тестирования, уже косвенный. Начальные тесты выполнялись в кодах КДП (т.е. Intel8085), последующие написаны на языке микроассемблера.

[Dale]

и видимо каждый отдельно проверяется в какой-то последовательности, а есть ли какие-то приоритеты? то есть один регистр важней и его мы проверим раньше, а потом другой?

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

[levon]

Найти такую документацию сейчас, наверное, почти невозможно?

Чтобы сами тесты разобрать подробно

[Dale]

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

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

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

[levon]

а сам микропроцессор в кдп не тестируется толком, да?

[Dale]

найти такую документацию сейчас наверно почти невозможно?

чтобы сами тесты разобрать подробно

Думаю, что весьма проблемно. А главное - зачем?

Чтобы действительно понять, как работают тесты, нужно достаточно досконально изучить архитектуру и схемотехнику VAX-11, а они непросты даже по нынешним меркам. Современные микропроцессоры для десктопов по части производительности гораздо мощнее, конечно, но исключительно за счет технологии - рост тактовой частоты, увеличение числа ядер. Метод грубой силы, короче. Опять же, примерно 99% тестов написаны на микроассемблере. Учить микроассемблер ныне мертвой машины - вряд ли рациональное приложение усилий.

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

[levon]

Молча соглашусь)
Тогда идею минимального ядра я, наверное, понял. Дальше идем?

А в современных контроллерах есть тот же секвенсор?

[Dale]

а сам микропроцессор в кдп не тестируется толком, да?

Сам микропроцессор проверяется типовым тестом, традиционным для закрытых архитектур без специальных средств диагностики. Что-то наподобие классического "упражнителя команд", которые испокон веков применялись для машин попроще. Ну и, само собой, быстрое тестирование ПЗУ вычислением CRC-32 и довольно тщательный тест ОЗУ (его там было всего 16 Кбайт, поэтому можно было себе позволить полный тест). А затем обычная раскрутка. Если не изменяет память, сначала тестируются безусловные ветвления, условные ветвления, затем пересылки, логические операции, арифметические...

Хотя, конечно, на самом деле все это с некоторой натяжкой. Например, как проверить контрольную сумму ПЗУ или протестировать ОЗУ еще не протестированным процессором? А как тестировать процессор посредством теста, загруженного в еще не протестированное ОЗУ? Обязательно возникает проблема курицы и яйца.

[Dale]

а в современных контроллерах есть тот же секвенсор?

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

Он не доступен ни программно, ни даже аппаратно через тот же JTAG.

[levon]

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

[Dale]

Вот один из примеров косвенного тестирования.

Имея исправный секвенсор, подгружаем в него микрокод для тестирования файла регистров общего назначения.

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

А теперь, полагая оттестированные РОН исправными, можно проверить работу АЛУ. Например, операцию сложения. Загружаем в пару регистров тестовые данные, заносим код операции сложения в поле управления АЛУ микрокоманды, сохраняем результат в РОН, который мы уже можем читать через проверенные на предыдущих этапах блоки.

[Dale]

про контрольные суммы понятно, а вот где можно прочитать про "безусловные ветвления, условные ветвления, затем пересылки, логические операции, арифметические..."? или как с ними разобраться?

Давайте по порядку.

Очевидно, что в процессе тестирования нам понадобится сравнивать действительный результат с желаемым. Значит, в первую очередь нам нужны операции сравнения и ветвления.

Сначала договоримся, что мы делаем в случае провала теста. Я предлагаю использовать команду-ловушку остановки процессора. Например, МК Atmel можно загнать в спящий режим, из которого он уже не выйдет.

Начнем с безусловных переходов. Проверяем относительный переход (пример на псевдокоде):

Код:

начало_теста:
        относительный_переход следующий_тест
        команда-ловушка
следующий_тест:
        ...

Для большей уверенности можно проверить переход на бОльшее расстояние:

Код:

начало_теста:
        относительный_переход следующий_тест
        команда-ловушка
        ...
        команда-ловушка
следующий_тест:
        ...

а также переходы назад.

Затем аналогично проверяем условные переходы, причем два варианта: наличие перехода, когда условие перехода выполнено; отсутствие перехода, когда условие не выполнено.

После этого проверяем команду сравнения. Сравниваем любой РОН с самим собой и пропускаем ловушку по равенству. Затем сравниваем этот же РОН с заведомо неравной ему константой и пропускаем ловушку по неравенству.

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

[levon]

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

[Dale]

как понять - пропускаем ловушку по равенству?

Попробую детальнее.

Задача: удостовериться, что команда сравнения работает, поскольку для остальных тестов нам потребуется сравнивать полученный результат с ожидаемым значением и на основании результата сравнения делать вывод об успешности теста.

Предлагаемое решение:

• 1. Удостовериться, что условные переходы по равенству или неравенству (в большинстве известных мне процессоров - флаг нуля Z) работают;
• 2. Загрузить в регистр (допустим, R16 для Atmel) константу 0;
• 3. Убедиться, что 0 == 0;
• 4. Убедиться, что 0 != 0xFF.

Предлагаемая реализация на псевдокоде:

Код:

начало_теста_операции_сравнения:
        сбросить_флаг_Z
        переход_по_неравенству М1
        команда_ловушка   ; переход по неравенству не работает
М1:     установить_флаг_Z
        переход_по_равенству   М2
        команда_ловушка   ; переход по равенству не работает
М2:     ; считаем, что переходам по равенству и неравенству можно доверять
        очистить регистр
        сравнить регистр, 0
        переход_по_равенству М3
        команда_ловушка   ; сравнение 0 и 0 дало неверный результат: 0 != 0
М3:     сравнить регистр, 0xFF
        переход_по_неравенству конец_теста_операции_сравнения
        команда_ловушка   ; сравнение 0 и 0xFF дало неверный результат: 0 == 0xFF 
конец_теста_операции_сравнения:
        ...

Итак, мы проверили, что:

• 1. Условные переходы по равенству/неравенству корректно работают для обоих возможных состояний флага Z;
• 2. Команда сравнения корректно устанавливает флаг Z как в случае равенства перандов, так и в случае их неравенства.

С этого момента минимальное ядро тестирования пополнилось операцией сравнения. Теперь мы можем писать дальнейшие тесты по схеме:

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

Если идея понятна, то перейти от псевдокода к реальным командам проверяемой системы не составит труда. Примерно по такой схеме тестировались процессоры семейств, с которыми мне доводилось иметь дело: VAX-11, PDP-11, IBM/360, IBM/370... Мнемоники команд ассемблера, конечно, у них разные, но суть примерно одинакова: в каждом тесте использовать только те узлы и команды, которые были проверены на предыдущих этапах тестирования.

[Sla]

Dale,
Извини, не понял, а зачем это?

4. Убедиться, что 0 != 0xFF.

Если говорить о "полноте" теста
то неплохо бы прогнать и бегущую единицу и бегущий ноль

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

1. Иметь приемочные тесты
2. Иметь специальный тестовый цикл, в который контроллер входит в ручном режиме.

Но!!!
например. На 51 серии МК  вся система команд занята.
И теперь представим,  что произойдет в случае сбоя счетчика команд, те. система уходит на самотестирование и при этом теряет контроль над объектом. Хорошо если такая система контроля не стоит (не стояла) в аппаратуре СШГЭС.

[Dale]

Dale,
Извини, не понял, а зачем это?

4. Убедиться, что 0 != 0xFF.

Это проверка, что при сравнении на неравенство: 1) правильно устанавливается (точнее, не устанавливается) флаг нуля; 2) правильно производится условный переход. Очень грубая проверка работоспособности операции сравнения. Если даже она не проходит, пытаться тестировать дальше просто бессмысленно.

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

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

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

[levon]

добрый вечер. про равенства/неравенства я даже понял! так что, если можно, то перейдем к "более ненадежным" элементам.

[Dale]

добрый вечер. про равенства/неравенства я даже понял! так что, если можно, то перейдем к "более ненадежным" элементам.

Следует полагать, по предыдущему материалу вопросов не осталось, все понятно хотя бы в общих чертах?

ОК. Теперь мы предполагаем, что ядро микроконтроллера (по крайней мере, его вычислительная часть) исправно и пригодно для того, чтобы тестировать периферийную часть.

Прежде всего займемся портами вывода. Убедимся, что: 1) все выходные буферы исправны; 2) отсутствуют внешние по отношению к микроконтроллеру дефекты (замыкания дорожек, постоянный высокий или низкий потенциал на входах микросхем, подключенных к МК, и т.д.).

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

Например, мы хотим проверить 8-разрядный порт, работающий как выходной. Добавляем в конструкцию мультиплексор 8х1, выделяем среди портов МК дополнительно 1 бит на ввод (к нему подключаем выход мультиплексора) и 3 бита на вывод для выбора проверяемого бита (их подключаем к адресным входам мультиплексора). Входы мультиплексора подключаем к выходам тестируемого порта. Теперь у нас есть все необходимое для того, чтобы проверить порт в реальных условиях.

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

Сразу оговорюсь, что тут мы обсуждаем общий подход, без деталей. В конкретных случаях особенности конструкции могут позволить нам выполнить проверку более экономными средствами. Например, в МК AVR для портов ввода/вывода имеются регистры PIN, которые позволяют напрямую считывать состояние выводов МК. В этом случае от мультиплексора можно отказаться. В других МК таких средств может не оказаться, придется добавлять дополнительные компоненты.

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

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

P.S. Мне кажется, мы уже выходим за рамки обсуждения устройства VAX и начинаем обсуждать общие методики самотестирования аппаратуры. Название темы может вводить читателей в заблуждение. Может, имеет смысл переименовать тему или начать новую?

[Sla]

Может, имеет смысл переименовать тему или начать новую?

Конечно переименовать
VAX использовать как пример.

levon,

про равенства/неравенства я даже понял!

Вопрос к лектору Dale был задан не для себя, а для других.

[levon]

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

Dale, создать новую тему? Раз уж из vax мне не выжать. Или как?



То есть самотестирование аппаратуры мне и нужно, но, видимо, начать нужно было не c vax, а вообще. Хотя тогда я бы Вас не нашел.
Ну что, создавать?

[Sla]

levon, не создавай,
просто зайди в первый пост твой и измени название

например, Принципы самотестирования