Научная статья на тему 'Микротесты для оценки производительности RTL-моделей микропроцессоров'

Микротесты для оценки производительности RTL-моделей микропроцессоров Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
171
56
i Надоели баннеры? Вы всегда можете отключить рекламу.
i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Микротесты для оценки производительности RTL-моделей микропроцессоров»

УДК 004

МИКРОТЕСТЫ ДЛЯ ОЦЕНКИ ПРОИЗВОДИТЕЛЬНОСТИ ИТЬ-МОДЕЛЕЙ МИКРОПРОЦЕССОРОВ

Н.В. Николина (НИИСИРАН, г. Москва, nikolina@ps.niisi.ras.ru)

Рассматривается подход к оценке и контролю производительности микропроцессоров на стадии их разработки. Предложена методика, позволяющая оценить производительность отдельных блоков, при этом игнорируется любое потенциальное влияние других. Представлен состав тестового набора для оценки производительности RTL-моделей микропроцессоров (моделей на уровне регистровых передач). Тестовый набор состоит из коротких программ (микротестов), направленных на оценку производительности отдельных блоков. Выбор тестового набора для разных блоков осуществляется с учетом особенностей его работы. В статье рассмотрены наборы микротестов для блока вещественной арифметики, блока выборки/выдачи инструкций (буфера инструкций) и подсистемы памяти, реализованные для MIPS-подобной архитектуры. Для анализа времени выполнения кода используются счетчики производительности, входящие в состав регистров управляющего сопроцессора микропроцессора. Предложена система для автоматизации создания тестовых ситуаций, регрессионного запуска тестов и визуализации результатов оценки производительности. Тестовая система позволяет в разумное время получить результат оценки производительности и сравнить его либо с результатами предыдущих версий RTL-модели, либо с эталонными значениями. Проводится также анализ влияния оценки производительности на архитектуру будущей микросхемы. Показана возможность исследования влияния на производительность таких факторов, как изменение частоты памяти при постоянной частоте процессора. Результаты измерений даны на примере оценки производительности разрабатываемых в НИИСИ РАН 64-разрядных суперскалярных микропроцессоров и подтверждены на готовых микросхемах.

Ключевые слова: микротесты, оценка производительности, организация регрессионного процесса оценки производительности.

MICROBENCHMARKS FOR MICROPROCESSOR RTL-MODELS PERFORMANCE ASSESSMENT Nikolina N.V. (SRISA RAS, Moscow, nikolina@cs.niisi.ras.ru) Abstract. An approach for evaluating and monitoring performance of the microprocessor on design stage is considered. The technique to estimate performance of separate blocks is offered, any potential influence of others is thus ignored. We propose a test suite for evaluating performance of microprocessor RTL-models (Register transfer level). The test set consists of the short programs (microtestbenches) directed on performance evaluating of separate blocks. A choice of test set for different modules is realized on taking into account features of its work. An article presents a number of test situations for evaluating such modules as instruction fetch and dispatch buffer (IFDB), floating point unit (FPU) and memory management unit (MMU) for MIPS-like architecture. For the analysis of run time performance counters are used, which are the parts of control coprocessor registers of microprocessor. Automation for creating test cases, regression performance measurement and visualization of performance evaluation results are proposed. During reasonable time the test system allows to receive results of a performance evaluation and to compare it with results of the previous versions of RTL model, or with reference values. Also the impact of performance measurements on architecture of future chip is considered. The possibility to investigate the influence on microprocessor performance of such factors as changing memory frequency is shown. The results of measurements are shown on example of performance evaluation of superscalar microprocessor which is developed in SRISA RAS. The results were confirmed on final crystal.

Keywords: microbenchmarks, performance evaluation, regression performance evaluation.

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

Существует большое количество программ, призванных давать оценку производительности микропроцессора [1, 2]. Это либо выдержки из реальных приложений, либо синтетические тесты, не являющиеся частью реальной вычислительной программы (программ). Известно, что моделирование таких сложных объектов, как микропроцессор, занимает намного больше времени, чем работа реального микропроцессора. Поэтому, несмотря на различные методы адаптации тестов

