Soft-CPU верификация


18

В настоящее время я занимаюсь разработкой простого процессора на VHDL с использованием Xilinx ISE и ISIM. Часть дизайна проходит замечательно хорошо, но я не могу найти способ последовательной проверки.

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

Я думал о разработке обширного набора тестов, но проблема в том, что потенциальное состояние компонента общего назначения как ЦП огромно по сравнению с менее общими компонентами.

Я ищу метод, который позволил бы мне выполнять проектирование и тестирование более контролируемым образом. Какой-то "аппаратный TDD", если хотите. Существует ли такая вещь? Может ли это быть относительно легко применимо к деталям общего назначения, таким как процессор?

Ответы:


16

Весь вопрос проверки ЦП очень большой и сложный. Есть люди, которые делают карьеру именно из этого. Я просто дам вам обзор ...

  1. Напишите программу на языке ассемблера, которая проверяет каждую инструкцию и каждую крошечную деталь каждой инструкции. Например, при тестировании инструкции ADD вы можете протестировать ее с числами, которые являются как положительными, так и отрицательными, и по одному на каждое (дважды). Затем вы должны проверить флаг переноса, флаг нуля и т. Д. Другие специальные функции ЦП (такие как прогнозирование ветвления и т. Д.) Будут иметь свою особую часть этого теста.

  2. Напишите, используя C / C ++ или что-то еще, модель вашего процессора. Это ваш виртуальный процессор. Это также ваш «золотой процессор», то есть это тот процессор, с которым сравнивается все остальное. В идеале человек, который написал VHDL, НЕ тот же человек, который пишет модель C / C ++.

  3. Напишите / создайте систему, в которой вы можете запустить модель C / C ++ и модель VHDL бок о бок и сравнивать результаты по циклам. Запустите программу сборки из шага 1 и убедитесь, что две модели совпадают.

  4. Запустите две ваши модели наугад "инструкции". По сути, заполните «ram» случайными данными и выполните эти случайные данные, как будто это настоящие инструкции. Запустите одни и те же случайные данные для моделей VHDL и C / C ++ и сравните результаты. Эта модель C / C ++ будет работать на некоторой рабочей станции и / или сервере (а не на новом процессоре).

  5. Настройте машину или несколько машин, чтобы повторить шаг 4 по существу навсегда. Даже если ваш процессор «закончен» и проработал год или более, вы все равно будете запускать этот тест.

  6. Повторите эти шаги всякий раз, когда есть что-то, что можно смоделировать. Например, вы можете запустить его на VHDL после маршрутизации с указанием времени, когда это будет доступно.

Нет никаких гарантий, что сравнение версий VHDL и C / C ++ поможет выявить каждую ошибку, но лучшего способа нет. А тестирование процессора на случайных инструкциях требует времени, но это также очень полезно. Единственная реальная альтернатива этому заключается в том, чтобы нанять множество людей, которые просто пишут код в течение всего дня, чтобы тестировать различные части ЦП - и крупные компании делают это, но они также делают случайные данные.

Для одного человека, пишущего код VHDL, обычно выполняется только первый шаг. Но если вы собираетесь продавать процессор, то должны быть выполнены хотя бы некоторые другие шаги (и действительно, вы должны сделать их все).


Отличный ответ, спасибо! Это имеет большой смысл. «Золотой процессор» - это действительно недостающий кусочек головоломки, который позволяет вам выполнять циклическую проверку при тестировании. Поскольку это в основном игрушечный проект, я думаю, что я буду соответствовать первому предложению последнего абзаца и сделаю только шаг # 1. Но знание того, что я должен делать, бесценно.
drxzcl

У вас также может быть золотая, но не точная в цикле, модель C ++, которая позволяет сделать ее намного проще и, следовательно, с большей вероятностью правильной - например, полезной для тестирования функциональности ALU ("2 + 2 = 4 и некоторые флаги, я не волнует, когда «а не« 2 + 2 = 4 после одного тика и флаги после 2 тиков »)
Мартин Томпсон

Кроме того, запустите покрытие кода (чтобы проверить, все ли вы реализовали) и покрытие тестирования (чтобы проверить, все ли тесты были протестированы как на тесты, так и на неудачи)
Мартин Томпсон,

Продолжение: используя процедуру «первого шага», мне удалось обнаружить множество ошибок ... в моем ассемблере: P Само ядро ​​выглядит относительно неплохо.
drxzcl
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.