CC BY
557
МЕТОДИКА ТЕСТИРОВАНИЯ МИКРОСХЕМ ДЛЯ КОМПЬЮТЕРОВ
СЕРИИ «БАГЕТ»
С.Г. Бобков, к.т.н. (Москва)
Создание тестового программного обеспечения (ПО) - одна из основных задач в процессе проектирования микросхем. С ростом объема микросхемы трудоемкость разработки тестового ПО растет существенно быстрее трудоемкости разработки аппаратной части, где зависимость близка к линейной при хорошо структурированном проекте, и особенно высока для сложнофункциональных микросхем. Трудоемкость создания тестового ПО для таких микросхем может превышать трудоемкость всей аппаратной разработки. При создании 64-разрядного суперскалярного микропроцессора 1890ВМ5Ф трудоемкость создания тестового ПО превысила в 1,5 раза трудоемкость разработки аппаратной части, несмотря на то что с аппаратной точки зрения проект микропроцессора достаточно сложный. В данном микропроцессоре целый ряд узлов создавался по методике заказного проектирования (суммарный объем заказных узлов составил около 300 тысяч транзисторов), использовалась динамическая логика, разрабатывались специальные библиотечные элементы, а общий объем микропроцессора составил 26,6 млн. транзисторов. Разработанный маршрут создания тестового ПО опробован при проектировании более 20 микросхем серии 1890 и является частью общего маршрута проектирования микросхем данной серии, однако данный маршрут универсален и может использоваться для проектирования других микросхем. Тестовое ПО в данном маршруте должно разрабатываться независимыми коллективами разработчиков. Опыт разработки показал, что менее квалифицированный разработчик, пишущий независимые тесты, может найти больше ошибок, чем более квалифицированный разработчик, разработавший соответствующий аппаратный узел. Современные цифровые микросхемы имеют сотни и тысячи регистров, число состояний и условий функционирования таково, что полное тестирование требует многолетней работы высокопроизводительной аппаратуры. Именно поэтому в настоящее время избежать ошибок очень сложно. Так, по данным компании Intel, микропроцессор PENTIUM 4 на апрель 2005 г. имеет 100 ошибок и несоответствий в документации, из них не исправлено 49, не будут исправляться 40, не известны пути обхода 22. Выделение области применения позволяет сократить число возможных состояний микросхем и максимально полно их протестировать. Другой путь к снижению ошибок - создание минимально возможной функциональности аппаратуры и операционной системы (ОС), достаточной для реализации и функционирования сервисов безопасности, позволяющей наиболее полно провести всестороннее тестирование и обеспечить возможность неформального доказательства корректности функционирования.
Тесты, необходимые для разработки микросхемы, можно разбить на 4 группы: тесты функцио-
нального контроля, сертификационные тесты, тесты для отбраковки кристаллов и микросхем и тесты для испытаний и периодического контроля. Наиболее сложными являются тесты функционального контроля, в них должны быть предусмотрены автоматический контроль выполнения тестов с записью полного состояния микросхемы в случае сбоя, возможность пошагового выполнения тестов, выдача (сохранение на диске) состояний микросхемы в запрашиваемые моменты времени. В разработанном маршруте должны быть созданы следующие тесты функционального контроля.
1. Архитектурные тесты, то есть тесты, проверяющие соответствие модели разрабатываемой архитектуре.
2. Тесты всех отдельных функциональных узлов, позволяющие хотя бы один раз изменить состояние каждого разряда регистра или ячейки памяти с единицы на ноль и наоборот и выполнить соответствующую функцию. Например, для памяти должны быть тесты бегущая единица, когда во всю память записываются нули и затем побитно записывается и считывается единица, бегущий ноль (обратный тест), шахматный код (чередуются единицы и нули) и пр. Эти тесты достаточно хорошо проверяют функционирование узла, но они не проверяют взаимодействие узлов между собой. Для эффективного выполнения этой группы тестов необходимо иметь достаточно мелкое разбиение проекта на функциональные узлы. Если число состояний требует слишком длительного тестирования, узел должен быть разбит на более мелкие части. Например, если тестирование АЛУ (арифметико-логического устройства) требует времени больше отведенного, должны тестироваться отдельно сумматор, умножитель и т.д.
3. Тесты взаимодействия узлов. Должны быть протестированы соседние функциональные узлы. Если устройство сложное, должно быть создано несколько иерархий взаимодействия узлов. Число иерархий и разбиение на узлы должно определяться отведенным временем тестирования.
4. Тестирование устройства в целом. Должны быть созданы тесты, проверяющие взаимодействие всех узлов модели и функционирование микросхемы в целом.
5. Тесты взаимодействия модели микросхемы с внешними устройствами. Должна быть протестирована работа микросхемы с микросхемами окружения и внешними устройствами. Для возможности данного тестирования должны быть соответствующие модели окружения, часть поведенческих моделей представляют компании, производящие микросхемы или внешние устройства. Например, практически все компании, производящие микросхемы памяти, представляют модели на своих сайтах в Интернете.
6. Соответствие логической модели поведение-
ской. Результаты (состояния регистров) тестирования поведенческой модели и модели уровня RTL должны совпасть.
7. Случайные тесты. Должен быть создан генератор случайных инструкций, случайным образом генерирующий последовательность разрешенных инструкций, которые поступают на тестируемое устройство и выполняются им. Этот вид теста показал очень высокую эффективность для сложнофункцио-нальных микросхем, таких как микропроцессор 1890ВМ5Ф. После прохождения всех предыдущих тестов в данном микропроцессоре случайные тесты продолжали выявлять ошибки в логической модели. Тест можно одновременно запускать на десятках и сотнях компьютеров и тем самым многократно ускорять процесс тестирования (для тестирования 1890ВМ5Ф использовался 64-процессорный кластер и несколько десятков отдельных персональных компьютеров, то есть достигнуто стократное ускорение тестирования).
8. Тестирование на аппаратном ускорителе. Это удобный инструмент для отладки логической модели с развитыми средствами диагностики, визуализации, поиска ошибок. Однако не всегда удается протестировать модель микросхемы с полным ее окружением из-за отсутствия полноценных моделей окружения. Для снижения стоимости разработки в силу ограниченности ресурсов в маршруте тестирования микросхем серии 1890 данное тестирование используется только для микропроцессоров и контроллеров объемом свыше 1 млн. транзисторов. Опыт разработки показал, что этот вид тестирования может рассматриваться как дополнительный, все ошибки, выявляемые данным инструментом, как правило, выявляются другими средствами. Однако ускорители позволяют иногда в несколько раз сократить время выявления некоторых ошибок.
9. Загрузка на моделях микросхем ОС типа Unix и ОС реального времени для микропроцессоров или соответствующих драйверов для контроллеров. Выполнение прикладных задач. Процесс загрузки ОС на логической модели, выполняемый самыми высокопроизводительными компьютерами, может составлять от нескольких дней до нескольких недель в зависимости от сложности проекта, что не позволяет проводить эффективную отладку логической модели. Это связано с последовательностью выполнения всех операций. Для распараллеливания этой функции в маршруте проектирования процесс загрузки разбит на определенные кванты времени, каждый из которых выполняется на отдельном компьютере. Начальное состояние микросхемы для каждого кванта времени определяется выполнением соответствующей загрузки на поведенческой модели. Таким образом, после исправления ошибки можно запустить параллельно работающие компьютеры, время всей загрузки ОС определяется только выделенным квантом времени.
10. Тестирование модели микросхемы на стенде с использованием микросхем FPGA. Должен быть создан прототип микросхемы на базе программируемых пользователями микросхем FPGA и проведено
тестирование прототипа под ОС с реальными пользовательскими программами. Данный вид тестирования может увеличить срок разработки микросхемы до полугода, однако для промышленных ЭВМ главным критерием является надежность работы. Тестирование же прототипных плат с микросхемами FPGA на прикладных задачах в выделенной области применения приводит к наиболее эффективному выявлению ошибок на заданных задачах и, соответственно, к повышению надежности функционирования аппаратуры на них. В рамках данного тестирования должно быть повторено выполнение архитектурных тестов и тестов всех функциональных узлов, загружены ОС типа Linux и ОС реального времени, исполнены возможные прикладные программы, прежде всего программы заказчика. Современные микросхемы FPGA позволяют загружать проекты микросхем объемом до нескольких десятков миллионов транзисторов. Микропроцессор 1890ВМ5Т, имеющий объем 26,6 млн. транзисторов, может загрузиться в одну микросхему FPGA компании Altera Stratix II EP2S180F1020. Это очень эффективное тестирование, однако для каждой микросхемы приходится разрабатывать свои технологические платы - прототипы требуемых плат. На первый взгляд, данное тестирование приводит к заметному повышению трудоемкости и увеличению времени проектирования. Однако при создании практически всех микросхем серии 1890 данное тестирование позволяло найти ошибки, которые привели бы к необходимости повторного запуска изготовления кристаллов. В конечном итоге создание тестовых плат привело к сокращению стоимости проектов без увеличения времени проектирования.
Оценим выигрыш в сроках проектирования и стоимости (без накладных расходов и зарплаты) при использовании технологических плат для микросхем, изготавливаемых с технологическими нормами 0,18 мкм и 0,35 мкм. Стоимость изготовления пластин составляет более $180 тысяч для норм 0,18 мкм и около $70 тысяч для норм 0,35 мкм (с учетом налогов), стоимость комплекта ПО (САПР) от $100 до $500 тысяч в год в зависимости от выбранных программных продуктов. Стоимостью корпусов и кор-пусирования можно пренебречь, время повторного топологического проектирования 2-3 месяца, время изготовления кристаллов - 2 месяца, время доставки и корпусирования кристаллов - 1 месяц. Таким образом, стоимость повторного запуска составит от $100 до $280 тысяч, время изготовления - 5-6 месяцев. Стоимость изготовления технологических плат с FPGA - $10-20 тысяч, стоимость САПР для FPGA -$2 тысячи в год, время разработки - 2 месяца, изготовления (с учетом времени закупки комплектующих) - 3 месяца. Видно, что если технологические платы позволяют найти дополнительные ошибки, не выявляемые на предыдущих этапах тестирования, то выигрыш в стоимости может превысить несколько сотен тысяч долларов, время разработки не увеличивается. При проектировании микросхем серии 1890 практически во всех микросхемах на данном этапе тестирования находились ошибки.
11. Тестирование заказных и аналоговых узлов. Достижение соответствия их функционирования поведенческим моделям.
12. Тестирование модели микросхемы транзисторного уровня после топологического проектирования. Смешанное моделирование при наличии заказных и аналоговых узлов. Эти тесты готовятся на базе ранее подготовленных архитектурных тестов и тестов внутренних узлов, взаимодействия разрабатываемой микросхемы с микросхемами окружения. Основная задача тестов состоит в соблюдении всех временных параметров функционирования микросхемы после перехода на транзисторный уровень и появлении паразитных элементов. Для достижения требуемых параметров иногда приходится возвращаться к изменению логической модели микросхемы. Смешанное моделирование не позволяет проводить детальное тестирование в силу большого времени выполнения данного тестирования, однако во всех разработанных микросхемах серии 1890 с аналоговыми и заказными блоками без такого тестирования в проекте остались бы ошибки.
13. Тестирование кристаллов и микросхем. Используется модернизированный (сокращенный) комплект тестов, созданный при разработке модели. Особую значимость приобретает выполнение системного и прикладного ПО на созданных микросхемах. Весьма эффективным тестированием является тестирование микросхем сторонними организациями. Такое тестирование можно разделить на сертификационное и на уровне пользовательских задач.
Сертификационные тесты должны максимально возможно поставляться сторонними организациями, имеющими соответствующие права и лицензии.
Тесты для отбраковки кристаллов и микросхем направлены на поиск возможных дефектов при их изготовлении. Как известо, различают следующие средства тестирования: проверка массивов логических блоков, массивов памяти и аналоговых блоков. Основная задача средств тестирования - выявление максимального количества технологических дефектов. При этом необходима минимизация времени и площади элементов тестирования.
Массивы логических блоков проверяются на предмет отсутствия технологических дефектов, на правильность функционирования на максимальной частоте работы и на правильность функционирования совместно с аналоговыми блоками и блоками памяти.
Разработка проектов с использованием САПР на основе библиотеки элементов дала широкие возможности по интеграции средств тестирования. Основой для проверки отсутствия технологических дефектов в разработанном маршруте служат сканирующие цепочки и автоматически сформированные тестовые вектора. Дальнейшим развитием этого метода стали интеграция блоков генерации теста и анализ результата в кристалле. Это позволило значительно сократить размер тестовых векторов и время тестирования, повысить эффективность, но привело к увеличению времени разработки тестовых векторов.
Проверка правильности функционирования на
максимальной частоте, а также совместно с аналоговыми блоками решается с помощью блоков самотестирования (LBIST). Формирование входных воздействий на блок производится с использованием специальных генераторов тестовых последовательностей. Анализ выходных сигналов блока делается с помощью, например, сигнатурного регистра. Для отладки микропроцессоров и интеллектуальных контроллеров в созданной методике используется пошаговое выполнение инструкций и считывание результата, такой тест может проводиться на максимальной частоте.
Для тестирования массивов памяти используются блоки самотестирования памяти (ABIST). Такие блоки могут функционировать на максимальной частоте работы памяти. Однако в сложнофункциональ-ных проектах зачастую приходится использовать специфические памяти для повышения производительности системы. Для решения подобных проблем разработана методика и средства построения блоков самотестирования памяти (см.: С.Г. Бобков, Б.Е. Ев-лампиев, А.Ю. Сидоров. Блок самотестирования внутренней памяти. М.: ИППМ РАН. 2005). Для тестирования аналоговых блоков используется возможность управлять работой их отдельных узлов с помощью специальных тестовых выводов кристалла.
Для упрощения и ускорения тестирования и отбраковки кристаллов и микросхем в маршруте используется введение в кристалл сканирующих цепочек (см.: http://www.synopsys.com/products/test/dft_com-pilermax/dft_compilermax_ds.pdf, 2005). Такой способ основан на следующем. Все триггеры проекта устанавливаются в определенные значения. Затем результат срабатывания комбинаторной логики, расположенной между триггерами, защелкивается в эти же триггеры. Далее анализируется состояние этих триггеров. Так проверяется отсутствие технологических дефектов в изготовленной схеме. Для загрузки триггеров и чтения их состояния все триггеры объединяются в сдвиговый регистр. В результате для получения тестопригодной схемы в проекте необходимо сделать три изменения. Первое, на входе триггера необходимо устанавливать дополнительный мультиплексор. Этот триггер необходим для переключения входного сигнала: либо рабочий сигнал от комбинаторной логики, либо сигнал с выхода предыдущего триггера в сканирующей цепочке. Второе изменение - разводка в кристалле дополнительных сигналов переключения режима связи триггеров в цепочку. Третье изменение - организация схемы переключения синхросигналов для проведения тестирования. С точки зрения блоков предельного быстродействия интеграция дополнительного элемента (мультиплексора) в комбинаторные тракты выглядит наиболее проблемно. Количество каскадов комбинаторных элементов в цепочках обработки данных, как правило, ограничено небольшой величиной (3-5 элементов). Максимальный запас, который может быть получен при оптимизации расстановки такого количества элементов, гораздо ниже по сравнению с трактами, где возможна установка десятков элементов для низкочастотной части схемы. Несмотря на то что
в библиотеках элементов присутствуют триггеры с интегрированными мультиплексорами, это мультиплексор дает ухудшение параметра setup-триггерa, что приводит к снижению максимальной частоты работы. Для решения проблемы предлагается использовать сигнатурный анализ (см.: В.К. Федоров, Н.П. Сергеев, А.А. Кондрашин. Контроль и испытания в проектировании и производстве радиоэлектронных средств. М.: МИФИ. 2005). Реализация этого метода требует разработки дополнительных блоков: управления процессом тестирования, генератора тестовых последовательностей, устройства, осуществляющего сжатие выходных данных конвейера в код, называемый сигнатурой. На рисунке представлен пример такого тестирования контроллера интерфейса ЭЛТ-монитора, входящего в графический контроллер 1890ВГ12Т. Тестирование осуществляется следующим образом. Программируются регистры управления контроллером (размер выводимого на экран изображения, глубина представления цвета и частота пиксельного синхросигнала, генерируемого синтезатором). Далее блок управления запускает режим тестирования на время, равное выводу на экран одного кадра изображения. В течение этого интервала времени данные, подаваемые в конвейер обработки данных, формируются генератором псевдослучайных чисел (ГПСЧ). А сигнатурный регистр (СР) осуществляет сжатие выходных данных конвейера в сигнатуру. По окончании режима тестирования производится сравнение полученной сигнатуры с эталонным значением для данного режима работы конвейера и для использованной псевдослучайной последовательности данных. Совпадение результатов говорит о работоспособности конвейера.
синтезатор
ГПСЧ
JTAG
Контроллер интерфейса ЭЛТ-монитора
CP
Регистры управления
Контроллер системной шины
Проведение испытаний микросхем и окончательное определение их параметров проводится в соответствии с существующими ГОСТами.
Таким образом, разработана методика тестирования микросхем различного уровня сложности и быстродействия, позволяющая провести тестирование проекта на всех этапах работ от разработки до производства микросхем. Эффективность методики показана на разработке более 20 микросхем серии 1890. Для примера, микросхема графического контроллера 1890ВГ14Т изготовлена без каких-либо ошибок с первого раза. Это сложнофункциональная микросхема со встроенными заказными и аналоговыми узлами, сложность проектирования таких микросхем не ниже сложности проектирования современных микропроцессоров.
АДАПТИВНАЯ КОМПИЛЯЦИЯ НА ОСНОВЕ ДАННЫХ ПРОФИЛИРОВАНИЯ Н.И. Вьюкова, В.А. Галатенко, д.ф.-ж.п, А.С. Малиновский, Н.В. Шмырев (Москва)
Современные компиляторы реализуют широкий спектр оптимизаций, обеспечивающих генерацию высокоэффективного кода для различных процессорных архитектур. Однако целесообразность выполнения той или иной оптимизации для данного фрагмента кода может зависеть не только от статических свойств программы, но и от динамических характеристик ее выполнения. Например, вынесение инвариантных вычислений из тела цикла, как правило, дает ускорение выполнения, однако если типичное число выполнений некоторого цикла равно нулю, то данная оптимизация лишь увеличит время выполнения программы. Существуют методы оценки динамических характеристик программы на основе статического анализа ее исходного кода, но достоверность результатов такого анализа невысока. Для решения этой проблемы в компиляторах применяются средства для получения профиля программы, который затем используется при оптимизации кода.
Средства профилирования программ изначально разрабатывались как инструменты, позволяющие
разработчику изучать профиль выполнения программы, чтобы вручную оптимизировать наиболее часто выполняемые (критические) фрагменты кода. Например, в критических участках кода программист мог вручную выполнить развертку (или конвейеризацию) циклов, подстановку коротких функций вместо их вызовов и др. Современные компиляторы способны автоматически выполнять подобные оптимизации с учетом данных профилирования, оставляя разработчику содержательную работу по совершенствованию алгоритмических решений. Более того, компиляторы выполняют с учетом профиля множество оптимизаций, недоступных программисту на уровне исходного кода, таких как глобальное планирование команд, распределение регистров и др. По результатам различных работ (см., например: J. Hubicka. Profile driven optimizations in gcc. In GCC Developers Summit Procedings. 2005.), повышение эффективности кода в результате применения оптимизаций по профилю может составлять 10-20 и более процентов.
