Использование архитектурного симулятора для тестирования формального описания цифровой логики микропроцессора

Создать новую статью

20.09.2010 10:00


Информация об авторе

Леченко Антон Владимирович, студент третьего курса кафедры «Микропроцессорные технологии» факультета радиотехники и кибернетики Московского физико-технического института. Проходил стажировку в московском офисе Intel.
Менторы: Михаил Цветков, Андрей Ефимов.
Менеджер: Александр Бутузов.

Аннотация

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

Введение

Разработка цифровых чипов требует применения методов автоматизации. Существующие подходы к разработке функциональных тестов ([1]) подразумевают написание вручную среды тестирования (тестбенч) из текстовых спецификаций. Запускается симулятор аппаратного описания (HDL симулятор), в котором симулируется формальное описание цифровой логики (HDL код) тестируемого модуля, обёрнутое в тестбенч. Тестируемый модуль считывает со своих входных портов специально сгенерированные тестовые вектора, и выставляет результаты работы на свои выходные порты для проверки с эталонными. Данные методологии обладают существенными недостатками. Первый состоит в необходимости написания различных тестбенчей для разных микроархитектрных модулей, количество которых может достигать нескольких сотен. Второй заключается в необходимости разработки критически важных компонентов, например генераторов тестов, основываясь на текстовых спецификациях. Потенциальная неоднозначность описания, заключённого в спецификации, совместно с большим объёмом монотонной ручной работы затрачиваемой на переписывание тестбенчей, приводит к большой вероятности ошибок, недопустимых ввиду высокой стоимости их исправления в готовом продукте.

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

Описание единой среды тестирования

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

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

fetcher.dot.png

Рис.1 Диаграмма связей блока выборки команд с внешними модулями, построена разработанным в ходе исследований скриптом.

Данный подход к проектированию моделей заложен в основе ряда распространенных инфраструктур, таких как SystemC, Liberty Simulation Environment, Asim и HAsim ([4,6,10]). Соответственно, верификация HDL описания определённой микроархитектурной единицы может быть реализована как проверка на равенство выходных данных соответствующего модуля архитектурного симулятора и симулятора аппаратного описания тестируемого блока, формируемых в ответ на одни и те же воздействия. При таком подходе архитектурный симулятор выступает в качестве генератора тестов, эталонной модели и монитора, отвечающего за проверку корректности работы тестируемого модуля.

Исследование взаимодействия архитектурных и HDL симуляторов

Данная задача подразумевает решение следующих проблем:

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

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

Также следует учесть, что оба симулятора работают параллельно и с разной скоростью. Это значит, что в момент времени t архитектурный симулятор может находиться на i-м такте, а HDL симулятор на j-м, и, следовательно, оба симулятора обрабатывают в этот момент времени различные данные. Но на i-м такте оба симулятора должны обрабатывать одинаковые данные. Для решения этой задачи предлагается синхронизировать симуляторы по сообщениям, используя именованные каналы (named pipes). Согласно стандарту POSIX, чтение из канала осуществимо, только если там находятся данные, в противном случае, читающий процесс будет остановлен. Соответственно, если один из симуляторов начинает работать быстрее другого, он тут же будет остановлен на чтении из пустого канала. Когда в буфере канала появится требуемая информация, процесс автоматически будет возобновлен операционной системой. Атомарность записи и чтения в свою очередь гарантирует цельность сообщений во время работы.

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

Вначале на примере одной команды разберём принцип работы архитектурного симулятора. Для простоты предположим, что наш симулятор состоит всего из трёх модулей: источник, который генерирует входные данные, эталонный модуль, и сток, в который эталонный модуль записывает свои выходные данные (рис.2, микроархитектурный потактовый симулятор). Жизненный цикл одной команды в данном симуляторе следующий.

Такт 0: Начинается выполнение инструкции. Источник порождает некоторый набор данных и пишет их в порт записи.

Такт 1: Эталон читает сигналы из портов чтения, обрабатывает их, генерирует новый набор выходных сигналов и пишет их в свои порты записи.

Такт 2: Сток читает из своих портов чтения эти сигналы.

Далее перейдём к принципу работы данной среды автоматизированного тестирования. HDL симулятор запускается отдельным процессом, параллельно архитектурному симулятору. Рассмотрим процесс тестирования микроархитектурного модуля, на основе жизненного цикла одной команды.

simple.png

Рис. 2 Принципиальная схема организации среды тестирования.

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

Такт 1: HDL симулятор обрабатывает полученные данные параллельно с эталоном. Эталон пишет свои выходные сигналы в порты записи.

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

Описанный подход универсален и применим для симуляторов, написанных на основе многих различных инфраструктур, а так же для HDL описаний, реализованных на большинстве языков. Решение, основанное на вышеприведённых идеях, было реализовано с использованием симулятора, основанного на инфраструктуре Asim, который представляет набор библиотек и средств для написания архитектурных симуляторов на C++. Были написаны необходимые библиотеки классов и функций, внесены небольшие правки в код. Результатом стала тестовая система для блока выборки команд (Fetcher), блок-схема которой представлена на рис. 3.