производительности для запуска их на RTL-мо-дели [3], запуск существующих тестов производительности, как правило, призванных оценить производительность готового процессора, не всегда удобен, особенно в условиях регулярной проверки.

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

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

зультатами предыдущих версий RTL-модели, либо с эталонными значениями.

Микротесты, определение тестового набора

В рамках работ по оценке производительности создаваемого в НИИСИ РАН 64-разрядного суперскалярного микропроцессора были разработаны наборы микротестов (коротких программ, предназначенных для оценки производительности отдельных блоков). Для анализа времени выполнения кода используются счетчики производительности, входящие в состав регистров управляющего сопроцессора микропроцессора. Счетчики измеряют время выполнения инструкций в процессорных тактах и не требуют затрат времени на обращение к ним, что позволяет наиболее точно оценить длительность выполнения интересуемых инструкций. Выбор тестового набора для разных блоков осуществляется с учетом особенностей его работы. Рассмотрим наборы микротестов для блока вещественной арифметики, блока выборки/выдачи инструкций (буфера инструкций) и подсистемы памяти, реализованные для MIPS-подобной архитектуры.

Блок вещественной арифметики. Для оценки производительности блока вещественной арифметики в микротестах измеряется время выполнения N инструкций вещественной арифметики в процессорных тактах. Рассматриваются следующие инструкции: зависимые и независимые, с одинарной и двойной точностью, с разрешенными и запрещенными исключительными ситуациями, с разным режимом работы вещественного регистрового файла (64-разрядный режим, когда вещественные регистры содержат 64-разрядные значения, или режим 32-разрядной совместимости, если 64-разрядные данные занимают пару из четного и нечетного регистров).

Полученное значение нормализуется на число, соответствующее эталонному значению процессорных тактов, необходимых для выполнения N независимых вещественных инструкций.

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

Буфер инструкций рассматриваемого микропроцессора выполняет запрос инструкций, анализ зависимостей по данным и выдачу команд в исполнительные блоки. Протокол запроса инструкций предусматривает чтение одной кэш-линии (8 команд) из кэш-памяти инструкций (при попадании в него) за 2 такта или чтение половины кэш-

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

Таким образом, для измерения длительности выполнения команд ветвления в тестовых ситуациях перебираются все условия, которые могут повлиять на скорость ее выполнения, а именно:

- положение инструкции ветвления в восьмерке считанных из кэш-памяти инструкций или четверке инструкций (в случае непопадания в кэшпамять);

- направление перехода;

- занятость кэш-памяти инструкций;

- количество команд ветвления в буфере инструкций (плотность следования инструкций перехода в коде программы).

Кроме того, в процессоре могут быть предусмотрены специальные механизмы обработки определенных последовательностей инструкций, например, механизм распознавания и ускорения выполнения коротких циклов (циклов, в теле которых от 0 до 6 инструкций). При выполнении коротких циклов производительность оценивается путем измерения времени выполнения М инструкций короткого цикла с разным числом независимых команд в теле. Независимые команды используются для оценки влияния на производительность только команд ветвления.

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

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

- в кэш-память первого уровня,

- в кэш-память второго уровня,

- в буферы данных,

- с промахом в кэш-память и буферы данных,

- с обратной записью.

В случае промаха в кэш-память и при некэши-руемом обращении измерения проводятся при нескольких значениях частоты работы памяти и процессора:

- при одинаковой частоте работы памяти и процессора (оценивается предел процессора);

- при частоте работы процессора, в два раза

большей частоты работы памяти (наиболее общий случай на практике);

- при частоте работы процессора, в четыре раза большей частоты работы памяти (оценивается влияние памяти на производительность).

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

Для копирования данных рассматриваются следующие ситуации.

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

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

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

Система оценки производительности

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

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

