Верификация процессорного ядра Опции

[flipflop]

Последнюю неделю бьюсь над задачей верификации процессорного ядра (RISC архитектура (load/store), 6 ступенчатый конвейер команд, только целочисленная математика). Задача для меня совсем новая (раньше делал только математику и коммуникационные контроллеры), поэтому не знаю даже с какой стороны подойти.

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

Может ли кто-нибудь поделиться опытом, как на практике верифицируют процессоры и покритиковать мой подход?

[flipflop]

Ну, более высокоуровневое описание того же алгоритма менее подвержено ошибкам.

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

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

Если компилятор (gcc) уже портирован, то у него полно тестов. Более чем нормальная вертификация.

Основной плюс формальной верификации в том, что она дает 100% покрытие по тем блокам на которые написана спека. Верификация путем логической
симуляции никогда не даст 100% покрытия по двум причинам:
1) Время симуляции будет стремиться к вечности;
2) Невозможно написать такую программу, которая покрыла бы все возможные состояния/ исключительные ситуации/форматы данных и.т.п.

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

Меня больше беспокоит вопрос создания эталонной модели: В простейшем случае, в качестве эталона можно использовать симулятор системы команд (Instruction Set Simulator),
он же Архитектурная модель (System Architecture Model). Это такая штука, которая эмулирует работу процессора с точностью до команды. Как правило, ISS'ы есть
в каждой нормальной среде разработки для микроконтроллеров, к примеру, в Keil. Если мы верифицируем мультитактную модель процессора, т.е. простейшую реализацию процессора
без конвейера команд, то все отлично: всегда есть такое состояние, когда процессор завершил выполнение одной команды, но еще не начал исполнять другую. Далее сравниваем состояние регистров
в RTL и ISS, если есть расхождения, то сразу ясно, на какой команде возникает ошибка.

Далее рассмотрим реализацию процессора с конвейером команд: куча команд выполняется параллельно, данные летают во все стороны (работают всякие forwarding'и, stall'ы c пузырями, отлавливаются конфликты
по управлению). Выловить завершение исполнения отдельной команды невозможно: т.е. сравнить выполнение каждой команды в ISS и в RTL мы не можем. В лучшем случае можно ловить циклы записи в память и сравнивать передаваемые данные. Но для RISC процессоров с тучей регистров, такой подход плохо подходит: обращение к памяти происходит редко. Если мы и отловим жука, то продебажить его будет очень тяжело.

Какой памяти, внешней, или внутренней?

Внутренней. Block Ram

Сообщение отредактировал flipflop - Dec 8 2009, 16:18