full.png

Рис. 3 Схема организации среды тестирования для блока выборки команд (Fetcher).

Рассмотренный вариант реализации не является единственно возможным. Инкапсулируя требуемую для тестирования функциональность внутри портов, можно относительно легко реорганизовывать тестовую систему. Возможно использование других протоколов передачи данных между процессами, как например, очереди сообщений, разделяемая память, TCP-IP. Возможен раздельный запуск архитектурного симулятора и симулятора аппаратного описания. При этом архитектурный симулятор генерирует файлы сообщений, которые могут использоваться как входные или эталонные вектора симулятором аппаратного описания. Можно данную тестовую систему использовать не только совместно с симулятором аппаратного описания, но и для тестирования объёмных микроархитектурных блоков, реализованных на ПЛИС (программируемая логическая интегральная схема). В данном случае, выполняется тестирование того же аппаратного описания, только производительность тестирования возрастает на порядки.

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

Заключение

В ходе работы над проектом были получены следующие результаты.

  1. Доказана принципиальная возможность использования архитектурного симулятора для HDL тестирования.
  2. Разработана универсальная методология тестирования HDL описания, основанная на использовании архитектурного симулятора. Данная методология обеспечивает сквозную интеграцию, уменьшает время разработки и вероятность ошибки.
  3. В соответствии с методологией, разработана библиотека для инфраструктуры Asim, автоматизирующая обмен данными между архитектурным симулятором и другими процессами, а также библиотека унифицирующая интерфейсы модулей в разных симуляторах.
  4. Рассмотрена возможность замещения модулей архитектурного симулятора их HDL описанием.
  5. Была реализована тестовая система для модулей микропроцессора, написанных на языках SystemVerilog и Bluespec SystemVerilog. При этом количество требуемых изменений в коде архитектурной модели уменьшено на порядок, за счет использования разработанных библиотек.

    code_reduce.png

  6. С помощью реализованной системы было проведено тестирование блока выборки команд, описанном на языке SystemVerilog, на наборе из 2318 тестов. Каждый тест состоял из порядка 100,000-1,000,000 команд. Успешно пройдено 92% тестов. Результаты выполнения данного набора тестов в разработанной тестовой системы совпадают с результатами отдельно-стоящего архитектурного симулятора. Это подтверждает возможность построения тестовой системы на основе архитектурного симулятора.

    test_re_fixed.png

  7. Был написан скрипт, строящий топологию портов архитектурной модели, что упрощает сбор данных, необходимых для адаптации тестовой системы под произвольный HDL модуль.
  8. Ведутся работы по автоматической настройке тестовой системы под определенный модуль.
  9. В данный момент тестовая система активно используется в работе над аппаратной реализацией микроархитектурного симулятора.

Список литературы

  1. Я.С. Губенко, А.С. Камкин, М.М. Чупилко. Сравнительный анализ современных технологий разработки тестов для моделей аппаратного обеспечения, 2009
  2. Sreekumar V. Kodakara, Deepak A. Mathaikutty, Ajit Dingankar, Sandeep Shukla, David Lilja. Model Based Test Generation for Microprocessor Architecture Validation, IEEE International Conference on VLSI Design (VLSI Design), 2007
  3. Deepak A. Mathaikutty, Sreekumar V. Kodakara, Ajit Dingankar, Sandeep K. Shukla, David J. Lilja. MMV: A Metamodeling Based Microprocessor Validation Environment, IEEE Transactions on Very Large Scale Integration (VLSI) Systems, 2008
  4. Joel Emer, Carl Beckmann, Michael Pellauer. AWB: The Asim Architect's Workbench, 2007
  5. Zhangxi Tan, Andrew Waterman, Henry Cook, Sarah Bird, Krste Asanovic, David Patterson. A Case for FAME: FPGA Architecture Model Execution, in ISCA '10: Proceedings of the 37th annual international symposium on Computer architecture (2010), pp. 290-301.
  6. David August, Jonathan Chang, Sylvain Girbal, Daniel Gracia-Perez, Gilles Mouchard, David Penry, Olivier Temam, Neil Vachharajani. UNISIM: An Open Simulation Environment and Library for Complex Architecture Design and Collaborative Development, IEEE Computer Architecture Letters, 2007
  7. Khizar Khan. Strategies for verifying microprocessors. http://www.design-reuse.com/articles/3096/strategies-for-verifying-microprocessors.html, 2002
  8. Alexander Kamkin. Specification-Driven Construction of Testbench Checkers for RTL Models of Synchronous Parallel-Pipeline Hardware, 2009
  9. Mikhail Chupilko, Alexander Kamkin. Specification-Driven Testbench Development for Synchronous Parallel-Pipeline Designs, 2009
  10. IEEE Standard SystemC® Language Reference Manual.