Этот процесс реализован с помощью общего для тестов ядра, где происходит подготовка ко всем интересующим ситуациям. Сами тесты представляют собой набор параметров, указывающих на то, какая именно подготовка необходима для данного теста. Как правило, параметры, характеризующие тестовую ситуацию, либо принимают значения «истина»/«ложь», либо имеют числовой эквивалент. Это позволяет автоматически перебирать параметры для каждого теста, а также дать тесту уникальное имя, характеризующее реализованную ситуацию. Результатом такого автоматического перебора является набор тестовых программ. Каждый тест находится в отдельной директории вместе со вспомогательными программами для компилирования и начальной загрузки. Сле-

дующим этапом является сборка тестовых программ с ядром тестов (рис. 1).

Рис. 1. Автоматизация получения тестовых ситуаций

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

В качестве вспомогательного инструмента для сравнения результатов был использован инструмент отслеживания ошибок Trac [5]. Результаты измерения производительности выдаются в wiki-формате и сохраняются на странице в Trac со ссылкой на ревизию тестируемого проекта в системе контроля версий. Таким образом, разработчик может увидеть результат прохождения тестов и при необходимости сравнить текущий результат с одним из предыдущих. Благодаря наличию ссылки на проект в системе контроля версий существует возможность увидеть, какие именно изменения в проекте привели к такому результату. Кроме того, предусмотрен механизм, выдающий отчет об отличии полученных данных от эталонных. Эталонными данными могут быть как максимально хороший результат, полученный ранее, так и результат, к которому стремится разработчик.

Результаты оценки производительности

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

В работе блока вещественной арифметики микротестами обнаружено, что в режиме 32-разрядной совместимости независимые команды вы-

полняются в 4-5 раз медленнее, чем в 64-разрядном режиме. При рассмотрении данного теста на временной диаграмме выяснилось, что после вещественной команды умножения с накоплением (даже если за ней не стояла зависимая от нее инструкция) следовала задержка до записи полученного значения в регистровый файл. После устранения данной задержки тестовые программы в режиме совместимости стали выполняться за то же время, что и в 64-разрядном режиме.

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

Микротесты оценили вклад буферов данных в производительность подсистемы памяти: исследованы различные объемы и количество буферов. На рисунке 2 показана скорость загрузки данных в тактах в зависимости от размера буферов предварительного вычитывания данных.

При случайном доступе к памяти буфер предварительного вычитывания замедлял чтение дан-

ных, так как происходила выборка лишней информации.

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

Кроме того, с помощью микротестов удобно проводить исследования влияния частоты работы процессора или памяти на скорость загруз-

Такты

.._l.ll

Непрерывные С обратной С шагом 32 С шагом 128 записью байта байт

■ Без буфера ■ Буфер 64 байт ■ Буфер 128 байт

Рис. 2. Время выполнения команд загрузки в тактах (частота работы памяти равна частоте работы процессора)

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

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

Предложенная методика позволяет выявить узкие места в архитектуре, задержки в выполнении команд, а также показать необходимость введения дополнительных механизмов повышения произ-

Частота памяти, МГц

Рис. 3. Скорость копирования в зависимости от частоты работы памяти

водительности еще на стадии проектирования (RTL-модели), исследовать влияние частоты работы памяти и процессора на скорость загрузки/сохранения или копирования данных.

Полученную базу тестов производительности удобно использовать в регрессионном тестировании. Запуск тестов производится регулярно после фиксации версии RTL-модели, результаты представляются в виде сравнительных таблиц.

Результаты оценки производительности подтверждены на готовых микросхемах 1890ВМ5Ф [6] и 1890ВМ6Я.

Литература

1. Standart Performance Evaluation Corporation. URL: http://www.spec.org (дата обращения: 12.05.2012).

2. Embedded Benchmark Consortium. URL: http://www.ee-mbc.org (дата обращения: 12.05.2012).

3. Аряшев С.И., Краснюк А.А., Чибисов П.А. Адаптация тестов для оценки производительности 64-разрядного универсального суперскалярного микропроцессора / Проблемы разработки перспективных микроэлектронных систем-2005: сб.

науч. тр.; [под ред. А.Л. Стемпковского]. М.: ИППМ РАН, 2005. С. 263-268.

