Вы точно знаете, что ваш RISC-V RTL не содержит сюрпризов?

Учитывая относительную новизну и сложность проектов RISC-V RTL, независимо от того, покупаете ли вы коммерчески поддерживаемое ядро ​​или загружаете популярное предложение с открытым исходным кодом, существует небольшой, но ненулевой риск того, что нежелательные сюрпризы проскользнут незамеченными в ваш конечный продукт. В порядке убывания вероятности рассмотрим:

• Наличие странной, но вполне возможной ошибки в крайнем случае.
• Ошибки «внутри» пользовательских инструкций, которые вы или ваш поставщик создаете для вашего приложения.
• Ошибки «по краям» пользовательской инструкции — например, инструкция выполняется правильно, но каким-то образом оставляет машину в поврежденном состоянии.
• Связано: недокументированные и/или плохо указанные новые функции, которые невольно открывают дыры в дизайне.
• Вредоносная логика трояна, тайно внедренная посредством атаки на цепочку поставок

Общие подходы к смягчению последствий

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

Следующая линия защиты — применение подходов, основанных на моделировании: моделирование набора команд (ISS), автоматическое сравнение вашего тестируемого устройства со зрелыми золотыми моделями, тестовые стенды UVM с ограничениями и случайностью для моделирования DUT RTL и даже передача реальных стимулов в аппаратную эмуляцию. ДУТ. Опять же, все эти подходы ценны и должны быть реализованы; но все они страдают одним и тем же недостатком: они по своей сути неполны, поскольку полагаются на генерацию стимулов. Например, в крайнем, но возможном случае атаки на цепочку поставок разработчик логики трояна намеренно создал триггерную последовательность сигналов и данных, которая, скорее всего, не сможет быть обнаружена даже самым изобретательным хакером в белой шляпе. И, конечно же, функциональные ошибки имеют свой собственный способ использования естественной энтропии, чтобы оставаться скрытыми.

Суть в том, что единственный способ быть полностью уверенным в том, что ваш RISC-V RTL не содержит каких-либо естественных или вредоносных неожиданностей, — это применить исчерпывающие формальные методы проверки проекта.

Легче сказать, чем сделать, верно?

И да, и нет: 14 лет назад подобный анализ был доступен только исследователям с докторской степенью, использующим свои собственные программы. Но с 2008 года инструменты и методы были разработаны таким образом, что любой, кто знаком с основами формальной верификации и написанием стандартных утверждений системы Verilog (SVA) IEEE, может быстро применить их и добиться успеха.

Трехэтапный формальный процесс

Рекомендуемый формальный поток выглядит следующим образом:

1. Создайте формальный испытательный стенд, который «моделирует» спецификацию тестируемого устройства.
2. Определите входные ограничения и проверки, которые будут выполняться для тестируемого устройства.
3. Выполнить анализ

Шаг 1. Создайте формальный испытательный стенд, который «моделирует» спецификацию ИУ.

В основе этой методологии лежит написание набора свойств, которые представляют поведение каждой инструкции в вашем проекте RISC-V. Задача состоит в том, чтобы уловить влияние данной инструкции на выходы IP и внутренние архитектурные состояния (в мире RISC-V это счетчик программ (PC) и файл регистров (RF)) для любой заданной входной последовательности произвольной длины. Это делается с помощью специального расширения IEEE SVA, называемого Operational SVA. В двух словах, это библиотека, поставляемая вместе с формальным инструментом проверки процессора; и с точки зрения инженера по верификации это выглядит как интуитивно понятное подмножество знакомого кода SVA. На рисунке 1 показана общая структура:

инструкция свойства_A; // концептуальное состояние t ##0 Ready_to_issue() и // триггер t ##0 opcode==instr_A_opc подразумевает // концептуальное состояние t ##0 Ready_to_issue() и // выходные данные интерфейсов памяти // чтение следующей инструкции t ##0 imem_access(instr_A_opc) и // загрузка/сохранение данных t ##1 dmem_access(instr_A_opc) и // архитектурные регистры t ##1 RF_update(instr_A_opc) и t ##1 PC_update(instr_A_opc) endproperty 

Рис. 1: Структура рабочего кода SVA, фиксирующего спецификацию инструкции процессора. [1]

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

Кроме того, необходимо доказать правильность выходных сигналов процессора — в этом случае, чтобы убедиться, что инструкция обращается к ожидаемым данным и ячейкам памяти инструкций. Это утверждение также доказывает, что машина готова выдать новую инструкцию в следующем цикле. Это крайне важно для отделения проверки инструкции от последовательности инструкций, частью которой она может быть. Например, инструкция А может выполниться правильно, но оставить машину в поврежденном состоянии. Это ошибочное состояние может привести к тому, что следующая инструкция B выдаст неправильные результаты не по своей вине. Следовательно, при использовании подхода Operational SVA инструкция B проверки утверждения пройдет успешно, а инструкция A проверки утверждения завершится неудачно (при этом операции чтения и записи в память могут длиться несколько циклов).

