Привет. Сегодня я хочу поговорить с вами о тестировании железа — с болезненными примерами и фотографиями из обыденной практики. Эту суровую реальность с пайкой, дебагом и сожженными чипами обычно все беспощадно лакируют, рассказывая только об успехах — ответственные за пиар и маркетинг люди обычно как огня боятся любых упоминаний об ошибках и сбоях. Но инженеры понимают, что сложные комплексы сразу безупречными не рождаются, поэтому мы не боимся рассказать вам про тестирование как есть. Ну и поделиться опытом, что делать, а чего избегать.
Предварительная подготовка
— Everyone please observe the fasten seat belt and no smoking signs have been turned on. Sit back and enjoy your ride.
Итак, по порядку.
Тестирование осуществляется на всех стадиях жизни аппаратуры. Тестирование бывает первоначальное (bringup), компонентное, функциональное, нагрузочное, производственное, и даже тестирование на заказчиках.
Еще на стадии разработки аппаратуры инженер думает о том, как он будет оживлять свое детище. Платы обсыпаются контрольными точками, отладочными коннекторами, перемычками, посадочными местами для запасных компонентов и прочим подобным. Совокупность возможностей для тестирования, заложенных в аппаратуру, называется DFT (Design for Testability). Плата, выпущенная в DFT фазе, может содержать в два раза больше компонентов, чем плата, вышедшая в тираж. Естественно, следуя принципу «работает – не трогай», потом ее никто не переделывает, и конечный потребитель недоуменно рассматривает пустующие посадочные места на материнской плате из магазина, придумывая различные конспирологические теории по поводу их предназначения.
Итак, нам произвели наш борд – что делать дальше? Ну конечно же – воткнуть в розетку и выпустить из него весь белый дым.
— Everybody falls the first time.
Фотка из интернета, у нас жжёных плат не нашлось, но каюсь – иногда так и делается. На моей памяти есть давняя история, когда любопытный системный архитектор сидел и подбирал наугад в какие разъёмы нужно воткнуть фазу, нейтраль и землю (ну вот не было у него времени заглянуть в схему), а рядом сидел разработчик и ловил бледного.
Но обычно всё происходит по-другому. Первая фаза тестирования – bringup (в народе «оживляш»).
Оживление Рождение
— Wake up, Neo...
Для bringup обычно изготавливается 3—5 образцов (в расчете на то, что как минимум два будут уничтожены в бреду дебага). Если в составе устройства есть дорогие чипы — на один из образцов они не устанавливаются. Фаб может предложить вам сэкономить на золоте — НИ В КОЕМ СЛУЧАЕ НЕ СОГЛАШАЙТЕСЬ (ну просто паять придется много и часто).
Плата без чипа — это первый кандидат на убой. На ней проверяются последовательность включения питания, сбросы, номиналы напряжений и прочее подобное. Потом такая плата является донором органов и/или полигоном для проверки всяческих гипотез. Также перед тем как что-то включать, нужно обязательно:
- прозвонить землю-питание, там частенько есть КЗ;
- визуально осмотреть плату – там запросто бывает перепутана полярность конденсаторов, чипы стоят вверх ногами, присутствует стружка, с лёгкостью можно найти пассивные компоненты, которые оторвали;
- отдельно изучить – а не поставили ли вам на плату компоненты, которые вы просили не ставить (лайфхак: не делайте черную маску на первых сэмплах – на ней не видно установлены или нет чип-резисторы).
Наигрались с первой жертвой – идем пускать дым из боевой платы. При этом необходимо запастись пилотом с кнопкой отрубания питания и тепловизором. Пилот надо поставить под ногу, на случай если по рукам будет бить 220 В (ну или просто руки будут заняты), а в тепловизор можно увидеть КЗ.
Но вообще при самом первом включении обычно можно не бояться — оно скорее всего не включится, так как вы наверняка забыли перепаять компоненты, у которых в дизайне перепутаны ноги:
И еще припаять немножко проводов:
Термоклей — наше все, лучший друг разработчика, почти как скотч в обычной жизни.
Сразу после Дремеля:
И молотка, которым приходится забивать бонки в плату, — не всегда выходит аккуратно.
Иногда приходится делать пациенту рентген или томографию. Выглядит это так:
Отсканировать плёнку, оказывается, не очень просто. Сняли телефоном на просвет напротив окна.
Конкретно на этом снимке не видно ничего — не вглядывайтесь. Но вообще на рентгене можно увидеть непропай, трещины и прочее подобное.
Отдельно стоит сказать про bringup материнских плат, потому что делается он по-другому. DFT сэмплов матерей обычно заказывается много – порядка 20 штук. Стоит это дорого, поэтому тут своя стратегия.
Берутся разработчики и отправляются на фабрику. Собирается порядка 5 плат и конвейер останавливается. Далее у разработчиков есть порядка 30 минут, чтобы плату включить (для x86-систем критерий успеха — загрузить BIOS). Если всем повезло — собираются остальные образцы. Если нет — производство отменяется, а разработчики едут домой думать. Деньги затраченные на PCB — потеряны, зато компоненты ждут на складе следующей попытки.
Хорошо — мы запустили нашу плату, и даже запустили другие, которые должны работать вместе с ней. Что дальше? Собираем стенд.
И тут вы, наверное, ожидаете увидеть такое?
Это все показуха для замминистров. Настоящий стенд должен быть собран из палок и желудей, и выглядит так:
— I didn't say it would be easy, Neo. I just said it would be the truth.
(стакан для противовеса, фломастер — чтоб радиатор внатяг сидел — оно там проводом примотано)
Или так:
В лабораторию набивается вот такая орда:
И все начинают наперегонки зашивать свои прошивки, программки, и тыкать везде осциллографом.
Иногда процессе то и дело раздается вежливая просьба «Дорогой коллега, пожалуйста, уберите паяльник от моей руки — уж очень горячо» или «Будьте так добры — больше не включайте источник питания, когда я привинчиваю плату к шасси».
Питерский офис очень на нас влияет. Как гласит наш веб-сайт:
В нашем конкретном случае основная цель проверки совместной работы нескольких устройств — узнать, работает ли PCI Express, соответствует ли он стандарту. Просто без всего остального в принципе можно жить. Обычно функционал, закладываемый в железку, избыточен. Тонны GPIO выводов, I2C/SPI шин, термодатчиков, ледов и прочего, как правило, остаются невостребованными, так как их отладку откладывают на последний момент, который никогда не наступает.
Естественно, у нас нет на каждый случай жизни измерительной аппаратуры за несколько миллионов рублей — это для слабаков. Нам на помощь спешит тестовое ПО от производителей компонентов. Практически все современные чипы с высокоскоростными интерфейсами имеют внутри цифровой осциллограф. К нему полагается специализированное ПО, позволяющее считать его показания. Запускаем и смотрим глазковые диаграммы. Видим такое:
Иногда видим опасный прищур:
А иногда ловим кальмаров:
Кальмары — самые опасные. Это нелинейные искажения, и встроенные эквалайзеры с таким бороться особо не умеют. Кальмары означают, что где-то в канале связи есть что-то очень плохое — слишком длинное переходное отверстие, существенный перепад импеданса, попадание какой-то неравномерности в 1/4 или 1/2 длины волны каких-то гармоник в полезной полосе и прочее подобное.
Кто-то, возможно, заметит, что кальмар немного похож на то, что делает с принятым сигналом DFE в эквалайзере приемника PCIe. Но в данном случае это таки кальмар, а не результат работы DFE (просто результат работы DFE используемое нами ПО отображать не умеет).
Отдельно надо сказать про тестовый софт, который тоже бывает крайне коварным. Например для снимания глазковых диаграмм мы используем две версии одной и той же программы — одна версия рисует картинки, но не пишет значения раскрыва глаза, вторая — наоборот.
Ну и да — если вы планируете снимать глаза по интерфейсу I2C — забудьте, это будет очень очень очень медленно. Только in-band. Проблема в том, что для съема in-band у Вашего устройства должен быть рабочий PCIe линк с компьютером, где работает тестовое ПО, что весьма проблематично когда Ваша железка не устанавливается в стандартный PCIe слот. И что самое забавное — у Вас уже должен быть хоть как-то работающий линк на том канале, который вы отлаживаете, причем именно в том режиме (gen2/3) в котором вам нужно (ибо в разных режимах разные глаза и по разному работают эквалайзеры). Нет ножек, нет мультиков линка, нет глаз — вот как хотите, так и выкручивайтесь.
Про то, как выкручиваться с PCIe — я ранее написал отдельную статью.
Вообще, при разработке сервера, конечно, очень важна поддержка со стороны производителей используемых компонентов, поскольку сегодня сложность даже относительно простых чипов такова, что без использования встроенных в них тестовых вещей полноценно проверить и отладить систему вряд ли получится. Тактовые генераторы, регуляторы напряжений, сетевые контроллеры, коммутаторы PCI Express, редрайверы – все это имеет встроенные средства для настройки, диагностики, и нуждается в определенном наборе программ и кабелей для подключения для полноценной настройки и тестирования, без использования которых разработка становится просто невозможной.
В процессе проведения проверок иногда выясняется, что где-то что-то идет не так. И тогда начинается увлекательный процесс локализации ошибки, чтобы ее можно было исправить в следующей ревизии. И хорошо если это «не так» стабильно повторяется – тогда выяснить, что именно является причиной ошибки, как правило, не составляет труда. Но иногда все гораздо хуже. Например, на некоторых экземплярах плат при длительном прогоне тестов возникают одиночные некорректируемые ошибки на шине (которых быть не должно совсем). И вот здесь зачастую уже приходится применять метод «пристального взгляда» — то есть просто сидеть, гипотетически глядя на схему предполагать, что именно может быть причиной, пробовать эту гипотетическую причину устранить в схеме, и тестами уже проверить – угадали мы или нет.
Мы с подобным сталкивались несколько лет назад, когда тесты NVIDIA (да, многие производители предоставляют специфические наборы тестов, которые позволяют проверить вещи, недоступные программным путем при использовании стандартных утилит) давали редкие одиночные ошибки при длительных (сутки и более) прогонах на некоторых экземплярах плат. Тогда все дело оказалось в неудачной трассировке референсного клока (100 MHz) — хотя прежде чем мы к этому пришли, проверено было много всего, начиная от качества питания и заканчивая глазковыми диаграммами по всем линиям.
И кстати, это хорошо. Самый большой кошмар разработчика — когда все работает сразу. Это значит только одно — где-то закопана мина, которая сработает после отгрузки 100500 единиц оборудования заказчику. Дело в том, что в процессе поиска причины какой-то глобальной проблемы осуществляется проверка нескольких гипотез и как правило выявляется множество мелких неисправностей, никак с возникшей проблемой не связанных. Нет большой проблемы — не найдёте маленьких. Их за вас найдут ваши заказчики.
Проверка по списку
— All I do is what he tells me to do.
После завершения компонентных тестов начинается функциональное тестирование – проверка работоспособности комплекса в целом и корректной работы всех заложенных функций. Обычно этим занимается QA. Простор для творчества здесь, конечно, весьма обширный, но в целом основной упор делается на корректную работу системы при проигрывании стандартных сценариев использования. Здесь обнаруженные ошибки могут уже иметь как аппаратную, так и программную природу, поэтому в первую очередь важно выяснить, что именно вызвало ошибку. Зачастую первые предположения могут быть обманчивыми, то есть явно аппаратная на первый взгляд проблема может быть вызвана некорректной работой встроенного ПО. Значительную часть в функциональном тестировании занимает проверка того, как система отрабатывает разнообразные ошибки, которые могут возникать в процессе работы. Современные отладочные средства позволяют осуществлять искусственную инжекцию ошибок в стандартные интерфейсы процессоров, потому что на уровне железа многие из них создать специально достаточно проблематично (ну не отрывать же на лету чипы памяти или замыкать линии шины PCI Express).
А… я же не сказал, что функциональное тестирование не означает собранную готовую к бою систему. Тут тоже бывает не все гладко. В какой-то момент оказалось что у нас нет в запасе OcuLink кабелей нужной длины, и у сервера появились кишки.
И почему-то вот в такой вот конфигурации при нагрузочном тесте все начало перегреваться. До сих гадаем — почему. Кабели грелись, наверное.
А два арбуза в каждой руке унести сможешь?
— You're faster than this. Don't think you are, know you are…
В какой-то момент параллельно с функциональным тестированием начинается тестирование нагрузочное — важно убедиться, что сервер продолжает корректно функционировать в предельных режимах работы. Причем нагрузочные тесты проводятся как применительно к отдельным подсистемам (диски, память, процессоры, ввод-вывод), так и на всей системе в целом. Как правило локализованные тесты позволяют сильнее нагрузить один конкретный модуль, чем это можно сделать при максимальной нагрузке на всю систему.
Кроме того, здесь помогают отладочные средства от производителя аппаратной платформы (например, Hardware Tests Executive от IBM). Таким образом можно загнать процессор в совсем предельные режимы, принципиально недостижимые при работе реальных приложений. Основные проблемы, выявляемые при нагрузочном тестировании – перегрев, нестабильность питания или перегрузка по максимальному току, ошибки при активной работе с интерфейсами ввода-вывода.
Также на помощь приходят бенчмарки. Потому что когда реальные значение бенчмарков сильно отличаются от прогнозируемых — значит что-то пошло не так. Хороший повод пойти потыкать плату палочкой.
На стадии тестирования мы используем в основном микробенчмарки:
Для процессоров это обычно однопоточные нагрузки, типа spec2006 (сейчас уже speccpu2017), parsec, но вообще их огромное количество от сборки ядра linux и компрессии (lzma, gzip), до перемножения матриц и вычисления быстрого преобразования Фурье (fftw).
Для памяти много лет ничего не меняется: STREAM, RAMspeed SMP, lmbench.
Для дисков: fio, iozone.
При успешном прохождении всех функциональных и нагрузочных тестов остаются еще ряд вещей, требующих проверки – стабильность работы во всем диапазоне температур, стойкость к вибрации, проверка совместимости с определенным набором стандартных компонентов (память, диски, PCI Express контроллеры).
P.S.: После того как мы на функциональных тестах первой ревизии сервера все проверили и обрадовались, у нас в лаборатории внезапно обвалилось три сервера. Мы начали проверять питание и на линии 1.2В (питание шины PCIe процессоров) увидели вот такое:
Акцентирую ваше внимание — одна клетка 500mV. Номинал 1.2В. Резистором ошиблись в цепи компенсации одного из VRM. Вот с таким вот питанием были успешно пройдены все нагрузочные тесты, бенчмарки, прожарки и прочее подобное, и дизайн радостно поехал на вторую ревизию.
Так что, когда на Вашем уютном домашнем компьютере именитого бренда внезапно появляется экран смерти — не стоит думать, что это непременно «глючит винда».
Автор: asmolenskiy