4. Аряшев С.И., Николина Н.В. Влияние буферизации данных на производительность подсистемы памяти / Электроника, микро- и наноэлектроника: сб. науч. тр.; [под ред. В.Я. Стенина]. М.: НИЯУ МИФИ, 2011. С. 164-167.

5. Trac Integrated SCM & Project Management. URL: http://trac.edgewall.org (дата обращения: 12.05.2012).

6. Бобков С.Г. Методика проектирования микросхем для компьютеров серии «Багет» // Информационные технологии. 2008. № 3. С. 2-7.

References

1. Standart Performance Evaluation Corporation, available at: www.spec.org (accessed 12.05.2012).

2. Embedded Benchmark Consortium, available at: www. eembc.org (accessed 12.05.2012).

3. Arjashev S.I., Krasnjuk A.A., Chibisov P.A., Sbornik nauch. trudov, Moscow, Institut problem proektirovaniya v mikroelektronike Rossiyskoi akademii nauk, 2005, pp. 263-268.

4. Arjashev S.I., Nikolina N.V., Moscow, Nacional'nyj issledovatel'skij jadernyj universitet MIFI, 2011, pp. 164-167.

5. Trac Integrated SCM & Project Management, available at: www.trac.edgewall.org (accessed 12.05.2012).

6. Bobkov S.G., Informacionnye tehnologii, 2008, no. 3, pp. 2-7.

УДК: 004.052.42

РОЛЬ СТОХАСТИЧЕСКОГО ТЕСТИРОВАНИЯ В ФУНКЦИОНАЛЬНОЙ ВЕРИФИКАЦИИ МИКРОПРОЦЕССОРОВ

И.Ш. Хисамбеев

(НИИСИ РАН, Москва, ildar@ps.niisi.ras.ru)

С ростом требований к характеристикам современных ИС, в том числе микропроцессоров и систем на кристалле, существенно усложняется их проектирование. Оно превратилось в многоступенчатый процесс, на каждой стадии которого от разработчиков требуется решение все более и более сложных задач. Одной из самых трудоемких из них является функциональная верификация проекта. Задача заключается в установлении соответствия между некоторым уровнем реализации проекта и функциональными требованиями его спецификации. Для проектов ИС современного уровня сложности отсутствует универсальный способ функциональной верификации, однако существует несколько взаимодополняющих подходов к проблеме. Одним из методов, применяемых в НИИСИ РАН при разработке микропроцессоров архитектуры MIPS64, является стохастическое тестирование. В его основе лежит симуляция выполнения тестовых программ на модели микропроцессора. Тесты (тестовые программы) генерируются автоматически по заданному шаблону с параметризованным случайным выбором инструкций тела теста и их аргументов. В данной статье уделяется внимание роли метода стохастического тестирования, области его применения, преимуществам и недостаткам. Функциональная верификация рассматривается как составная часть процесса проектирования ИС. Описываются наиболее известные в мировой практике подходы к верификации и коротко рассматриваются лежащие в их основе идеи. Дается информация о классе методов, основанных на симуляции, и методе стохастического тестирования. Делаются выводы о преимуществах и недостатках данного метода, иллюстрируемые некоторыми результатами его применения в НИИСИ.

Ключевые слова: микропроцессор, функциональная верификация, RTL-модель, симуляция, стохастическое тестирование, генерация случайных тестов, метрики тестового покрытия.

ROLE OF STOCHASTIC TESTING IN MICROPROCESSORS FUNCTIONAL VERIFICATION KhisambeevI.Sh. (SRISA RAS, Moscow, ildar@cs.niisi.ras.ru) Abstract. With the growth of the performance requirements of modern IC, including microprocessors and Systems-on-Chip, their development complicates considerably. It has become a multistage process, and there are many sophisticated tasks to be done on each stage. One of the most labor-consuming tasks is design functional verification. Its goal is to approve a conformity between implementation of a design and it's specification functional requirements. While it does not yet have a general solution, considering modern IC designs complexity, several complementary approaches were developed to address

i Надоели баннеры? Вы всегда можете отключить рекламу.