В прошлых записях я рассказывал о том, что такое коммуникационные фабрики, в чем заключаются проблемы связанные с их проектированиеми верификацией, а также об использовании высокоуровневого моделированиякак подхода к решению проблемы сложности. Однако, даже имея высокоуровневую модель микроархитектуры, абстрагированную от многих деталей реализации, для верификации простейших свойств такой модели требуются дополнительные усилия.
В этой записи я немного расскажу о том, что представляет собой процесс верификации простейших свойств с одной из точек зрения, почему его сложность высока и как с ней бороться.
Пространство состояний
Состояние фрагмента архитектурной модели можно описать некоторым количеством бит состояния, число которых равно числу регистров внутри данного фрагмента модели и числу входных сигнальных линий. Соответственно, как учит комбинаторика, число возможных состояний для такого фрагмента равно двум в степени количества бит состояния. Очевидно, что даже для простейшей модели это число огромно.
Т.к. состояние системы не статично, а меняется в процессе работы, то состояния можно представить в виде вершин ориентированного графа – графа состояний, дуги которого соответствуют возможным переходам между состояниями.
Верификация простейшего свойства
В качестве примера рассмотрим простейшее свойство: «определенный бит состояния всегда сохраняет нулевое значение». Для доказательства такого свойства нам необходимо убедиться, что это свойство выполняется во всех вершинах графа состояний, достижимых из начального состояния. В качестве начального состояния выбирается то состояние, в котором система находится после выполнения сброса/начальной установке.
Конечно, в чистом виде состояния никто не перебирает, вместо этого используются различные нетривиальные подходы для представления групп состояний и техники на основе решений SAT задачи. Но, в силу размерности это всё равно крайне трудоемкая задача.
Ограничение пространства состояний
Практически во всех системах большая часть состояний не является допустимыми. Исключение части недопустимых состояний позволяет радикально ускорить процесс верификации. Это можно сделать путем формулирования вспомогательных свойств (инвариантов), которые определяют, является ли состояние корректным. Такие свойства можно сформулировать на основе информации о структуре системы и логике её работы.
Недопустимые состояния можно разделить на две категории: недопустимые по структуре и недопустимые по выполнению.
Приведу примеры.
Предположим, в структуре передаваемых по модели пакетов есть четырехбитное поле (диапазон значений 0-15), хранящее номер передающего устройства. Но в системе присутствует только 10 передающих устройств (номера 0-9). Соответственно, все состояния содержащие пакеты, в соответствующем поле которых находится значение большее 9, не являются допустимыми по своей структуре.
Другой пример:
Предположим, что в системе есть фрагмент, состоящий из двух параллельных очередей с емкостью 2 пакета (см. рис.). Схема устроена так, что пакеты помещаются и извлекаются из очередей только одновременно, а после сброса очереди пусты. В ходе работы системы очереди такого фрагмента всегда будут содержать равное число пакетов.
Ситуация, когда количество корректных пакетов в этих двух очередях различно, является корректной, но она недостижима ни на каком из путей выполнения системы. Это недопустимое по выполнению состояние.
Кроме того, такие ситуации привносят неожиданные поведения в систему. В частности, если одна из очередей целиком заполнена, а другая пуста, то такой фрагмент полностью блокирует движение пакетов через систему. Так как одна очередь полностью заполнена, то нельзя одновременно поместить по одному пакету в каждую из очередей. Аналогично, нельзя одновременно извлечь из каждой очереди по пакету.
![]()
Фрагмент микроархитектурной модели из двух параллельных очередей
Верификация свойства из произвольного состояния
При верификации простейшего свойства описанного выше можно воспользоваться не подходом поиска на графе состояний, начиная из начального состояния системы, а иным подходом. В качестве проверяемого состояния можно использовать не конкретное состояние системы, а произвольное, абстрактное, ограниченное вспомогательными инвариантами. Достоинством такого подхода является то, что нам необходимо проверить единственное состояние, что быстрее поиска перебором на графе.
Недостатком же такого подхода является то, что неудача в доказательстве свойства совершенно не означает, что оно действительно нарушается. Возможно, система ограничивающих инвариантов недостаточно сильна и не отсекает часть недопустимых состояний. И одно из таких недопустимых состояний в результате приводится как контр пример к доказываемому свойству.
Запись получилась не очень длинная, отчасти потому, что и февраль – месяц короткий :). В следующей записи я думаю написать о том, как можно верифицировать более нетривиальные свойства, формулируемые с помощью операторов линейной темпоральной логики, например, свойств ограничения задержки передачи данных.
В этой записи я немного расскажу о том, что представляет собой процесс верификации простейших свойств с одной из точек зрения, почему его сложность высока и как с ней бороться.
Пространство состояний
Состояние фрагмента архитектурной модели можно описать некоторым количеством бит состояния, число которых равно числу регистров внутри данного фрагмента модели и числу входных сигнальных линий. Соответственно, как учит комбинаторика, число возможных состояний для такого фрагмента равно двум в степени количества бит состояния. Очевидно, что даже для простейшей модели это число огромно.
Т.к. состояние системы не статично, а меняется в процессе работы, то состояния можно представить в виде вершин ориентированного графа – графа состояний, дуги которого соответствуют возможным переходам между состояниями.
Верификация простейшего свойства
В качестве примера рассмотрим простейшее свойство: «определенный бит состояния всегда сохраняет нулевое значение». Для доказательства такого свойства нам необходимо убедиться, что это свойство выполняется во всех вершинах графа состояний, достижимых из начального состояния. В качестве начального состояния выбирается то состояние, в котором система находится после выполнения сброса/начальной установке.
Конечно, в чистом виде состояния никто не перебирает, вместо этого используются различные нетривиальные подходы для представления групп состояний и техники на основе решений SAT задачи. Но, в силу размерности это всё равно крайне трудоемкая задача.
Ограничение пространства состояний
Практически во всех системах большая часть состояний не является допустимыми. Исключение части недопустимых состояний позволяет радикально ускорить процесс верификации. Это можно сделать путем формулирования вспомогательных свойств (инвариантов), которые определяют, является ли состояние корректным. Такие свойства можно сформулировать на основе информации о структуре системы и логике её работы.
Недопустимые состояния можно разделить на две категории: недопустимые по структуре и недопустимые по выполнению.
Приведу примеры.
Предположим, в структуре передаваемых по модели пакетов есть четырехбитное поле (диапазон значений 0-15), хранящее номер передающего устройства. Но в системе присутствует только 10 передающих устройств (номера 0-9). Соответственно, все состояния содержащие пакеты, в соответствующем поле которых находится значение большее 9, не являются допустимыми по своей структуре.
Другой пример:
Предположим, что в системе есть фрагмент, состоящий из двух параллельных очередей с емкостью 2 пакета (см. рис.). Схема устроена так, что пакеты помещаются и извлекаются из очередей только одновременно, а после сброса очереди пусты. В ходе работы системы очереди такого фрагмента всегда будут содержать равное число пакетов.
Ситуация, когда количество корректных пакетов в этих двух очередях различно, является корректной, но она недостижима ни на каком из путей выполнения системы. Это недопустимое по выполнению состояние.
Кроме того, такие ситуации привносят неожиданные поведения в систему. В частности, если одна из очередей целиком заполнена, а другая пуста, то такой фрагмент полностью блокирует движение пакетов через систему. Так как одна очередь полностью заполнена, то нельзя одновременно поместить по одному пакету в каждую из очередей. Аналогично, нельзя одновременно извлечь из каждой очереди по пакету.
Фрагмент микроархитектурной модели из двух параллельных очередей
Верификация свойства из произвольного состояния
При верификации простейшего свойства описанного выше можно воспользоваться не подходом поиска на графе состояний, начиная из начального состояния системы, а иным подходом. В качестве проверяемого состояния можно использовать не конкретное состояние системы, а произвольное, абстрактное, ограниченное вспомогательными инвариантами. Достоинством такого подхода является то, что нам необходимо проверить единственное состояние, что быстрее поиска перебором на графе.
Недостатком же такого подхода является то, что неудача в доказательстве свойства совершенно не означает, что оно действительно нарушается. Возможно, система ограничивающих инвариантов недостаточно сильна и не отсекает часть недопустимых состояний. И одно из таких недопустимых состояний в результате приводится как контр пример к доказываемому свойству.
Запись получилась не очень длинная, отчасти потому, что и февраль – месяц короткий :). В следующей записи я думаю написать о том, как можно верифицировать более нетривиальные свойства, формулируемые с помощью операторов линейной темпоральной логики, например, свойств ограничения задержки передачи данных.