Итог: функции, представляющие архитектурные состояния в коде Operational SVA, должны быть сопоставлены с сигналами реализации и отражать микроархитектуру процессора. Например, статус RF может зависеть от активации путей пересылки. [1]

[Примечание: для тех из вас, кто знаком с моделированием или формальным функциональным покрытием, это понятие полноты не зависит от показателей структурного покрытия или от создания и сбора показателей для модели функционального покрытия. Вместо этого (и немного опережая оставшиеся шаги и результаты) результат анализа здесь сводится к получению полных доказательств для всех свойств. Полные доказательства также неявно показывают, что не существует никакой другой функциональности — которая была неуказанной или неожиданной (ошибка спецификации или кодирования) или была вставлена ​​злонамеренно — которая не была бы зафиксирована этим набором свойств. Перефразируя, вся суть этой методологии заключается в достижении 100% «охвата плана тестирования», что подтверждается результатами исчерпывающего формального анализа – где нет ничего более «полного», чем математическое доказательство!]

Шаг 2. Определите входные ограничения и проверки, которые будут выполняться для тестируемого устройства.

Следующим шагом, чтобы дополнить свойства спецификации для каждой инструкции, является определение ограничений ввода и любых дополнительных проверок вывода. Опять же, используется Operational SVA, где пользователь теперь указывает «план полноты» для определения как допустимых входных данных, так и недопустимых сигналов, которые тестируемое устройство должно игнорировать. В примере, показанном на рисунке 2, имеется три раздела: предположения определения, требования определения и график свойств.

процессор полноты; определение_предположений: // ВХОДЫ определены(imem_data_i); определено (dmem_valid_i); если (dmem_valid_i) определено (dmem_data_i) endif; Definition_requirements: // ВЫХОДЫ определены (imem_read_o), если (imem_read_o) определены (imem_addr_o) endif; определено (dmem_enable_o); если (dmem_enable_o) определено (dmem_rd_wr_o), определено (dmem_addr_o) endif; // АРХИТЕКТУРНЫЕ СОСТОЯНИЯ определены(PC); детерминированный(РФ); property_graph: all_instructions := инструкция_not_a, инструкция_add_a, инструкция_sub_a, [...] all_instructions -> all_instructions; конечная завершенность; 

Рис. 2: Пример плана полноты с допущениями и требованиями условного определения.

Чтобы уточнить:

• «determination_assumptions» — это просто причудливое название для ограничений входных значений.
• «determination_requirements» — это определение сигналов, которые необходимо проверить (как выходные сигналы процессора, так и архитектурные состояния).
• Раздел «property_graph» — это просто привязка этого файла ко всем свойствам, созданным на шаге 1.

Подведем итоги: на шаге 1 вы создали модель ИУ с точностью до цикла, истинность которой должна быть доказана для всех времен и всех входов; на шаге 2 вы устанавливаете ограничения и особые варианты поведения, на которые следует обратить внимание. Сложите их вместе, и, по сути, вы получите формальный тестовый стенд, готовый к запуску!

Шаг 3 – Выполнение анализа

Цель всех формальных инструментов — исчерпывающе доказать, что все свойства верны для любого времени и всех входных данных. В случае проверки процессора RISC-V инструмент работает, чтобы доказать, что любая входная последовательность произвольной длины может быть сопоставлена ​​с уникальной последовательностью указанного Operational SVA, которая прогнозирует значения выходов и архитектурные состояния.

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

В любом случае, когда эти проблемы исправлены и инструмент подтверждает все свойства, результаты действительно «полные» — т. е. вы можете быть математически уверены, что нет ошибок кодирования RTL — формальный анализ буквально доказал отсутствие каких-либо ошибок. !

Итоги

Во-первых, как отмечалось выше, за прошедшие годы многие разработчики процессоров воспользовались этим подходом [2], [3], [4].

Опробовав эту методологию с помощью RISC-V, мои коллеги провели тематическое исследование с использованием популярного ядра Rocket Chip с открытым исходным кодом. В частности, была рассмотрена конфигурация виртуальной машины RV64IMAFDC — sv39. Это 64-битное процессорное ядро ​​с 39-битной системой виртуальной памяти [5] и расширениями, такими как сжатые и атомарные инструкции [6]. Эта реализация RISC-V ISA с открытым исходным кодом использует пятиэтапный, однозадачный, упорядоченный конвейер с внеочередным завершением для инструкций с большой задержкой, таких как деление или промахи в кэше. Ядро также поддерживает прогнозирование ветвлений и модификацию регистра «misa» во время выполнения, что позволяет отключать определенные расширения набора команд.

