Данная запись является продолжением записи «Использование информации о структуре микроархитектурных моделей при верификации: вступление». Поэтому я полагаю, что читатель уже имеет представление о языке моделирования xMAS и его примитивах, описанных в предыдущей статье.
В конце предыдущей записи я показал соотношение, связывающее число пакетов в различных очередях простейшего фрагмента архитектурной модели. В этот раз я попробую привести более содержательный пример, чтобы объяснить зачем такие соотношения могут быть полезны. Ну и, само собой, покажу, как можно получать подобные соотношения автоматически, используя информацию о структуре модели.
Пример: схема с использованием кредитной логики
Рассмотрим модель xMAS на рис. 1. Эта модель показывает взаимодействие двух простейших агентов: ведущий агент (master) M передает данные ведомому (target) T. Схема кредитной логики(credit logic), входящая в состав target, в любой момент времени предоставляет не более kкредитов ведущему агенту. Master обязан дождаться получения кредита со стороны ведомого агента прежде чем сможет передать данные.
![]()
Рисунок 1.
Назначение механизма обмена кредитами в том, чтобы гарантировать, что во входящей очереди (ingress queue) target всегда есть место для данных передаваемых master. Иными словами, никакая передача на канале r не застревает по причине неготовности target принять данные. Такое свойство канала rназывается неблокирующим (non-blocking). В терминах LTL это свойство выглядит следующим образом:
В приведенной на рис. 1 модели кредиты высвобождаются в момент чтения данных из входящей очереди.
Неблокирующее свойство канала rне является индуктивным, и, поэтому, сложно для доказательства (используя Intel Xeon 3 GHz, доказательство занимает несколько часов).
Однако, после добавления следующего инварианта (аналогичного приведенному в предыдущей записи)
Неблокирующее свойство становится индуктивным и доказывается менее чем за секунду. Здесь numc, numi и numo обозначают количество пакетов в соответствующих очередях:
Единственный вопрос – как получить этот инвариант?
Поиск инвариантов
Введем обозначение trans(X), показывающее общее число передач пакетов на канале Xс начального момента времени.
Анализируя уравнения, описывающие поведение примитивов, нетрудно показать, что, например, для барьера(join) передача пакетов происходит одновременно на обоих входных каналах и выходном канале, или не происходит вовсе. Это позволяет записать следующие равенства:
Аналогично, для форка(fork) можно показать, что передача пакетов проиходит одновременно на обоих выходах и входе, или не происходит вовсе. Иными словами:
Ситуация с очередью(queue) более интересна: любой пакет попавший в очередь или всё еще находится внутри, или покинул очередь через выход. Т.е.:
Заметьте, с одной стороны эти выражения были получены нами «бесплатно» - без каких либо вычислений. С другой стороны, мы использовали знание о поведении отдельных примитивов и том, какие каналы ими связываются. А это ни что иное, как информация о структуре модели, которая, после того, как модель транслируется в описание на языке Verilog, недоступна инструментам верификации.
Но откуда всё-таки возьмется интересующий наш инвариант? Оказывается, если применить к этой системе из 7 уравнений, например, алгоритм Гаусса для того, чтобы избавиться от переменных trans(), то мы получим в точности интересующее нас соотношение.
Вот такое простое и элегантное решение. Есть и другие подходы, работающие для инвариантов других типов. Однако, они гораздо сложнее и я не буду о них писать.
И напоследок замечу, что инварианты, получаемые таким образом для реальных моделей, могут связывать десятки очередей в абсолютно неочевидных соотношениях и просто посмотрев пристально на модель их найти не удастся. А если к этому добавить разделение между так называемыми виртуальными каналами… Но об этом как-нибудь в другой раз.
В конце предыдущей записи я показал соотношение, связывающее число пакетов в различных очередях простейшего фрагмента архитектурной модели. В этот раз я попробую привести более содержательный пример, чтобы объяснить зачем такие соотношения могут быть полезны. Ну и, само собой, покажу, как можно получать подобные соотношения автоматически, используя информацию о структуре модели.
Пример: схема с использованием кредитной логики
Рассмотрим модель xMAS на рис. 1. Эта модель показывает взаимодействие двух простейших агентов: ведущий агент (master) M передает данные ведомому (target) T. Схема кредитной логики(credit logic), входящая в состав target, в любой момент времени предоставляет не более kкредитов ведущему агенту. Master обязан дождаться получения кредита со стороны ведомого агента прежде чем сможет передать данные.
Рисунок 1.
Назначение механизма обмена кредитами в том, чтобы гарантировать, что во входящей очереди (ingress queue) target всегда есть место для данных передаваемых master. Иными словами, никакая передача на канале r не застревает по причине неготовности target принять данные. Такое свойство канала rназывается неблокирующим (non-blocking). В терминах LTL это свойство выглядит следующим образом:
G (r.irdy => r.trdy).В приведенной на рис. 1 модели кредиты высвобождаются в момент чтения данных из входящей очереди.
Неблокирующее свойство канала rне является индуктивным, и, поэтому, сложно для доказательства (используя Intel Xeon 3 GHz, доказательство занимает несколько часов).
Однако, после добавления следующего инварианта (аналогичного приведенному в предыдущей записи)
G(numc + numi = numo)Неблокирующее свойство становится индуктивным и доказывается менее чем за секунду. Здесь numc, numi и numo обозначают количество пакетов в соответствующих очередях:
Numi – число пакетов, ожидающих обслуживания во входящей очереди target
Numc – число свободных кредитов (доступных master для передачи пакетов)
Numo – общее число кредитов, предоставленных кредитной логикой.
Единственный вопрос – как получить этот инвариант?
Поиск инвариантов
Введем обозначение trans(X), показывающее общее число передач пакетов на канале Xс начального момента времени.
Анализируя уравнения, описывающие поведение примитивов, нетрудно показать, что, например, для барьера(join) передача пакетов происходит одновременно на обоих входных каналах и выходном канале, или не происходит вовсе. Это позволяет записать следующие равенства:
trans(e) = trans(f) = trans®
trans(s) = trans(w) = trans(z)Аналогично, для форка(fork) можно показать, что передача пакетов проиходит одновременно на обоих выходах и входе, или не происходит вовсе. Иными словами:
trans(t) = trans(u) = trans(w)
trans(p) = trans(n) = trans(s)Ситуация с очередью(queue) более интересна: любой пакет попавший в очередь или всё еще находится внутри, или покинул очередь через выход. Т.е.:
trans® = numi + trans(p)
trans(t) = numc + trans(e)
trans(v) = numo + trans(w)Заметьте, с одной стороны эти выражения были получены нами «бесплатно» - без каких либо вычислений. С другой стороны, мы использовали знание о поведении отдельных примитивов и том, какие каналы ими связываются. А это ни что иное, как информация о структуре модели, которая, после того, как модель транслируется в описание на языке Verilog, недоступна инструментам верификации.
Но откуда всё-таки возьмется интересующий наш инвариант? Оказывается, если применить к этой системе из 7 уравнений, например, алгоритм Гаусса для того, чтобы избавиться от переменных trans(), то мы получим в точности интересующее нас соотношение.
Вот такое простое и элегантное решение. Есть и другие подходы, работающие для инвариантов других типов. Однако, они гораздо сложнее и я не буду о них писать.
И напоследок замечу, что инварианты, получаемые таким образом для реальных моделей, могут связывать десятки очередей в абсолютно неочевидных соотношениях и просто посмотрев пристально на модель их найти не удастся. А если к этому добавить разделение между так называемыми виртуальными каналами… Но об этом как-нибудь в другой раз.