Автоматизация тестовых примеров C для проверки встроенной системы

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

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

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

Инженеры по проверке SoC осознают ограничения тестовых стендов с произвольным ограничением, заставляя их вручную писать тесты C для запуска на процессорах как для моделирования, так и для аппаратной эмуляции, даже если они ограничены в полной реализации проекта SoC. Производительность этих платформ проверки недостаточна для запуска полной операционной системы (ОС), поэтому эти тесты выполняются «с нуля», что добавляет значительные накладные расходы к усилиям по компоновке. Для написанных от руки тестов, особенно без помощи служб ОС, нехарактерно скоординированное выполнение на многоядерных процессорах, использующих несколько потоков. В результате такие аспекты поведения SoC, такие как параллельные операции и согласованность, проверяются минимально.

Автоматическое создание тестов C

Конечно, автоматически сгенерированные тесты C позволят более эффективно использовать инженерные ресурсы. Они также увеличивают охват. Сгенерированные тестовые примеры C могут использовать больше функциональных возможностей SoC, чем рукописные тесты, и будут искать трудновообразимые сложные угловые примеры. Многопоточные, многопроцессорные тестовые примеры могут проверять все параллельные пути в рамках проекта для проверки параллелизма. Они могут перемещать данные между сегментами памяти, чтобы усилить алгоритмы согласованности, и координировать с транзакциями ввода-вывода, когда данные должны отправляться на входы микросхемы или считываться с ее выходов. Общий эффект от этого заключается в увеличении функционального охвата системы, обычно более чем на 90% по сравнению с числами, которые обычно намного ниже.

Программное обеспечение для генерации тестов, известное как Test Suite Synthesis, использует простую для понимания сценарную модель на основе графов, которая фиксирует предполагаемое поведение проекта. Эти модели могут быть написаны с использованием Accellera Portable Stimulus Standard с использованием собственного C ++ или описаны визуально. Модели сценариев создаются инженерами-проектировщиками или инженерами по верификации как естественная часть разработки SoC, поскольку они напоминают традиционные диаграммы потоков данных микросхемы, которые можно нарисовать на доске для объяснения части проектной спецификации.

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

Преимущества синтеза набора тестов

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

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

В одном типичном проекте большой SoC, разработанном известной полупроводниковой компанией, инженеры по верификации сократили время составления теста до 20% от того, что ранее требовало рукописных тестов. Технология автоматизации позволила создать более строгие тестовые сценарии, увеличив охват с 84% до 97%. Кроме того, модели портативные.

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

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

Сценарии применения

С помощью синтезированных тестовых примеров можно реализовать реалистичные сценарии использования, называемые сценариями приложений, для проектирования. Например, рассмотрим SoC цифровой камеры, показанный на рисунке 1.

щелкните, чтобы увеличить изображение

Рисунок 1:Пример SoC обработки изображения. (Источник:Breker Verification Systems)

Компоненты блочного уровня SoC включают два процессора, периферийные устройства и память. Под блок-схемой показан простой график для SoC. График включает возможные высокоуровневые пути, которые могут быть реализованы в процессе проверки SoC. Например, один из возможных сценариев, выраженный в верхнем пути графика, считывает изображение JPEG с SD-карты и передает его в фотопроцессор через выделенную область в памяти. Изображение преобразуется в форму, которая может быть отображена и загружена во второй блок памяти. Оттуда он передается контроллеру дисплея. Конечно, каждый из этих высокоуровневых блоков является иерархическим по своей природе, и многие действия и решения выполняются как часть процесса.

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

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

Заключение

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