Хотя этот снимок Rocket Chip был тщательно проверен и записан несколько раз, были выявлены четыре ранее неизвестных подозрительных поведения, о которых было сообщено разработчикам Rocket Core RTL. Эти проблемы ([7], [8], [9] и [10]) были обнаружены исключительно благодаря систематическому применению подхода полной формальной проверки, изложенного в этой статье.

Конкретно [10] — обнаружение нестандартной инструкции CEASE (код операции 0x30500073) в RTL: явно команда Rocket Chip отстала от документации (и исправила это почти сразу после подачи запроса на извлечение GitHub). Более важный момент заключается в том, что это демонстрирует, что логика, необходимая для реализации всей инструкции — десятки строк кода и множество элементов синтезированной, размещенной и маршрутизируемой логики — может избежать обнаружения при визуальном осмотре, моделировании RTL, моделировании уровня вентиля и т. д. процесс внутренней реализации и прототипы оборудования в лаборатории!

А как насчет производительности этого потока?

Во-первых, давайте обратимся к более широкому значению слова «производительность». Из-за новизны конструкции Rocket Chip в рамках данного тематического исследования нашим специалистам по формальной проверке потребовалось около 20 недель, чтобы разработать весь испытательный стенд и ограничения. Однако предыдущие применения этого потока в более структурированной коммерческой интеллектуальной собственности обычно занимали часть этого времени. Естественно, весь процесс разработки будет проходить намного быстрее, чем стабильнее и зрелее будут спецификации, насколько хорошо документирован и удобочитаем код DUT RTL и насколько у вас есть доступ к инженерам-проектировщикам для вопросов и ответов.

После настройки среды время работы настенных часов составило всего 2 часа — то есть намного меньше, чем можно было разумно ожидать от ограниченно-случайного моделирования RTL и даже аппаратной проверки. Плюс напомним, что результаты этого анализа действительны для всех входных данных и в любое время — словом, они являются исчерпывающими [11].

Обзор

Полный формальный подход к проверке процессора, представленный в этой статье, использует расширение IEEE SVA, Operational SVA, для формальной проверки отсутствия пробелов и несоответствий в RISC-V ISA. В отличие от тестовых стендов с ограниченно-случайным моделированием, эмуляции или физического прототипирования, полный набор свойств и ограничений исчерпывающе обнаруживает многие типы ошибок RTL, а также наличие недокументированного или плохо определенного кода и вредоносных троянов.

Рекомендации

1 – Конференция GOMACTech 2019, Альбукерке, Нью-Мексико, 28 марта 2019 г.: Полная формальная проверка IP-адресов процессоров RISC-V для доверенных микросхем без троянов, Дэвид Лэндолл и др.

2 – DVCon 2007: Полная официальная проверка TriCore2 и других процессоров, Infineon Gmbh.

3 – 51^st Конференция по автоматизации проектирования (DAC): формальная проверка применительно к платформе проектирования Renesas MCU с использованием инструментов OneSpin

4 – DVCon Europe 2019: Полная официальная проверка семейства автомобильных DSP, Bosch Gmbh.

5 – Руководство по набору команд RISC-V, Том II: Привилегированная архитектура, версия документа 1.10.

6 - https://github.com/freechipsproject/rocket-chip [по состоянию на 20 декабря 2018 г.]

7 – Результат инструкции DIV не записывается в файл регистрации
https://github.com/freechipsproject/rocket-chip/issues/1752

8 – Инструкции JAL и JALR хранят разные возвращаемые ПК
https://github.com/freechipsproject/rocket-chip/issues/1757

9. Недопустимые коды операций воспроизводятся и вызывают неожиданные побочные эффекты
https://github.com/freechipsproject/rocket-chip/issues/1861

10 – Нестандартная инструкция CEASE (код операции 0x30500073), обнаруженная в RTL, https://github.com/freechipsproject/rocket-chip/issues/1868

11 – Блог Verification Horizons, «Как вы можете сказать, что формальная проверка является исчерпывающей?», Джо Хапси III
https://blogs.sw.siemens.com/verificationhorizons/2021/09/16/how-can-you-say-that-formal-verification-is-exhaustive/

Источник: https://semiengineering.com/do-you-know-for-sure-your-risc-v-rtl-doesnt-contain-any-surprises/