Wiki - Вклад участника [ru]

PSL/A Practical Introduction to PSL/SERE Style

2014-02-17T08:22:58Z

Valentin: /* 5.4 Операторы повторения SERE ([*n], [=n], и [->n]) */

{{PSL TOC}}

=Стиль SERE=


До этого момента, мы видели свойства PSL, построенные на булевых выражениях и временных операторах в стиле LTL. Другой путь построения свойств использует SERE - Последовательные расширения регулярных выражений. SERE по-сути тоже самое, что и регулярные выражения, как те, которые используются для сопоставления во многих приложениях. Отличие лишь в том, что атом SERE - булево выражение, в то время, как атомы стандартного регулярного выражения - отдельные символы.


SERE обычно заключается в фигурные скобки, и атом SERE обычно разделен точкой с запятой. Например, <code>{a;b;c}</code> - это SERE, и SERE 5.1a - это более сложный SERE. SERE 5.1a описывает последовательность циклов, в которых утверждается <code>(req_out && !ack)</code> на первом цикле, далее <code>(busy && !ack)</code> утверждается нуль или более циклов, показанный последовательным оператором повторения <code>[*]</code>, и в итоге утверждается ack. Таким образом, SERE 5.1a отмечает последовательность циклов, под лейблом “1” в тракте 5.1(i).


Не поддавайтесь искушению в трактовке SERE более, чем показано здесь: SERE 5.1a показывает последовательность циклов под лейблом “2” в тракте 5.1(i). SERE 5.1a не запрещает утверждения занятости в течение последнего цикла SERE. Если важно исключить такое поведение, занятость может быть явно указана, как показано в SERE 5.1b. SERE 5.1b показывает последовательность циклов под лейблом “1”, показанная на тракте 5.1(i), но не показывает последовательность циклов под лейблом “2” в этом же тракте.


Как использовать SERE? Во-первых, SERE может также быть под-свойством. Например, свойство 5.2a выполняется, если существует утверждение <code>req_in && gnt</code>, далее начиная со следующего цикла, мы видим последовательность циклов отмеченных SERE 5.1a. Свойство 5.2a выполняется на тракте 5.2(i).


Примечание: SERE - это свойство, но свойство это не всегда SERE. Таким образом, пока мы можем использовать SERE, как операнд временного оператора, мы не можем вставить временной оператор, такой как <code>always</code> или <code>next</code>, внутрь SERE.


Сейчас предположим, что у нас есть ситуация похожая на свойство 5.2a, но в которой грант (утверждение сигнала <code>gnt</code>) появляется циклом ''позже'' утверждения <code>req_in</code>. Мы можем попробовать заменить булево выражение <code>req_in && gnt</code> временным выражением <code>req_in && next gnt</code>, как в свойстве 5.3a. Однако, вспомним урок раздела 3.4: в свойстве 5.3a текущий цикл лева-ориентированной стороны <tt>(req_in && next gnt)</tt> тот же самый, что и текущий цикл право-ориентированной стороны (потому что они соединены булевым оператором <tt>-></tt>). Таким образом, текущий цикл <code>gnt</code> (который является операндом оператора <code>next</code>) - это тот же текущий цикл для SERE (который также является операндом оператора <code>next</code>). Это немного запутанно, и действительно свойство 5.3а не принадлежит простому подмножеству PSL, которые мы обсуждали в главе 9.


Давайте модифицируем свойство 5.3а, как показано в свойстве 5.3b. Сейчас один оператор <code>next</code> применяется для обоих, <code>gnt</code> и SERE, которые являются операндами оператора <code>-></code>. Свойство 5.3b эквивалентно свойству 5.3a, но оно из просто подмножества, делая более простым отслеживание временной выборки между <code>gnt</code> и SERE. Если мы подразумеваем, что текущий цикл SERE должен быть циклом ''позже'' <code>gnt</code>, мы можем манипулировать свойством 5.3b, добавляя <code>next</code>, как в свойстве 5.3c. Однако, суффиксная импликация операторов предоставляет более простой путь.

{| align=center
! [[Файл:Psl fig5.1.png]]
|-
!(i) SERE 5.1a отмечает 1 и 2. SERE 5.1b отмечает 1, но не 2.
|-
|<pre>
{(req_out && !ack) ; (busy && !ack)[*] ; ack} (5.1a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack && !busy} (5.1b)
</pre>
|-
! Рис. 5.1: Два простых SEREs
|}

{| align=center
! [[Файл:Psl fig5.2.png]]
|-
!(i) Свойство 5.2a выполняется
|-
|<pre>
always ((req_in && gnt) -> (5.2a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
</pre>
|-
! Рис. 5.2: SERE - свойство
|}

{| align=center width=80%
|<pre>
always ((req_in && next gnt) -> (5.3a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
always (req_in -> next (gnt -> (5.3b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}))
always (req_in -> next (gnt -> (5.3c)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack}))
</pre>
|-
! Рис. 5.3: Свойство 5.3a не из простого подмножества. Свойства 5.3b и 5.3c из простого подмножества,
но они сложны для чтения. Эти свойства можно выразить проще, используя суффиксную импликацию.
|}

==5.1 Суффиксная импликация (<code>|-></code> и <code>|=></code>)==


Операторы ''суффиксной импликации'' (<code>|-></code> и <code>|=></code>) предоставляют возможность ссылаться на два SERE таким образом, что право-ориентированная сторона начинает работать, когда лева-сторонняя сторона заканчивает работы. Параллельный оператор суффиксной импликации (<code>|-></code>) интерпретирует “когда лева-ориентированная сторона заканчивает работать” также, как “в том же цикле, когда лева-ориентированная сторона заканчивает работать”, в то время как не параллельный оператор суффиксной импликации (<code>|=></code>) интерпретирует это, как “цикл после цикла, в котором лева-ориентированная сторона завершила работу”. Таким образом, свойство 5.4а эквивалентно свойству 5.3b, и свойство 5.4b эквивалентно свойству 5.3c. Оба свойства 5.4a и 5.4b легче для понимания, чем эквивалентное свойство без суффиксной импликации , и оба принадлежат простому подмножеству из главы 9.

{| align=center
! [[Файл:Psl fig5.4.png]]
|-
|<pre>
always {req_in;gnt} |-> (5.4a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.4b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}

</pre>
|-
! Рис. 5.4: Суффиксная импликация
|}


Напомним, что логический оператор импликации (<code>-></code>) может интерпретироваться, как if-then выражение, с безоговорочно утвержденной else-частью. Суффиксный оператор импликации (<code>|-></code> and <code>|=></code>) может восприниматься также. Разница между логическим оператором импликации (<code>-></code>) и суффиксным оператором импликации (<code>|-></code> and <code>|=></code>) во временных взаимоотношениях между if- и then-частями. В то время, как текущий цикл then-части для оператора логической импликации
(->) тот же, что и для if-части, текущий цикл then-части суффиксного оператора импликации (<code>|-></code> or <code>|=></code>) это первый цикл ''суффикса'' тракта, который остается после того, как сменяется if-часть. Это показано для свойств 5.4a и 5.4b в трактах 5.4(i) и 5.4(ii).

{| align=center
! [[Файл:Psl fig5.5.png]]
|-
! (i) Тракт имеет множественные if-then пары. Свойство 5.5a выполняется.
|-
|<pre>
always {req_in;gnt} |=> (5.5a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.5: if-часть другой if-then пары может начаться перед тем, как if-часть или
then-часть предыдущей if-then пары выполниться
|}


В трактах 5.4(i) и 5.4(ii) присутствует единичное утверждение сигнала <code>req_in</code>. Если бы здесь было множественные утверждения <code>req_in</code>, то, конечно же, мы должны были бы идентифицировать множественные if-then пары, как показано в тракте 5.5(i). Отметим, что if-часть другой if-then пары может начинаться, перед завершение выполнения if-части или then-части предыдущей if-then пары. Например, вторая if-then пара начинается в седьмом цикле, перед тем, как выполнится then-часть первой пары. Третья if-then прара начинается в цикле 8, перед тем как выполнятся then-часть первой пары и if-часть второй пары. Мы могли видеть такой вид перекрытия ранее, в трактах 2.2(ii) и 2.3(iii). Отметим, что в тракте 5.5(i) утверждение <code>ack</code> в цикле 16 завершает then-часть второй и третьей if-then пары. Для более глубокого объяснения этого феномена,смотрите раздел 13.4.2.

Свойства 5.6a и 5.6b выполняются в тракте 5.6(i), потому что не существует последовательности циклов согласованных с левой стороной, т.о. else-часть по-умолчанию утверждается в каждом цикле.

{| align=center
! [[Файл:Psl fig5.6.png]]
|-
! (i) Свойства 5.6a и 5.6b выполняются
|-
|<pre>
always {req_in;gnt} |-> (5.6a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.6b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.6: else-часть суффиксной импликации по-умолчанию утверждена
|}

==5.2 Слабый и сильный SERE==


Как и временные операторы, SERE могут быть слабыми и сильными, и как и временные операторы, сильные версии SERE обозначаются восклицательным знаком (<code>!</code>). Таким образом, свойство 5.7а, правая сторона которого - сильный SERE, выполняется только, если будет достигнут цикл, в котором встречается <code>ack</code>. Другими словами, слабая версия SERE позволяет нам принимать тракт, который является “слишком коротким”, в то время как сильная версия предполагает, что мы должны добраться до конца SERE. Таким образом, в то время как свойство 5.7a выполняется на тракте 5.7(i), также как и на тракте 5.7(ii), свойство 5.7b, сильная версия, выполняется в тракте 5.7(ii), но не в тракте 5.7(i).

{| align=center
! [[Файл:Psl fig5.7.png]]
|-
|<pre>
always {req_in;gnt} |=> (5.7a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.7b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}!
</pre>
|-
! Рис. 5.7: Слабый SERE выполняется даже, если тракт “слишком короткий”, в то время как сильный SERE,
должен “достигать конца”
|}

==5.3 Оператор <code>never</code> применимый в SERE==


Другой способ использования SERE состоит в описании событий, которые никогда не произойдут. Например, утверждение 5.8a показывает, что сигнал <code>req</code> не должен быть утвержден в двух последовательных циклах, и таким образом не выполняется в тракте 5.8(i).


Другой пример, рассмотрим утверждение 5.9a. Оно показывает, что признанный высоко приоритетный запрос (утверждение <code>req</code> вместе с <code>high_pri</code>, следует циклом позже <code>ack</code>) не может быть прерван (утверждение <code>cancel</code> циклом позже <code>ack</code>). Таким образом, оно выполняется на тракте 5.9(i), но не выполняется в тракте 5.9(ii).

{| align=center
! [[Файл:Psl fig5.8.png]]
|-
| (i) Утверждение 5.8a не выполняется
|-
|<pre>
assert never {req;req}; (5.8a)
</pre>
|-
! Рис. 5.8: Оператор never
|}

{| align=center
! [[Файл:Psl fig5.9.png]]
|-
| (i) Утверждение 5.8a не выполняется
|-
|<pre>
assert never {req && high_pri ; ack ; cancel}; (5.9a)
</pre>
|-
! Рис. 5.9: Еще об опрераторе never
|}

==5.4 Операторы повторения SERE (<code>[*n]</code>, <code>[=n]</code>, и <code>[->n]</code>)==


До теперешнего момента, мы видели основу SERE состоящую из Булевых выражений, разделенных точкой с запятой. В данном разделе мы рассмотрим операторы SERE, которые позволяют вам построить более сложные SERE, используя вариации операторов повторения SERE <code>[*n]</code>, <code>[=n]</code> и <code>[->n]</code>.


Последовательные операторы повторения предоставляют возможность получения одинаковых под-SERE во времени. Оператор <code>[*n]</code> это аббревиатура для n повторений SERE. Например, вместо того, чтобы писать <code>busy;busy;busy</code> в утверждении 5.10a, мы можем использовать <code>busy[*3]</code>, как в утверждении 5.10b. Утверждения 5.10a и 5.10b показывают, что после запроса (утверждения сигнала <code>req</code>), мы ожидаем увидеть предопределение (утверждение сигнала <code>ack</code>) с последующими тремя циклами, в которых утверждается сигнал <code>busy</code>, с последующим утверждением сигнал <code>done</code>. Тракт 5.10(i) пример тракта, в которых выполняются утверждения 5.10a и 5.10b.

{| align=center
! [[Файл:Psl fig5.10.png]]
|-
|<pre>
assert always {req} |=> {ack;busy;busy;busy;done}; (5.10a)
assert always {req} |=> {ack ; busy[*3] ; done}; (5.10b)
assert always {req} |=> {ack ; busy[*3:5] ; done}; (5.10c)
</pre>
|-
! Рис. 5.10: Операторы <code>[*n]</code> и <code>[*i:j]</code>
|}


Вместо отдельного написания числа повторений, мы можем определить диапазон, от i до j, вот так: <code>[*i:j]</code>. Таким образом, утверждение 5.10c одинаково с утверждением 5.10b, но вместо точно требуемых трех утверждений сигнала <code>busy</code>, мы требуем между тех и пяти. Утверждение 5.10c выполняются в тракте 5.10(i), также как и в тракте 5.10(ii).


Верхняя граница диапазона может быть бесконечность, которая обозначается <code>$</code> в SystemVerilog, ''null'' в GDL и inf в Verilog, VHDL и SystemC. Например, SERE <code>{b[*5:inf]}</code> предполагает пять или более повторений <code>b</code>.


Мы можем повторять не только Булевы выражения, но и SERE. Например, свойство 5.11а выполняется, если после предопределенного запроса (утверждение сигнала <code>req</code> последует утверждение сигнала <code>ack</code>), мы видим три передачи данных, с последующим утверждение сигнала <code>d_end</code>, где передача данных это утверждение сигнала <code>start</code>, с последующим утверждение сигнала <code>busy</code>, с полседующим утверждением сигнала <code>done</code>. Тракт 5.11(i) это пример тракта, в котором выполняется свойство 5.11a.


Если мы пропустим <code>n</code>, в результате SERE выберет произвольное число повторений Булевого выражения или SERE, которое повторялось. Например, утверждение свойства 5.11b показывает, что после предопределенного запроса, мы ожидаем увидеть некое число передач данных, сопровождаемых утверждением <code>done</code>. Свойство 5.11b выполняется на тракте 5.11(i), также как и трактах 5.11(ii) и 5.11(iii).


<code>[*]</code> предполагает любое количество повторений, в том числе и их отсутствие. Таким образом, свойство 5.11b выполняется на тракте 5.11(iv). Если мы хотим определить любое ненулевое число повторений, нужно использовать <code>[+]</code>. Таким образом, свойство 5.11c аналогично свойству 5.11b, но оно предполагает минимум одну передачу данных перед утверждением сигнала done. Таким образом, свойство 5.11с не выполняется на тракте 5.11(iv), но выполняется на трактах 5.11(i), 5.11(ii) и 5.11(iii).


Вместо того, чтобы опустить n, мы можем опустить Булево выражение или SERE и оставить повторение <code>[*n]</code> в одиночестве. Одинокий <code>[*n]</code> эквивалентен <code>‘true[*n]</code>. Другими словами, <code>[*n]</code> определяет любые n циклов (потому что <code>‘true</code> выполняется во всех циклах). Другой вариант восприятия этого, это понимание того, что таким образом мы можем “пропустить” <code>n</code> циклов. Таким образом, свойство 5.12a аналогично свойству Property 5.11b, но вместо подтверждения (утверждение сигнала <code>ack</code>), выполняющегося сразу после запроса (утверждения сигнала <code>req</code>), это происходит четырьмя циклами позже. Свойство 5.12a выполняется на тракте 5.12(i).


Непоследовательный оператор повторения (<code>[=n]</code>) предоставляет возможность описания повторений, которые происходят на непоследовательных циклах. Это может применять только для Булевых выражений. Например, для описания требования, что после запроса (утверждения сигнала <code>req</code>), мы ожидаем увидеть подтверждение (утверждение сигнала <code>ack</code>) в сопровождении некоторого количества циклов, включая три необязательно последовательных утверждения сигнала <code>busy</code>, в сопровождении утверждения сигнала <code>done</code>, утверждение 5.13a. Утверждение 5.13a выполняется на тракте Trace 5.13(i). Обратите внимания на циклы отмеченные “<code>busy[=3]</code>” в тракте 5.13(i). Они не начинаются с утверждением сигнала <code>busy</code> , при этом они не заканчиваются после одного. Непоследовательный оператор повторения <code>[=n]</code> определяет последовательность циклов, в которой <code>n</code> необязательно последовательное повторение Булевого выражения, включая последовательности циклов, в которых “padding” вначале и/или в конце. Другими словами, он определяет любую последовательность циклов, в которой число утверждений Булевого выражения повторится <code>n</code> раз.

Если вы хотите запретить заполнение в конце, используйте оператор повторения goto [->n]. Оператор повторения [->n] идентичен непоследовательному оператору повторения, за исключением того, что последовательность циклов будет описываться с утверждение Булевого выражения, которое должно повторяться, в конце. Другими словами, он показывает последовательность циклов, начиная с текущего цикла и заканчивая после вашего “go to” n-го вхождения в Булево выражение (использование -> предназначено для упоминания, что по стрелки вы переходите к инструкции n). Таким образом утверждение 5.13b не выполняется в тракте 5.13(i), но выполняется в тракте 5.13(ii), потому что третий busy сопровождается утверждением сигнала done.


n может быть опущен для оператора повторения goto, в этом случаи n по-умолчанию равняется 1. Другими словами, b[->] эквивалентно [->1].

Как и последовательные операторы повторения, непоследовательный оператор и оператор goto могут принимать диапазон. Таким образом, утверждение 5.14a требует три - пять не обязательных последовательных утверждений busy, после утверждения сигнала ack и перед утверждением done, в то время как утверждение 5.14b требует тоже самое, и в дополнение, то что утверждение сигнала done появляется, незамедлительно, после 3-го, 4-го или 5-го утверждения сигнала busy. Таким образом, утверждение 5.14a выполняется на трактах 5.14(i) и 5.14(ii), в то время как утверждение 5.14b выполняется на тракте 5.14(ii), но не на тракте 5.14(i).

==5.5 Concatenation (;) and fusion (:)==

We have already seen the concatenation operator, a semi-colon, which is used
to join two SEREs (or two Boolean expressions, or a Boolean expression and
a SERE) in such a way that the right-hand SERE starts the cycle after the
left-hand SERE ends. The fusion operator, a colon, is used to join two SEREs
(or two Boolean expressions, or a Boolean expression and a SERE) in such a
way that there is a single cycle of overlap between them: the right-hand SERE
starts the same cycle that the left-hand SERE ends.

For example, consider the case that we want to specify the behavior of As-
sertion 5.14b, and in addition, following the assertion of signal done, we should
see a data transfer, which consists of the assertion of signal data for some num-
ber of cycles (might be zero), followed by an assertion of signal d end. Using
the concatenation operator, we can write Assertion 5.15a. Trace 5.15(i) is a
trace on which Assertion 5.15a holds. The first assertion of signal req gets
three cycles of data before the assertion of d end, while the second assertion
of signal req sees four cycles of data before seeing d end.

If the data transfer should start the same cycle as signal done is asserted,
then we can use the fusion operator as in Assertion 5.16a. Trace 5.16(i) is an
example of a trace on which Assertion 5.16a holds. It is similar to Trace 5.15(i),
except that the data transfer starts the same cycle as that in which done is
asserted, rather than the cycle following the assertion of signal done.

Note that while it may be tempting to understand the concatenation op-
erator (;) as a delay, the operator does not necessarily “eat” a cycle. For in-
stance, in the case of the SERE {a ; b[*] ; c}, the b[*] may match zero,
one, or more cycles, as illustrated in Trace 5.17(i). The first match shown in
Trace 5.17(i) is only two cycles long, thus, the second concatenation operator
(;) did not “eat” a delay. A better way to think of it is that concatenation
gives you an ordered list of things to happen – some of them may consume
one cycle, some more, and some no cycles at all.

Further note that fusion requires an overlap of at least one cycle. Thus,
while the {b[*]} in {b[*] ; c} may match an empty sequence of cycles,
replacing the concatenation operator with the fusion operator like this: {b[*]: c}
results in a SERE with at least one assertion of b (otherwise there is
nothing to overlap with the assertion of c). In both cases, the match may
consist of a single cycle. The difference is that in the case of {b[*] ; c} the
single cycle may not include an assertion of b (because there may be zero
assertions of b preceding c), while in the case of {b[*] : c}, the single cycle
must include an assertion of b (which overlaps with the assertion of c).

==5.6 Compound SEREs==

Compound SEREs are SEREs built from other SEREs through operations
other than concatenation and fusion. The available operators allow you to
“and” or “or” together two or more SEREs, as well as to express the situation
where a match of one SERE occurs within a sequence of cycles matched by
another.

Consider the case that we want to say that signal read complete is as-
serted on the last data cycle of every read operation, where we have two kinds
of read operations: a short read consists of an assertion of signal short rd fol-
lowed by eight not necessarily consecutive assertions of data, and a long read
consists of an assertion of signal long rd followed by 32 such assertions. We
could code two separate properties, as shown in Properties 5.18a and 5.18b.
Alternatively, we could use the SERE “or” operator (|) to “or” the two SEREs
together, as in Property 5.18c.

The SERE “and” operator comes in two types: length-matching and non-
length-matching. Both the length-matching (&&) and the non-length-matching
(&) “and” operators match a sequence of cycles if starting at the current cycle,
the left-hand side and the right-hand side are matched. The difference is that
in addition, the length-matching “and” operator requires that the lengths of
the sequences matched by both the left- and right-hand sides are the same,
while the non-length-matching operator matches even if they are different. A
length-matching “and” between SEREs R and S is illustrated in Trace 5.19(i),
and a non-length-matching “and” between SEREs R and S is illustrated in
Traces 5.20(i), 5.20(ii) and 5.20(iii).

When a non-length-matching “and” is used on the left-hand side of a con-
catenation or a fusion, the current cycle of the right-hand side of the concate-
nation or fusion is determined by the longer of the two subsequences making
up the non-length-matching “and”. For instance, in the SERE {{{a;b[*5];c}
& {d[*];e}} ; f}, the current cycle of f is the cycle after the cycle in which
the longer of the two SEREs {a;b[*5];c} and {d[*];e} completes. This is
illustrated in Traces 5.21(i) and 5.21(ii). Note that in each of the traces, sig-
nal f is asserted twice: once after the completion of {a;b[*5];c}, and once
after the completion of {d[*];e}. However, in each trace, only the assertion
of signal f that happens after the completion of the longer of the two SEREs
participates in the “match” of SERE {{{a;b[*5];c} & {d[*];e}} ; f}.

NOTE: A length-matching “and” such as {a;b;c} && {d} is legal, but
makes no sense (because there is no sequence which is both 3 cycles long to
match {a;b;c} and 1 cycle long to match {d}). Many tools will probably issue
a warning for such a SERE.

As an example of the use of the length-matching “and”, consider the case
that a read request (assertion of signal read req) that is granted (assertion of
signal gnt within 5 cycles of the request) should be followed by a data transfer
(assertion of signal data start followed by some number of consecutive as-
sertions of data, followed by an assertion of data end), unless it is canceled.
A cancel is an assertion of signal cancel any time between the assertion of
read req and the assertion of gnt, inclusive. We can express this using As-
sertion 5.22a. Assertion 5.22a holds on Trace 5.22(i): the first read request is
followed by a data transfer, while the second read request is not followed by
a data transfer, but is not required to be since it is canceled.

In the case of Assertion 5.22a, we needed the length-matching “and”.
To see why, consider what would have happened had we used the non-
length-matching “and” as in Assertion 5.22b. In the case of Assertion 5.22b,
the left-hand side SERE {{read req ; [*0:4] ; gnt} & {cancel[=0]}} is
matched not only by the sequence of cycles starting at cycle 2 and ending at
cycle 5, but also by the sequences of cycles starting at cycle 2 and ending at
any of the cycles 6 through 16. Thus, Assertion 5.22b requires that we see a
data transfer starting not only at cycle 6, but also at cycles 7, 8, 9, 10 and so
on. Obviously, this is not what we wanted.

As an example where we want the non-length-matching “and” rather than
the length-matching “and”, consider the case that signal global print req
indicates that we should see a print on each of printers 1, 2, and 3 (comple-
tion of which is indicated by assertions of p1 done, p2 done, and p3 done,
respectively), and that following completion of the last print job, we should
see an assertion of signal print success. We can express this as shown in
Assertion 5.23a. Assertion 5.23a holds on Trace 5.23(i) because following the
assertion of signal global print req, we see assertions of each of the signals
p1 done, p2 done and p3 done, the last of which is followed by an assertion
of print success.

The non-length-matching “and” was needed for Assertion 5.23a. To see
why, consider what would have happened if we had used the length-matching
“and”, as in Assertion 5.23b. Assertion 5.23b does not hold on Trace 5.23(i)
because the use of the length-matching “and” means that p1 done[->],
p2 done[->] and p3 done[->] must all have the same length, i.e., that
p1 done, p2 done and p3 done must all be asserted at the same time.

The SERE within operator is useful if you want to describe a situation
where one SERE occurs within the time frame of another. For instance, sup-
pose that the normal behavior of the design is to complete a high priority
request first, even if there is a pending low priority request that started be-
fore it. However, if signal no nesting is asserted when the low priority re-
quest is issued, then this is prohibited. In other words, the situation shown
in Trace 5.24(i) is not allowed. We can describe the prohibited situation as
shown in Assertion 5.24a. Assertion 5.24a does not hold on Trace 5.24(i)
because there is a match of {high pri begin ; high pri end[->]} that is
entirely enclosed within the match of {(low pri begin && no nesting) ;
low pri end[->]}.

NOTE: If the left and right operands of a within operator are s and t
respectively, then the within operator is simply a shorthand for a length-
matching “and” between {[*] ; s ; [*]} and {t}. That is, s within t is
equivalent to {[*] ; s ; [*]} && {t}.

==5.7 More about suffix implication==

Up until now, we have seen the suffix implication operators (|-> and |=>)
used with SEREs on both the left- and the right-hand sides. While the left-
hand side of a suffix implication operator must be a SERE, the right-hand
side of a suffix implication operator can be any property. Thus, if we want to
express the requirement that whenever we have a request that is acknowledged
(assertion of req followed by an assertion of ack) we should see a grant
(assertion of signal gnt within three cycles of the acknowledge), we can code
as in Assertion 5.25a.

This is illustrated in Trace 5.25(i). In the trace, there are three occurrences
of the SERE {req;ack}. The first is followed by an assertion of ack after two
cycles, the second after three cycles, and the third after a single cycle. Thus,
Assertion 5.25a holds on the trace.

Of course, we could have written Assertion 5.25a entirely in SERE style,
as shown in Assertion 5.25b, or entirely without SEREs, as in Assertion 5.25c.
Assertions 5.25a, 5.25b and 5.25c are equivalent, thus the issue is purely one
of style. Some people prefer using only one style, others find a mix of styles,
depending on the particular property, to be easier to understand.

==5.8 The built-in function ended()==

The built-in function ended() takes a SERE as an argument and returns true
in any cycle where that SERE has just ended.1 For example, Trace 5.26(i) has
been annotated with a waveform labeled ended({a ; b[*] ; c}) to show
the value of the call to ended() at each cycle.

<blockquote>1 - In previous versions of PSL, the role of the built-in function ended() was played by
endpoints. Endpoints are no longer a part of the language – use built-in function
ended() instead.</blockquote>

How is ended() used? Consider that a complete data transfer consists of
an assertion of signal data start followed by some number of assertions of
data, followed by an assertion of data end. Consider further that we have a
signal data transfer complete that should be asserted when a data trans-
fer is completed, and that we would like to specify the correct behavior of
this signal. A good start would be Assertion 5.27a. Assertion 5.27a ensures
that data transfer complete is asserted at the conclusion of every data
transfer. But what about the other direction? That is, what about ensuring
that whenever data transfer complete is asserted, a complete data trans-
fer has indeed concluded? Assertion 5.27a does not ensure this, and thus
it holds on Trace 5.27(i), even though there are “extraneous” assertions of
data transfer complete at cycles 6 and 15. We would like an assertion that
holds on Trace 5.27(ii) but not on 5.27(i).

In order to check the second direction (that there are no extraneous asser-
tions of data transfer complete) we need to switch the direction of the
implication: we need to say that if data transfer complete is asserted,
then we have just seen the conclusion of a complete data transfer. We could
try Assertion 5.27b. However, that doesn’t work. Assertion 5.27b requires
that the SERE {data start ; data[*] ; data end} start the same cycle as
data transfer complete, while we want it to end that cycle.

This is where the built-in function ended() comes in. Using ended(),
we can code what we want as shown in Assertion 5.27c, which states that
whenever we see an assertion of data transfer complete, we must have just
seen the end of SERE {data start ; data[*] ; data end}, and it does not
hold on Trace 5.27(i).

Note that ended() returns a Boolean value. Since the left-hand side of the
suffix implication in Assertion 5.27c consists of a single Boolean expression,
we could have coded Assertion 5.27c equivalently using logical implication as
shown in Assertion 5.27d.

==5.9 Overlapping matches of a SERE==

Up until now, we have been concentrating on explaining the meaning of each
SERE operator, using relatively simple examples. It is now time to introduce
some more complex examples, in order to emphasize that like LTL style prop-
erties, interpreting a SERE style property on a trace can involve examining
overlapping sets of cycles.

Consider Property 5.28a on Traces 5.28(i) and 5.28(ii). There are multiple
matches of {a ; b[*] ; c} on Trace 5.28(i), one match ending at cycle 2,
one ending at cycle 3, and one ending at cycle 4. Property 5.28a does not
hold on Trace 5.28(i), because the matches ending at cycles 2 and 3 do not
have associated assertions of signal d at cycles 3 and 4. A suffix implication
requires that for every match of the left-hand side, the right-hand side holds.
Property 5.28a does hold on Trace 5.28(ii), because signal d is asserted after
each match of {a ; b[*] ; c}.

Note that although Property 5.28a contains an always operator, the
always operator is not the source of the overlapping matches in this case.
Rather, for a single current cycle (cycle 1), there are three separate matches
of the SERE {a ; b[*] ; c}, each ending at a different cycle.

The overlapping can happen on the right-hand side of a suffix implication
as well. Consider for example Property 5.29a on Trace 5.29(i). There are three
matches of {d ; e[*] ; f}, ending at cycles 3, 4, and 5. One match would
have been enough to satisfy Property 5.29a, because as long as there exists one
match, {d ; e[*] ; f} holds. The fact that there are in fact three matches
does not hurt. Thus, Property 5.29a holds on Trace 5.29(i).

We have just explained that we require at least one match of the right-hand
side for every match of the left-hand side of a suffix implication, and it might
seem that in so doing, we have introduced something new. Actually, the rule
could have been deduced from the parallel we have previously drawn between
a suffix implication and an if-then statement. SERE {a ; b[*] ; c} can be
understood as an infinite “or” between SEREs {a;c}, {a;b;c}, {a;b;b;c},
and so on. So Property 5.28a can be understood as “if {a;c} or {a;b;c} or
{a;b;b;c} or ..., then d”, which clearly should hold only if we see a d every
time the if-part is matched. And Property 5.29a can be understood as “if c,
then {d;f} or {d;e;f} or {d;e;e;f} or ...”, which of course should hold as
long as we have seen at least a single match of the then-part.

==5.10 How not to use SEREs==

[[Файл:Psl fig5.4.png]]

[[Файл:Psl fig5.5.png]]

[[Файл:Psl fig5.6.png]]

[[Файл:Psl fig5.7.png]]

[[Файл:Psl fig5.8.png]]

[[Файл:Psl fig5.9.png]]

[[Файл:Psl fig5.10.png]]

[[Файл:Psl fig5.11.png]]

[[Файл:Psl fig5.12.png]]

[[Файл:Psl fig5.13.png]]

[[Файл:Psl fig5.14.png]]

[[Файл:Psl fig5.15.png]]

[[Файл:Psl fig5.16.png]]

PSL/A Practical Introduction to PSL/SERE Style

2014-02-07T11:07:50Z

Valentin: /* 5.4 Операторы повторения SERE ([*n], [=n], и [->n]) */

{{PSL TOC}}

=Стиль SERE=


До этого момента, мы видели свойства PSL, построенные на булевых выражениях и временных операторах в стиле LTL. Другой путь построения свойств использует SERE - Последовательные расширения регулярных выражений. SERE по-сути тоже самое, что и регулярные выражения, как те, которые используются для сопоставления во многих приложениях. Отличие лишь в том, что атом SERE - булево выражение, в то время, как атомы стандартного регулярного выражения - отдельные символы.


SERE обычно заключается в фигурные скобки, и атом SERE обычно разделен точкой с запятой. Например, <code>{a;b;c}</code> - это SERE, и SERE 5.1a - это более сложный SERE. SERE 5.1a описывает последовательность циклов, в которых утверждается <code>(req_out && !ack)</code> на первом цикле, далее <code>(busy && !ack)</code> утверждается нуль или более циклов, показанный последовательным оператором повторения <code>[*]</code>, и в итоге утверждается ack. Таким образом, SERE 5.1a отмечает последовательность циклов, под лейблом “1” в тракте 5.1(i).


Не поддавайтесь искушению в трактовке SERE более, чем показано здесь: SERE 5.1a показывает последовательность циклов под лейблом “2” в тракте 5.1(i). SERE 5.1a не запрещает утверждения занятости в течение последнего цикла SERE. Если важно исключить такое поведение, занятость может быть явно указана, как показано в SERE 5.1b. SERE 5.1b показывает последовательность циклов под лейблом “1”, показанная на тракте 5.1(i), но не показывает последовательность циклов под лейблом “2” в этом же тракте.


Как использовать SERE? Во-первых, SERE может также быть под-свойством. Например, свойство 5.2a выполняется, если существует утверждение <code>req_in && gnt</code>, далее начиная со следующего цикла, мы видим последовательность циклов отмеченных SERE 5.1a. Свойство 5.2a выполняется на тракте 5.2(i).


Примечание: SERE - это свойство, но свойство это не всегда SERE. Таким образом, пока мы можем использовать SERE, как операнд временного оператора, мы не можем вставить временной оператор, такой как <code>always</code> или <code>next</code>, внутрь SERE.


Сейчас предположим, что у нас есть ситуация похожая на свойство 5.2a, но в которой грант (утверждение сигнала <code>gnt</code>) появляется циклом ''позже'' утверждения <code>req_in</code>. Мы можем попробовать заменить булево выражение <code>req_in && gnt</code> временным выражением <code>req_in && next gnt</code>, как в свойстве 5.3a. Однако, вспомним урок раздела 3.4: в свойстве 5.3a текущий цикл лева-ориентированной стороны <tt>(req_in && next gnt)</tt> тот же самый, что и текущий цикл право-ориентированной стороны (потому что они соединены булевым оператором <tt>-></tt>). Таким образом, текущий цикл <code>gnt</code> (который является операндом оператора <code>next</code>) - это тот же текущий цикл для SERE (который также является операндом оператора <code>next</code>). Это немного запутанно, и действительно свойство 5.3а не принадлежит простому подмножеству PSL, которые мы обсуждали в главе 9.


Давайте модифицируем свойство 5.3а, как показано в свойстве 5.3b. Сейчас один оператор <code>next</code> применяется для обоих, <code>gnt</code> и SERE, которые являются операндами оператора <code>-></code>. Свойство 5.3b эквивалентно свойству 5.3a, но оно из просто подмножества, делая более простым отслеживание временной выборки между <code>gnt</code> и SERE. Если мы подразумеваем, что текущий цикл SERE должен быть циклом ''позже'' <code>gnt</code>, мы можем манипулировать свойством 5.3b, добавляя <code>next</code>, как в свойстве 5.3c. Однако, суффиксная импликация операторов предоставляет более простой путь.

{| align=center
! [[Файл:Psl fig5.1.png]]
|-
!(i) SERE 5.1a отмечает 1 и 2. SERE 5.1b отмечает 1, но не 2.
|-
|<pre>
{(req_out && !ack) ; (busy && !ack)[*] ; ack} (5.1a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack && !busy} (5.1b)
</pre>
|-
! Рис. 5.1: Два простых SEREs
|}

{| align=center
! [[Файл:Psl fig5.2.png]]
|-
!(i) Свойство 5.2a выполняется
|-
|<pre>
always ((req_in && gnt) -> (5.2a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
</pre>
|-
! Рис. 5.2: SERE - свойство
|}

{| align=center width=80%
|<pre>
always ((req_in && next gnt) -> (5.3a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
always (req_in -> next (gnt -> (5.3b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}))
always (req_in -> next (gnt -> (5.3c)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack}))
</pre>
|-
! Рис. 5.3: Свойство 5.3a не из простого подмножества. Свойства 5.3b и 5.3c из простого подмножества,
но они сложны для чтения. Эти свойства можно выразить проще, используя суффиксную импликацию.
|}

==5.1 Суффиксная импликация (<code>|-></code> и <code>|=></code>)==


Операторы ''суффиксной импликации'' (<code>|-></code> и <code>|=></code>) предоставляют возможность ссылаться на два SERE таким образом, что право-ориентированная сторона начинает работать, когда лева-сторонняя сторона заканчивает работы. Параллельный оператор суффиксной импликации (<code>|-></code>) интерпретирует “когда лева-ориентированная сторона заканчивает работать” также, как “в том же цикле, когда лева-ориентированная сторона заканчивает работать”, в то время как не параллельный оператор суффиксной импликации (<code>|=></code>) интерпретирует это, как “цикл после цикла, в котором лева-ориентированная сторона завершила работу”. Таким образом, свойство 5.4а эквивалентно свойству 5.3b, и свойство 5.4b эквивалентно свойству 5.3c. Оба свойства 5.4a и 5.4b легче для понимания, чем эквивалентное свойство без суффиксной импликации , и оба принадлежат простому подмножеству из главы 9.

{| align=center
! [[Файл:Psl fig5.4.png]]
|-
|<pre>
always {req_in;gnt} |-> (5.4a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.4b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}

</pre>
|-
! Рис. 5.4: Суффиксная импликация
|}


Напомним, что логический оператор импликации (<code>-></code>) может интерпретироваться, как if-then выражение, с безоговорочно утвержденной else-частью. Суффиксный оператор импликации (<code>|-></code> and <code>|=></code>) может восприниматься также. Разница между логическим оператором импликации (<code>-></code>) и суффиксным оператором импликации (<code>|-></code> and <code>|=></code>) во временных взаимоотношениях между if- и then-частями. В то время, как текущий цикл then-части для оператора логической импликации
(->) тот же, что и для if-части, текущий цикл then-части суффиксного оператора импликации (<code>|-></code> or <code>|=></code>) это первый цикл ''суффикса'' тракта, который остается после того, как сменяется if-часть. Это показано для свойств 5.4a и 5.4b в трактах 5.4(i) и 5.4(ii).

{| align=center
! [[Файл:Psl fig5.5.png]]
|-
! (i) Тракт имеет множественные if-then пары. Свойство 5.5a выполняется.
|-
|<pre>
always {req_in;gnt} |=> (5.5a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.5: if-часть другой if-then пары может начаться перед тем, как if-часть или
then-часть предыдущей if-then пары выполниться
|}


В трактах 5.4(i) и 5.4(ii) присутствует единичное утверждение сигнала <code>req_in</code>. Если бы здесь было множественные утверждения <code>req_in</code>, то, конечно же, мы должны были бы идентифицировать множественные if-then пары, как показано в тракте 5.5(i). Отметим, что if-часть другой if-then пары может начинаться, перед завершение выполнения if-части или then-части предыдущей if-then пары. Например, вторая if-then пара начинается в седьмом цикле, перед тем, как выполнится then-часть первой пары. Третья if-then прара начинается в цикле 8, перед тем как выполнятся then-часть первой пары и if-часть второй пары. Мы могли видеть такой вид перекрытия ранее, в трактах 2.2(ii) и 2.3(iii). Отметим, что в тракте 5.5(i) утверждение <code>ack</code> в цикле 16 завершает then-часть второй и третьей if-then пары. Для более глубокого объяснения этого феномена,смотрите раздел 13.4.2.

Свойства 5.6a и 5.6b выполняются в тракте 5.6(i), потому что не существует последовательности циклов согласованных с левой стороной, т.о. else-часть по-умолчанию утверждается в каждом цикле.

{| align=center
! [[Файл:Psl fig5.6.png]]
|-
! (i) Свойства 5.6a и 5.6b выполняются
|-
|<pre>
always {req_in;gnt} |-> (5.6a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.6b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.6: else-часть суффиксной импликации по-умолчанию утверждена
|}

==5.2 Слабый и сильный SERE==


Как и временные операторы, SERE могут быть слабыми и сильными, и как и временные операторы, сильные версии SERE обозначаются восклицательным знаком (<code>!</code>). Таким образом, свойство 5.7а, правая сторона которого - сильный SERE, выполняется только, если будет достигнут цикл, в котором встречается <code>ack</code>. Другими словами, слабая версия SERE позволяет нам принимать тракт, который является “слишком коротким”, в то время как сильная версия предполагает, что мы должны добраться до конца SERE. Таким образом, в то время как свойство 5.7a выполняется на тракте 5.7(i), также как и на тракте 5.7(ii), свойство 5.7b, сильная версия, выполняется в тракте 5.7(ii), но не в тракте 5.7(i).

{| align=center
! [[Файл:Psl fig5.7.png]]
|-
|<pre>
always {req_in;gnt} |=> (5.7a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.7b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}!
</pre>
|-
! Рис. 5.7: Слабый SERE выполняется даже, если тракт “слишком короткий”, в то время как сильный SERE,
должен “достигать конца”
|}

==5.3 Оператор <code>never</code> применимый в SERE==


Другой способ использования SERE состоит в описании событий, которые никогда не произойдут. Например, утверждение 5.8a показывает, что сигнал <code>req</code> не должен быть утвержден в двух последовательных циклах, и таким образом не выполняется в тракте 5.8(i).


Другой пример, рассмотрим утверждение 5.9a. Оно показывает, что признанный высоко приоритетный запрос (утверждение <code>req</code> вместе с <code>high_pri</code>, следует циклом позже <code>ack</code>) не может быть прерван (утверждение <code>cancel</code> циклом позже <code>ack</code>). Таким образом, оно выполняется на тракте 5.9(i), но не выполняется в тракте 5.9(ii).

{| align=center
! [[Файл:Psl fig5.8.png]]
|-
| (i) Утверждение 5.8a не выполняется
|-
|<pre>
assert never {req;req}; (5.8a)
</pre>
|-
! Рис. 5.8: Оператор never
|}

{| align=center
! [[Файл:Psl fig5.9.png]]
|-
| (i) Утверждение 5.8a не выполняется
|-
|<pre>
assert never {req && high_pri ; ack ; cancel}; (5.9a)
</pre>
|-
! Рис. 5.9: Еще об опрераторе never
|}

==5.4 Операторы повторения SERE (<code>[*n]</code>, <code>[=n]</code>, и <code>[->n]</code>)==


До теперешнего момента, мы видели основу SERE состоящую из Булевых выражений, разделенных точкой с запятой. В данном разделе мы рассмотрим операторы SERE, которые позволяют вам построить более сложные SERE, используя вариации операторов повторения SERE <code>[*n]</code>, <code>[=n]</code> и <code>[->n]</code>.


Последовательные операторы повторения предоставляют возможность получения одинаковых под-SERE во времени. Оператор <code>[*n]</code> это аббревиатура для n повторений SERE. Например, вместо того, чтобы писать <code>busy;busy;busy</code> в утверждении 5.10a, мы можем использовать <code>busy[*3]</code>, как в утверждении 5.10b. Утверждения 5.10a и 5.10b показывают, что после запроса (утверждения сигнала <code>req</code>), мы ожидаем увидеть предопределение (утверждение сигнала <code>ack</code>) с последующими тремя циклами, в которых утверждается сигнал <code>busy</code>, с последующим утверждением сигнал <code>done</code>. Тракт 5.10(i) пример тракта, в которых выполняются утверждения 5.10a и 5.10b.

{| align=center
! [[Файл:Psl fig5.10.png]]
|-
|<pre>
assert always {req} |=> {ack;busy;busy;busy;done}; (5.10a)
assert always {req} |=> {ack ; busy[*3] ; done}; (5.10b)
assert always {req} |=> {ack ; busy[*3:5] ; done}; (5.10c)
</pre>
|-
! Рис. 5.10: Операторы <code>[*n]</code> и <code>[*i:j]</code>
|}


Вместо отдельного написания числа повторений, мы можем определить диапазон, от i до j, вот так: <code>[*i:j]</code>. Таким образом, утверждение 5.10c одинаково с утверждением 5.10b, но вместо точно требуемых трех утверждений сигнала <code>busy</code>, мы требуем между тех и пяти. Утверждение 5.10c выполняются в тракте 5.10(i), также как и в тракте 5.10(ii).


Верхняя граница диапазона может быть бесконечность, которая обозначается <code>$</code> в SystemVerilog, ''null'' в GDL и inf в Verilog, VHDL и SystemC. Например, SERE <code>{b[*5:inf]}</code> предполагает пять или более повторений <code>b</code>.


Мы можем повторять не только Булевы выражения, но и SERE. Например, свойство 5.11а выполняется, если после предопределенного запроса (утверждение сигнала <code>req</code> последует утверждение сигнала <code>ack</code>), мы видим три передачи данных, с последующим утверждение сигнала <code>d_end</code>, где передача данных это утверждение сигнала <code>start</code>, с последующим утверждение сигнала <code>busy</code>, с полседующим утверждением сигнала <code>done</code>. Тракт 5.11(i) это пример тракта, в котором выполняется свойство 5.11a.


Если мы пропустим <code>n</code>, в результате SERE выберет произвольное число повторений Булевого выражения или SERE, которое повторялось. Например, утверждение свойства 5.11b показывает, что после предопределенного запроса, мы ожидаем увидеть некое число передач данных, сопровождаемых утверждением <code>done</code>. Свойство 5.11b выполняется на тракте 5.11(i), также как и трактах 5.11(ii) и 5.11(iii).


<code>[*]</code> предполагает любое количество повторений, в том числе и их отсутствие. Таким образом, свойство 5.11b выполняется на тракте 5.11(iv). Если мы хотим определить любое ненулевое число повторений, нужно использовать <code>[+]</code>. Таким образом, свойство 5.11c аналогично свойству 5.11b, но оно предполагает минимум одну передачу данных перед утверждением сигнала done. Таким образом, свойство 5.11с не выполняется на тракте 5.11(iv), но выполняется на трактах 5.11(i), 5.11(ii) и 5.11(iii).


Вместо того, чтобы опустить n, мы можем опустить Булево выражение или SERE и оставить повторение <code>[*n]</code> в одиночестве. Одинокий <code>[*n]</code> эквивалентен <code>‘true[*n]</code>. Другими словами, <code>[*n]</code> определяет любые n циклов (потому что <code>‘true</code> выполняется во всех циклах). Другой вариант восприятия этого, это понимание того, что таким образом мы можем “пропустить” <code>n</code> циклов. Таким образом, свойство 5.12a аналогично свойству Property 5.11b, но вместо подтверждения (утверждение сигнала <code>ack</code>), выполняющегося сразу после запроса (утверждения сигнала <code>req</code>), это происходит четырьмя циклами позже. Свойство 5.12a выполняется на тракте 5.12(i).


Непоследовательный оператор повторения (<code>[=n]</code>) предоставляет возможность описания повторений, которые происходят на непоследовательных циклах. Это может применять только для Булевых выражений. Например, для описания требования, что после запроса (утверждения сигнала <code>req</code>), мы ожидаем увидеть подтверждение (утверждение сигнала <code>ack</code>) в сопровождении некоторого количества циклов, включая три необязательно последовательных утверждения сигнала <code>busy</code>, в сопровождении утверждения сигнала <code>done</code>, утверждение 5.13a. Утверждение 5.13a выполняется на тракте Trace 5.13(i). Обратите внимания на циклы отмеченные “<code>busy[=3]</code>” в тракте 5.13(i). Они не начинаются с утверждением сигнала <code>busy</code> , при этом они не заканчиваются после одного. Непоследовательный оператор повторения <code>[=n]</code> определяет последовательность циклов, в которой <code>n</code> необязательно последовательное повторение Булевого выражения, включая последовательности циклов, в которых “padding” вначале и/или в конце. Другими словами, он определяет любую последовательность циклов, в которой число утверждений Булевого выражения повторится <code>n</code> раз.

If you want to disallow the padding at the end, use the goto repetition op-
erator [->n]. The goto repetition operator [->n] is similar to the nonconsec-
utive repetition operator, except that the sequence of cycles being described
ends with an assertion of the Boolean expression being repeated. In other
words, it will match any sequence of cycles starting at the current cycle and
ending after you “go to” the nth occurrence of the Boolean expression (the
use of the -> is intended to remind you of an arrow instructing you to go to
n). Thus Assertion 5.13b does not hold on Trace 5.13(i), but it does hold on
Trace 5.13(ii) because the third busy is immediately followed by an assertion
of signal done.

The n can be omitted for the goto repetition operator, in which case n
defaults to 1. In other words, b[->] is equivalent to b[->1].

Like the consecutive repetition operators, the nonconsecutive repetition
operator and the goto repetition operator can take a range. Thus, Asser-
tion 5.14a requires three to five not necessarily consecutive assertions of busy
after the assertion of signal ack and before the assertion of done, while Asser-
tion 5.14b requires the same, and in addition that the assertion of signal done
occur immediately after the 3rd, 4th, or 5th assertion of signal busy. Thus As-
sertion 5.14a holds on Traces 5.14(i) and 5.14(ii), while Assertion 5.14b holds
on Trace 5.14(ii) but not on Trace 5.14(i).

==5.5 Concatenation (;) and fusion (:)==

We have already seen the concatenation operator, a semi-colon, which is used
to join two SEREs (or two Boolean expressions, or a Boolean expression and
a SERE) in such a way that the right-hand SERE starts the cycle after the
left-hand SERE ends. The fusion operator, a colon, is used to join two SEREs
(or two Boolean expressions, or a Boolean expression and a SERE) in such a
way that there is a single cycle of overlap between them: the right-hand SERE
starts the same cycle that the left-hand SERE ends.

For example, consider the case that we want to specify the behavior of As-
sertion 5.14b, and in addition, following the assertion of signal done, we should
see a data transfer, which consists of the assertion of signal data for some num-
ber of cycles (might be zero), followed by an assertion of signal d end. Using
the concatenation operator, we can write Assertion 5.15a. Trace 5.15(i) is a
trace on which Assertion 5.15a holds. The first assertion of signal req gets
three cycles of data before the assertion of d end, while the second assertion
of signal req sees four cycles of data before seeing d end.

If the data transfer should start the same cycle as signal done is asserted,
then we can use the fusion operator as in Assertion 5.16a. Trace 5.16(i) is an
example of a trace on which Assertion 5.16a holds. It is similar to Trace 5.15(i),
except that the data transfer starts the same cycle as that in which done is
asserted, rather than the cycle following the assertion of signal done.

Note that while it may be tempting to understand the concatenation op-
erator (;) as a delay, the operator does not necessarily “eat” a cycle. For in-
stance, in the case of the SERE {a ; b[*] ; c}, the b[*] may match zero,
one, or more cycles, as illustrated in Trace 5.17(i). The first match shown in
Trace 5.17(i) is only two cycles long, thus, the second concatenation operator
(;) did not “eat” a delay. A better way to think of it is that concatenation
gives you an ordered list of things to happen – some of them may consume
one cycle, some more, and some no cycles at all.

Further note that fusion requires an overlap of at least one cycle. Thus,
while the {b[*]} in {b[*] ; c} may match an empty sequence of cycles,
replacing the concatenation operator with the fusion operator like this: {b[*]: c}
results in a SERE with at least one assertion of b (otherwise there is
nothing to overlap with the assertion of c). In both cases, the match may
consist of a single cycle. The difference is that in the case of {b[*] ; c} the
single cycle may not include an assertion of b (because there may be zero
assertions of b preceding c), while in the case of {b[*] : c}, the single cycle
must include an assertion of b (which overlaps with the assertion of c).

==5.6 Compound SEREs==

Compound SEREs are SEREs built from other SEREs through operations
other than concatenation and fusion. The available operators allow you to
“and” or “or” together two or more SEREs, as well as to express the situation
where a match of one SERE occurs within a sequence of cycles matched by
another.

Consider the case that we want to say that signal read complete is as-
serted on the last data cycle of every read operation, where we have two kinds
of read operations: a short read consists of an assertion of signal short rd fol-
lowed by eight not necessarily consecutive assertions of data, and a long read
consists of an assertion of signal long rd followed by 32 such assertions. We
could code two separate properties, as shown in Properties 5.18a and 5.18b.
Alternatively, we could use the SERE “or” operator (|) to “or” the two SEREs
together, as in Property 5.18c.

The SERE “and” operator comes in two types: length-matching and non-
length-matching. Both the length-matching (&&) and the non-length-matching
(&) “and” operators match a sequence of cycles if starting at the current cycle,
the left-hand side and the right-hand side are matched. The difference is that
in addition, the length-matching “and” operator requires that the lengths of
the sequences matched by both the left- and right-hand sides are the same,
while the non-length-matching operator matches even if they are different. A
length-matching “and” between SEREs R and S is illustrated in Trace 5.19(i),
and a non-length-matching “and” between SEREs R and S is illustrated in
Traces 5.20(i), 5.20(ii) and 5.20(iii).

When a non-length-matching “and” is used on the left-hand side of a con-
catenation or a fusion, the current cycle of the right-hand side of the concate-
nation or fusion is determined by the longer of the two subsequences making
up the non-length-matching “and”. For instance, in the SERE {{{a;b[*5];c}
& {d[*];e}} ; f}, the current cycle of f is the cycle after the cycle in which
the longer of the two SEREs {a;b[*5];c} and {d[*];e} completes. This is
illustrated in Traces 5.21(i) and 5.21(ii). Note that in each of the traces, sig-
nal f is asserted twice: once after the completion of {a;b[*5];c}, and once
after the completion of {d[*];e}. However, in each trace, only the assertion
of signal f that happens after the completion of the longer of the two SEREs
participates in the “match” of SERE {{{a;b[*5];c} & {d[*];e}} ; f}.

NOTE: A length-matching “and” such as {a;b;c} && {d} is legal, but
makes no sense (because there is no sequence which is both 3 cycles long to
match {a;b;c} and 1 cycle long to match {d}). Many tools will probably issue
a warning for such a SERE.

As an example of the use of the length-matching “and”, consider the case
that a read request (assertion of signal read req) that is granted (assertion of
signal gnt within 5 cycles of the request) should be followed by a data transfer
(assertion of signal data start followed by some number of consecutive as-
sertions of data, followed by an assertion of data end), unless it is canceled.
A cancel is an assertion of signal cancel any time between the assertion of
read req and the assertion of gnt, inclusive. We can express this using As-
sertion 5.22a. Assertion 5.22a holds on Trace 5.22(i): the first read request is
followed by a data transfer, while the second read request is not followed by
a data transfer, but is not required to be since it is canceled.

In the case of Assertion 5.22a, we needed the length-matching “and”.
To see why, consider what would have happened had we used the non-
length-matching “and” as in Assertion 5.22b. In the case of Assertion 5.22b,
the left-hand side SERE {{read req ; [*0:4] ; gnt} & {cancel[=0]}} is
matched not only by the sequence of cycles starting at cycle 2 and ending at
cycle 5, but also by the sequences of cycles starting at cycle 2 and ending at
any of the cycles 6 through 16. Thus, Assertion 5.22b requires that we see a
data transfer starting not only at cycle 6, but also at cycles 7, 8, 9, 10 and so
on. Obviously, this is not what we wanted.

As an example where we want the non-length-matching “and” rather than
the length-matching “and”, consider the case that signal global print req
indicates that we should see a print on each of printers 1, 2, and 3 (comple-
tion of which is indicated by assertions of p1 done, p2 done, and p3 done,
respectively), and that following completion of the last print job, we should
see an assertion of signal print success. We can express this as shown in
Assertion 5.23a. Assertion 5.23a holds on Trace 5.23(i) because following the
assertion of signal global print req, we see assertions of each of the signals
p1 done, p2 done and p3 done, the last of which is followed by an assertion
of print success.

The non-length-matching “and” was needed for Assertion 5.23a. To see
why, consider what would have happened if we had used the length-matching
“and”, as in Assertion 5.23b. Assertion 5.23b does not hold on Trace 5.23(i)
because the use of the length-matching “and” means that p1 done[->],
p2 done[->] and p3 done[->] must all have the same length, i.e., that
p1 done, p2 done and p3 done must all be asserted at the same time.

The SERE within operator is useful if you want to describe a situation
where one SERE occurs within the time frame of another. For instance, sup-
pose that the normal behavior of the design is to complete a high priority
request first, even if there is a pending low priority request that started be-
fore it. However, if signal no nesting is asserted when the low priority re-
quest is issued, then this is prohibited. In other words, the situation shown
in Trace 5.24(i) is not allowed. We can describe the prohibited situation as
shown in Assertion 5.24a. Assertion 5.24a does not hold on Trace 5.24(i)
because there is a match of {high pri begin ; high pri end[->]} that is
entirely enclosed within the match of {(low pri begin && no nesting) ;
low pri end[->]}.

NOTE: If the left and right operands of a within operator are s and t
respectively, then the within operator is simply a shorthand for a length-
matching “and” between {[*] ; s ; [*]} and {t}. That is, s within t is
equivalent to {[*] ; s ; [*]} && {t}.

==5.7 More about suffix implication==

Up until now, we have seen the suffix implication operators (|-> and |=>)
used with SEREs on both the left- and the right-hand sides. While the left-
hand side of a suffix implication operator must be a SERE, the right-hand
side of a suffix implication operator can be any property. Thus, if we want to
express the requirement that whenever we have a request that is acknowledged
(assertion of req followed by an assertion of ack) we should see a grant
(assertion of signal gnt within three cycles of the acknowledge), we can code
as in Assertion 5.25a.

This is illustrated in Trace 5.25(i). In the trace, there are three occurrences
of the SERE {req;ack}. The first is followed by an assertion of ack after two
cycles, the second after three cycles, and the third after a single cycle. Thus,
Assertion 5.25a holds on the trace.

Of course, we could have written Assertion 5.25a entirely in SERE style,
as shown in Assertion 5.25b, or entirely without SEREs, as in Assertion 5.25c.
Assertions 5.25a, 5.25b and 5.25c are equivalent, thus the issue is purely one
of style. Some people prefer using only one style, others find a mix of styles,
depending on the particular property, to be easier to understand.

==5.8 The built-in function ended()==

The built-in function ended() takes a SERE as an argument and returns true
in any cycle where that SERE has just ended.1 For example, Trace 5.26(i) has
been annotated with a waveform labeled ended({a ; b[*] ; c}) to show
the value of the call to ended() at each cycle.

<blockquote>1 - In previous versions of PSL, the role of the built-in function ended() was played by
endpoints. Endpoints are no longer a part of the language – use built-in function
ended() instead.</blockquote>

How is ended() used? Consider that a complete data transfer consists of
an assertion of signal data start followed by some number of assertions of
data, followed by an assertion of data end. Consider further that we have a
signal data transfer complete that should be asserted when a data trans-
fer is completed, and that we would like to specify the correct behavior of
this signal. A good start would be Assertion 5.27a. Assertion 5.27a ensures
that data transfer complete is asserted at the conclusion of every data
transfer. But what about the other direction? That is, what about ensuring
that whenever data transfer complete is asserted, a complete data trans-
fer has indeed concluded? Assertion 5.27a does not ensure this, and thus
it holds on Trace 5.27(i), even though there are “extraneous” assertions of
data transfer complete at cycles 6 and 15. We would like an assertion that
holds on Trace 5.27(ii) but not on 5.27(i).

In order to check the second direction (that there are no extraneous asser-
tions of data transfer complete) we need to switch the direction of the
implication: we need to say that if data transfer complete is asserted,
then we have just seen the conclusion of a complete data transfer. We could
try Assertion 5.27b. However, that doesn’t work. Assertion 5.27b requires
that the SERE {data start ; data[*] ; data end} start the same cycle as
data transfer complete, while we want it to end that cycle.

This is where the built-in function ended() comes in. Using ended(),
we can code what we want as shown in Assertion 5.27c, which states that
whenever we see an assertion of data transfer complete, we must have just
seen the end of SERE {data start ; data[*] ; data end}, and it does not
hold on Trace 5.27(i).

Note that ended() returns a Boolean value. Since the left-hand side of the
suffix implication in Assertion 5.27c consists of a single Boolean expression,
we could have coded Assertion 5.27c equivalently using logical implication as
shown in Assertion 5.27d.

==5.9 Overlapping matches of a SERE==

Up until now, we have been concentrating on explaining the meaning of each
SERE operator, using relatively simple examples. It is now time to introduce
some more complex examples, in order to emphasize that like LTL style prop-
erties, interpreting a SERE style property on a trace can involve examining
overlapping sets of cycles.

Consider Property 5.28a on Traces 5.28(i) and 5.28(ii). There are multiple
matches of {a ; b[*] ; c} on Trace 5.28(i), one match ending at cycle 2,
one ending at cycle 3, and one ending at cycle 4. Property 5.28a does not
hold on Trace 5.28(i), because the matches ending at cycles 2 and 3 do not
have associated assertions of signal d at cycles 3 and 4. A suffix implication
requires that for every match of the left-hand side, the right-hand side holds.
Property 5.28a does hold on Trace 5.28(ii), because signal d is asserted after
each match of {a ; b[*] ; c}.

Note that although Property 5.28a contains an always operator, the
always operator is not the source of the overlapping matches in this case.
Rather, for a single current cycle (cycle 1), there are three separate matches
of the SERE {a ; b[*] ; c}, each ending at a different cycle.

The overlapping can happen on the right-hand side of a suffix implication
as well. Consider for example Property 5.29a on Trace 5.29(i). There are three
matches of {d ; e[*] ; f}, ending at cycles 3, 4, and 5. One match would
have been enough to satisfy Property 5.29a, because as long as there exists one
match, {d ; e[*] ; f} holds. The fact that there are in fact three matches
does not hurt. Thus, Property 5.29a holds on Trace 5.29(i).

We have just explained that we require at least one match of the right-hand
side for every match of the left-hand side of a suffix implication, and it might
seem that in so doing, we have introduced something new. Actually, the rule
could have been deduced from the parallel we have previously drawn between
a suffix implication and an if-then statement. SERE {a ; b[*] ; c} can be
understood as an infinite “or” between SEREs {a;c}, {a;b;c}, {a;b;b;c},
and so on. So Property 5.28a can be understood as “if {a;c} or {a;b;c} or
{a;b;b;c} or ..., then d”, which clearly should hold only if we see a d every
time the if-part is matched. And Property 5.29a can be understood as “if c,
then {d;f} or {d;e;f} or {d;e;e;f} or ...”, which of course should hold as
long as we have seen at least a single match of the then-part.

==5.10 How not to use SEREs==

[[Файл:Psl fig5.4.png]]

[[Файл:Psl fig5.5.png]]

[[Файл:Psl fig5.6.png]]

[[Файл:Psl fig5.7.png]]

[[Файл:Psl fig5.8.png]]

[[Файл:Psl fig5.9.png]]

[[Файл:Psl fig5.10.png]]

[[Файл:Psl fig5.11.png]]

[[Файл:Psl fig5.12.png]]

[[Файл:Psl fig5.13.png]]

[[Файл:Psl fig5.14.png]]

[[Файл:Psl fig5.15.png]]

[[Файл:Psl fig5.16.png]]

PSL/A Practical Introduction to PSL/SERE Style

2014-01-30T10:57:28Z

Valentin: /* 5.4 SERE repetition operators ([*n], [=n], and [->n]) */

{{PSL TOC}}

=Стиль SERE=


До этого момента, мы видели свойства PSL, построенные на булевых выражениях и временных операторах в стиле LTL. Другой путь построения свойств использует SERE - Последовательные расширения регулярных выражений. SERE по-сути тоже самое, что и регулярные выражения, как те, которые используются для сопоставления во многих приложениях. Отличие лишь в том, что атом SERE - булево выражение, в то время, как атомы стандартного регулярного выражения - отдельные символы.


SERE обычно заключается в фигурные скобки, и атом SERE обычно разделен точкой с запятой. Например, <code>{a;b;c}</code> - это SERE, и SERE 5.1a - это более сложный SERE. SERE 5.1a описывает последовательность циклов, в которых утверждается <code>(req_out && !ack)</code> на первом цикле, далее <code>(busy && !ack)</code> утверждается нуль или более циклов, показанный последовательным оператором повторения <code>[*]</code>, и в итоге утверждается ack. Таким образом, SERE 5.1a отмечает последовательность циклов, под лейблом “1” в тракте 5.1(i).


Не поддавайтесь искушению в трактовке SERE более, чем показано здесь: SERE 5.1a показывает последовательность циклов под лейблом “2” в тракте 5.1(i). SERE 5.1a не запрещает утверждения занятости в течение последнего цикла SERE. Если важно исключить такое поведение, занятость может быть явно указана, как показано в SERE 5.1b. SERE 5.1b показывает последовательность циклов под лейблом “1”, показанная на тракте 5.1(i), но не показывает последовательность циклов под лейблом “2” в этом же тракте.


Как использовать SERE? Во-первых, SERE может также быть под-свойством. Например, свойство 5.2a выполняется, если существует утверждение <code>req_in && gnt</code>, далее начиная со следующего цикла, мы видим последовательность циклов отмеченных SERE 5.1a. Свойство 5.2a выполняется на тракте 5.2(i).


Примечание: SERE - это свойство, но свойство это не всегда SERE. Таким образом, пока мы можем использовать SERE, как операнд временного оператора, мы не можем вставить временной оператор, такой как <code>always</code> или <code>next</code>, внутрь SERE.


Сейчас предположим, что у нас есть ситуация похожая на свойство 5.2a, но в которой грант (утверждение сигнала <code>gnt</code>) появляется циклом ''позже'' утверждения <code>req_in</code>. Мы можем попробовать заменить булево выражение <code>req_in && gnt</code> временным выражением <code>req_in && next gnt</code>, как в свойстве 5.3a. Однако, вспомним урок раздела 3.4: в свойстве 5.3a текущий цикл лева-ориентированной стороны <tt>(req_in && next gnt)</tt> тот же самый, что и текущий цикл право-ориентированной стороны (потому что они соединены булевым оператором <tt>-></tt>). Таким образом, текущий цикл <code>gnt</code> (который является операндом оператора <code>next</code>) - это тот же текущий цикл для SERE (который также является операндом оператора <code>next</code>). Это немного запутанно, и действительно свойство 5.3а не принадлежит простому подмножеству PSL, которые мы обсуждали в главе 9.


Давайте модифицируем свойство 5.3а, как показано в свойстве 5.3b. Сейчас один оператор <code>next</code> применяется для обоих, <code>gnt</code> и SERE, которые являются операндами оператора <code>-></code>. Свойство 5.3b эквивалентно свойству 5.3a, но оно из просто подмножества, делая более простым отслеживание временной выборки между <code>gnt</code> и SERE. Если мы подразумеваем, что текущий цикл SERE должен быть циклом ''позже'' <code>gnt</code>, мы можем манипулировать свойством 5.3b, добавляя <code>next</code>, как в свойстве 5.3c. Однако, суффиксная импликация операторов предоставляет более простой путь.

{| align=center
! [[Файл:Psl fig5.1.png]]
|-
!(i) SERE 5.1a отмечает 1 и 2. SERE 5.1b отмечает 1, но не 2.
|-
|<pre>
{(req_out && !ack) ; (busy && !ack)[*] ; ack} (5.1a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack && !busy} (5.1b)
</pre>
|-
! Рис. 5.1: Два простых SEREs
|}

{| align=center
! [[Файл:Psl fig5.2.png]]
|-
!(i) Свойство 5.2a выполняется
|-
|<pre>
always ((req_in && gnt) -> (5.2a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
</pre>
|-
! Рис. 5.2: SERE - свойство
|}

{| align=center width=80%
|<pre>
always ((req_in && next gnt) -> (5.3a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
always (req_in -> next (gnt -> (5.3b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}))
always (req_in -> next (gnt -> (5.3c)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack}))
</pre>
|-
! Рис. 5.3: Свойство 5.3a не из простого подмножества. Свойства 5.3b и 5.3c из простого подмножества,
но они сложны для чтения. Эти свойства можно выразить проще, используя суффиксную импликацию.
|}

==5.1 Суффиксная импликация (<code>|-></code> и <code>|=></code>)==


Операторы ''суффиксной импликации'' (<code>|-></code> и <code>|=></code>) предоставляют возможность ссылаться на два SERE таким образом, что право-ориентированная сторона начинает работать, когда лева-сторонняя сторона заканчивает работы. Параллельный оператор суффиксной импликации (<code>|-></code>) интерпретирует “когда лева-ориентированная сторона заканчивает работать” также, как “в том же цикле, когда лева-ориентированная сторона заканчивает работать”, в то время как не параллельный оператор суффиксной импликации (<code>|=></code>) интерпретирует это, как “цикл после цикла, в котором лева-ориентированная сторона завершила работу”. Таким образом, свойство 5.4а эквивалентно свойству 5.3b, и свойство 5.4b эквивалентно свойству 5.3c. Оба свойства 5.4a и 5.4b легче для понимания, чем эквивалентное свойство без суффиксной импликации , и оба принадлежат простому подмножеству из главы 9.

{| align=center
! [[Файл:Psl fig5.4.png]]
|-
|<pre>
always {req_in;gnt} |-> (5.4a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.4b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}

</pre>
|-
! Рис. 5.4: Суффиксная импликация
|}


Напомним, что логический оператор импликации (<code>-></code>) может интерпретироваться, как if-then выражение, с безоговорочно утвержденной else-частью. Суффиксный оператор импликации (<code>|-></code> and <code>|=></code>) может восприниматься также. Разница между логическим оператором импликации (<code>-></code>) и суффиксным оператором импликации (<code>|-></code> and <code>|=></code>) во временных взаимоотношениях между if- и then-частями. В то время, как текущий цикл then-части для оператора логической импликации
(->) тот же, что и для if-части, текущий цикл then-части суффиксного оператора импликации (<code>|-></code> or <code>|=></code>) это первый цикл ''суффикса'' тракта, который остается после того, как сменяется if-часть. Это показано для свойств 5.4a и 5.4b в трактах 5.4(i) и 5.4(ii).

{| align=center
! [[Файл:Psl fig5.5.png]]
|-
! (i) Тракт имеет множественные if-then пары. Свойство 5.5a выполняется.
|-
|<pre>
always {req_in;gnt} |=> (5.5a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.5: if-часть другой if-then пары может начаться перед тем, как if-часть или
then-часть предыдущей if-then пары выполниться
|}


В трактах 5.4(i) и 5.4(ii) присутствует единичное утверждение сигнала <code>req_in</code>. Если бы здесь было множественные утверждения <code>req_in</code>, то, конечно же, мы должны были бы идентифицировать множественные if-then пары, как показано в тракте 5.5(i). Отметим, что if-часть другой if-then пары может начинаться, перед завершение выполнения if-части или then-части предыдущей if-then пары. Например, вторая if-then пара начинается в седьмом цикле, перед тем, как выполнится then-часть первой пары. Третья if-then прара начинается в цикле 8, перед тем как выполнятся then-часть первой пары и if-часть второй пары. Мы могли видеть такой вид перекрытия ранее, в трактах 2.2(ii) и 2.3(iii). Отметим, что в тракте 5.5(i) утверждение <code>ack</code> в цикле 16 завершает then-часть второй и третьей if-then пары. Для более глубокого объяснения этого феномена,смотрите раздел 13.4.2.

Свойства 5.6a и 5.6b выполняются в тракте 5.6(i), потому что не существует последовательности циклов согласованных с левой стороной, т.о. else-часть по-умолчанию утверждается в каждом цикле.

{| align=center
! [[Файл:Psl fig5.6.png]]
|-
! (i) Свойства 5.6a и 5.6b выполняются
|-
|<pre>
always {req_in;gnt} |-> (5.6a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.6b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.6: else-часть суффиксной импликации по-умолчанию утверждена
|}

==5.2 Слабый и сильный SERE==


Как и временные операторы, SERE могут быть слабыми и сильными, и как и временные операторы, сильные версии SERE обозначаются восклицательным знаком (<code>!</code>). Таким образом, свойство 5.7а, правая сторона которого - сильный SERE, выполняется только, если будет достигнут цикл, в котором встречается <code>ack</code>. Другими словами, слабая версия SERE позволяет нам принимать тракт, который является “слишком коротким”, в то время как сильная версия предполагает, что мы должны добраться до конца SERE. Таким образом, в то время как свойство 5.7a выполняется на тракте 5.7(i), также как и на тракте 5.7(ii), свойство 5.7b, сильная версия, выполняется в тракте 5.7(ii), но не в тракте 5.7(i).

{| align=center
! [[Файл:Psl fig5.7.png]]
|-
|<pre>
always {req_in;gnt} |=> (5.7a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.7b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}!
</pre>
|-
! Рис. 5.7: Слабый SERE выполняется даже, если тракт “слишком короткий”, в то время как сильный SERE,
должен “достигать конца”
|}

==5.3 Оператор <code>never</code> применимый в SERE==


Другой способ использования SERE состоит в описании событий, которые никогда не произойдут. Например, утверждение 5.8a показывает, что сигнал <code>req</code> не должен быть утвержден в двух последовательных циклах, и таким образом не выполняется в тракте 5.8(i).


Другой пример, рассмотрим утверждение 5.9a. Оно показывает, что признанный высоко приоритетный запрос (утверждение <code>req</code> вместе с <code>high_pri</code>, следует циклом позже <code>ack</code>) не может быть прерван (утверждение <code>cancel</code> циклом позже <code>ack</code>). Таким образом, оно выполняется на тракте 5.9(i), но не выполняется в тракте 5.9(ii).

{| align=center
! [[Файл:Psl fig5.8.png]]
|-
| (i) Утверждение 5.8a не выполняется
|-
|<pre>
assert never {req;req}; (5.8a)
</pre>
|-
! Рис. 5.8: Оператор never
|}

{| align=center
! [[Файл:Psl fig5.9.png]]
|-
| (i) Утверждение 5.8a не выполняется
|-
|<pre>
assert never {req && high_pri ; ack ; cancel}; (5.9a)
</pre>
|-
! Рис. 5.9: Еще об опрераторе never
|}

==5.4 Операторы повторения SERE (<code>[*n]</code>, <code>[=n]</code>, и <code>[->n]</code>)==


До теперешнего момента, мы видели основу SERE состоящую из Булевых выражений, разделенных точкой с запятой. В данном разделе мы рассмотрим операторы SERE, которые позволяют вам построить более сложные SERE, используя вариации операторов повторения SERE <code>[*n]</code>, <code>[=n]</code> и <code>[->n]</code>.


Последовательные операторы повторения предоставляют возможность получения одинаковых под-SERE во времени. Оператор <code>[*n]</code> это аббревиатура для n повторений SERE. Например, вместо того, чтобы писать <code>busy;busy;busy</code> в утверждении 5.10a, мы можем использовать <code>busy[*3]</code>, как в утверждении 5.10b. Утверждения 5.10a и 5.10b показывают, что после запроса (утверждения сигнала <code>req</code>), мы ожидаем увидеть предопределение (утверждение сигнала <code>ack</code>) с последующими тремя циклами, в которых утверждается сигнал <code>busy</code>, с последующим утверждением сигнал <code>done</code>. Тракт 5.10(i) пример тракта, в которых выполняются утверждения 5.10a и 5.10b.

{| align=center
! [[Файл:Psl fig5.10.png]]
|-
|<pre>
assert always {req} |=> {ack;busy;busy;busy;done}; (5.10a)
assert always {req} |=> {ack ; busy[*3] ; done}; (5.10b)
assert always {req} |=> {ack ; busy[*3:5] ; done}; (5.10c)
</pre>
|-
! Рис. 5.10: Операторы <code>[*n]</code> и <code>[*i:j]</code>
|}


Вместо отдельного написания числа повторений, мы можем определить диапазон, от i до j, вот так: <code>[*i:j]</code>. Таким образом, утверждение 5.10c одинаково с утверждением 5.10b, но вместо точно требуемых трех утверждений сигнала <code>busy</code>, мы требуем между тех и пяти. Утверждение 5.10c выполняются в тракте 5.10(i), также как и в тракте 5.10(ii).


Верхняя граница диапазона может быть бесконечность, которая обозначается <code>$</code> в SystemVerilog, ''null'' в GDL и inf в Verilog, VHDL и SystemC. Например, SERE <code>{b[*5:inf]}</code> предполагает пять или более повторений <code>b</code>.


Мы можем повторять не только Булевы выражения, но и SERE. Например, свойство 5.11а выполняется, если после предопределенного запроса (утверждение сигнала <code>req</code> последует утверждение сигнала <code>ack</code>), мы видим три передачи данных, с последующим утверждение сигнала <code>d_end</code>, где передача данных это утверждение сигнала <code>start</code>, с последующим утверждение сигнала <code>busy</code>, с полседующим утверждением сигнала <code>done</code>. Тракт 5.11(i) это пример тракта, в котором выполняется свойство 5.11a.

If we omit the <code>n</code>, the resulting SERE matches any number of repetitions of
the Boolean expression or SERE that is being repeated. For example, asserting
Property 5.11b indicates that after an acknowledged request, we expect to see
any number of data transfers followed by an assertion of <code>done</code>. Property 5.11b
holds on Trace 5.11(i), as well as on Traces 5.11(ii) and 5.11(iii).

A <code>[*]</code> repetition matches any number of repetitions, including none. Thus,
Property 5.11b holds on Trace 5.11(iv) as well. If you want to specify any
non-zero number of repetitions, use the <code>[+]</code>. Thus, Property 5.11c is similar
to Property 5.11b, but it requires at least one data transfer before signal done
is asserted. Thus, Property 5.11c does not hold on Trace 5.11(iv), but it does
hold on Traces 5.11(i), 5.11(ii) and 5.11(iii).

Instead of omitting the n, we can omit the Boolean expression or SERE
and let the repetition <code>[*n]</code> stand alone. A stand-alone <code>[*n]</code> is equivalent
to <code>‘true[*n]</code>. In other words, <code>[*n]</code> matches any n cycles (because <code>‘true</code>
holds in all cycles). Another way to think of it is that it allows us to “skip”
<code>n</code> cycles. Thus, Property 5.12a is similar to Property 5.11b, but instead of
the acknowledge (assertion of signal <code>ack</code>) coming immediately following the
request (assertion of signal <code>req</code>), it comes four cycles later. Property 5.12a
holds on Trace 5.12(i).

The nonconsecutive repetition operator (<code>[=n]</code>) provides a way to describe
repetitions that happen on not necessarily consecutive cycles. It can be ap-
plied only to a Boolean expression. For example, to describe the requirement
that after a request (assertion of signal <code>req</code>), we expect to see an acknowledge
(assertion of signal <code>ack</code>) followed by some number of cycles including three
not necessarily consecutive assertions of signal <code>busy</code>, followed by an asser-
tion of signal <code>done</code>, we can code Assertion 5.13a. Assertion 5.13a holds on
Trace 5.13(i). Note the cycles marked “<code>busy[=3]</code>” in Trace 5.13(i). They do
not start with an assertion of <code>busy</code>, nor do they end with one. The noncon-
secutive repetition operator <code>[=n]</code> will match any sequence of cycles in which
there are <code>n</code> not necessarily consecutive repetitions of the Boolean expression
being repeated, including sequences of cycles in which the “padding” is at
the beginning and/or at the end. In other words, it will match any sequence
of cycles in which the number of assertions of the Boolean expression being
repeated is ''equal to'' <code>n</code> (thus the use of the equals sign in <code>[=n]</code>).

If you want to disallow the padding at the end, use the goto repetition op-
erator [->n]. The goto repetition operator [->n] is similar to the nonconsec-
utive repetition operator, except that the sequence of cycles being described
ends with an assertion of the Boolean expression being repeated. In other
words, it will match any sequence of cycles starting at the current cycle and
ending after you “go to” the nth occurrence of the Boolean expression (the
use of the -> is intended to remind you of an arrow instructing you to go to
n). Thus Assertion 5.13b does not hold on Trace 5.13(i), but it does hold on
Trace 5.13(ii) because the third busy is immediately followed by an assertion
of signal done.

The n can be omitted for the goto repetition operator, in which case n
defaults to 1. In other words, b[->] is equivalent to b[->1].

Like the consecutive repetition operators, the nonconsecutive repetition
operator and the goto repetition operator can take a range. Thus, Asser-
tion 5.14a requires three to five not necessarily consecutive assertions of busy
after the assertion of signal ack and before the assertion of done, while Asser-
tion 5.14b requires the same, and in addition that the assertion of signal done
occur immediately after the 3rd, 4th, or 5th assertion of signal busy. Thus As-
sertion 5.14a holds on Traces 5.14(i) and 5.14(ii), while Assertion 5.14b holds
on Trace 5.14(ii) but not on Trace 5.14(i).

==5.5 Concatenation (;) and fusion (:)==

We have already seen the concatenation operator, a semi-colon, which is used
to join two SEREs (or two Boolean expressions, or a Boolean expression and
a SERE) in such a way that the right-hand SERE starts the cycle after the
left-hand SERE ends. The fusion operator, a colon, is used to join two SEREs
(or two Boolean expressions, or a Boolean expression and a SERE) in such a
way that there is a single cycle of overlap between them: the right-hand SERE
starts the same cycle that the left-hand SERE ends.

For example, consider the case that we want to specify the behavior of As-
sertion 5.14b, and in addition, following the assertion of signal done, we should
see a data transfer, which consists of the assertion of signal data for some num-
ber of cycles (might be zero), followed by an assertion of signal d end. Using
the concatenation operator, we can write Assertion 5.15a. Trace 5.15(i) is a
trace on which Assertion 5.15a holds. The first assertion of signal req gets
three cycles of data before the assertion of d end, while the second assertion
of signal req sees four cycles of data before seeing d end.

If the data transfer should start the same cycle as signal done is asserted,
then we can use the fusion operator as in Assertion 5.16a. Trace 5.16(i) is an
example of a trace on which Assertion 5.16a holds. It is similar to Trace 5.15(i),
except that the data transfer starts the same cycle as that in which done is
asserted, rather than the cycle following the assertion of signal done.

Note that while it may be tempting to understand the concatenation op-
erator (;) as a delay, the operator does not necessarily “eat” a cycle. For in-
stance, in the case of the SERE {a ; b[*] ; c}, the b[*] may match zero,
one, or more cycles, as illustrated in Trace 5.17(i). The first match shown in
Trace 5.17(i) is only two cycles long, thus, the second concatenation operator
(;) did not “eat” a delay. A better way to think of it is that concatenation
gives you an ordered list of things to happen – some of them may consume
one cycle, some more, and some no cycles at all.

Further note that fusion requires an overlap of at least one cycle. Thus,
while the {b[*]} in {b[*] ; c} may match an empty sequence of cycles,
replacing the concatenation operator with the fusion operator like this: {b[*]: c}
results in a SERE with at least one assertion of b (otherwise there is
nothing to overlap with the assertion of c). In both cases, the match may
consist of a single cycle. The difference is that in the case of {b[*] ; c} the
single cycle may not include an assertion of b (because there may be zero
assertions of b preceding c), while in the case of {b[*] : c}, the single cycle
must include an assertion of b (which overlaps with the assertion of c).

==5.6 Compound SEREs==

Compound SEREs are SEREs built from other SEREs through operations
other than concatenation and fusion. The available operators allow you to
“and” or “or” together two or more SEREs, as well as to express the situation
where a match of one SERE occurs within a sequence of cycles matched by
another.

Consider the case that we want to say that signal read complete is as-
serted on the last data cycle of every read operation, where we have two kinds
of read operations: a short read consists of an assertion of signal short rd fol-
lowed by eight not necessarily consecutive assertions of data, and a long read
consists of an assertion of signal long rd followed by 32 such assertions. We
could code two separate properties, as shown in Properties 5.18a and 5.18b.
Alternatively, we could use the SERE “or” operator (|) to “or” the two SEREs
together, as in Property 5.18c.

The SERE “and” operator comes in two types: length-matching and non-
length-matching. Both the length-matching (&&) and the non-length-matching
(&) “and” operators match a sequence of cycles if starting at the current cycle,
the left-hand side and the right-hand side are matched. The difference is that
in addition, the length-matching “and” operator requires that the lengths of
the sequences matched by both the left- and right-hand sides are the same,
while the non-length-matching operator matches even if they are different. A
length-matching “and” between SEREs R and S is illustrated in Trace 5.19(i),
and a non-length-matching “and” between SEREs R and S is illustrated in
Traces 5.20(i), 5.20(ii) and 5.20(iii).

When a non-length-matching “and” is used on the left-hand side of a con-
catenation or a fusion, the current cycle of the right-hand side of the concate-
nation or fusion is determined by the longer of the two subsequences making
up the non-length-matching “and”. For instance, in the SERE {{{a;b[*5];c}
& {d[*];e}} ; f}, the current cycle of f is the cycle after the cycle in which
the longer of the two SEREs {a;b[*5];c} and {d[*];e} completes. This is
illustrated in Traces 5.21(i) and 5.21(ii). Note that in each of the traces, sig-
nal f is asserted twice: once after the completion of {a;b[*5];c}, and once
after the completion of {d[*];e}. However, in each trace, only the assertion
of signal f that happens after the completion of the longer of the two SEREs
participates in the “match” of SERE {{{a;b[*5];c} & {d[*];e}} ; f}.

NOTE: A length-matching “and” such as {a;b;c} && {d} is legal, but
makes no sense (because there is no sequence which is both 3 cycles long to
match {a;b;c} and 1 cycle long to match {d}). Many tools will probably issue
a warning for such a SERE.

As an example of the use of the length-matching “and”, consider the case
that a read request (assertion of signal read req) that is granted (assertion of
signal gnt within 5 cycles of the request) should be followed by a data transfer
(assertion of signal data start followed by some number of consecutive as-
sertions of data, followed by an assertion of data end), unless it is canceled.
A cancel is an assertion of signal cancel any time between the assertion of
read req and the assertion of gnt, inclusive. We can express this using As-
sertion 5.22a. Assertion 5.22a holds on Trace 5.22(i): the first read request is
followed by a data transfer, while the second read request is not followed by
a data transfer, but is not required to be since it is canceled.

In the case of Assertion 5.22a, we needed the length-matching “and”.
To see why, consider what would have happened had we used the non-
length-matching “and” as in Assertion 5.22b. In the case of Assertion 5.22b,
the left-hand side SERE {{read req ; [*0:4] ; gnt} & {cancel[=0]}} is
matched not only by the sequence of cycles starting at cycle 2 and ending at
cycle 5, but also by the sequences of cycles starting at cycle 2 and ending at
any of the cycles 6 through 16. Thus, Assertion 5.22b requires that we see a
data transfer starting not only at cycle 6, but also at cycles 7, 8, 9, 10 and so
on. Obviously, this is not what we wanted.

As an example where we want the non-length-matching “and” rather than
the length-matching “and”, consider the case that signal global print req
indicates that we should see a print on each of printers 1, 2, and 3 (comple-
tion of which is indicated by assertions of p1 done, p2 done, and p3 done,
respectively), and that following completion of the last print job, we should
see an assertion of signal print success. We can express this as shown in
Assertion 5.23a. Assertion 5.23a holds on Trace 5.23(i) because following the
assertion of signal global print req, we see assertions of each of the signals
p1 done, p2 done and p3 done, the last of which is followed by an assertion
of print success.

The non-length-matching “and” was needed for Assertion 5.23a. To see
why, consider what would have happened if we had used the length-matching
“and”, as in Assertion 5.23b. Assertion 5.23b does not hold on Trace 5.23(i)
because the use of the length-matching “and” means that p1 done[->],
p2 done[->] and p3 done[->] must all have the same length, i.e., that
p1 done, p2 done and p3 done must all be asserted at the same time.

The SERE within operator is useful if you want to describe a situation
where one SERE occurs within the time frame of another. For instance, sup-
pose that the normal behavior of the design is to complete a high priority
request first, even if there is a pending low priority request that started be-
fore it. However, if signal no nesting is asserted when the low priority re-
quest is issued, then this is prohibited. In other words, the situation shown
in Trace 5.24(i) is not allowed. We can describe the prohibited situation as
shown in Assertion 5.24a. Assertion 5.24a does not hold on Trace 5.24(i)
because there is a match of {high pri begin ; high pri end[->]} that is
entirely enclosed within the match of {(low pri begin && no nesting) ;
low pri end[->]}.

NOTE: If the left and right operands of a within operator are s and t
respectively, then the within operator is simply a shorthand for a length-
matching “and” between {[*] ; s ; [*]} and {t}. That is, s within t is
equivalent to {[*] ; s ; [*]} && {t}.

==5.7 More about suffix implication==

Up until now, we have seen the suffix implication operators (|-> and |=>)
used with SEREs on both the left- and the right-hand sides. While the left-
hand side of a suffix implication operator must be a SERE, the right-hand
side of a suffix implication operator can be any property. Thus, if we want to
express the requirement that whenever we have a request that is acknowledged
(assertion of req followed by an assertion of ack) we should see a grant
(assertion of signal gnt within three cycles of the acknowledge), we can code
as in Assertion 5.25a.

This is illustrated in Trace 5.25(i). In the trace, there are three occurrences
of the SERE {req;ack}. The first is followed by an assertion of ack after two
cycles, the second after three cycles, and the third after a single cycle. Thus,
Assertion 5.25a holds on the trace.

Of course, we could have written Assertion 5.25a entirely in SERE style,
as shown in Assertion 5.25b, or entirely without SEREs, as in Assertion 5.25c.
Assertions 5.25a, 5.25b and 5.25c are equivalent, thus the issue is purely one
of style. Some people prefer using only one style, others find a mix of styles,
depending on the particular property, to be easier to understand.

==5.8 The built-in function ended()==

The built-in function ended() takes a SERE as an argument and returns true
in any cycle where that SERE has just ended.1 For example, Trace 5.26(i) has
been annotated with a waveform labeled ended({a ; b[*] ; c}) to show
the value of the call to ended() at each cycle.

<blockquote>1 - In previous versions of PSL, the role of the built-in function ended() was played by
endpoints. Endpoints are no longer a part of the language – use built-in function
ended() instead.</blockquote>

How is ended() used? Consider that a complete data transfer consists of
an assertion of signal data start followed by some number of assertions of
data, followed by an assertion of data end. Consider further that we have a
signal data transfer complete that should be asserted when a data trans-
fer is completed, and that we would like to specify the correct behavior of
this signal. A good start would be Assertion 5.27a. Assertion 5.27a ensures
that data transfer complete is asserted at the conclusion of every data
transfer. But what about the other direction? That is, what about ensuring
that whenever data transfer complete is asserted, a complete data trans-
fer has indeed concluded? Assertion 5.27a does not ensure this, and thus
it holds on Trace 5.27(i), even though there are “extraneous” assertions of
data transfer complete at cycles 6 and 15. We would like an assertion that
holds on Trace 5.27(ii) but not on 5.27(i).

In order to check the second direction (that there are no extraneous asser-
tions of data transfer complete) we need to switch the direction of the
implication: we need to say that if data transfer complete is asserted,
then we have just seen the conclusion of a complete data transfer. We could
try Assertion 5.27b. However, that doesn’t work. Assertion 5.27b requires
that the SERE {data start ; data[*] ; data end} start the same cycle as
data transfer complete, while we want it to end that cycle.

This is where the built-in function ended() comes in. Using ended(),
we can code what we want as shown in Assertion 5.27c, which states that
whenever we see an assertion of data transfer complete, we must have just
seen the end of SERE {data start ; data[*] ; data end}, and it does not
hold on Trace 5.27(i).

Note that ended() returns a Boolean value. Since the left-hand side of the
suffix implication in Assertion 5.27c consists of a single Boolean expression,
we could have coded Assertion 5.27c equivalently using logical implication as
shown in Assertion 5.27d.

==5.9 Overlapping matches of a SERE==

Up until now, we have been concentrating on explaining the meaning of each
SERE operator, using relatively simple examples. It is now time to introduce
some more complex examples, in order to emphasize that like LTL style prop-
erties, interpreting a SERE style property on a trace can involve examining
overlapping sets of cycles.

Consider Property 5.28a on Traces 5.28(i) and 5.28(ii). There are multiple
matches of {a ; b[*] ; c} on Trace 5.28(i), one match ending at cycle 2,
one ending at cycle 3, and one ending at cycle 4. Property 5.28a does not
hold on Trace 5.28(i), because the matches ending at cycles 2 and 3 do not
have associated assertions of signal d at cycles 3 and 4. A suffix implication
requires that for every match of the left-hand side, the right-hand side holds.
Property 5.28a does hold on Trace 5.28(ii), because signal d is asserted after
each match of {a ; b[*] ; c}.

Note that although Property 5.28a contains an always operator, the
always operator is not the source of the overlapping matches in this case.
Rather, for a single current cycle (cycle 1), there are three separate matches
of the SERE {a ; b[*] ; c}, each ending at a different cycle.

The overlapping can happen on the right-hand side of a suffix implication
as well. Consider for example Property 5.29a on Trace 5.29(i). There are three
matches of {d ; e[*] ; f}, ending at cycles 3, 4, and 5. One match would
have been enough to satisfy Property 5.29a, because as long as there exists one
match, {d ; e[*] ; f} holds. The fact that there are in fact three matches
does not hurt. Thus, Property 5.29a holds on Trace 5.29(i).

We have just explained that we require at least one match of the right-hand
side for every match of the left-hand side of a suffix implication, and it might
seem that in so doing, we have introduced something new. Actually, the rule
could have been deduced from the parallel we have previously drawn between
a suffix implication and an if-then statement. SERE {a ; b[*] ; c} can be
understood as an infinite “or” between SEREs {a;c}, {a;b;c}, {a;b;b;c},
and so on. So Property 5.28a can be understood as “if {a;c} or {a;b;c} or
{a;b;b;c} or ..., then d”, which clearly should hold only if we see a d every
time the if-part is matched. And Property 5.29a can be understood as “if c,
then {d;f} or {d;e;f} or {d;e;e;f} or ...”, which of course should hold as
long as we have seen at least a single match of the then-part.

==5.10 How not to use SEREs==

[[Файл:Psl fig5.4.png]]

[[Файл:Psl fig5.5.png]]

[[Файл:Psl fig5.6.png]]

[[Файл:Psl fig5.7.png]]

[[Файл:Psl fig5.8.png]]

[[Файл:Psl fig5.9.png]]

[[Файл:Psl fig5.10.png]]

[[Файл:Psl fig5.11.png]]

[[Файл:Psl fig5.12.png]]

[[Файл:Psl fig5.13.png]]

[[Файл:Psl fig5.14.png]]

[[Файл:Psl fig5.15.png]]

[[Файл:Psl fig5.16.png]]

PSL/A Practical Introduction to PSL/SERE Style

2014-01-30T09:42:20Z

Valentin: /* 5.3 The never operator applied to a SERE */

{{PSL TOC}}

=Стиль SERE=


До этого момента, мы видели свойства PSL, построенные на булевых выражениях и временных операторах в стиле LTL. Другой путь построения свойств использует SERE - Последовательные расширения регулярных выражений. SERE по-сути тоже самое, что и регулярные выражения, как те, которые используются для сопоставления во многих приложениях. Отличие лишь в том, что атом SERE - булево выражение, в то время, как атомы стандартного регулярного выражения - отдельные символы.


SERE обычно заключается в фигурные скобки, и атом SERE обычно разделен точкой с запятой. Например, <code>{a;b;c}</code> - это SERE, и SERE 5.1a - это более сложный SERE. SERE 5.1a описывает последовательность циклов, в которых утверждается <code>(req_out && !ack)</code> на первом цикле, далее <code>(busy && !ack)</code> утверждается нуль или более циклов, показанный последовательным оператором повторения <code>[*]</code>, и в итоге утверждается ack. Таким образом, SERE 5.1a отмечает последовательность циклов, под лейблом “1” в тракте 5.1(i).


Не поддавайтесь искушению в трактовке SERE более, чем показано здесь: SERE 5.1a показывает последовательность циклов под лейблом “2” в тракте 5.1(i). SERE 5.1a не запрещает утверждения занятости в течение последнего цикла SERE. Если важно исключить такое поведение, занятость может быть явно указана, как показано в SERE 5.1b. SERE 5.1b показывает последовательность циклов под лейблом “1”, показанная на тракте 5.1(i), но не показывает последовательность циклов под лейблом “2” в этом же тракте.


Как использовать SERE? Во-первых, SERE может также быть под-свойством. Например, свойство 5.2a выполняется, если существует утверждение <code>req_in && gnt</code>, далее начиная со следующего цикла, мы видим последовательность циклов отмеченных SERE 5.1a. Свойство 5.2a выполняется на тракте 5.2(i).


Примечание: SERE - это свойство, но свойство это не всегда SERE. Таким образом, пока мы можем использовать SERE, как операнд временного оператора, мы не можем вставить временной оператор, такой как <code>always</code> или <code>next</code>, внутрь SERE.


Сейчас предположим, что у нас есть ситуация похожая на свойство 5.2a, но в которой грант (утверждение сигнала <code>gnt</code>) появляется циклом ''позже'' утверждения <code>req_in</code>. Мы можем попробовать заменить булево выражение <code>req_in && gnt</code> временным выражением <code>req_in && next gnt</code>, как в свойстве 5.3a. Однако, вспомним урок раздела 3.4: в свойстве 5.3a текущий цикл лева-ориентированной стороны <tt>(req_in && next gnt)</tt> тот же самый, что и текущий цикл право-ориентированной стороны (потому что они соединены булевым оператором <tt>-></tt>). Таким образом, текущий цикл <code>gnt</code> (который является операндом оператора <code>next</code>) - это тот же текущий цикл для SERE (который также является операндом оператора <code>next</code>). Это немного запутанно, и действительно свойство 5.3а не принадлежит простому подмножеству PSL, которые мы обсуждали в главе 9.


Давайте модифицируем свойство 5.3а, как показано в свойстве 5.3b. Сейчас один оператор <code>next</code> применяется для обоих, <code>gnt</code> и SERE, которые являются операндами оператора <code>-></code>. Свойство 5.3b эквивалентно свойству 5.3a, но оно из просто подмножества, делая более простым отслеживание временной выборки между <code>gnt</code> и SERE. Если мы подразумеваем, что текущий цикл SERE должен быть циклом ''позже'' <code>gnt</code>, мы можем манипулировать свойством 5.3b, добавляя <code>next</code>, как в свойстве 5.3c. Однако, суффиксная импликация операторов предоставляет более простой путь.

{| align=center
! [[Файл:Psl fig5.1.png]]
|-
!(i) SERE 5.1a отмечает 1 и 2. SERE 5.1b отмечает 1, но не 2.
|-
|<pre>
{(req_out && !ack) ; (busy && !ack)[*] ; ack} (5.1a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack && !busy} (5.1b)
</pre>
|-
! Рис. 5.1: Два простых SEREs
|}

{| align=center
! [[Файл:Psl fig5.2.png]]
|-
!(i) Свойство 5.2a выполняется
|-
|<pre>
always ((req_in && gnt) -> (5.2a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
</pre>
|-
! Рис. 5.2: SERE - свойство
|}

{| align=center width=80%
|<pre>
always ((req_in && next gnt) -> (5.3a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
always (req_in -> next (gnt -> (5.3b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}))
always (req_in -> next (gnt -> (5.3c)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack}))
</pre>
|-
! Рис. 5.3: Свойство 5.3a не из простого подмножества. Свойства 5.3b и 5.3c из простого подмножества,
но они сложны для чтения. Эти свойства можно выразить проще, используя суффиксную импликацию.
|}

==5.1 Суффиксная импликация (<code>|-></code> и <code>|=></code>)==


Операторы ''суффиксной импликации'' (<code>|-></code> и <code>|=></code>) предоставляют возможность ссылаться на два SERE таким образом, что право-ориентированная сторона начинает работать, когда лева-сторонняя сторона заканчивает работы. Параллельный оператор суффиксной импликации (<code>|-></code>) интерпретирует “когда лева-ориентированная сторона заканчивает работать” также, как “в том же цикле, когда лева-ориентированная сторона заканчивает работать”, в то время как не параллельный оператор суффиксной импликации (<code>|=></code>) интерпретирует это, как “цикл после цикла, в котором лева-ориентированная сторона завершила работу”. Таким образом, свойство 5.4а эквивалентно свойству 5.3b, и свойство 5.4b эквивалентно свойству 5.3c. Оба свойства 5.4a и 5.4b легче для понимания, чем эквивалентное свойство без суффиксной импликации , и оба принадлежат простому подмножеству из главы 9.

{| align=center
! [[Файл:Psl fig5.4.png]]
|-
|<pre>
always {req_in;gnt} |-> (5.4a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.4b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}

</pre>
|-
! Рис. 5.4: Суффиксная импликация
|}


Напомним, что логический оператор импликации (<code>-></code>) может интерпретироваться, как if-then выражение, с безоговорочно утвержденной else-частью. Суффиксный оператор импликации (<code>|-></code> and <code>|=></code>) может восприниматься также. Разница между логическим оператором импликации (<code>-></code>) и суффиксным оператором импликации (<code>|-></code> and <code>|=></code>) во временных взаимоотношениях между if- и then-частями. В то время, как текущий цикл then-части для оператора логической импликации
(->) тот же, что и для if-части, текущий цикл then-части суффиксного оператора импликации (<code>|-></code> or <code>|=></code>) это первый цикл ''суффикса'' тракта, который остается после того, как сменяется if-часть. Это показано для свойств 5.4a и 5.4b в трактах 5.4(i) и 5.4(ii).

{| align=center
! [[Файл:Psl fig5.5.png]]
|-
! (i) Тракт имеет множественные if-then пары. Свойство 5.5a выполняется.
|-
|<pre>
always {req_in;gnt} |=> (5.5a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.5: if-часть другой if-then пары может начаться перед тем, как if-часть или
then-часть предыдущей if-then пары выполниться
|}


В трактах 5.4(i) и 5.4(ii) присутствует единичное утверждение сигнала <code>req_in</code>. Если бы здесь было множественные утверждения <code>req_in</code>, то, конечно же, мы должны были бы идентифицировать множественные if-then пары, как показано в тракте 5.5(i). Отметим, что if-часть другой if-then пары может начинаться, перед завершение выполнения if-части или then-части предыдущей if-then пары. Например, вторая if-then пара начинается в седьмом цикле, перед тем, как выполнится then-часть первой пары. Третья if-then прара начинается в цикле 8, перед тем как выполнятся then-часть первой пары и if-часть второй пары. Мы могли видеть такой вид перекрытия ранее, в трактах 2.2(ii) и 2.3(iii). Отметим, что в тракте 5.5(i) утверждение <code>ack</code> в цикле 16 завершает then-часть второй и третьей if-then пары. Для более глубокого объяснения этого феномена,смотрите раздел 13.4.2.

Свойства 5.6a и 5.6b выполняются в тракте 5.6(i), потому что не существует последовательности циклов согласованных с левой стороной, т.о. else-часть по-умолчанию утверждается в каждом цикле.

{| align=center
! [[Файл:Psl fig5.6.png]]
|-
! (i) Свойства 5.6a и 5.6b выполняются
|-
|<pre>
always {req_in;gnt} |-> (5.6a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.6b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.6: else-часть суффиксной импликации по-умолчанию утверждена
|}

==5.2 Слабый и сильный SERE==


Как и временные операторы, SERE могут быть слабыми и сильными, и как и временные операторы, сильные версии SERE обозначаются восклицательным знаком (<code>!</code>). Таким образом, свойство 5.7а, правая сторона которого - сильный SERE, выполняется только, если будет достигнут цикл, в котором встречается <code>ack</code>. Другими словами, слабая версия SERE позволяет нам принимать тракт, который является “слишком коротким”, в то время как сильная версия предполагает, что мы должны добраться до конца SERE. Таким образом, в то время как свойство 5.7a выполняется на тракте 5.7(i), также как и на тракте 5.7(ii), свойство 5.7b, сильная версия, выполняется в тракте 5.7(ii), но не в тракте 5.7(i).

{| align=center
! [[Файл:Psl fig5.7.png]]
|-
|<pre>
always {req_in;gnt} |=> (5.7a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.7b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}!
</pre>
|-
! Рис. 5.7: Слабый SERE выполняется даже, если тракт “слишком короткий”, в то время как сильный SERE,
должен “достигать конца”
|}

==5.3 Оператор <code>never</code> применимый в SERE==


Другой способ использования SERE состоит в описании событий, которые никогда не произойдут. Например, утверждение 5.8a показывает, что сигнал <code>req</code> не должен быть утвержден в двух последовательных циклах, и таким образом не выполняется в тракте 5.8(i).


Другой пример, рассмотрим утверждение 5.9a. Оно показывает, что признанный высоко приоритетный запрос (утверждение <code>req</code> вместе с <code>high_pri</code>, следует циклом позже <code>ack</code>) не может быть прерван (утверждение <code>cancel</code> циклом позже <code>ack</code>). Таким образом, оно выполняется на тракте 5.9(i), но не выполняется в тракте 5.9(ii).

{| align=center
! [[Файл:Psl fig5.8.png]]
|-
| (i) Утверждение 5.8a не выполняется
|-
|<pre>
assert never {req;req}; (5.8a)
</pre>
|-
! Рис. 5.8: Оператор never
|}

{| align=center
! [[Файл:Psl fig5.9.png]]
|-
| (i) Утверждение 5.8a не выполняется
|-
|<pre>
assert never {req && high_pri ; ack ; cancel}; (5.9a)
</pre>
|-
! Рис. 5.9: Еще об опрераторе never
|}

==5.4 SERE repetition operators (<code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>)==

Up until now, we have seen basic SEREs composed of (possibly repeated)
Boolean expressions separated by semi-colons. In this section, we examine
SERE operators that allow you to build more sophisticated SEREs, using
variations on the SERE repetition operators <code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>.

Consecutive repetition operators provide a shortcut to typing the same
sub-SERE a number of times. The <code>[*n]</code> operator is an abbreviation for
n repetitions of the SERE it is applied to. For example, instead of typing
<code>busy;busy;busy</code> in Assertion 5.10a, we can use the abbreviation <code>busy[*3]</code>,
as in Assertion 5.10b. Assertions 5.10a and 5.10b state that after a request
(assertion of signal <code>req</code>), we expect to see an acknowledge (assertion of signal
<code>ack</code>) followed by three cycles in which signal <code>busy</code> is asserted, followed by
an assertion of signal <code>done</code>. Trace 5.10(i) is an example of a trace on which
Assertions 5.10a and 5.10b hold.

{| align=center
! [[Файл:Psl fig5.10.png]]
|-
|<pre>
assert always {req} |=> {ack;busy;busy;busy;done}; (5.10a)
assert always {req} |=> {ack ; busy[*3] ; done}; (5.10b)
assert always {req} |=> {ack ; busy[*3:5] ; done}; (5.10c)
</pre>
|-
! Fig. 5.10: The <code>[*n]</code> and <code>[*i:j]</code> operators
|}

Instead of a specific number of repetitions, we can specify a range, i
through <code>j</code>, like this: <code>[*i:j]</code>. Thus, Assertion 5.10c is similar to Asser-
tion 5.10b, but instead of requiring exactly three assertions of signal <code>busy</code>,
we require between three and five. Assertion 5.10c holds on Trace 5.10(i) as
well as on Trace 5.10(ii).

The upper bound of a range can be infinity, which is indicated by a <code>$</code> in
the SystemVerilog flavor, by ''null'' in the GDL flavor, and by inf in the Verilog,
VHDL, and SystemC flavors. For instance, the SERE <code>{b[*5:inf]}</code> matches
five or more repetitions of <code>b</code>.

We can repeat not only a Boolean expression, but a SERE as well. For
example, Property 5.11a holds if after an acknowledged request (an assertion
of signal <code>req</code> followed by an assertion of signal <code>ack</code>), we see three data transfers
followed by an assertion of signal <code>d_end</code>, where a data transfer is an assertion
of signal <code>start</code> followed by an assertion of signal <code>busy</code> followed by an assertion
of signal <code>done</code>. Trace 5.11(i) is an example of a trace on which Property 5.11a
holds.

If we omit the <code>n</code>, the resulting SERE matches any number of repetitions of
the Boolean expression or SERE that is being repeated. For example, asserting
Property 5.11b indicates that after an acknowledged request, we expect to see
any number of data transfers followed by an assertion of <code>done</code>. Property 5.11b
holds on Trace 5.11(i), as well as on Traces 5.11(ii) and 5.11(iii).

A <code>[*]</code> repetition matches any number of repetitions, including none. Thus,
Property 5.11b holds on Trace 5.11(iv) as well. If you want to specify any
non-zero number of repetitions, use the <code>[+]</code>. Thus, Property 5.11c is similar
to Property 5.11b, but it requires at least one data transfer before signal done
is asserted. Thus, Property 5.11c does not hold on Trace 5.11(iv), but it does
hold on Traces 5.11(i), 5.11(ii) and 5.11(iii).

Instead of omitting the n, we can omit the Boolean expression or SERE
and let the repetition <code>[*n]</code> stand alone. A stand-alone <code>[*n]</code> is equivalent
to <code>‘true[*n]</code>. In other words, <code>[*n]</code> matches any n cycles (because <code>‘true</code>
holds in all cycles). Another way to think of it is that it allows us to “skip”
<code>n</code> cycles. Thus, Property 5.12a is similar to Property 5.11b, but instead of
the acknowledge (assertion of signal <code>ack</code>) coming immediately following the
request (assertion of signal <code>req</code>), it comes four cycles later. Property 5.12a
holds on Trace 5.12(i).

The nonconsecutive repetition operator (<code>[=n]</code>) provides a way to describe
repetitions that happen on not necessarily consecutive cycles. It can be ap-
plied only to a Boolean expression. For example, to describe the requirement
that after a request (assertion of signal <code>req</code>), we expect to see an acknowledge
(assertion of signal <code>ack</code>) followed by some number of cycles including three
not necessarily consecutive assertions of signal <code>busy</code>, followed by an asser-
tion of signal <code>done</code>, we can code Assertion 5.13a. Assertion 5.13a holds on
Trace 5.13(i). Note the cycles marked “<code>busy[=3]</code>” in Trace 5.13(i). They do
not start with an assertion of <code>busy</code>, nor do they end with one. The noncon-
secutive repetition operator <code>[=n]</code> will match any sequence of cycles in which
there are <code>n</code> not necessarily consecutive repetitions of the Boolean expression
being repeated, including sequences of cycles in which the “padding” is at
the beginning and/or at the end. In other words, it will match any sequence
of cycles in which the number of assertions of the Boolean expression being
repeated is ''equal to'' <code>n</code> (thus the use of the equals sign in <code>[=n]</code>).

If you want to disallow the padding at the end, use the goto repetition op-
erator [->n]. The goto repetition operator [->n] is similar to the nonconsec-
utive repetition operator, except that the sequence of cycles being described
ends with an assertion of the Boolean expression being repeated. In other
words, it will match any sequence of cycles starting at the current cycle and
ending after you “go to” the nth occurrence of the Boolean expression (the
use of the -> is intended to remind you of an arrow instructing you to go to
n). Thus Assertion 5.13b does not hold on Trace 5.13(i), but it does hold on
Trace 5.13(ii) because the third busy is immediately followed by an assertion
of signal done.

The n can be omitted for the goto repetition operator, in which case n
defaults to 1. In other words, b[->] is equivalent to b[->1].

Like the consecutive repetition operators, the nonconsecutive repetition
operator and the goto repetition operator can take a range. Thus, Asser-
tion 5.14a requires three to five not necessarily consecutive assertions of busy
after the assertion of signal ack and before the assertion of done, while Asser-
tion 5.14b requires the same, and in addition that the assertion of signal done
occur immediately after the 3rd, 4th, or 5th assertion of signal busy. Thus As-
sertion 5.14a holds on Traces 5.14(i) and 5.14(ii), while Assertion 5.14b holds
on Trace 5.14(ii) but not on Trace 5.14(i).

==5.5 Concatenation (;) and fusion (:)==

We have already seen the concatenation operator, a semi-colon, which is used
to join two SEREs (or two Boolean expressions, or a Boolean expression and
a SERE) in such a way that the right-hand SERE starts the cycle after the
left-hand SERE ends. The fusion operator, a colon, is used to join two SEREs
(or two Boolean expressions, or a Boolean expression and a SERE) in such a
way that there is a single cycle of overlap between them: the right-hand SERE
starts the same cycle that the left-hand SERE ends.

For example, consider the case that we want to specify the behavior of As-
sertion 5.14b, and in addition, following the assertion of signal done, we should
see a data transfer, which consists of the assertion of signal data for some num-
ber of cycles (might be zero), followed by an assertion of signal d end. Using
the concatenation operator, we can write Assertion 5.15a. Trace 5.15(i) is a
trace on which Assertion 5.15a holds. The first assertion of signal req gets
three cycles of data before the assertion of d end, while the second assertion
of signal req sees four cycles of data before seeing d end.

If the data transfer should start the same cycle as signal done is asserted,
then we can use the fusion operator as in Assertion 5.16a. Trace 5.16(i) is an
example of a trace on which Assertion 5.16a holds. It is similar to Trace 5.15(i),
except that the data transfer starts the same cycle as that in which done is
asserted, rather than the cycle following the assertion of signal done.

Note that while it may be tempting to understand the concatenation op-
erator (;) as a delay, the operator does not necessarily “eat” a cycle. For in-
stance, in the case of the SERE {a ; b[*] ; c}, the b[*] may match zero,
one, or more cycles, as illustrated in Trace 5.17(i). The first match shown in
Trace 5.17(i) is only two cycles long, thus, the second concatenation operator
(;) did not “eat” a delay. A better way to think of it is that concatenation
gives you an ordered list of things to happen – some of them may consume
one cycle, some more, and some no cycles at all.

Further note that fusion requires an overlap of at least one cycle. Thus,
while the {b[*]} in {b[*] ; c} may match an empty sequence of cycles,
replacing the concatenation operator with the fusion operator like this: {b[*]: c}
results in a SERE with at least one assertion of b (otherwise there is
nothing to overlap with the assertion of c). In both cases, the match may
consist of a single cycle. The difference is that in the case of {b[*] ; c} the
single cycle may not include an assertion of b (because there may be zero
assertions of b preceding c), while in the case of {b[*] : c}, the single cycle
must include an assertion of b (which overlaps with the assertion of c).

==5.6 Compound SEREs==

Compound SEREs are SEREs built from other SEREs through operations
other than concatenation and fusion. The available operators allow you to
“and” or “or” together two or more SEREs, as well as to express the situation
where a match of one SERE occurs within a sequence of cycles matched by
another.

Consider the case that we want to say that signal read complete is as-
serted on the last data cycle of every read operation, where we have two kinds
of read operations: a short read consists of an assertion of signal short rd fol-
lowed by eight not necessarily consecutive assertions of data, and a long read
consists of an assertion of signal long rd followed by 32 such assertions. We
could code two separate properties, as shown in Properties 5.18a and 5.18b.
Alternatively, we could use the SERE “or” operator (|) to “or” the two SEREs
together, as in Property 5.18c.

The SERE “and” operator comes in two types: length-matching and non-
length-matching. Both the length-matching (&&) and the non-length-matching
(&) “and” operators match a sequence of cycles if starting at the current cycle,
the left-hand side and the right-hand side are matched. The difference is that
in addition, the length-matching “and” operator requires that the lengths of
the sequences matched by both the left- and right-hand sides are the same,
while the non-length-matching operator matches even if they are different. A
length-matching “and” between SEREs R and S is illustrated in Trace 5.19(i),
and a non-length-matching “and” between SEREs R and S is illustrated in
Traces 5.20(i), 5.20(ii) and 5.20(iii).

When a non-length-matching “and” is used on the left-hand side of a con-
catenation or a fusion, the current cycle of the right-hand side of the concate-
nation or fusion is determined by the longer of the two subsequences making
up the non-length-matching “and”. For instance, in the SERE {{{a;b[*5];c}
& {d[*];e}} ; f}, the current cycle of f is the cycle after the cycle in which
the longer of the two SEREs {a;b[*5];c} and {d[*];e} completes. This is
illustrated in Traces 5.21(i) and 5.21(ii). Note that in each of the traces, sig-
nal f is asserted twice: once after the completion of {a;b[*5];c}, and once
after the completion of {d[*];e}. However, in each trace, only the assertion
of signal f that happens after the completion of the longer of the two SEREs
participates in the “match” of SERE {{{a;b[*5];c} & {d[*];e}} ; f}.

NOTE: A length-matching “and” such as {a;b;c} && {d} is legal, but
makes no sense (because there is no sequence which is both 3 cycles long to
match {a;b;c} and 1 cycle long to match {d}). Many tools will probably issue
a warning for such a SERE.

As an example of the use of the length-matching “and”, consider the case
that a read request (assertion of signal read req) that is granted (assertion of
signal gnt within 5 cycles of the request) should be followed by a data transfer
(assertion of signal data start followed by some number of consecutive as-
sertions of data, followed by an assertion of data end), unless it is canceled.
A cancel is an assertion of signal cancel any time between the assertion of
read req and the assertion of gnt, inclusive. We can express this using As-
sertion 5.22a. Assertion 5.22a holds on Trace 5.22(i): the first read request is
followed by a data transfer, while the second read request is not followed by
a data transfer, but is not required to be since it is canceled.

In the case of Assertion 5.22a, we needed the length-matching “and”.
To see why, consider what would have happened had we used the non-
length-matching “and” as in Assertion 5.22b. In the case of Assertion 5.22b,
the left-hand side SERE {{read req ; [*0:4] ; gnt} & {cancel[=0]}} is
matched not only by the sequence of cycles starting at cycle 2 and ending at
cycle 5, but also by the sequences of cycles starting at cycle 2 and ending at
any of the cycles 6 through 16. Thus, Assertion 5.22b requires that we see a
data transfer starting not only at cycle 6, but also at cycles 7, 8, 9, 10 and so
on. Obviously, this is not what we wanted.

As an example where we want the non-length-matching “and” rather than
the length-matching “and”, consider the case that signal global print req
indicates that we should see a print on each of printers 1, 2, and 3 (comple-
tion of which is indicated by assertions of p1 done, p2 done, and p3 done,
respectively), and that following completion of the last print job, we should
see an assertion of signal print success. We can express this as shown in
Assertion 5.23a. Assertion 5.23a holds on Trace 5.23(i) because following the
assertion of signal global print req, we see assertions of each of the signals
p1 done, p2 done and p3 done, the last of which is followed by an assertion
of print success.

The non-length-matching “and” was needed for Assertion 5.23a. To see
why, consider what would have happened if we had used the length-matching
“and”, as in Assertion 5.23b. Assertion 5.23b does not hold on Trace 5.23(i)
because the use of the length-matching “and” means that p1 done[->],
p2 done[->] and p3 done[->] must all have the same length, i.e., that
p1 done, p2 done and p3 done must all be asserted at the same time.

The SERE within operator is useful if you want to describe a situation
where one SERE occurs within the time frame of another. For instance, sup-
pose that the normal behavior of the design is to complete a high priority
request first, even if there is a pending low priority request that started be-
fore it. However, if signal no nesting is asserted when the low priority re-
quest is issued, then this is prohibited. In other words, the situation shown
in Trace 5.24(i) is not allowed. We can describe the prohibited situation as
shown in Assertion 5.24a. Assertion 5.24a does not hold on Trace 5.24(i)
because there is a match of {high pri begin ; high pri end[->]} that is
entirely enclosed within the match of {(low pri begin && no nesting) ;
low pri end[->]}.

NOTE: If the left and right operands of a within operator are s and t
respectively, then the within operator is simply a shorthand for a length-
matching “and” between {[*] ; s ; [*]} and {t}. That is, s within t is
equivalent to {[*] ; s ; [*]} && {t}.

==5.7 More about suffix implication==

Up until now, we have seen the suffix implication operators (|-> and |=>)
used with SEREs on both the left- and the right-hand sides. While the left-
hand side of a suffix implication operator must be a SERE, the right-hand
side of a suffix implication operator can be any property. Thus, if we want to
express the requirement that whenever we have a request that is acknowledged
(assertion of req followed by an assertion of ack) we should see a grant
(assertion of signal gnt within three cycles of the acknowledge), we can code
as in Assertion 5.25a.

This is illustrated in Trace 5.25(i). In the trace, there are three occurrences
of the SERE {req;ack}. The first is followed by an assertion of ack after two
cycles, the second after three cycles, and the third after a single cycle. Thus,
Assertion 5.25a holds on the trace.

Of course, we could have written Assertion 5.25a entirely in SERE style,
as shown in Assertion 5.25b, or entirely without SEREs, as in Assertion 5.25c.
Assertions 5.25a, 5.25b and 5.25c are equivalent, thus the issue is purely one
of style. Some people prefer using only one style, others find a mix of styles,
depending on the particular property, to be easier to understand.

==5.8 The built-in function ended()==

The built-in function ended() takes a SERE as an argument and returns true
in any cycle where that SERE has just ended.1 For example, Trace 5.26(i) has
been annotated with a waveform labeled ended({a ; b[*] ; c}) to show
the value of the call to ended() at each cycle.

<blockquote>1 - In previous versions of PSL, the role of the built-in function ended() was played by
endpoints. Endpoints are no longer a part of the language – use built-in function
ended() instead.</blockquote>

How is ended() used? Consider that a complete data transfer consists of
an assertion of signal data start followed by some number of assertions of
data, followed by an assertion of data end. Consider further that we have a
signal data transfer complete that should be asserted when a data trans-
fer is completed, and that we would like to specify the correct behavior of
this signal. A good start would be Assertion 5.27a. Assertion 5.27a ensures
that data transfer complete is asserted at the conclusion of every data
transfer. But what about the other direction? That is, what about ensuring
that whenever data transfer complete is asserted, a complete data trans-
fer has indeed concluded? Assertion 5.27a does not ensure this, and thus
it holds on Trace 5.27(i), even though there are “extraneous” assertions of
data transfer complete at cycles 6 and 15. We would like an assertion that
holds on Trace 5.27(ii) but not on 5.27(i).

In order to check the second direction (that there are no extraneous asser-
tions of data transfer complete) we need to switch the direction of the
implication: we need to say that if data transfer complete is asserted,
then we have just seen the conclusion of a complete data transfer. We could
try Assertion 5.27b. However, that doesn’t work. Assertion 5.27b requires
that the SERE {data start ; data[*] ; data end} start the same cycle as
data transfer complete, while we want it to end that cycle.

This is where the built-in function ended() comes in. Using ended(),
we can code what we want as shown in Assertion 5.27c, which states that
whenever we see an assertion of data transfer complete, we must have just
seen the end of SERE {data start ; data[*] ; data end}, and it does not
hold on Trace 5.27(i).

Note that ended() returns a Boolean value. Since the left-hand side of the
suffix implication in Assertion 5.27c consists of a single Boolean expression,
we could have coded Assertion 5.27c equivalently using logical implication as
shown in Assertion 5.27d.

==5.9 Overlapping matches of a SERE==

Up until now, we have been concentrating on explaining the meaning of each
SERE operator, using relatively simple examples. It is now time to introduce
some more complex examples, in order to emphasize that like LTL style prop-
erties, interpreting a SERE style property on a trace can involve examining
overlapping sets of cycles.

Consider Property 5.28a on Traces 5.28(i) and 5.28(ii). There are multiple
matches of {a ; b[*] ; c} on Trace 5.28(i), one match ending at cycle 2,
one ending at cycle 3, and one ending at cycle 4. Property 5.28a does not
hold on Trace 5.28(i), because the matches ending at cycles 2 and 3 do not
have associated assertions of signal d at cycles 3 and 4. A suffix implication
requires that for every match of the left-hand side, the right-hand side holds.
Property 5.28a does hold on Trace 5.28(ii), because signal d is asserted after
each match of {a ; b[*] ; c}.

Note that although Property 5.28a contains an always operator, the
always operator is not the source of the overlapping matches in this case.
Rather, for a single current cycle (cycle 1), there are three separate matches
of the SERE {a ; b[*] ; c}, each ending at a different cycle.

The overlapping can happen on the right-hand side of a suffix implication
as well. Consider for example Property 5.29a on Trace 5.29(i). There are three
matches of {d ; e[*] ; f}, ending at cycles 3, 4, and 5. One match would
have been enough to satisfy Property 5.29a, because as long as there exists one
match, {d ; e[*] ; f} holds. The fact that there are in fact three matches
does not hurt. Thus, Property 5.29a holds on Trace 5.29(i).

We have just explained that we require at least one match of the right-hand
side for every match of the left-hand side of a suffix implication, and it might
seem that in so doing, we have introduced something new. Actually, the rule
could have been deduced from the parallel we have previously drawn between
a suffix implication and an if-then statement. SERE {a ; b[*] ; c} can be
understood as an infinite “or” between SEREs {a;c}, {a;b;c}, {a;b;b;c},
and so on. So Property 5.28a can be understood as “if {a;c} or {a;b;c} or
{a;b;b;c} or ..., then d”, which clearly should hold only if we see a d every
time the if-part is matched. And Property 5.29a can be understood as “if c,
then {d;f} or {d;e;f} or {d;e;e;f} or ...”, which of course should hold as
long as we have seen at least a single match of the then-part.

==5.10 How not to use SEREs==

[[Файл:Psl fig5.4.png]]

[[Файл:Psl fig5.5.png]]

[[Файл:Psl fig5.6.png]]

[[Файл:Psl fig5.7.png]]

[[Файл:Psl fig5.8.png]]

[[Файл:Psl fig5.9.png]]

[[Файл:Psl fig5.10.png]]

[[Файл:Psl fig5.11.png]]

[[Файл:Psl fig5.12.png]]

[[Файл:Psl fig5.13.png]]

[[Файл:Psl fig5.14.png]]

[[Файл:Psl fig5.15.png]]

[[Файл:Psl fig5.16.png]]

PSL/A Practical Introduction to PSL/SERE Style

2014-01-30T09:26:46Z

Valentin: /* 5.2 Слабый и сильный SERE */

{{PSL TOC}}

=Стиль SERE=


До этого момента, мы видели свойства PSL, построенные на булевых выражениях и временных операторах в стиле LTL. Другой путь построения свойств использует SERE - Последовательные расширения регулярных выражений. SERE по-сути тоже самое, что и регулярные выражения, как те, которые используются для сопоставления во многих приложениях. Отличие лишь в том, что атом SERE - булево выражение, в то время, как атомы стандартного регулярного выражения - отдельные символы.


SERE обычно заключается в фигурные скобки, и атом SERE обычно разделен точкой с запятой. Например, <code>{a;b;c}</code> - это SERE, и SERE 5.1a - это более сложный SERE. SERE 5.1a описывает последовательность циклов, в которых утверждается <code>(req_out && !ack)</code> на первом цикле, далее <code>(busy && !ack)</code> утверждается нуль или более циклов, показанный последовательным оператором повторения <code>[*]</code>, и в итоге утверждается ack. Таким образом, SERE 5.1a отмечает последовательность циклов, под лейблом “1” в тракте 5.1(i).


Не поддавайтесь искушению в трактовке SERE более, чем показано здесь: SERE 5.1a показывает последовательность циклов под лейблом “2” в тракте 5.1(i). SERE 5.1a не запрещает утверждения занятости в течение последнего цикла SERE. Если важно исключить такое поведение, занятость может быть явно указана, как показано в SERE 5.1b. SERE 5.1b показывает последовательность циклов под лейблом “1”, показанная на тракте 5.1(i), но не показывает последовательность циклов под лейблом “2” в этом же тракте.


Как использовать SERE? Во-первых, SERE может также быть под-свойством. Например, свойство 5.2a выполняется, если существует утверждение <code>req_in && gnt</code>, далее начиная со следующего цикла, мы видим последовательность циклов отмеченных SERE 5.1a. Свойство 5.2a выполняется на тракте 5.2(i).


Примечание: SERE - это свойство, но свойство это не всегда SERE. Таким образом, пока мы можем использовать SERE, как операнд временного оператора, мы не можем вставить временной оператор, такой как <code>always</code> или <code>next</code>, внутрь SERE.


Сейчас предположим, что у нас есть ситуация похожая на свойство 5.2a, но в которой грант (утверждение сигнала <code>gnt</code>) появляется циклом ''позже'' утверждения <code>req_in</code>. Мы можем попробовать заменить булево выражение <code>req_in && gnt</code> временным выражением <code>req_in && next gnt</code>, как в свойстве 5.3a. Однако, вспомним урок раздела 3.4: в свойстве 5.3a текущий цикл лева-ориентированной стороны <tt>(req_in && next gnt)</tt> тот же самый, что и текущий цикл право-ориентированной стороны (потому что они соединены булевым оператором <tt>-></tt>). Таким образом, текущий цикл <code>gnt</code> (который является операндом оператора <code>next</code>) - это тот же текущий цикл для SERE (который также является операндом оператора <code>next</code>). Это немного запутанно, и действительно свойство 5.3а не принадлежит простому подмножеству PSL, которые мы обсуждали в главе 9.


Давайте модифицируем свойство 5.3а, как показано в свойстве 5.3b. Сейчас один оператор <code>next</code> применяется для обоих, <code>gnt</code> и SERE, которые являются операндами оператора <code>-></code>. Свойство 5.3b эквивалентно свойству 5.3a, но оно из просто подмножества, делая более простым отслеживание временной выборки между <code>gnt</code> и SERE. Если мы подразумеваем, что текущий цикл SERE должен быть циклом ''позже'' <code>gnt</code>, мы можем манипулировать свойством 5.3b, добавляя <code>next</code>, как в свойстве 5.3c. Однако, суффиксная импликация операторов предоставляет более простой путь.

{| align=center
! [[Файл:Psl fig5.1.png]]
|-
!(i) SERE 5.1a отмечает 1 и 2. SERE 5.1b отмечает 1, но не 2.
|-
|<pre>
{(req_out && !ack) ; (busy && !ack)[*] ; ack} (5.1a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack && !busy} (5.1b)
</pre>
|-
! Рис. 5.1: Два простых SEREs
|}

{| align=center
! [[Файл:Psl fig5.2.png]]
|-
!(i) Свойство 5.2a выполняется
|-
|<pre>
always ((req_in && gnt) -> (5.2a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
</pre>
|-
! Рис. 5.2: SERE - свойство
|}

{| align=center width=80%
|<pre>
always ((req_in && next gnt) -> (5.3a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
always (req_in -> next (gnt -> (5.3b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}))
always (req_in -> next (gnt -> (5.3c)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack}))
</pre>
|-
! Рис. 5.3: Свойство 5.3a не из простого подмножества. Свойства 5.3b и 5.3c из простого подмножества,
но они сложны для чтения. Эти свойства можно выразить проще, используя суффиксную импликацию.
|}

==5.1 Суффиксная импликация (<code>|-></code> и <code>|=></code>)==


Операторы ''суффиксной импликации'' (<code>|-></code> и <code>|=></code>) предоставляют возможность ссылаться на два SERE таким образом, что право-ориентированная сторона начинает работать, когда лева-сторонняя сторона заканчивает работы. Параллельный оператор суффиксной импликации (<code>|-></code>) интерпретирует “когда лева-ориентированная сторона заканчивает работать” также, как “в том же цикле, когда лева-ориентированная сторона заканчивает работать”, в то время как не параллельный оператор суффиксной импликации (<code>|=></code>) интерпретирует это, как “цикл после цикла, в котором лева-ориентированная сторона завершила работу”. Таким образом, свойство 5.4а эквивалентно свойству 5.3b, и свойство 5.4b эквивалентно свойству 5.3c. Оба свойства 5.4a и 5.4b легче для понимания, чем эквивалентное свойство без суффиксной импликации , и оба принадлежат простому подмножеству из главы 9.

{| align=center
! [[Файл:Psl fig5.4.png]]
|-
|<pre>
always {req_in;gnt} |-> (5.4a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.4b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}

</pre>
|-
! Рис. 5.4: Суффиксная импликация
|}


Напомним, что логический оператор импликации (<code>-></code>) может интерпретироваться, как if-then выражение, с безоговорочно утвержденной else-частью. Суффиксный оператор импликации (<code>|-></code> and <code>|=></code>) может восприниматься также. Разница между логическим оператором импликации (<code>-></code>) и суффиксным оператором импликации (<code>|-></code> and <code>|=></code>) во временных взаимоотношениях между if- и then-частями. В то время, как текущий цикл then-части для оператора логической импликации
(->) тот же, что и для if-части, текущий цикл then-части суффиксного оператора импликации (<code>|-></code> or <code>|=></code>) это первый цикл ''суффикса'' тракта, который остается после того, как сменяется if-часть. Это показано для свойств 5.4a и 5.4b в трактах 5.4(i) и 5.4(ii).

{| align=center
! [[Файл:Psl fig5.5.png]]
|-
! (i) Тракт имеет множественные if-then пары. Свойство 5.5a выполняется.
|-
|<pre>
always {req_in;gnt} |=> (5.5a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.5: if-часть другой if-then пары может начаться перед тем, как if-часть или
then-часть предыдущей if-then пары выполниться
|}


В трактах 5.4(i) и 5.4(ii) присутствует единичное утверждение сигнала <code>req_in</code>. Если бы здесь было множественные утверждения <code>req_in</code>, то, конечно же, мы должны были бы идентифицировать множественные if-then пары, как показано в тракте 5.5(i). Отметим, что if-часть другой if-then пары может начинаться, перед завершение выполнения if-части или then-части предыдущей if-then пары. Например, вторая if-then пара начинается в седьмом цикле, перед тем, как выполнится then-часть первой пары. Третья if-then прара начинается в цикле 8, перед тем как выполнятся then-часть первой пары и if-часть второй пары. Мы могли видеть такой вид перекрытия ранее, в трактах 2.2(ii) и 2.3(iii). Отметим, что в тракте 5.5(i) утверждение <code>ack</code> в цикле 16 завершает then-часть второй и третьей if-then пары. Для более глубокого объяснения этого феномена,смотрите раздел 13.4.2.

Свойства 5.6a и 5.6b выполняются в тракте 5.6(i), потому что не существует последовательности циклов согласованных с левой стороной, т.о. else-часть по-умолчанию утверждается в каждом цикле.

{| align=center
! [[Файл:Psl fig5.6.png]]
|-
! (i) Свойства 5.6a и 5.6b выполняются
|-
|<pre>
always {req_in;gnt} |-> (5.6a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.6b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.6: else-часть суффиксной импликации по-умолчанию утверждена
|}

==5.2 Слабый и сильный SERE==


Как и временные операторы, SERE могут быть слабыми и сильными, и как и временные операторы, сильные версии SERE обозначаются восклицательным знаком (<code>!</code>). Таким образом, свойство 5.7а, правая сторона которого - сильный SERE, выполняется только, если будет достигнут цикл, в котором встречается <code>ack</code>. Другими словами, слабая версия SERE позволяет нам принимать тракт, который является “слишком коротким”, в то время как сильная версия предполагает, что мы должны добраться до конца SERE. Таким образом, в то время как свойство 5.7a выполняется на тракте 5.7(i), также как и на тракте 5.7(ii), свойство 5.7b, сильная версия, выполняется в тракте 5.7(ii), но не в тракте 5.7(i).

{| align=center
! [[Файл:Psl fig5.7.png]]
|-
|<pre>
always {req_in;gnt} |=> (5.7a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.7b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}!
</pre>
|-
! Рис. 5.7: Слабый SERE выполняется даже, если тракт “слишком короткий”, в то время как сильный SERE,
должен “достигать конца”
|}

==5.3 The <code>never</code> operator applied to a SERE==

Another way to use a SERE is in describing sequences of events that should
never happen. For example, Assertion 5.8a states that signal <code>req</code> should never
be asserted for two consecutive cycles, and thus does not hold on Trace 5.8(i).

As another example, consider Assertion 5.9a. It states that an acknowl-
edged high priority request (assertion of <code>req</code> together with <code>high_pri</code>, followed
a cycle later by <code>ack</code>) cannot be canceled (assertion of <code>cancel</code> the cycle after
<code>ack</code>). Thus it holds on Trace 5.9(i), but not on Trace 5.9(ii).

{| align=center
! [[Файл:Psl fig5.8.png]]
|-
| (i) Assertion 5.8a does not hold
|-
|<pre>
assert never {req;req}; (5.8a)
</pre>
|-
! Fig. 5.8: The never operator
|}

{| align=center
! [[Файл:Psl fig5.9.png]]
|-
| (i) Assertion 5.8a does not hold
|-
|<pre>
assert never {req && high_pri ; ack ; cancel}; (5.9a)
</pre>
|-
! Fig. 5.9: More about the never operator
|}

==5.4 SERE repetition operators (<code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>)==

Up until now, we have seen basic SEREs composed of (possibly repeated)
Boolean expressions separated by semi-colons. In this section, we examine
SERE operators that allow you to build more sophisticated SEREs, using
variations on the SERE repetition operators <code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>.

Consecutive repetition operators provide a shortcut to typing the same
sub-SERE a number of times. The <code>[*n]</code> operator is an abbreviation for
n repetitions of the SERE it is applied to. For example, instead of typing
<code>busy;busy;busy</code> in Assertion 5.10a, we can use the abbreviation <code>busy[*3]</code>,
as in Assertion 5.10b. Assertions 5.10a and 5.10b state that after a request
(assertion of signal <code>req</code>), we expect to see an acknowledge (assertion of signal
<code>ack</code>) followed by three cycles in which signal <code>busy</code> is asserted, followed by
an assertion of signal <code>done</code>. Trace 5.10(i) is an example of a trace on which
Assertions 5.10a and 5.10b hold.

{| align=center
! [[Файл:Psl fig5.10.png]]
|-
|<pre>
assert always {req} |=> {ack;busy;busy;busy;done}; (5.10a)
assert always {req} |=> {ack ; busy[*3] ; done}; (5.10b)
assert always {req} |=> {ack ; busy[*3:5] ; done}; (5.10c)
</pre>
|-
! Fig. 5.10: The <code>[*n]</code> and <code>[*i:j]</code> operators
|}

Instead of a specific number of repetitions, we can specify a range, i
through <code>j</code>, like this: <code>[*i:j]</code>. Thus, Assertion 5.10c is similar to Asser-
tion 5.10b, but instead of requiring exactly three assertions of signal <code>busy</code>,
we require between three and five. Assertion 5.10c holds on Trace 5.10(i) as
well as on Trace 5.10(ii).

The upper bound of a range can be infinity, which is indicated by a <code>$</code> in
the SystemVerilog flavor, by ''null'' in the GDL flavor, and by inf in the Verilog,
VHDL, and SystemC flavors. For instance, the SERE <code>{b[*5:inf]}</code> matches
five or more repetitions of <code>b</code>.

We can repeat not only a Boolean expression, but a SERE as well. For
example, Property 5.11a holds if after an acknowledged request (an assertion
of signal <code>req</code> followed by an assertion of signal <code>ack</code>), we see three data transfers
followed by an assertion of signal <code>d_end</code>, where a data transfer is an assertion
of signal <code>start</code> followed by an assertion of signal <code>busy</code> followed by an assertion
of signal <code>done</code>. Trace 5.11(i) is an example of a trace on which Property 5.11a
holds.

If we omit the <code>n</code>, the resulting SERE matches any number of repetitions of
the Boolean expression or SERE that is being repeated. For example, asserting
Property 5.11b indicates that after an acknowledged request, we expect to see
any number of data transfers followed by an assertion of <code>done</code>. Property 5.11b
holds on Trace 5.11(i), as well as on Traces 5.11(ii) and 5.11(iii).

A <code>[*]</code> repetition matches any number of repetitions, including none. Thus,
Property 5.11b holds on Trace 5.11(iv) as well. If you want to specify any
non-zero number of repetitions, use the <code>[+]</code>. Thus, Property 5.11c is similar
to Property 5.11b, but it requires at least one data transfer before signal done
is asserted. Thus, Property 5.11c does not hold on Trace 5.11(iv), but it does
hold on Traces 5.11(i), 5.11(ii) and 5.11(iii).

Instead of omitting the n, we can omit the Boolean expression or SERE
and let the repetition <code>[*n]</code> stand alone. A stand-alone <code>[*n]</code> is equivalent
to <code>‘true[*n]</code>. In other words, <code>[*n]</code> matches any n cycles (because <code>‘true</code>
holds in all cycles). Another way to think of it is that it allows us to “skip”
<code>n</code> cycles. Thus, Property 5.12a is similar to Property 5.11b, but instead of
the acknowledge (assertion of signal <code>ack</code>) coming immediately following the
request (assertion of signal <code>req</code>), it comes four cycles later. Property 5.12a
holds on Trace 5.12(i).

The nonconsecutive repetition operator (<code>[=n]</code>) provides a way to describe
repetitions that happen on not necessarily consecutive cycles. It can be ap-
plied only to a Boolean expression. For example, to describe the requirement
that after a request (assertion of signal <code>req</code>), we expect to see an acknowledge
(assertion of signal <code>ack</code>) followed by some number of cycles including three
not necessarily consecutive assertions of signal <code>busy</code>, followed by an asser-
tion of signal <code>done</code>, we can code Assertion 5.13a. Assertion 5.13a holds on
Trace 5.13(i). Note the cycles marked “<code>busy[=3]</code>” in Trace 5.13(i). They do
not start with an assertion of <code>busy</code>, nor do they end with one. The noncon-
secutive repetition operator <code>[=n]</code> will match any sequence of cycles in which
there are <code>n</code> not necessarily consecutive repetitions of the Boolean expression
being repeated, including sequences of cycles in which the “padding” is at
the beginning and/or at the end. In other words, it will match any sequence
of cycles in which the number of assertions of the Boolean expression being
repeated is ''equal to'' <code>n</code> (thus the use of the equals sign in <code>[=n]</code>).

If you want to disallow the padding at the end, use the goto repetition op-
erator [->n]. The goto repetition operator [->n] is similar to the nonconsec-
utive repetition operator, except that the sequence of cycles being described
ends with an assertion of the Boolean expression being repeated. In other
words, it will match any sequence of cycles starting at the current cycle and
ending after you “go to” the nth occurrence of the Boolean expression (the
use of the -> is intended to remind you of an arrow instructing you to go to
n). Thus Assertion 5.13b does not hold on Trace 5.13(i), but it does hold on
Trace 5.13(ii) because the third busy is immediately followed by an assertion
of signal done.

The n can be omitted for the goto repetition operator, in which case n
defaults to 1. In other words, b[->] is equivalent to b[->1].

Like the consecutive repetition operators, the nonconsecutive repetition
operator and the goto repetition operator can take a range. Thus, Asser-
tion 5.14a requires three to five not necessarily consecutive assertions of busy
after the assertion of signal ack and before the assertion of done, while Asser-
tion 5.14b requires the same, and in addition that the assertion of signal done
occur immediately after the 3rd, 4th, or 5th assertion of signal busy. Thus As-
sertion 5.14a holds on Traces 5.14(i) and 5.14(ii), while Assertion 5.14b holds
on Trace 5.14(ii) but not on Trace 5.14(i).

==5.5 Concatenation (;) and fusion (:)==

We have already seen the concatenation operator, a semi-colon, which is used
to join two SEREs (or two Boolean expressions, or a Boolean expression and
a SERE) in such a way that the right-hand SERE starts the cycle after the
left-hand SERE ends. The fusion operator, a colon, is used to join two SEREs
(or two Boolean expressions, or a Boolean expression and a SERE) in such a
way that there is a single cycle of overlap between them: the right-hand SERE
starts the same cycle that the left-hand SERE ends.

For example, consider the case that we want to specify the behavior of As-
sertion 5.14b, and in addition, following the assertion of signal done, we should
see a data transfer, which consists of the assertion of signal data for some num-
ber of cycles (might be zero), followed by an assertion of signal d end. Using
the concatenation operator, we can write Assertion 5.15a. Trace 5.15(i) is a
trace on which Assertion 5.15a holds. The first assertion of signal req gets
three cycles of data before the assertion of d end, while the second assertion
of signal req sees four cycles of data before seeing d end.

If the data transfer should start the same cycle as signal done is asserted,
then we can use the fusion operator as in Assertion 5.16a. Trace 5.16(i) is an
example of a trace on which Assertion 5.16a holds. It is similar to Trace 5.15(i),
except that the data transfer starts the same cycle as that in which done is
asserted, rather than the cycle following the assertion of signal done.

Note that while it may be tempting to understand the concatenation op-
erator (;) as a delay, the operator does not necessarily “eat” a cycle. For in-
stance, in the case of the SERE {a ; b[*] ; c}, the b[*] may match zero,
one, or more cycles, as illustrated in Trace 5.17(i). The first match shown in
Trace 5.17(i) is only two cycles long, thus, the second concatenation operator
(;) did not “eat” a delay. A better way to think of it is that concatenation
gives you an ordered list of things to happen – some of them may consume
one cycle, some more, and some no cycles at all.

Further note that fusion requires an overlap of at least one cycle. Thus,
while the {b[*]} in {b[*] ; c} may match an empty sequence of cycles,
replacing the concatenation operator with the fusion operator like this: {b[*]: c}
results in a SERE with at least one assertion of b (otherwise there is
nothing to overlap with the assertion of c). In both cases, the match may
consist of a single cycle. The difference is that in the case of {b[*] ; c} the
single cycle may not include an assertion of b (because there may be zero
assertions of b preceding c), while in the case of {b[*] : c}, the single cycle
must include an assertion of b (which overlaps with the assertion of c).

==5.6 Compound SEREs==

Compound SEREs are SEREs built from other SEREs through operations
other than concatenation and fusion. The available operators allow you to
“and” or “or” together two or more SEREs, as well as to express the situation
where a match of one SERE occurs within a sequence of cycles matched by
another.

Consider the case that we want to say that signal read complete is as-
serted on the last data cycle of every read operation, where we have two kinds
of read operations: a short read consists of an assertion of signal short rd fol-
lowed by eight not necessarily consecutive assertions of data, and a long read
consists of an assertion of signal long rd followed by 32 such assertions. We
could code two separate properties, as shown in Properties 5.18a and 5.18b.
Alternatively, we could use the SERE “or” operator (|) to “or” the two SEREs
together, as in Property 5.18c.

The SERE “and” operator comes in two types: length-matching and non-
length-matching. Both the length-matching (&&) and the non-length-matching
(&) “and” operators match a sequence of cycles if starting at the current cycle,
the left-hand side and the right-hand side are matched. The difference is that
in addition, the length-matching “and” operator requires that the lengths of
the sequences matched by both the left- and right-hand sides are the same,
while the non-length-matching operator matches even if they are different. A
length-matching “and” between SEREs R and S is illustrated in Trace 5.19(i),
and a non-length-matching “and” between SEREs R and S is illustrated in
Traces 5.20(i), 5.20(ii) and 5.20(iii).

When a non-length-matching “and” is used on the left-hand side of a con-
catenation or a fusion, the current cycle of the right-hand side of the concate-
nation or fusion is determined by the longer of the two subsequences making
up the non-length-matching “and”. For instance, in the SERE {{{a;b[*5];c}
& {d[*];e}} ; f}, the current cycle of f is the cycle after the cycle in which
the longer of the two SEREs {a;b[*5];c} and {d[*];e} completes. This is
illustrated in Traces 5.21(i) and 5.21(ii). Note that in each of the traces, sig-
nal f is asserted twice: once after the completion of {a;b[*5];c}, and once
after the completion of {d[*];e}. However, in each trace, only the assertion
of signal f that happens after the completion of the longer of the two SEREs
participates in the “match” of SERE {{{a;b[*5];c} & {d[*];e}} ; f}.

NOTE: A length-matching “and” such as {a;b;c} && {d} is legal, but
makes no sense (because there is no sequence which is both 3 cycles long to
match {a;b;c} and 1 cycle long to match {d}). Many tools will probably issue
a warning for such a SERE.

As an example of the use of the length-matching “and”, consider the case
that a read request (assertion of signal read req) that is granted (assertion of
signal gnt within 5 cycles of the request) should be followed by a data transfer
(assertion of signal data start followed by some number of consecutive as-
sertions of data, followed by an assertion of data end), unless it is canceled.
A cancel is an assertion of signal cancel any time between the assertion of
read req and the assertion of gnt, inclusive. We can express this using As-
sertion 5.22a. Assertion 5.22a holds on Trace 5.22(i): the first read request is
followed by a data transfer, while the second read request is not followed by
a data transfer, but is not required to be since it is canceled.

In the case of Assertion 5.22a, we needed the length-matching “and”.
To see why, consider what would have happened had we used the non-
length-matching “and” as in Assertion 5.22b. In the case of Assertion 5.22b,
the left-hand side SERE {{read req ; [*0:4] ; gnt} & {cancel[=0]}} is
matched not only by the sequence of cycles starting at cycle 2 and ending at
cycle 5, but also by the sequences of cycles starting at cycle 2 and ending at
any of the cycles 6 through 16. Thus, Assertion 5.22b requires that we see a
data transfer starting not only at cycle 6, but also at cycles 7, 8, 9, 10 and so
on. Obviously, this is not what we wanted.

As an example where we want the non-length-matching “and” rather than
the length-matching “and”, consider the case that signal global print req
indicates that we should see a print on each of printers 1, 2, and 3 (comple-
tion of which is indicated by assertions of p1 done, p2 done, and p3 done,
respectively), and that following completion of the last print job, we should
see an assertion of signal print success. We can express this as shown in
Assertion 5.23a. Assertion 5.23a holds on Trace 5.23(i) because following the
assertion of signal global print req, we see assertions of each of the signals
p1 done, p2 done and p3 done, the last of which is followed by an assertion
of print success.

The non-length-matching “and” was needed for Assertion 5.23a. To see
why, consider what would have happened if we had used the length-matching
“and”, as in Assertion 5.23b. Assertion 5.23b does not hold on Trace 5.23(i)
because the use of the length-matching “and” means that p1 done[->],
p2 done[->] and p3 done[->] must all have the same length, i.e., that
p1 done, p2 done and p3 done must all be asserted at the same time.

The SERE within operator is useful if you want to describe a situation
where one SERE occurs within the time frame of another. For instance, sup-
pose that the normal behavior of the design is to complete a high priority
request first, even if there is a pending low priority request that started be-
fore it. However, if signal no nesting is asserted when the low priority re-
quest is issued, then this is prohibited. In other words, the situation shown
in Trace 5.24(i) is not allowed. We can describe the prohibited situation as
shown in Assertion 5.24a. Assertion 5.24a does not hold on Trace 5.24(i)
because there is a match of {high pri begin ; high pri end[->]} that is
entirely enclosed within the match of {(low pri begin && no nesting) ;
low pri end[->]}.

NOTE: If the left and right operands of a within operator are s and t
respectively, then the within operator is simply a shorthand for a length-
matching “and” between {[*] ; s ; [*]} and {t}. That is, s within t is
equivalent to {[*] ; s ; [*]} && {t}.

==5.7 More about suffix implication==

Up until now, we have seen the suffix implication operators (|-> and |=>)
used with SEREs on both the left- and the right-hand sides. While the left-
hand side of a suffix implication operator must be a SERE, the right-hand
side of a suffix implication operator can be any property. Thus, if we want to
express the requirement that whenever we have a request that is acknowledged
(assertion of req followed by an assertion of ack) we should see a grant
(assertion of signal gnt within three cycles of the acknowledge), we can code
as in Assertion 5.25a.

This is illustrated in Trace 5.25(i). In the trace, there are three occurrences
of the SERE {req;ack}. The first is followed by an assertion of ack after two
cycles, the second after three cycles, and the third after a single cycle. Thus,
Assertion 5.25a holds on the trace.

Of course, we could have written Assertion 5.25a entirely in SERE style,
as shown in Assertion 5.25b, or entirely without SEREs, as in Assertion 5.25c.
Assertions 5.25a, 5.25b and 5.25c are equivalent, thus the issue is purely one
of style. Some people prefer using only one style, others find a mix of styles,
depending on the particular property, to be easier to understand.

==5.8 The built-in function ended()==

The built-in function ended() takes a SERE as an argument and returns true
in any cycle where that SERE has just ended.1 For example, Trace 5.26(i) has
been annotated with a waveform labeled ended({a ; b[*] ; c}) to show
the value of the call to ended() at each cycle.

<blockquote>1 - In previous versions of PSL, the role of the built-in function ended() was played by
endpoints. Endpoints are no longer a part of the language – use built-in function
ended() instead.</blockquote>

How is ended() used? Consider that a complete data transfer consists of
an assertion of signal data start followed by some number of assertions of
data, followed by an assertion of data end. Consider further that we have a
signal data transfer complete that should be asserted when a data trans-
fer is completed, and that we would like to specify the correct behavior of
this signal. A good start would be Assertion 5.27a. Assertion 5.27a ensures
that data transfer complete is asserted at the conclusion of every data
transfer. But what about the other direction? That is, what about ensuring
that whenever data transfer complete is asserted, a complete data trans-
fer has indeed concluded? Assertion 5.27a does not ensure this, and thus
it holds on Trace 5.27(i), even though there are “extraneous” assertions of
data transfer complete at cycles 6 and 15. We would like an assertion that
holds on Trace 5.27(ii) but not on 5.27(i).

In order to check the second direction (that there are no extraneous asser-
tions of data transfer complete) we need to switch the direction of the
implication: we need to say that if data transfer complete is asserted,
then we have just seen the conclusion of a complete data transfer. We could
try Assertion 5.27b. However, that doesn’t work. Assertion 5.27b requires
that the SERE {data start ; data[*] ; data end} start the same cycle as
data transfer complete, while we want it to end that cycle.

This is where the built-in function ended() comes in. Using ended(),
we can code what we want as shown in Assertion 5.27c, which states that
whenever we see an assertion of data transfer complete, we must have just
seen the end of SERE {data start ; data[*] ; data end}, and it does not
hold on Trace 5.27(i).

Note that ended() returns a Boolean value. Since the left-hand side of the
suffix implication in Assertion 5.27c consists of a single Boolean expression,
we could have coded Assertion 5.27c equivalently using logical implication as
shown in Assertion 5.27d.

==5.9 Overlapping matches of a SERE==

Up until now, we have been concentrating on explaining the meaning of each
SERE operator, using relatively simple examples. It is now time to introduce
some more complex examples, in order to emphasize that like LTL style prop-
erties, interpreting a SERE style property on a trace can involve examining
overlapping sets of cycles.

Consider Property 5.28a on Traces 5.28(i) and 5.28(ii). There are multiple
matches of {a ; b[*] ; c} on Trace 5.28(i), one match ending at cycle 2,
one ending at cycle 3, and one ending at cycle 4. Property 5.28a does not
hold on Trace 5.28(i), because the matches ending at cycles 2 and 3 do not
have associated assertions of signal d at cycles 3 and 4. A suffix implication
requires that for every match of the left-hand side, the right-hand side holds.
Property 5.28a does hold on Trace 5.28(ii), because signal d is asserted after
each match of {a ; b[*] ; c}.

Note that although Property 5.28a contains an always operator, the
always operator is not the source of the overlapping matches in this case.
Rather, for a single current cycle (cycle 1), there are three separate matches
of the SERE {a ; b[*] ; c}, each ending at a different cycle.

The overlapping can happen on the right-hand side of a suffix implication
as well. Consider for example Property 5.29a on Trace 5.29(i). There are three
matches of {d ; e[*] ; f}, ending at cycles 3, 4, and 5. One match would
have been enough to satisfy Property 5.29a, because as long as there exists one
match, {d ; e[*] ; f} holds. The fact that there are in fact three matches
does not hurt. Thus, Property 5.29a holds on Trace 5.29(i).

We have just explained that we require at least one match of the right-hand
side for every match of the left-hand side of a suffix implication, and it might
seem that in so doing, we have introduced something new. Actually, the rule
could have been deduced from the parallel we have previously drawn between
a suffix implication and an if-then statement. SERE {a ; b[*] ; c} can be
understood as an infinite “or” between SEREs {a;c}, {a;b;c}, {a;b;b;c},
and so on. So Property 5.28a can be understood as “if {a;c} or {a;b;c} or
{a;b;b;c} or ..., then d”, which clearly should hold only if we see a d every
time the if-part is matched. And Property 5.29a can be understood as “if c,
then {d;f} or {d;e;f} or {d;e;e;f} or ...”, which of course should hold as
long as we have seen at least a single match of the then-part.

==5.10 How not to use SEREs==

[[Файл:Psl fig5.4.png]]

[[Файл:Psl fig5.5.png]]

[[Файл:Psl fig5.6.png]]

[[Файл:Psl fig5.7.png]]

[[Файл:Psl fig5.8.png]]

[[Файл:Psl fig5.9.png]]

[[Файл:Psl fig5.10.png]]

[[Файл:Psl fig5.11.png]]

[[Файл:Psl fig5.12.png]]

[[Файл:Psl fig5.13.png]]

[[Файл:Psl fig5.14.png]]

[[Файл:Psl fig5.15.png]]

[[Файл:Psl fig5.16.png]]

PSL/A Practical Introduction to PSL/SERE Style

2014-01-30T09:05:08Z

Valentin: /* 5.2 Weak and strong SEREs */

{{PSL TOC}}

=Стиль SERE=


До этого момента, мы видели свойства PSL, построенные на булевых выражениях и временных операторах в стиле LTL. Другой путь построения свойств использует SERE - Последовательные расширения регулярных выражений. SERE по-сути тоже самое, что и регулярные выражения, как те, которые используются для сопоставления во многих приложениях. Отличие лишь в том, что атом SERE - булево выражение, в то время, как атомы стандартного регулярного выражения - отдельные символы.


SERE обычно заключается в фигурные скобки, и атом SERE обычно разделен точкой с запятой. Например, <code>{a;b;c}</code> - это SERE, и SERE 5.1a - это более сложный SERE. SERE 5.1a описывает последовательность циклов, в которых утверждается <code>(req_out && !ack)</code> на первом цикле, далее <code>(busy && !ack)</code> утверждается нуль или более циклов, показанный последовательным оператором повторения <code>[*]</code>, и в итоге утверждается ack. Таким образом, SERE 5.1a отмечает последовательность циклов, под лейблом “1” в тракте 5.1(i).


Не поддавайтесь искушению в трактовке SERE более, чем показано здесь: SERE 5.1a показывает последовательность циклов под лейблом “2” в тракте 5.1(i). SERE 5.1a не запрещает утверждения занятости в течение последнего цикла SERE. Если важно исключить такое поведение, занятость может быть явно указана, как показано в SERE 5.1b. SERE 5.1b показывает последовательность циклов под лейблом “1”, показанная на тракте 5.1(i), но не показывает последовательность циклов под лейблом “2” в этом же тракте.


Как использовать SERE? Во-первых, SERE может также быть под-свойством. Например, свойство 5.2a выполняется, если существует утверждение <code>req_in && gnt</code>, далее начиная со следующего цикла, мы видим последовательность циклов отмеченных SERE 5.1a. Свойство 5.2a выполняется на тракте 5.2(i).


Примечание: SERE - это свойство, но свойство это не всегда SERE. Таким образом, пока мы можем использовать SERE, как операнд временного оператора, мы не можем вставить временной оператор, такой как <code>always</code> или <code>next</code>, внутрь SERE.


Сейчас предположим, что у нас есть ситуация похожая на свойство 5.2a, но в которой грант (утверждение сигнала <code>gnt</code>) появляется циклом ''позже'' утверждения <code>req_in</code>. Мы можем попробовать заменить булево выражение <code>req_in && gnt</code> временным выражением <code>req_in && next gnt</code>, как в свойстве 5.3a. Однако, вспомним урок раздела 3.4: в свойстве 5.3a текущий цикл лева-ориентированной стороны <tt>(req_in && next gnt)</tt> тот же самый, что и текущий цикл право-ориентированной стороны (потому что они соединены булевым оператором <tt>-></tt>). Таким образом, текущий цикл <code>gnt</code> (который является операндом оператора <code>next</code>) - это тот же текущий цикл для SERE (который также является операндом оператора <code>next</code>). Это немного запутанно, и действительно свойство 5.3а не принадлежит простому подмножеству PSL, которые мы обсуждали в главе 9.


Давайте модифицируем свойство 5.3а, как показано в свойстве 5.3b. Сейчас один оператор <code>next</code> применяется для обоих, <code>gnt</code> и SERE, которые являются операндами оператора <code>-></code>. Свойство 5.3b эквивалентно свойству 5.3a, но оно из просто подмножества, делая более простым отслеживание временной выборки между <code>gnt</code> и SERE. Если мы подразумеваем, что текущий цикл SERE должен быть циклом ''позже'' <code>gnt</code>, мы можем манипулировать свойством 5.3b, добавляя <code>next</code>, как в свойстве 5.3c. Однако, суффиксная импликация операторов предоставляет более простой путь.

{| align=center
! [[Файл:Psl fig5.1.png]]
|-
!(i) SERE 5.1a отмечает 1 и 2. SERE 5.1b отмечает 1, но не 2.
|-
|<pre>
{(req_out && !ack) ; (busy && !ack)[*] ; ack} (5.1a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack && !busy} (5.1b)
</pre>
|-
! Рис. 5.1: Два простых SEREs
|}

{| align=center
! [[Файл:Psl fig5.2.png]]
|-
!(i) Свойство 5.2a выполняется
|-
|<pre>
always ((req_in && gnt) -> (5.2a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
</pre>
|-
! Рис. 5.2: SERE - свойство
|}

{| align=center width=80%
|<pre>
always ((req_in && next gnt) -> (5.3a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
always (req_in -> next (gnt -> (5.3b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}))
always (req_in -> next (gnt -> (5.3c)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack}))
</pre>
|-
! Рис. 5.3: Свойство 5.3a не из простого подмножества. Свойства 5.3b и 5.3c из простого подмножества,
но они сложны для чтения. Эти свойства можно выразить проще, используя суффиксную импликацию.
|}

==5.1 Суффиксная импликация (<code>|-></code> и <code>|=></code>)==


Операторы ''суффиксной импликации'' (<code>|-></code> и <code>|=></code>) предоставляют возможность ссылаться на два SERE таким образом, что право-ориентированная сторона начинает работать, когда лева-сторонняя сторона заканчивает работы. Параллельный оператор суффиксной импликации (<code>|-></code>) интерпретирует “когда лева-ориентированная сторона заканчивает работать” также, как “в том же цикле, когда лева-ориентированная сторона заканчивает работать”, в то время как не параллельный оператор суффиксной импликации (<code>|=></code>) интерпретирует это, как “цикл после цикла, в котором лева-ориентированная сторона завершила работу”. Таким образом, свойство 5.4а эквивалентно свойству 5.3b, и свойство 5.4b эквивалентно свойству 5.3c. Оба свойства 5.4a и 5.4b легче для понимания, чем эквивалентное свойство без суффиксной импликации , и оба принадлежат простому подмножеству из главы 9.

{| align=center
! [[Файл:Psl fig5.4.png]]
|-
|<pre>
always {req_in;gnt} |-> (5.4a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.4b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}

</pre>
|-
! Рис. 5.4: Суффиксная импликация
|}


Напомним, что логический оператор импликации (<code>-></code>) может интерпретироваться, как if-then выражение, с безоговорочно утвержденной else-частью. Суффиксный оператор импликации (<code>|-></code> and <code>|=></code>) может восприниматься также. Разница между логическим оператором импликации (<code>-></code>) и суффиксным оператором импликации (<code>|-></code> and <code>|=></code>) во временных взаимоотношениях между if- и then-частями. В то время, как текущий цикл then-части для оператора логической импликации
(->) тот же, что и для if-части, текущий цикл then-части суффиксного оператора импликации (<code>|-></code> or <code>|=></code>) это первый цикл ''суффикса'' тракта, который остается после того, как сменяется if-часть. Это показано для свойств 5.4a и 5.4b в трактах 5.4(i) и 5.4(ii).

{| align=center
! [[Файл:Psl fig5.5.png]]
|-
! (i) Тракт имеет множественные if-then пары. Свойство 5.5a выполняется.
|-
|<pre>
always {req_in;gnt} |=> (5.5a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.5: if-часть другой if-then пары может начаться перед тем, как if-часть или
then-часть предыдущей if-then пары выполниться
|}


В трактах 5.4(i) и 5.4(ii) присутствует единичное утверждение сигнала <code>req_in</code>. Если бы здесь было множественные утверждения <code>req_in</code>, то, конечно же, мы должны были бы идентифицировать множественные if-then пары, как показано в тракте 5.5(i). Отметим, что if-часть другой if-then пары может начинаться, перед завершение выполнения if-части или then-части предыдущей if-then пары. Например, вторая if-then пара начинается в седьмом цикле, перед тем, как выполнится then-часть первой пары. Третья if-then прара начинается в цикле 8, перед тем как выполнятся then-часть первой пары и if-часть второй пары. Мы могли видеть такой вид перекрытия ранее, в трактах 2.2(ii) и 2.3(iii). Отметим, что в тракте 5.5(i) утверждение <code>ack</code> в цикле 16 завершает then-часть второй и третьей if-then пары. Для более глубокого объяснения этого феномена,смотрите раздел 13.4.2.

Свойства 5.6a и 5.6b выполняются в тракте 5.6(i), потому что не существует последовательности циклов согласованных с левой стороной, т.о. else-часть по-умолчанию утверждается в каждом цикле.

{| align=center
! [[Файл:Psl fig5.6.png]]
|-
! (i) Свойства 5.6a и 5.6b выполняются
|-
|<pre>
always {req_in;gnt} |-> (5.6a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.6b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.6: else-часть суффиксной импликации по-умолчанию утверждена
|}

==5.2 Слабый и сильный SERE==


Как и временные операторы, SERE могут быть слабыми и сильными, и как и временные операторы, сильные версии SERE обозначаются восклицательным знаком (<code>!</code>). Таким образом, свойство 5.7а, правая сторона которого

{| align=center
! [[Файл:Psl fig5.7.png]]
|-
|<pre>
always {req_in;gnt} |=> (5.7a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.7b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}!
</pre>
|-
! Fig. 5.7: A weak SERE holds even if the trace is “too short”, while a strong SERE
must “reach the end”
|}

==5.3 The <code>never</code> operator applied to a SERE==

Another way to use a SERE is in describing sequences of events that should
never happen. For example, Assertion 5.8a states that signal <code>req</code> should never
be asserted for two consecutive cycles, and thus does not hold on Trace 5.8(i).

As another example, consider Assertion 5.9a. It states that an acknowl-
edged high priority request (assertion of <code>req</code> together with <code>high_pri</code>, followed
a cycle later by <code>ack</code>) cannot be canceled (assertion of <code>cancel</code> the cycle after
<code>ack</code>). Thus it holds on Trace 5.9(i), but not on Trace 5.9(ii).

{| align=center
! [[Файл:Psl fig5.8.png]]
|-
| (i) Assertion 5.8a does not hold
|-
|<pre>
assert never {req;req}; (5.8a)
</pre>
|-
! Fig. 5.8: The never operator
|}

{| align=center
! [[Файл:Psl fig5.9.png]]
|-
| (i) Assertion 5.8a does not hold
|-
|<pre>
assert never {req && high_pri ; ack ; cancel}; (5.9a)
</pre>
|-
! Fig. 5.9: More about the never operator
|}

==5.4 SERE repetition operators (<code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>)==

Up until now, we have seen basic SEREs composed of (possibly repeated)
Boolean expressions separated by semi-colons. In this section, we examine
SERE operators that allow you to build more sophisticated SEREs, using
variations on the SERE repetition operators <code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>.

Consecutive repetition operators provide a shortcut to typing the same
sub-SERE a number of times. The <code>[*n]</code> operator is an abbreviation for
n repetitions of the SERE it is applied to. For example, instead of typing
<code>busy;busy;busy</code> in Assertion 5.10a, we can use the abbreviation <code>busy[*3]</code>,
as in Assertion 5.10b. Assertions 5.10a and 5.10b state that after a request
(assertion of signal <code>req</code>), we expect to see an acknowledge (assertion of signal
<code>ack</code>) followed by three cycles in which signal <code>busy</code> is asserted, followed by
an assertion of signal <code>done</code>. Trace 5.10(i) is an example of a trace on which
Assertions 5.10a and 5.10b hold.

{| align=center
! [[Файл:Psl fig5.10.png]]
|-
|<pre>
assert always {req} |=> {ack;busy;busy;busy;done}; (5.10a)
assert always {req} |=> {ack ; busy[*3] ; done}; (5.10b)
assert always {req} |=> {ack ; busy[*3:5] ; done}; (5.10c)
</pre>
|-
! Fig. 5.10: The <code>[*n]</code> and <code>[*i:j]</code> operators
|}

Instead of a specific number of repetitions, we can specify a range, i
through <code>j</code>, like this: <code>[*i:j]</code>. Thus, Assertion 5.10c is similar to Asser-
tion 5.10b, but instead of requiring exactly three assertions of signal <code>busy</code>,
we require between three and five. Assertion 5.10c holds on Trace 5.10(i) as
well as on Trace 5.10(ii).

The upper bound of a range can be infinity, which is indicated by a <code>$</code> in
the SystemVerilog flavor, by ''null'' in the GDL flavor, and by inf in the Verilog,
VHDL, and SystemC flavors. For instance, the SERE <code>{b[*5:inf]}</code> matches
five or more repetitions of <code>b</code>.

We can repeat not only a Boolean expression, but a SERE as well. For
example, Property 5.11a holds if after an acknowledged request (an assertion
of signal <code>req</code> followed by an assertion of signal <code>ack</code>), we see three data transfers
followed by an assertion of signal <code>d_end</code>, where a data transfer is an assertion
of signal <code>start</code> followed by an assertion of signal <code>busy</code> followed by an assertion
of signal <code>done</code>. Trace 5.11(i) is an example of a trace on which Property 5.11a
holds.

If we omit the <code>n</code>, the resulting SERE matches any number of repetitions of
the Boolean expression or SERE that is being repeated. For example, asserting
Property 5.11b indicates that after an acknowledged request, we expect to see
any number of data transfers followed by an assertion of <code>done</code>. Property 5.11b
holds on Trace 5.11(i), as well as on Traces 5.11(ii) and 5.11(iii).

A <code>[*]</code> repetition matches any number of repetitions, including none. Thus,
Property 5.11b holds on Trace 5.11(iv) as well. If you want to specify any
non-zero number of repetitions, use the <code>[+]</code>. Thus, Property 5.11c is similar
to Property 5.11b, but it requires at least one data transfer before signal done
is asserted. Thus, Property 5.11c does not hold on Trace 5.11(iv), but it does
hold on Traces 5.11(i), 5.11(ii) and 5.11(iii).

Instead of omitting the n, we can omit the Boolean expression or SERE
and let the repetition <code>[*n]</code> stand alone. A stand-alone <code>[*n]</code> is equivalent
to <code>‘true[*n]</code>. In other words, <code>[*n]</code> matches any n cycles (because <code>‘true</code>
holds in all cycles). Another way to think of it is that it allows us to “skip”
<code>n</code> cycles. Thus, Property 5.12a is similar to Property 5.11b, but instead of
the acknowledge (assertion of signal <code>ack</code>) coming immediately following the
request (assertion of signal <code>req</code>), it comes four cycles later. Property 5.12a
holds on Trace 5.12(i).

The nonconsecutive repetition operator (<code>[=n]</code>) provides a way to describe
repetitions that happen on not necessarily consecutive cycles. It can be ap-
plied only to a Boolean expression. For example, to describe the requirement
that after a request (assertion of signal <code>req</code>), we expect to see an acknowledge
(assertion of signal <code>ack</code>) followed by some number of cycles including three
not necessarily consecutive assertions of signal <code>busy</code>, followed by an asser-
tion of signal <code>done</code>, we can code Assertion 5.13a. Assertion 5.13a holds on
Trace 5.13(i). Note the cycles marked “<code>busy[=3]</code>” in Trace 5.13(i). They do
not start with an assertion of <code>busy</code>, nor do they end with one. The noncon-
secutive repetition operator <code>[=n]</code> will match any sequence of cycles in which
there are <code>n</code> not necessarily consecutive repetitions of the Boolean expression
being repeated, including sequences of cycles in which the “padding” is at
the beginning and/or at the end. In other words, it will match any sequence
of cycles in which the number of assertions of the Boolean expression being
repeated is ''equal to'' <code>n</code> (thus the use of the equals sign in <code>[=n]</code>).

If you want to disallow the padding at the end, use the goto repetition op-
erator [->n]. The goto repetition operator [->n] is similar to the nonconsec-
utive repetition operator, except that the sequence of cycles being described
ends with an assertion of the Boolean expression being repeated. In other
words, it will match any sequence of cycles starting at the current cycle and
ending after you “go to” the nth occurrence of the Boolean expression (the
use of the -> is intended to remind you of an arrow instructing you to go to
n). Thus Assertion 5.13b does not hold on Trace 5.13(i), but it does hold on
Trace 5.13(ii) because the third busy is immediately followed by an assertion
of signal done.

The n can be omitted for the goto repetition operator, in which case n
defaults to 1. In other words, b[->] is equivalent to b[->1].

Like the consecutive repetition operators, the nonconsecutive repetition
operator and the goto repetition operator can take a range. Thus, Asser-
tion 5.14a requires three to five not necessarily consecutive assertions of busy
after the assertion of signal ack and before the assertion of done, while Asser-
tion 5.14b requires the same, and in addition that the assertion of signal done
occur immediately after the 3rd, 4th, or 5th assertion of signal busy. Thus As-
sertion 5.14a holds on Traces 5.14(i) and 5.14(ii), while Assertion 5.14b holds
on Trace 5.14(ii) but not on Trace 5.14(i).

==5.5 Concatenation (;) and fusion (:)==

We have already seen the concatenation operator, a semi-colon, which is used
to join two SEREs (or two Boolean expressions, or a Boolean expression and
a SERE) in such a way that the right-hand SERE starts the cycle after the
left-hand SERE ends. The fusion operator, a colon, is used to join two SEREs
(or two Boolean expressions, or a Boolean expression and a SERE) in such a
way that there is a single cycle of overlap between them: the right-hand SERE
starts the same cycle that the left-hand SERE ends.

For example, consider the case that we want to specify the behavior of As-
sertion 5.14b, and in addition, following the assertion of signal done, we should
see a data transfer, which consists of the assertion of signal data for some num-
ber of cycles (might be zero), followed by an assertion of signal d end. Using
the concatenation operator, we can write Assertion 5.15a. Trace 5.15(i) is a
trace on which Assertion 5.15a holds. The first assertion of signal req gets
three cycles of data before the assertion of d end, while the second assertion
of signal req sees four cycles of data before seeing d end.

If the data transfer should start the same cycle as signal done is asserted,
then we can use the fusion operator as in Assertion 5.16a. Trace 5.16(i) is an
example of a trace on which Assertion 5.16a holds. It is similar to Trace 5.15(i),
except that the data transfer starts the same cycle as that in which done is
asserted, rather than the cycle following the assertion of signal done.

Note that while it may be tempting to understand the concatenation op-
erator (;) as a delay, the operator does not necessarily “eat” a cycle. For in-
stance, in the case of the SERE {a ; b[*] ; c}, the b[*] may match zero,
one, or more cycles, as illustrated in Trace 5.17(i). The first match shown in
Trace 5.17(i) is only two cycles long, thus, the second concatenation operator
(;) did not “eat” a delay. A better way to think of it is that concatenation
gives you an ordered list of things to happen – some of them may consume
one cycle, some more, and some no cycles at all.

Further note that fusion requires an overlap of at least one cycle. Thus,
while the {b[*]} in {b[*] ; c} may match an empty sequence of cycles,
replacing the concatenation operator with the fusion operator like this: {b[*]: c}
results in a SERE with at least one assertion of b (otherwise there is
nothing to overlap with the assertion of c). In both cases, the match may
consist of a single cycle. The difference is that in the case of {b[*] ; c} the
single cycle may not include an assertion of b (because there may be zero
assertions of b preceding c), while in the case of {b[*] : c}, the single cycle
must include an assertion of b (which overlaps with the assertion of c).

==5.6 Compound SEREs==

Compound SEREs are SEREs built from other SEREs through operations
other than concatenation and fusion. The available operators allow you to
“and” or “or” together two or more SEREs, as well as to express the situation
where a match of one SERE occurs within a sequence of cycles matched by
another.

Consider the case that we want to say that signal read complete is as-
serted on the last data cycle of every read operation, where we have two kinds
of read operations: a short read consists of an assertion of signal short rd fol-
lowed by eight not necessarily consecutive assertions of data, and a long read
consists of an assertion of signal long rd followed by 32 such assertions. We
could code two separate properties, as shown in Properties 5.18a and 5.18b.
Alternatively, we could use the SERE “or” operator (|) to “or” the two SEREs
together, as in Property 5.18c.

The SERE “and” operator comes in two types: length-matching and non-
length-matching. Both the length-matching (&&) and the non-length-matching
(&) “and” operators match a sequence of cycles if starting at the current cycle,
the left-hand side and the right-hand side are matched. The difference is that
in addition, the length-matching “and” operator requires that the lengths of
the sequences matched by both the left- and right-hand sides are the same,
while the non-length-matching operator matches even if they are different. A
length-matching “and” between SEREs R and S is illustrated in Trace 5.19(i),
and a non-length-matching “and” between SEREs R and S is illustrated in
Traces 5.20(i), 5.20(ii) and 5.20(iii).

When a non-length-matching “and” is used on the left-hand side of a con-
catenation or a fusion, the current cycle of the right-hand side of the concate-
nation or fusion is determined by the longer of the two subsequences making
up the non-length-matching “and”. For instance, in the SERE {{{a;b[*5];c}
& {d[*];e}} ; f}, the current cycle of f is the cycle after the cycle in which
the longer of the two SEREs {a;b[*5];c} and {d[*];e} completes. This is
illustrated in Traces 5.21(i) and 5.21(ii). Note that in each of the traces, sig-
nal f is asserted twice: once after the completion of {a;b[*5];c}, and once
after the completion of {d[*];e}. However, in each trace, only the assertion
of signal f that happens after the completion of the longer of the two SEREs
participates in the “match” of SERE {{{a;b[*5];c} & {d[*];e}} ; f}.

NOTE: A length-matching “and” such as {a;b;c} && {d} is legal, but
makes no sense (because there is no sequence which is both 3 cycles long to
match {a;b;c} and 1 cycle long to match {d}). Many tools will probably issue
a warning for such a SERE.

As an example of the use of the length-matching “and”, consider the case
that a read request (assertion of signal read req) that is granted (assertion of
signal gnt within 5 cycles of the request) should be followed by a data transfer
(assertion of signal data start followed by some number of consecutive as-
sertions of data, followed by an assertion of data end), unless it is canceled.
A cancel is an assertion of signal cancel any time between the assertion of
read req and the assertion of gnt, inclusive. We can express this using As-
sertion 5.22a. Assertion 5.22a holds on Trace 5.22(i): the first read request is
followed by a data transfer, while the second read request is not followed by
a data transfer, but is not required to be since it is canceled.

In the case of Assertion 5.22a, we needed the length-matching “and”.
To see why, consider what would have happened had we used the non-
length-matching “and” as in Assertion 5.22b. In the case of Assertion 5.22b,
the left-hand side SERE {{read req ; [*0:4] ; gnt} & {cancel[=0]}} is
matched not only by the sequence of cycles starting at cycle 2 and ending at
cycle 5, but also by the sequences of cycles starting at cycle 2 and ending at
any of the cycles 6 through 16. Thus, Assertion 5.22b requires that we see a
data transfer starting not only at cycle 6, but also at cycles 7, 8, 9, 10 and so
on. Obviously, this is not what we wanted.

As an example where we want the non-length-matching “and” rather than
the length-matching “and”, consider the case that signal global print req
indicates that we should see a print on each of printers 1, 2, and 3 (comple-
tion of which is indicated by assertions of p1 done, p2 done, and p3 done,
respectively), and that following completion of the last print job, we should
see an assertion of signal print success. We can express this as shown in
Assertion 5.23a. Assertion 5.23a holds on Trace 5.23(i) because following the
assertion of signal global print req, we see assertions of each of the signals
p1 done, p2 done and p3 done, the last of which is followed by an assertion
of print success.

The non-length-matching “and” was needed for Assertion 5.23a. To see
why, consider what would have happened if we had used the length-matching
“and”, as in Assertion 5.23b. Assertion 5.23b does not hold on Trace 5.23(i)
because the use of the length-matching “and” means that p1 done[->],
p2 done[->] and p3 done[->] must all have the same length, i.e., that
p1 done, p2 done and p3 done must all be asserted at the same time.

The SERE within operator is useful if you want to describe a situation
where one SERE occurs within the time frame of another. For instance, sup-
pose that the normal behavior of the design is to complete a high priority
request first, even if there is a pending low priority request that started be-
fore it. However, if signal no nesting is asserted when the low priority re-
quest is issued, then this is prohibited. In other words, the situation shown
in Trace 5.24(i) is not allowed. We can describe the prohibited situation as
shown in Assertion 5.24a. Assertion 5.24a does not hold on Trace 5.24(i)
because there is a match of {high pri begin ; high pri end[->]} that is
entirely enclosed within the match of {(low pri begin && no nesting) ;
low pri end[->]}.

NOTE: If the left and right operands of a within operator are s and t
respectively, then the within operator is simply a shorthand for a length-
matching “and” between {[*] ; s ; [*]} and {t}. That is, s within t is
equivalent to {[*] ; s ; [*]} && {t}.

==5.7 More about suffix implication==

Up until now, we have seen the suffix implication operators (|-> and |=>)
used with SEREs on both the left- and the right-hand sides. While the left-
hand side of a suffix implication operator must be a SERE, the right-hand
side of a suffix implication operator can be any property. Thus, if we want to
express the requirement that whenever we have a request that is acknowledged
(assertion of req followed by an assertion of ack) we should see a grant
(assertion of signal gnt within three cycles of the acknowledge), we can code
as in Assertion 5.25a.

This is illustrated in Trace 5.25(i). In the trace, there are three occurrences
of the SERE {req;ack}. The first is followed by an assertion of ack after two
cycles, the second after three cycles, and the third after a single cycle. Thus,
Assertion 5.25a holds on the trace.

Of course, we could have written Assertion 5.25a entirely in SERE style,
as shown in Assertion 5.25b, or entirely without SEREs, as in Assertion 5.25c.
Assertions 5.25a, 5.25b and 5.25c are equivalent, thus the issue is purely one
of style. Some people prefer using only one style, others find a mix of styles,
depending on the particular property, to be easier to understand.

==5.8 The built-in function ended()==

The built-in function ended() takes a SERE as an argument and returns true
in any cycle where that SERE has just ended.1 For example, Trace 5.26(i) has
been annotated with a waveform labeled ended({a ; b[*] ; c}) to show
the value of the call to ended() at each cycle.

<blockquote>1 - In previous versions of PSL, the role of the built-in function ended() was played by
endpoints. Endpoints are no longer a part of the language – use built-in function
ended() instead.</blockquote>

How is ended() used? Consider that a complete data transfer consists of
an assertion of signal data start followed by some number of assertions of
data, followed by an assertion of data end. Consider further that we have a
signal data transfer complete that should be asserted when a data trans-
fer is completed, and that we would like to specify the correct behavior of
this signal. A good start would be Assertion 5.27a. Assertion 5.27a ensures
that data transfer complete is asserted at the conclusion of every data
transfer. But what about the other direction? That is, what about ensuring
that whenever data transfer complete is asserted, a complete data trans-
fer has indeed concluded? Assertion 5.27a does not ensure this, and thus
it holds on Trace 5.27(i), even though there are “extraneous” assertions of
data transfer complete at cycles 6 and 15. We would like an assertion that
holds on Trace 5.27(ii) but not on 5.27(i).

In order to check the second direction (that there are no extraneous asser-
tions of data transfer complete) we need to switch the direction of the
implication: we need to say that if data transfer complete is asserted,
then we have just seen the conclusion of a complete data transfer. We could
try Assertion 5.27b. However, that doesn’t work. Assertion 5.27b requires
that the SERE {data start ; data[*] ; data end} start the same cycle as
data transfer complete, while we want it to end that cycle.

This is where the built-in function ended() comes in. Using ended(),
we can code what we want as shown in Assertion 5.27c, which states that
whenever we see an assertion of data transfer complete, we must have just
seen the end of SERE {data start ; data[*] ; data end}, and it does not
hold on Trace 5.27(i).

Note that ended() returns a Boolean value. Since the left-hand side of the
suffix implication in Assertion 5.27c consists of a single Boolean expression,
we could have coded Assertion 5.27c equivalently using logical implication as
shown in Assertion 5.27d.

==5.9 Overlapping matches of a SERE==

Up until now, we have been concentrating on explaining the meaning of each
SERE operator, using relatively simple examples. It is now time to introduce
some more complex examples, in order to emphasize that like LTL style prop-
erties, interpreting a SERE style property on a trace can involve examining
overlapping sets of cycles.

Consider Property 5.28a on Traces 5.28(i) and 5.28(ii). There are multiple
matches of {a ; b[*] ; c} on Trace 5.28(i), one match ending at cycle 2,
one ending at cycle 3, and one ending at cycle 4. Property 5.28a does not
hold on Trace 5.28(i), because the matches ending at cycles 2 and 3 do not
have associated assertions of signal d at cycles 3 and 4. A suffix implication
requires that for every match of the left-hand side, the right-hand side holds.
Property 5.28a does hold on Trace 5.28(ii), because signal d is asserted after
each match of {a ; b[*] ; c}.

Note that although Property 5.28a contains an always operator, the
always operator is not the source of the overlapping matches in this case.
Rather, for a single current cycle (cycle 1), there are three separate matches
of the SERE {a ; b[*] ; c}, each ending at a different cycle.

The overlapping can happen on the right-hand side of a suffix implication
as well. Consider for example Property 5.29a on Trace 5.29(i). There are three
matches of {d ; e[*] ; f}, ending at cycles 3, 4, and 5. One match would
have been enough to satisfy Property 5.29a, because as long as there exists one
match, {d ; e[*] ; f} holds. The fact that there are in fact three matches
does not hurt. Thus, Property 5.29a holds on Trace 5.29(i).

We have just explained that we require at least one match of the right-hand
side for every match of the left-hand side of a suffix implication, and it might
seem that in so doing, we have introduced something new. Actually, the rule
could have been deduced from the parallel we have previously drawn between
a suffix implication and an if-then statement. SERE {a ; b[*] ; c} can be
understood as an infinite “or” between SEREs {a;c}, {a;b;c}, {a;b;b;c},
and so on. So Property 5.28a can be understood as “if {a;c} or {a;b;c} or
{a;b;b;c} or ..., then d”, which clearly should hold only if we see a d every
time the if-part is matched. And Property 5.29a can be understood as “if c,
then {d;f} or {d;e;f} or {d;e;e;f} or ...”, which of course should hold as
long as we have seen at least a single match of the then-part.

==5.10 How not to use SEREs==

[[Файл:Psl fig5.4.png]]

[[Файл:Psl fig5.5.png]]

[[Файл:Psl fig5.6.png]]

[[Файл:Psl fig5.7.png]]

[[Файл:Psl fig5.8.png]]

[[Файл:Psl fig5.9.png]]

[[Файл:Psl fig5.10.png]]

[[Файл:Psl fig5.11.png]]

[[Файл:Psl fig5.12.png]]

[[Файл:Psl fig5.13.png]]

[[Файл:Psl fig5.14.png]]

[[Файл:Psl fig5.15.png]]

[[Файл:Psl fig5.16.png]]

PSL/A Practical Introduction to PSL/SERE Style

2014-01-30T08:37:42Z

Valentin: /* 5.1 Суффиксная импликация (|-> и |=>) */

{{PSL TOC}}

=Стиль SERE=


До этого момента, мы видели свойства PSL, построенные на булевых выражениях и временных операторах в стиле LTL. Другой путь построения свойств использует SERE - Последовательные расширения регулярных выражений. SERE по-сути тоже самое, что и регулярные выражения, как те, которые используются для сопоставления во многих приложениях. Отличие лишь в том, что атом SERE - булево выражение, в то время, как атомы стандартного регулярного выражения - отдельные символы.


SERE обычно заключается в фигурные скобки, и атом SERE обычно разделен точкой с запятой. Например, <code>{a;b;c}</code> - это SERE, и SERE 5.1a - это более сложный SERE. SERE 5.1a описывает последовательность циклов, в которых утверждается <code>(req_out && !ack)</code> на первом цикле, далее <code>(busy && !ack)</code> утверждается нуль или более циклов, показанный последовательным оператором повторения <code>[*]</code>, и в итоге утверждается ack. Таким образом, SERE 5.1a отмечает последовательность циклов, под лейблом “1” в тракте 5.1(i).


Не поддавайтесь искушению в трактовке SERE более, чем показано здесь: SERE 5.1a показывает последовательность циклов под лейблом “2” в тракте 5.1(i). SERE 5.1a не запрещает утверждения занятости в течение последнего цикла SERE. Если важно исключить такое поведение, занятость может быть явно указана, как показано в SERE 5.1b. SERE 5.1b показывает последовательность циклов под лейблом “1”, показанная на тракте 5.1(i), но не показывает последовательность циклов под лейблом “2” в этом же тракте.


Как использовать SERE? Во-первых, SERE может также быть под-свойством. Например, свойство 5.2a выполняется, если существует утверждение <code>req_in && gnt</code>, далее начиная со следующего цикла, мы видим последовательность циклов отмеченных SERE 5.1a. Свойство 5.2a выполняется на тракте 5.2(i).


Примечание: SERE - это свойство, но свойство это не всегда SERE. Таким образом, пока мы можем использовать SERE, как операнд временного оператора, мы не можем вставить временной оператор, такой как <code>always</code> или <code>next</code>, внутрь SERE.


Сейчас предположим, что у нас есть ситуация похожая на свойство 5.2a, но в которой грант (утверждение сигнала <code>gnt</code>) появляется циклом ''позже'' утверждения <code>req_in</code>. Мы можем попробовать заменить булево выражение <code>req_in && gnt</code> временным выражением <code>req_in && next gnt</code>, как в свойстве 5.3a. Однако, вспомним урок раздела 3.4: в свойстве 5.3a текущий цикл лева-ориентированной стороны <tt>(req_in && next gnt)</tt> тот же самый, что и текущий цикл право-ориентированной стороны (потому что они соединены булевым оператором <tt>-></tt>). Таким образом, текущий цикл <code>gnt</code> (который является операндом оператора <code>next</code>) - это тот же текущий цикл для SERE (который также является операндом оператора <code>next</code>). Это немного запутанно, и действительно свойство 5.3а не принадлежит простому подмножеству PSL, которые мы обсуждали в главе 9.


Давайте модифицируем свойство 5.3а, как показано в свойстве 5.3b. Сейчас один оператор <code>next</code> применяется для обоих, <code>gnt</code> и SERE, которые являются операндами оператора <code>-></code>. Свойство 5.3b эквивалентно свойству 5.3a, но оно из просто подмножества, делая более простым отслеживание временной выборки между <code>gnt</code> и SERE. Если мы подразумеваем, что текущий цикл SERE должен быть циклом ''позже'' <code>gnt</code>, мы можем манипулировать свойством 5.3b, добавляя <code>next</code>, как в свойстве 5.3c. Однако, суффиксная импликация операторов предоставляет более простой путь.

{| align=center
! [[Файл:Psl fig5.1.png]]
|-
!(i) SERE 5.1a отмечает 1 и 2. SERE 5.1b отмечает 1, но не 2.
|-
|<pre>
{(req_out && !ack) ; (busy && !ack)[*] ; ack} (5.1a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack && !busy} (5.1b)
</pre>
|-
! Рис. 5.1: Два простых SEREs
|}

{| align=center
! [[Файл:Psl fig5.2.png]]
|-
!(i) Свойство 5.2a выполняется
|-
|<pre>
always ((req_in && gnt) -> (5.2a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
</pre>
|-
! Рис. 5.2: SERE - свойство
|}

{| align=center width=80%
|<pre>
always ((req_in && next gnt) -> (5.3a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
always (req_in -> next (gnt -> (5.3b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}))
always (req_in -> next (gnt -> (5.3c)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack}))
</pre>
|-
! Рис. 5.3: Свойство 5.3a не из простого подмножества. Свойства 5.3b и 5.3c из простого подмножества,
но они сложны для чтения. Эти свойства можно выразить проще, используя суффиксную импликацию.
|}

==5.1 Суффиксная импликация (<code>|-></code> и <code>|=></code>)==


Операторы ''суффиксной импликации'' (<code>|-></code> и <code>|=></code>) предоставляют возможность ссылаться на два SERE таким образом, что право-ориентированная сторона начинает работать, когда лева-сторонняя сторона заканчивает работы. Параллельный оператор суффиксной импликации (<code>|-></code>) интерпретирует “когда лева-ориентированная сторона заканчивает работать” также, как “в том же цикле, когда лева-ориентированная сторона заканчивает работать”, в то время как не параллельный оператор суффиксной импликации (<code>|=></code>) интерпретирует это, как “цикл после цикла, в котором лева-ориентированная сторона завершила работу”. Таким образом, свойство 5.4а эквивалентно свойству 5.3b, и свойство 5.4b эквивалентно свойству 5.3c. Оба свойства 5.4a и 5.4b легче для понимания, чем эквивалентное свойство без суффиксной импликации , и оба принадлежат простому подмножеству из главы 9.

{| align=center
! [[Файл:Psl fig5.4.png]]
|-
|<pre>
always {req_in;gnt} |-> (5.4a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.4b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}

</pre>
|-
! Рис. 5.4: Суффиксная импликация
|}


Напомним, что логический оператор импликации (<code>-></code>) может интерпретироваться, как if-then выражение, с безоговорочно утвержденной else-частью. Суффиксный оператор импликации (<code>|-></code> and <code>|=></code>) может восприниматься также. Разница между логическим оператором импликации (<code>-></code>) и суффиксным оператором импликации (<code>|-></code> and <code>|=></code>) во временных взаимоотношениях между if- и then-частями. В то время, как текущий цикл then-части для оператора логической импликации
(->) тот же, что и для if-части, текущий цикл then-части суффиксного оператора импликации (<code>|-></code> or <code>|=></code>) это первый цикл ''суффикса'' тракта, который остается после того, как сменяется if-часть. Это показано для свойств 5.4a и 5.4b в трактах 5.4(i) и 5.4(ii).

{| align=center
! [[Файл:Psl fig5.5.png]]
|-
! (i) Тракт имеет множественные if-then пары. Свойство 5.5a выполняется.
|-
|<pre>
always {req_in;gnt} |=> (5.5a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.5: if-часть другой if-then пары может начаться перед тем, как if-часть или
then-часть предыдущей if-then пары выполниться
|}


В трактах 5.4(i) и 5.4(ii) присутствует единичное утверждение сигнала <code>req_in</code>. Если бы здесь было множественные утверждения <code>req_in</code>, то, конечно же, мы должны были бы идентифицировать множественные if-then пары, как показано в тракте 5.5(i). Отметим, что if-часть другой if-then пары может начинаться, перед завершение выполнения if-части или then-части предыдущей if-then пары. Например, вторая if-then пара начинается в седьмом цикле, перед тем, как выполнится then-часть первой пары. Третья if-then прара начинается в цикле 8, перед тем как выполнятся then-часть первой пары и if-часть второй пары. Мы могли видеть такой вид перекрытия ранее, в трактах 2.2(ii) и 2.3(iii). Отметим, что в тракте 5.5(i) утверждение <code>ack</code> в цикле 16 завершает then-часть второй и третьей if-then пары. Для более глубокого объяснения этого феномена,смотрите раздел 13.4.2.

Свойства 5.6a и 5.6b выполняются в тракте 5.6(i), потому что не существует последовательности циклов согласованных с левой стороной, т.о. else-часть по-умолчанию утверждается в каждом цикле.

{| align=center
! [[Файл:Psl fig5.6.png]]
|-
! (i) Свойства 5.6a и 5.6b выполняются
|-
|<pre>
always {req_in;gnt} |-> (5.6a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.6b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.6: else-часть суффиксной импликации по-умолчанию утверждена
|}

==5.2 Weak and strong SEREs==

Like temporal operators, SEREs come in weak and strong versions, and like
temporal operators, the strong version of a SERE is indicated by an exclama-
tion point (<code>!</code>). Thus, Property 5.7a, whose right-hand side is a weak SERE,
holds even if signal <code>ack</code> is never asserted (as long as the rest of the SERE is
not violated). Property 5.7b, whose right-hand side is a strong SERE, holds
only if we eventually reach a cycle where <code>ack</code> occurs. In other words, the weak
version of a SERE allows us to accept a trace that is “too short”, whereas
the strong version requires that we “reach the end” of the SERE. Thus, while
Property 5.7a holds on Trace 5.7(i) as well as Trace 5.7(ii), Property 5.7b, the
strong version, holds on Trace 5.7(ii) but not on Trace 5.7(i).

{| align=center
! [[Файл:Psl fig5.7.png]]
|-
|<pre>
always {req_in;gnt} |=> (5.7a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.7b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}!
</pre>
|-
! Fig. 5.7: A weak SERE holds even if the trace is “too short”, while a strong SERE
must “reach the end”
|}

==5.3 The <code>never</code> operator applied to a SERE==

Another way to use a SERE is in describing sequences of events that should
never happen. For example, Assertion 5.8a states that signal <code>req</code> should never
be asserted for two consecutive cycles, and thus does not hold on Trace 5.8(i).

As another example, consider Assertion 5.9a. It states that an acknowl-
edged high priority request (assertion of <code>req</code> together with <code>high_pri</code>, followed
a cycle later by <code>ack</code>) cannot be canceled (assertion of <code>cancel</code> the cycle after
<code>ack</code>). Thus it holds on Trace 5.9(i), but not on Trace 5.9(ii).

{| align=center
! [[Файл:Psl fig5.8.png]]
|-
| (i) Assertion 5.8a does not hold
|-
|<pre>
assert never {req;req}; (5.8a)
</pre>
|-
! Fig. 5.8: The never operator
|}

{| align=center
! [[Файл:Psl fig5.9.png]]
|-
| (i) Assertion 5.8a does not hold
|-
|<pre>
assert never {req && high_pri ; ack ; cancel}; (5.9a)
</pre>
|-
! Fig. 5.9: More about the never operator
|}

==5.4 SERE repetition operators (<code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>)==

Up until now, we have seen basic SEREs composed of (possibly repeated)
Boolean expressions separated by semi-colons. In this section, we examine
SERE operators that allow you to build more sophisticated SEREs, using
variations on the SERE repetition operators <code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>.

Consecutive repetition operators provide a shortcut to typing the same
sub-SERE a number of times. The <code>[*n]</code> operator is an abbreviation for
n repetitions of the SERE it is applied to. For example, instead of typing
<code>busy;busy;busy</code> in Assertion 5.10a, we can use the abbreviation <code>busy[*3]</code>,
as in Assertion 5.10b. Assertions 5.10a and 5.10b state that after a request
(assertion of signal <code>req</code>), we expect to see an acknowledge (assertion of signal
<code>ack</code>) followed by three cycles in which signal <code>busy</code> is asserted, followed by
an assertion of signal <code>done</code>. Trace 5.10(i) is an example of a trace on which
Assertions 5.10a and 5.10b hold.

{| align=center
! [[Файл:Psl fig5.10.png]]
|-
|<pre>
assert always {req} |=> {ack;busy;busy;busy;done}; (5.10a)
assert always {req} |=> {ack ; busy[*3] ; done}; (5.10b)
assert always {req} |=> {ack ; busy[*3:5] ; done}; (5.10c)
</pre>
|-
! Fig. 5.10: The <code>[*n]</code> and <code>[*i:j]</code> operators
|}

Instead of a specific number of repetitions, we can specify a range, i
through <code>j</code>, like this: <code>[*i:j]</code>. Thus, Assertion 5.10c is similar to Asser-
tion 5.10b, but instead of requiring exactly three assertions of signal <code>busy</code>,
we require between three and five. Assertion 5.10c holds on Trace 5.10(i) as
well as on Trace 5.10(ii).

The upper bound of a range can be infinity, which is indicated by a <code>$</code> in
the SystemVerilog flavor, by ''null'' in the GDL flavor, and by inf in the Verilog,
VHDL, and SystemC flavors. For instance, the SERE <code>{b[*5:inf]}</code> matches
five or more repetitions of <code>b</code>.

We can repeat not only a Boolean expression, but a SERE as well. For
example, Property 5.11a holds if after an acknowledged request (an assertion
of signal <code>req</code> followed by an assertion of signal <code>ack</code>), we see three data transfers
followed by an assertion of signal <code>d_end</code>, where a data transfer is an assertion
of signal <code>start</code> followed by an assertion of signal <code>busy</code> followed by an assertion
of signal <code>done</code>. Trace 5.11(i) is an example of a trace on which Property 5.11a
holds.

If we omit the <code>n</code>, the resulting SERE matches any number of repetitions of
the Boolean expression or SERE that is being repeated. For example, asserting
Property 5.11b indicates that after an acknowledged request, we expect to see
any number of data transfers followed by an assertion of <code>done</code>. Property 5.11b
holds on Trace 5.11(i), as well as on Traces 5.11(ii) and 5.11(iii).

A <code>[*]</code> repetition matches any number of repetitions, including none. Thus,
Property 5.11b holds on Trace 5.11(iv) as well. If you want to specify any
non-zero number of repetitions, use the <code>[+]</code>. Thus, Property 5.11c is similar
to Property 5.11b, but it requires at least one data transfer before signal done
is asserted. Thus, Property 5.11c does not hold on Trace 5.11(iv), but it does
hold on Traces 5.11(i), 5.11(ii) and 5.11(iii).

Instead of omitting the n, we can omit the Boolean expression or SERE
and let the repetition <code>[*n]</code> stand alone. A stand-alone <code>[*n]</code> is equivalent
to <code>‘true[*n]</code>. In other words, <code>[*n]</code> matches any n cycles (because <code>‘true</code>
holds in all cycles). Another way to think of it is that it allows us to “skip”
<code>n</code> cycles. Thus, Property 5.12a is similar to Property 5.11b, but instead of
the acknowledge (assertion of signal <code>ack</code>) coming immediately following the
request (assertion of signal <code>req</code>), it comes four cycles later. Property 5.12a
holds on Trace 5.12(i).

The nonconsecutive repetition operator (<code>[=n]</code>) provides a way to describe
repetitions that happen on not necessarily consecutive cycles. It can be ap-
plied only to a Boolean expression. For example, to describe the requirement
that after a request (assertion of signal <code>req</code>), we expect to see an acknowledge
(assertion of signal <code>ack</code>) followed by some number of cycles including three
not necessarily consecutive assertions of signal <code>busy</code>, followed by an asser-
tion of signal <code>done</code>, we can code Assertion 5.13a. Assertion 5.13a holds on
Trace 5.13(i). Note the cycles marked “<code>busy[=3]</code>” in Trace 5.13(i). They do
not start with an assertion of <code>busy</code>, nor do they end with one. The noncon-
secutive repetition operator <code>[=n]</code> will match any sequence of cycles in which
there are <code>n</code> not necessarily consecutive repetitions of the Boolean expression
being repeated, including sequences of cycles in which the “padding” is at
the beginning and/or at the end. In other words, it will match any sequence
of cycles in which the number of assertions of the Boolean expression being
repeated is ''equal to'' <code>n</code> (thus the use of the equals sign in <code>[=n]</code>).

If you want to disallow the padding at the end, use the goto repetition op-
erator [->n]. The goto repetition operator [->n] is similar to the nonconsec-
utive repetition operator, except that the sequence of cycles being described
ends with an assertion of the Boolean expression being repeated. In other
words, it will match any sequence of cycles starting at the current cycle and
ending after you “go to” the nth occurrence of the Boolean expression (the
use of the -> is intended to remind you of an arrow instructing you to go to
n). Thus Assertion 5.13b does not hold on Trace 5.13(i), but it does hold on
Trace 5.13(ii) because the third busy is immediately followed by an assertion
of signal done.

The n can be omitted for the goto repetition operator, in which case n
defaults to 1. In other words, b[->] is equivalent to b[->1].

Like the consecutive repetition operators, the nonconsecutive repetition
operator and the goto repetition operator can take a range. Thus, Asser-
tion 5.14a requires three to five not necessarily consecutive assertions of busy
after the assertion of signal ack and before the assertion of done, while Asser-
tion 5.14b requires the same, and in addition that the assertion of signal done
occur immediately after the 3rd, 4th, or 5th assertion of signal busy. Thus As-
sertion 5.14a holds on Traces 5.14(i) and 5.14(ii), while Assertion 5.14b holds
on Trace 5.14(ii) but not on Trace 5.14(i).

==5.5 Concatenation (;) and fusion (:)==

We have already seen the concatenation operator, a semi-colon, which is used
to join two SEREs (or two Boolean expressions, or a Boolean expression and
a SERE) in such a way that the right-hand SERE starts the cycle after the
left-hand SERE ends. The fusion operator, a colon, is used to join two SEREs
(or two Boolean expressions, or a Boolean expression and a SERE) in such a
way that there is a single cycle of overlap between them: the right-hand SERE
starts the same cycle that the left-hand SERE ends.

For example, consider the case that we want to specify the behavior of As-
sertion 5.14b, and in addition, following the assertion of signal done, we should
see a data transfer, which consists of the assertion of signal data for some num-
ber of cycles (might be zero), followed by an assertion of signal d end. Using
the concatenation operator, we can write Assertion 5.15a. Trace 5.15(i) is a
trace on which Assertion 5.15a holds. The first assertion of signal req gets
three cycles of data before the assertion of d end, while the second assertion
of signal req sees four cycles of data before seeing d end.

If the data transfer should start the same cycle as signal done is asserted,
then we can use the fusion operator as in Assertion 5.16a. Trace 5.16(i) is an
example of a trace on which Assertion 5.16a holds. It is similar to Trace 5.15(i),
except that the data transfer starts the same cycle as that in which done is
asserted, rather than the cycle following the assertion of signal done.

Note that while it may be tempting to understand the concatenation op-
erator (;) as a delay, the operator does not necessarily “eat” a cycle. For in-
stance, in the case of the SERE {a ; b[*] ; c}, the b[*] may match zero,
one, or more cycles, as illustrated in Trace 5.17(i). The first match shown in
Trace 5.17(i) is only two cycles long, thus, the second concatenation operator
(;) did not “eat” a delay. A better way to think of it is that concatenation
gives you an ordered list of things to happen – some of them may consume
one cycle, some more, and some no cycles at all.

Further note that fusion requires an overlap of at least one cycle. Thus,
while the {b[*]} in {b[*] ; c} may match an empty sequence of cycles,
replacing the concatenation operator with the fusion operator like this: {b[*]: c}
results in a SERE with at least one assertion of b (otherwise there is
nothing to overlap with the assertion of c). In both cases, the match may
consist of a single cycle. The difference is that in the case of {b[*] ; c} the
single cycle may not include an assertion of b (because there may be zero
assertions of b preceding c), while in the case of {b[*] : c}, the single cycle
must include an assertion of b (which overlaps with the assertion of c).

==5.6 Compound SEREs==

Compound SEREs are SEREs built from other SEREs through operations
other than concatenation and fusion. The available operators allow you to
“and” or “or” together two or more SEREs, as well as to express the situation
where a match of one SERE occurs within a sequence of cycles matched by
another.

Consider the case that we want to say that signal read complete is as-
serted on the last data cycle of every read operation, where we have two kinds
of read operations: a short read consists of an assertion of signal short rd fol-
lowed by eight not necessarily consecutive assertions of data, and a long read
consists of an assertion of signal long rd followed by 32 such assertions. We
could code two separate properties, as shown in Properties 5.18a and 5.18b.
Alternatively, we could use the SERE “or” operator (|) to “or” the two SEREs
together, as in Property 5.18c.

The SERE “and” operator comes in two types: length-matching and non-
length-matching. Both the length-matching (&&) and the non-length-matching
(&) “and” operators match a sequence of cycles if starting at the current cycle,
the left-hand side and the right-hand side are matched. The difference is that
in addition, the length-matching “and” operator requires that the lengths of
the sequences matched by both the left- and right-hand sides are the same,
while the non-length-matching operator matches even if they are different. A
length-matching “and” between SEREs R and S is illustrated in Trace 5.19(i),
and a non-length-matching “and” between SEREs R and S is illustrated in
Traces 5.20(i), 5.20(ii) and 5.20(iii).

When a non-length-matching “and” is used on the left-hand side of a con-
catenation or a fusion, the current cycle of the right-hand side of the concate-
nation or fusion is determined by the longer of the two subsequences making
up the non-length-matching “and”. For instance, in the SERE {{{a;b[*5];c}
& {d[*];e}} ; f}, the current cycle of f is the cycle after the cycle in which
the longer of the two SEREs {a;b[*5];c} and {d[*];e} completes. This is
illustrated in Traces 5.21(i) and 5.21(ii). Note that in each of the traces, sig-
nal f is asserted twice: once after the completion of {a;b[*5];c}, and once
after the completion of {d[*];e}. However, in each trace, only the assertion
of signal f that happens after the completion of the longer of the two SEREs
participates in the “match” of SERE {{{a;b[*5];c} & {d[*];e}} ; f}.

NOTE: A length-matching “and” such as {a;b;c} && {d} is legal, but
makes no sense (because there is no sequence which is both 3 cycles long to
match {a;b;c} and 1 cycle long to match {d}). Many tools will probably issue
a warning for such a SERE.

As an example of the use of the length-matching “and”, consider the case
that a read request (assertion of signal read req) that is granted (assertion of
signal gnt within 5 cycles of the request) should be followed by a data transfer
(assertion of signal data start followed by some number of consecutive as-
sertions of data, followed by an assertion of data end), unless it is canceled.
A cancel is an assertion of signal cancel any time between the assertion of
read req and the assertion of gnt, inclusive. We can express this using As-
sertion 5.22a. Assertion 5.22a holds on Trace 5.22(i): the first read request is
followed by a data transfer, while the second read request is not followed by
a data transfer, but is not required to be since it is canceled.

In the case of Assertion 5.22a, we needed the length-matching “and”.
To see why, consider what would have happened had we used the non-
length-matching “and” as in Assertion 5.22b. In the case of Assertion 5.22b,
the left-hand side SERE {{read req ; [*0:4] ; gnt} & {cancel[=0]}} is
matched not only by the sequence of cycles starting at cycle 2 and ending at
cycle 5, but also by the sequences of cycles starting at cycle 2 and ending at
any of the cycles 6 through 16. Thus, Assertion 5.22b requires that we see a
data transfer starting not only at cycle 6, but also at cycles 7, 8, 9, 10 and so
on. Obviously, this is not what we wanted.

As an example where we want the non-length-matching “and” rather than
the length-matching “and”, consider the case that signal global print req
indicates that we should see a print on each of printers 1, 2, and 3 (comple-
tion of which is indicated by assertions of p1 done, p2 done, and p3 done,
respectively), and that following completion of the last print job, we should
see an assertion of signal print success. We can express this as shown in
Assertion 5.23a. Assertion 5.23a holds on Trace 5.23(i) because following the
assertion of signal global print req, we see assertions of each of the signals
p1 done, p2 done and p3 done, the last of which is followed by an assertion
of print success.

The non-length-matching “and” was needed for Assertion 5.23a. To see
why, consider what would have happened if we had used the length-matching
“and”, as in Assertion 5.23b. Assertion 5.23b does not hold on Trace 5.23(i)
because the use of the length-matching “and” means that p1 done[->],
p2 done[->] and p3 done[->] must all have the same length, i.e., that
p1 done, p2 done and p3 done must all be asserted at the same time.

The SERE within operator is useful if you want to describe a situation
where one SERE occurs within the time frame of another. For instance, sup-
pose that the normal behavior of the design is to complete a high priority
request first, even if there is a pending low priority request that started be-
fore it. However, if signal no nesting is asserted when the low priority re-
quest is issued, then this is prohibited. In other words, the situation shown
in Trace 5.24(i) is not allowed. We can describe the prohibited situation as
shown in Assertion 5.24a. Assertion 5.24a does not hold on Trace 5.24(i)
because there is a match of {high pri begin ; high pri end[->]} that is
entirely enclosed within the match of {(low pri begin && no nesting) ;
low pri end[->]}.

NOTE: If the left and right operands of a within operator are s and t
respectively, then the within operator is simply a shorthand for a length-
matching “and” between {[*] ; s ; [*]} and {t}. That is, s within t is
equivalent to {[*] ; s ; [*]} && {t}.

==5.7 More about suffix implication==

Up until now, we have seen the suffix implication operators (|-> and |=>)
used with SEREs on both the left- and the right-hand sides. While the left-
hand side of a suffix implication operator must be a SERE, the right-hand
side of a suffix implication operator can be any property. Thus, if we want to
express the requirement that whenever we have a request that is acknowledged
(assertion of req followed by an assertion of ack) we should see a grant
(assertion of signal gnt within three cycles of the acknowledge), we can code
as in Assertion 5.25a.

This is illustrated in Trace 5.25(i). In the trace, there are three occurrences
of the SERE {req;ack}. The first is followed by an assertion of ack after two
cycles, the second after three cycles, and the third after a single cycle. Thus,
Assertion 5.25a holds on the trace.

Of course, we could have written Assertion 5.25a entirely in SERE style,
as shown in Assertion 5.25b, or entirely without SEREs, as in Assertion 5.25c.
Assertions 5.25a, 5.25b and 5.25c are equivalent, thus the issue is purely one
of style. Some people prefer using only one style, others find a mix of styles,
depending on the particular property, to be easier to understand.

==5.8 The built-in function ended()==

The built-in function ended() takes a SERE as an argument and returns true
in any cycle where that SERE has just ended.1 For example, Trace 5.26(i) has
been annotated with a waveform labeled ended({a ; b[*] ; c}) to show
the value of the call to ended() at each cycle.

<blockquote>1 - In previous versions of PSL, the role of the built-in function ended() was played by
endpoints. Endpoints are no longer a part of the language – use built-in function
ended() instead.</blockquote>

How is ended() used? Consider that a complete data transfer consists of
an assertion of signal data start followed by some number of assertions of
data, followed by an assertion of data end. Consider further that we have a
signal data transfer complete that should be asserted when a data trans-
fer is completed, and that we would like to specify the correct behavior of
this signal. A good start would be Assertion 5.27a. Assertion 5.27a ensures
that data transfer complete is asserted at the conclusion of every data
transfer. But what about the other direction? That is, what about ensuring
that whenever data transfer complete is asserted, a complete data trans-
fer has indeed concluded? Assertion 5.27a does not ensure this, and thus
it holds on Trace 5.27(i), even though there are “extraneous” assertions of
data transfer complete at cycles 6 and 15. We would like an assertion that
holds on Trace 5.27(ii) but not on 5.27(i).

In order to check the second direction (that there are no extraneous asser-
tions of data transfer complete) we need to switch the direction of the
implication: we need to say that if data transfer complete is asserted,
then we have just seen the conclusion of a complete data transfer. We could
try Assertion 5.27b. However, that doesn’t work. Assertion 5.27b requires
that the SERE {data start ; data[*] ; data end} start the same cycle as
data transfer complete, while we want it to end that cycle.

This is where the built-in function ended() comes in. Using ended(),
we can code what we want as shown in Assertion 5.27c, which states that
whenever we see an assertion of data transfer complete, we must have just
seen the end of SERE {data start ; data[*] ; data end}, and it does not
hold on Trace 5.27(i).

Note that ended() returns a Boolean value. Since the left-hand side of the
suffix implication in Assertion 5.27c consists of a single Boolean expression,
we could have coded Assertion 5.27c equivalently using logical implication as
shown in Assertion 5.27d.

==5.9 Overlapping matches of a SERE==

Up until now, we have been concentrating on explaining the meaning of each
SERE operator, using relatively simple examples. It is now time to introduce
some more complex examples, in order to emphasize that like LTL style prop-
erties, interpreting a SERE style property on a trace can involve examining
overlapping sets of cycles.

Consider Property 5.28a on Traces 5.28(i) and 5.28(ii). There are multiple
matches of {a ; b[*] ; c} on Trace 5.28(i), one match ending at cycle 2,
one ending at cycle 3, and one ending at cycle 4. Property 5.28a does not
hold on Trace 5.28(i), because the matches ending at cycles 2 and 3 do not
have associated assertions of signal d at cycles 3 and 4. A suffix implication
requires that for every match of the left-hand side, the right-hand side holds.
Property 5.28a does hold on Trace 5.28(ii), because signal d is asserted after
each match of {a ; b[*] ; c}.

Note that although Property 5.28a contains an always operator, the
always operator is not the source of the overlapping matches in this case.
Rather, for a single current cycle (cycle 1), there are three separate matches
of the SERE {a ; b[*] ; c}, each ending at a different cycle.

The overlapping can happen on the right-hand side of a suffix implication
as well. Consider for example Property 5.29a on Trace 5.29(i). There are three
matches of {d ; e[*] ; f}, ending at cycles 3, 4, and 5. One match would
have been enough to satisfy Property 5.29a, because as long as there exists one
match, {d ; e[*] ; f} holds. The fact that there are in fact three matches
does not hurt. Thus, Property 5.29a holds on Trace 5.29(i).

We have just explained that we require at least one match of the right-hand
side for every match of the left-hand side of a suffix implication, and it might
seem that in so doing, we have introduced something new. Actually, the rule
could have been deduced from the parallel we have previously drawn between
a suffix implication and an if-then statement. SERE {a ; b[*] ; c} can be
understood as an infinite “or” between SEREs {a;c}, {a;b;c}, {a;b;b;c},
and so on. So Property 5.28a can be understood as “if {a;c} or {a;b;c} or
{a;b;b;c} or ..., then d”, which clearly should hold only if we see a d every
time the if-part is matched. And Property 5.29a can be understood as “if c,
then {d;f} or {d;e;f} or {d;e;e;f} or ...”, which of course should hold as
long as we have seen at least a single match of the then-part.

==5.10 How not to use SEREs==

[[Файл:Psl fig5.4.png]]

[[Файл:Psl fig5.5.png]]

[[Файл:Psl fig5.6.png]]

[[Файл:Psl fig5.7.png]]

[[Файл:Psl fig5.8.png]]

[[Файл:Psl fig5.9.png]]

[[Файл:Psl fig5.10.png]]

[[Файл:Psl fig5.11.png]]

[[Файл:Psl fig5.12.png]]

[[Файл:Psl fig5.13.png]]

[[Файл:Psl fig5.14.png]]

[[Файл:Psl fig5.15.png]]

[[Файл:Psl fig5.16.png]]

PSL/A Practical Introduction to PSL/SERE Style

2014-01-27T10:27:51Z

Valentin: /* 5.1 Суффиксная импликация (|-> и |=>) */

{{PSL TOC}}

=Стиль SERE=


До этого момента, мы видели свойства PSL, построенные на булевых выражениях и временных операторах в стиле LTL. Другой путь построения свойств использует SERE - Последовательные расширения регулярных выражений. SERE по-сути тоже самое, что и регулярные выражения, как те, которые используются для сопоставления во многих приложениях. Отличие лишь в том, что атом SERE - булево выражение, в то время, как атомы стандартного регулярного выражения - отдельные символы.


SERE обычно заключается в фигурные скобки, и атом SERE обычно разделен точкой с запятой. Например, <code>{a;b;c}</code> - это SERE, и SERE 5.1a - это более сложный SERE. SERE 5.1a описывает последовательность циклов, в которых утверждается <code>(req_out && !ack)</code> на первом цикле, далее <code>(busy && !ack)</code> утверждается нуль или более циклов, показанный последовательным оператором повторения <code>[*]</code>, и в итоге утверждается ack. Таким образом, SERE 5.1a отмечает последовательность циклов, под лейблом “1” в тракте 5.1(i).


Не поддавайтесь искушению в трактовке SERE более, чем показано здесь: SERE 5.1a показывает последовательность циклов под лейблом “2” в тракте 5.1(i). SERE 5.1a не запрещает утверждения занятости в течение последнего цикла SERE. Если важно исключить такое поведение, занятость может быть явно указана, как показано в SERE 5.1b. SERE 5.1b показывает последовательность циклов под лейблом “1”, показанная на тракте 5.1(i), но не показывает последовательность циклов под лейблом “2” в этом же тракте.


Как использовать SERE? Во-первых, SERE может также быть под-свойством. Например, свойство 5.2a выполняется, если существует утверждение <code>req_in && gnt</code>, далее начиная со следующего цикла, мы видим последовательность циклов отмеченных SERE 5.1a. Свойство 5.2a выполняется на тракте 5.2(i).


Примечание: SERE - это свойство, но свойство это не всегда SERE. Таким образом, пока мы можем использовать SERE, как операнд временного оператора, мы не можем вставить временной оператор, такой как <code>always</code> или <code>next</code>, внутрь SERE.


Сейчас предположим, что у нас есть ситуация похожая на свойство 5.2a, но в которой грант (утверждение сигнала <code>gnt</code>) появляется циклом ''позже'' утверждения <code>req_in</code>. Мы можем попробовать заменить булево выражение <code>req_in && gnt</code> временным выражением <code>req_in && next gnt</code>, как в свойстве 5.3a. Однако, вспомним урок раздела 3.4: в свойстве 5.3a текущий цикл лева-ориентированной стороны <tt>(req_in && next gnt)</tt> тот же самый, что и текущий цикл право-ориентированной стороны (потому что они соединены булевым оператором <tt>-></tt>). Таким образом, текущий цикл <code>gnt</code> (который является операндом оператора <code>next</code>) - это тот же текущий цикл для SERE (который также является операндом оператора <code>next</code>). Это немного запутанно, и действительно свойство 5.3а не принадлежит простому подмножеству PSL, которые мы обсуждали в главе 9.


Давайте модифицируем свойство 5.3а, как показано в свойстве 5.3b. Сейчас один оператор <code>next</code> применяется для обоих, <code>gnt</code> и SERE, которые являются операндами оператора <code>-></code>. Свойство 5.3b эквивалентно свойству 5.3a, но оно из просто подмножества, делая более простым отслеживание временной выборки между <code>gnt</code> и SERE. Если мы подразумеваем, что текущий цикл SERE должен быть циклом ''позже'' <code>gnt</code>, мы можем манипулировать свойством 5.3b, добавляя <code>next</code>, как в свойстве 5.3c. Однако, суффиксная импликация операторов предоставляет более простой путь.

{| align=center
! [[Файл:Psl fig5.1.png]]
|-
!(i) SERE 5.1a отмечает 1 и 2. SERE 5.1b отмечает 1, но не 2.
|-
|<pre>
{(req_out && !ack) ; (busy && !ack)[*] ; ack} (5.1a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack && !busy} (5.1b)
</pre>
|-
! Рис. 5.1: Два простых SEREs
|}

{| align=center
! [[Файл:Psl fig5.2.png]]
|-
!(i) Свойство 5.2a выполняется
|-
|<pre>
always ((req_in && gnt) -> (5.2a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
</pre>
|-
! Рис. 5.2: SERE - свойство
|}

{| align=center width=80%
|<pre>
always ((req_in && next gnt) -> (5.3a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
always (req_in -> next (gnt -> (5.3b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}))
always (req_in -> next (gnt -> (5.3c)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack}))
</pre>
|-
! Рис. 5.3: Свойство 5.3a не из простого подмножества. Свойства 5.3b и 5.3c из простого подмножества,
но они сложны для чтения. Эти свойства можно выразить проще, используя суффиксную импликацию.
|}

==5.1 Суффиксная импликация (<code>|-></code> и <code>|=></code>)==


Операторы ''суффиксной импликации'' (<code>|-></code> и <code>|=></code>) предоставляют возможность ссылаться на два SERE таким образом, что право-ориентированная сторона начинает работать, когда лева-сторонняя сторона заканчивает работы. Параллельный оператор суффиксной импликации (<code>|-></code>) интерпретирует “когда лева-ориентированная сторона заканчивает работать” также, как “в том же цикле, когда лева-ориентированная сторона заканчивает работать”, в то время как не параллельный оператор суффиксной импликации (<code>|=></code>) интерпретирует это, как “цикл после цикла, в котором лева-ориентированная сторона завершила работу”. Таким образом, свойство 5.4а эквивалентно свойству 5.3b, и свойство 5.4b эквивалентно свойству 5.3c. Оба свойства 5.4a и 5.4b легче для понимания, чем эквивалентное свойство без суффиксной импликации , и оба принадлежат простому подмножеству из главы 9.

{| align=center
! [[Файл:Psl fig5.4.png]]
|-
|<pre>
always {req_in;gnt} |-> (5.4a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.4b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}

</pre>
|-
! Рис. 5.4: Суффиксная импликация
|}


Напомним, что логический оператор импликации (<code>-></code>) может интерпретироваться, как if-then выражение, с безоговорочно утвержденной else-частью. Суффиксный оператор импликации (<code>|-></code> and <code>|=></code>) может восприниматься также. Разница между логическим оператором импликации (<code>-></code>) и суффиксным оператором импликации (<code>|-></code> and <code>|=></code>) во временных взаимоотношениях между if- и then-частями. В то время, как текущий цикл then-части для оператора логической импликации
(->) тот же, что и для if-части, текущий цикл then-части суффиксного оператора импликации (<code>|-></code> or <code>|=></code>) это первый цикл ''суффикса'' тракта, который остается после того, как сменяется if-часть. Это показано для свойств 5.4a и 5.4b в трактах 5.4(i) и 5.4(ii).

{| align=center
! [[Файл:Psl fig5.5.png]]
|-
! (i) Тракт имеет множественные if-then пары. Свойство 5.5a выполняется.
|-
|<pre>
always {req_in;gnt} |=> (5.5a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.5: if-часть другой if-then пары может начаться перед тем, как if-часть или
then-часть предыдущей if-then пары выполниться
|}


В трактах 5.4(i) и 5.4(ii) присутствует единичное утверждение сигнала <code>req_in</code>. Если бы здесь было множественные утверждения <code>req_in</code>, то, конечно же, мы должны были бы идентифицировать множественные if-then пары, как показано в тракте 5.5(i). Отметим, что if-часть другой if-then пары может начинаться, перед завершение выполнения if-части или then-части предыдущей if-then пары. Например, вторая if-then пара начинается в седьмом цикле, перед тем, как выполнится then-часть первой пары. Третья if-then прара начинается в цикле 8, перед тем как выполнятся then-часть первой пары и if-часть второй пары. Мы могли видеть такой вид перекрытия ранее, в трактах 2.2(ii) и 2.3(iii).

Properties 5.6a and 5.6b hold on Trace 5.6(i) because there is no sequence
of cycles matching the left-hand side, thus the else-parts default to true at
every cycle.

{| align=center
! [[Файл:Psl fig5.6.png]]
|-
! (i) Properties 5.6a and 5.6b both hold
|-
|<pre>
always {req_in;gnt} |-> (5.6a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.6b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Fig. 5.6: The else-part of a suffix implication defaults to true
|}

==5.2 Weak and strong SEREs==

Like temporal operators, SEREs come in weak and strong versions, and like
temporal operators, the strong version of a SERE is indicated by an exclama-
tion point (<code>!</code>). Thus, Property 5.7a, whose right-hand side is a weak SERE,
holds even if signal <code>ack</code> is never asserted (as long as the rest of the SERE is
not violated). Property 5.7b, whose right-hand side is a strong SERE, holds
only if we eventually reach a cycle where <code>ack</code> occurs. In other words, the weak
version of a SERE allows us to accept a trace that is “too short”, whereas
the strong version requires that we “reach the end” of the SERE. Thus, while
Property 5.7a holds on Trace 5.7(i) as well as Trace 5.7(ii), Property 5.7b, the
strong version, holds on Trace 5.7(ii) but not on Trace 5.7(i).

{| align=center
! [[Файл:Psl fig5.7.png]]
|-
|<pre>
always {req_in;gnt} |=> (5.7a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.7b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}!
</pre>
|-
! Fig. 5.7: A weak SERE holds even if the trace is “too short”, while a strong SERE
must “reach the end”
|}

==5.3 The <code>never</code> operator applied to a SERE==

Another way to use a SERE is in describing sequences of events that should
never happen. For example, Assertion 5.8a states that signal <code>req</code> should never
be asserted for two consecutive cycles, and thus does not hold on Trace 5.8(i).

As another example, consider Assertion 5.9a. It states that an acknowl-
edged high priority request (assertion of <code>req</code> together with <code>high_pri</code>, followed
a cycle later by <code>ack</code>) cannot be canceled (assertion of <code>cancel</code> the cycle after
<code>ack</code>). Thus it holds on Trace 5.9(i), but not on Trace 5.9(ii).

{| align=center
! [[Файл:Psl fig5.8.png]]
|-
| (i) Assertion 5.8a does not hold
|-
|<pre>
assert never {req;req}; (5.8a)
</pre>
|-
! Fig. 5.8: The never operator
|}

{| align=center
! [[Файл:Psl fig5.9.png]]
|-
| (i) Assertion 5.8a does not hold
|-
|<pre>
assert never {req && high_pri ; ack ; cancel}; (5.9a)
</pre>
|-
! Fig. 5.9: More about the never operator
|}

==5.4 SERE repetition operators (<code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>)==

Up until now, we have seen basic SEREs composed of (possibly repeated)
Boolean expressions separated by semi-colons. In this section, we examine
SERE operators that allow you to build more sophisticated SEREs, using
variations on the SERE repetition operators <code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>.

Consecutive repetition operators provide a shortcut to typing the same
sub-SERE a number of times. The <code>[*n]</code> operator is an abbreviation for
n repetitions of the SERE it is applied to. For example, instead of typing
<code>busy;busy;busy</code> in Assertion 5.10a, we can use the abbreviation <code>busy[*3]</code>,
as in Assertion 5.10b. Assertions 5.10a and 5.10b state that after a request
(assertion of signal <code>req</code>), we expect to see an acknowledge (assertion of signal
<code>ack</code>) followed by three cycles in which signal <code>busy</code> is asserted, followed by
an assertion of signal <code>done</code>. Trace 5.10(i) is an example of a trace on which
Assertions 5.10a and 5.10b hold.

{| align=center
! [[Файл:Psl fig5.10.png]]
|-
|<pre>
assert always {req} |=> {ack;busy;busy;busy;done}; (5.10a)
assert always {req} |=> {ack ; busy[*3] ; done}; (5.10b)
assert always {req} |=> {ack ; busy[*3:5] ; done}; (5.10c)
</pre>
|-
! Fig. 5.10: The <code>[*n]</code> and <code>[*i:j]</code> operators
|}

Instead of a specific number of repetitions, we can specify a range, i
through <code>j</code>, like this: <code>[*i:j]</code>. Thus, Assertion 5.10c is similar to Asser-
tion 5.10b, but instead of requiring exactly three assertions of signal <code>busy</code>,
we require between three and five. Assertion 5.10c holds on Trace 5.10(i) as
well as on Trace 5.10(ii).

The upper bound of a range can be infinity, which is indicated by a <code>$</code> in
the SystemVerilog flavor, by ''null'' in the GDL flavor, and by inf in the Verilog,
VHDL, and SystemC flavors. For instance, the SERE <code>{b[*5:inf]}</code> matches
five or more repetitions of <code>b</code>.

We can repeat not only a Boolean expression, but a SERE as well. For
example, Property 5.11a holds if after an acknowledged request (an assertion
of signal <code>req</code> followed by an assertion of signal <code>ack</code>), we see three data transfers
followed by an assertion of signal <code>d_end</code>, where a data transfer is an assertion
of signal <code>start</code> followed by an assertion of signal <code>busy</code> followed by an assertion
of signal <code>done</code>. Trace 5.11(i) is an example of a trace on which Property 5.11a
holds.

If we omit the <code>n</code>, the resulting SERE matches any number of repetitions of
the Boolean expression or SERE that is being repeated. For example, asserting
Property 5.11b indicates that after an acknowledged request, we expect to see
any number of data transfers followed by an assertion of <code>done</code>. Property 5.11b
holds on Trace 5.11(i), as well as on Traces 5.11(ii) and 5.11(iii).

A <code>[*]</code> repetition matches any number of repetitions, including none. Thus,
Property 5.11b holds on Trace 5.11(iv) as well. If you want to specify any
non-zero number of repetitions, use the <code>[+]</code>. Thus, Property 5.11c is similar
to Property 5.11b, but it requires at least one data transfer before signal done
is asserted. Thus, Property 5.11c does not hold on Trace 5.11(iv), but it does
hold on Traces 5.11(i), 5.11(ii) and 5.11(iii).

Instead of omitting the n, we can omit the Boolean expression or SERE
and let the repetition <code>[*n]</code> stand alone. A stand-alone <code>[*n]</code> is equivalent
to <code>‘true[*n]</code>. In other words, <code>[*n]</code> matches any n cycles (because <code>‘true</code>
holds in all cycles). Another way to think of it is that it allows us to “skip”
<code>n</code> cycles. Thus, Property 5.12a is similar to Property 5.11b, but instead of
the acknowledge (assertion of signal <code>ack</code>) coming immediately following the
request (assertion of signal <code>req</code>), it comes four cycles later. Property 5.12a
holds on Trace 5.12(i).

The nonconsecutive repetition operator (<code>[=n]</code>) provides a way to describe
repetitions that happen on not necessarily consecutive cycles. It can be ap-
plied only to a Boolean expression. For example, to describe the requirement
that after a request (assertion of signal <code>req</code>), we expect to see an acknowledge
(assertion of signal <code>ack</code>) followed by some number of cycles including three
not necessarily consecutive assertions of signal <code>busy</code>, followed by an asser-
tion of signal <code>done</code>, we can code Assertion 5.13a. Assertion 5.13a holds on
Trace 5.13(i). Note the cycles marked “<code>busy[=3]</code>” in Trace 5.13(i). They do
not start with an assertion of <code>busy</code>, nor do they end with one. The noncon-
secutive repetition operator <code>[=n]</code> will match any sequence of cycles in which
there are <code>n</code> not necessarily consecutive repetitions of the Boolean expression
being repeated, including sequences of cycles in which the “padding” is at
the beginning and/or at the end. In other words, it will match any sequence
of cycles in which the number of assertions of the Boolean expression being
repeated is ''equal to'' <code>n</code> (thus the use of the equals sign in <code>[=n]</code>).

If you want to disallow the padding at the end, use the goto repetition op-
erator [->n]. The goto repetition operator [->n] is similar to the nonconsec-
utive repetition operator, except that the sequence of cycles being described
ends with an assertion of the Boolean expression being repeated. In other
words, it will match any sequence of cycles starting at the current cycle and
ending after you “go to” the nth occurrence of the Boolean expression (the
use of the -> is intended to remind you of an arrow instructing you to go to
n). Thus Assertion 5.13b does not hold on Trace 5.13(i), but it does hold on
Trace 5.13(ii) because the third busy is immediately followed by an assertion
of signal done.

The n can be omitted for the goto repetition operator, in which case n
defaults to 1. In other words, b[->] is equivalent to b[->1].

Like the consecutive repetition operators, the nonconsecutive repetition
operator and the goto repetition operator can take a range. Thus, Asser-
tion 5.14a requires three to five not necessarily consecutive assertions of busy
after the assertion of signal ack and before the assertion of done, while Asser-
tion 5.14b requires the same, and in addition that the assertion of signal done
occur immediately after the 3rd, 4th, or 5th assertion of signal busy. Thus As-
sertion 5.14a holds on Traces 5.14(i) and 5.14(ii), while Assertion 5.14b holds
on Trace 5.14(ii) but not on Trace 5.14(i).

==5.5 Concatenation (;) and fusion (:)==

We have already seen the concatenation operator, a semi-colon, which is used
to join two SEREs (or two Boolean expressions, or a Boolean expression and
a SERE) in such a way that the right-hand SERE starts the cycle after the
left-hand SERE ends. The fusion operator, a colon, is used to join two SEREs
(or two Boolean expressions, or a Boolean expression and a SERE) in such a
way that there is a single cycle of overlap between them: the right-hand SERE
starts the same cycle that the left-hand SERE ends.

For example, consider the case that we want to specify the behavior of As-
sertion 5.14b, and in addition, following the assertion of signal done, we should
see a data transfer, which consists of the assertion of signal data for some num-
ber of cycles (might be zero), followed by an assertion of signal d end. Using
the concatenation operator, we can write Assertion 5.15a. Trace 5.15(i) is a
trace on which Assertion 5.15a holds. The first assertion of signal req gets
three cycles of data before the assertion of d end, while the second assertion
of signal req sees four cycles of data before seeing d end.

If the data transfer should start the same cycle as signal done is asserted,
then we can use the fusion operator as in Assertion 5.16a. Trace 5.16(i) is an
example of a trace on which Assertion 5.16a holds. It is similar to Trace 5.15(i),
except that the data transfer starts the same cycle as that in which done is
asserted, rather than the cycle following the assertion of signal done.

Note that while it may be tempting to understand the concatenation op-
erator (;) as a delay, the operator does not necessarily “eat” a cycle. For in-
stance, in the case of the SERE {a ; b[*] ; c}, the b[*] may match zero,
one, or more cycles, as illustrated in Trace 5.17(i). The first match shown in
Trace 5.17(i) is only two cycles long, thus, the second concatenation operator
(;) did not “eat” a delay. A better way to think of it is that concatenation
gives you an ordered list of things to happen – some of them may consume
one cycle, some more, and some no cycles at all.

Further note that fusion requires an overlap of at least one cycle. Thus,
while the {b[*]} in {b[*] ; c} may match an empty sequence of cycles,
replacing the concatenation operator with the fusion operator like this: {b[*]: c}
results in a SERE with at least one assertion of b (otherwise there is
nothing to overlap with the assertion of c). In both cases, the match may
consist of a single cycle. The difference is that in the case of {b[*] ; c} the
single cycle may not include an assertion of b (because there may be zero
assertions of b preceding c), while in the case of {b[*] : c}, the single cycle
must include an assertion of b (which overlaps with the assertion of c).

==5.6 Compound SEREs==

Compound SEREs are SEREs built from other SEREs through operations
other than concatenation and fusion. The available operators allow you to
“and” or “or” together two or more SEREs, as well as to express the situation
where a match of one SERE occurs within a sequence of cycles matched by
another.

Consider the case that we want to say that signal read complete is as-
serted on the last data cycle of every read operation, where we have two kinds
of read operations: a short read consists of an assertion of signal short rd fol-
lowed by eight not necessarily consecutive assertions of data, and a long read
consists of an assertion of signal long rd followed by 32 such assertions. We
could code two separate properties, as shown in Properties 5.18a and 5.18b.
Alternatively, we could use the SERE “or” operator (|) to “or” the two SEREs
together, as in Property 5.18c.

The SERE “and” operator comes in two types: length-matching and non-
length-matching. Both the length-matching (&&) and the non-length-matching
(&) “and” operators match a sequence of cycles if starting at the current cycle,
the left-hand side and the right-hand side are matched. The difference is that
in addition, the length-matching “and” operator requires that the lengths of
the sequences matched by both the left- and right-hand sides are the same,
while the non-length-matching operator matches even if they are different. A
length-matching “and” between SEREs R and S is illustrated in Trace 5.19(i),
and a non-length-matching “and” between SEREs R and S is illustrated in
Traces 5.20(i), 5.20(ii) and 5.20(iii).

When a non-length-matching “and” is used on the left-hand side of a con-
catenation or a fusion, the current cycle of the right-hand side of the concate-
nation or fusion is determined by the longer of the two subsequences making
up the non-length-matching “and”. For instance, in the SERE {{{a;b[*5];c}
& {d[*];e}} ; f}, the current cycle of f is the cycle after the cycle in which
the longer of the two SEREs {a;b[*5];c} and {d[*];e} completes. This is
illustrated in Traces 5.21(i) and 5.21(ii). Note that in each of the traces, sig-
nal f is asserted twice: once after the completion of {a;b[*5];c}, and once
after the completion of {d[*];e}. However, in each trace, only the assertion
of signal f that happens after the completion of the longer of the two SEREs
participates in the “match” of SERE {{{a;b[*5];c} & {d[*];e}} ; f}.

NOTE: A length-matching “and” such as {a;b;c} && {d} is legal, but
makes no sense (because there is no sequence which is both 3 cycles long to
match {a;b;c} and 1 cycle long to match {d}). Many tools will probably issue
a warning for such a SERE.

As an example of the use of the length-matching “and”, consider the case
that a read request (assertion of signal read req) that is granted (assertion of
signal gnt within 5 cycles of the request) should be followed by a data transfer
(assertion of signal data start followed by some number of consecutive as-
sertions of data, followed by an assertion of data end), unless it is canceled.
A cancel is an assertion of signal cancel any time between the assertion of
read req and the assertion of gnt, inclusive. We can express this using As-
sertion 5.22a. Assertion 5.22a holds on Trace 5.22(i): the first read request is
followed by a data transfer, while the second read request is not followed by
a data transfer, but is not required to be since it is canceled.

In the case of Assertion 5.22a, we needed the length-matching “and”.
To see why, consider what would have happened had we used the non-
length-matching “and” as in Assertion 5.22b. In the case of Assertion 5.22b,
the left-hand side SERE {{read req ; [*0:4] ; gnt} & {cancel[=0]}} is
matched not only by the sequence of cycles starting at cycle 2 and ending at
cycle 5, but also by the sequences of cycles starting at cycle 2 and ending at
any of the cycles 6 through 16. Thus, Assertion 5.22b requires that we see a
data transfer starting not only at cycle 6, but also at cycles 7, 8, 9, 10 and so
on. Obviously, this is not what we wanted.

As an example where we want the non-length-matching “and” rather than
the length-matching “and”, consider the case that signal global print req
indicates that we should see a print on each of printers 1, 2, and 3 (comple-
tion of which is indicated by assertions of p1 done, p2 done, and p3 done,
respectively), and that following completion of the last print job, we should
see an assertion of signal print success. We can express this as shown in
Assertion 5.23a. Assertion 5.23a holds on Trace 5.23(i) because following the
assertion of signal global print req, we see assertions of each of the signals
p1 done, p2 done and p3 done, the last of which is followed by an assertion
of print success.

The non-length-matching “and” was needed for Assertion 5.23a. To see
why, consider what would have happened if we had used the length-matching
“and”, as in Assertion 5.23b. Assertion 5.23b does not hold on Trace 5.23(i)
because the use of the length-matching “and” means that p1 done[->],
p2 done[->] and p3 done[->] must all have the same length, i.e., that
p1 done, p2 done and p3 done must all be asserted at the same time.

The SERE within operator is useful if you want to describe a situation
where one SERE occurs within the time frame of another. For instance, sup-
pose that the normal behavior of the design is to complete a high priority
request first, even if there is a pending low priority request that started be-
fore it. However, if signal no nesting is asserted when the low priority re-
quest is issued, then this is prohibited. In other words, the situation shown
in Trace 5.24(i) is not allowed. We can describe the prohibited situation as
shown in Assertion 5.24a. Assertion 5.24a does not hold on Trace 5.24(i)
because there is a match of {high pri begin ; high pri end[->]} that is
entirely enclosed within the match of {(low pri begin && no nesting) ;
low pri end[->]}.

NOTE: If the left and right operands of a within operator are s and t
respectively, then the within operator is simply a shorthand for a length-
matching “and” between {[*] ; s ; [*]} and {t}. That is, s within t is
equivalent to {[*] ; s ; [*]} && {t}.

==5.7 More about suffix implication==

Up until now, we have seen the suffix implication operators (|-> and |=>)
used with SEREs on both the left- and the right-hand sides. While the left-
hand side of a suffix implication operator must be a SERE, the right-hand
side of a suffix implication operator can be any property. Thus, if we want to
express the requirement that whenever we have a request that is acknowledged
(assertion of req followed by an assertion of ack) we should see a grant
(assertion of signal gnt within three cycles of the acknowledge), we can code
as in Assertion 5.25a.

This is illustrated in Trace 5.25(i). In the trace, there are three occurrences
of the SERE {req;ack}. The first is followed by an assertion of ack after two
cycles, the second after three cycles, and the third after a single cycle. Thus,
Assertion 5.25a holds on the trace.

Of course, we could have written Assertion 5.25a entirely in SERE style,
as shown in Assertion 5.25b, or entirely without SEREs, as in Assertion 5.25c.
Assertions 5.25a, 5.25b and 5.25c are equivalent, thus the issue is purely one
of style. Some people prefer using only one style, others find a mix of styles,
depending on the particular property, to be easier to understand.

==5.8 The built-in function ended()==

The built-in function ended() takes a SERE as an argument and returns true
in any cycle where that SERE has just ended.1 For example, Trace 5.26(i) has
been annotated with a waveform labeled ended({a ; b[*] ; c}) to show
the value of the call to ended() at each cycle.

<blockquote>1 - In previous versions of PSL, the role of the built-in function ended() was played by
endpoints. Endpoints are no longer a part of the language – use built-in function
ended() instead.</blockquote>

How is ended() used? Consider that a complete data transfer consists of
an assertion of signal data start followed by some number of assertions of
data, followed by an assertion of data end. Consider further that we have a
signal data transfer complete that should be asserted when a data trans-
fer is completed, and that we would like to specify the correct behavior of
this signal. A good start would be Assertion 5.27a. Assertion 5.27a ensures
that data transfer complete is asserted at the conclusion of every data
transfer. But what about the other direction? That is, what about ensuring
that whenever data transfer complete is asserted, a complete data trans-
fer has indeed concluded? Assertion 5.27a does not ensure this, and thus
it holds on Trace 5.27(i), even though there are “extraneous” assertions of
data transfer complete at cycles 6 and 15. We would like an assertion that
holds on Trace 5.27(ii) but not on 5.27(i).

In order to check the second direction (that there are no extraneous asser-
tions of data transfer complete) we need to switch the direction of the
implication: we need to say that if data transfer complete is asserted,
then we have just seen the conclusion of a complete data transfer. We could
try Assertion 5.27b. However, that doesn’t work. Assertion 5.27b requires
that the SERE {data start ; data[*] ; data end} start the same cycle as
data transfer complete, while we want it to end that cycle.

This is where the built-in function ended() comes in. Using ended(),
we can code what we want as shown in Assertion 5.27c, which states that
whenever we see an assertion of data transfer complete, we must have just
seen the end of SERE {data start ; data[*] ; data end}, and it does not
hold on Trace 5.27(i).

Note that ended() returns a Boolean value. Since the left-hand side of the
suffix implication in Assertion 5.27c consists of a single Boolean expression,
we could have coded Assertion 5.27c equivalently using logical implication as
shown in Assertion 5.27d.

==5.9 Overlapping matches of a SERE==

Up until now, we have been concentrating on explaining the meaning of each
SERE operator, using relatively simple examples. It is now time to introduce
some more complex examples, in order to emphasize that like LTL style prop-
erties, interpreting a SERE style property on a trace can involve examining
overlapping sets of cycles.

Consider Property 5.28a on Traces 5.28(i) and 5.28(ii). There are multiple
matches of {a ; b[*] ; c} on Trace 5.28(i), one match ending at cycle 2,
one ending at cycle 3, and one ending at cycle 4. Property 5.28a does not
hold on Trace 5.28(i), because the matches ending at cycles 2 and 3 do not
have associated assertions of signal d at cycles 3 and 4. A suffix implication
requires that for every match of the left-hand side, the right-hand side holds.
Property 5.28a does hold on Trace 5.28(ii), because signal d is asserted after
each match of {a ; b[*] ; c}.

Note that although Property 5.28a contains an always operator, the
always operator is not the source of the overlapping matches in this case.
Rather, for a single current cycle (cycle 1), there are three separate matches
of the SERE {a ; b[*] ; c}, each ending at a different cycle.

The overlapping can happen on the right-hand side of a suffix implication
as well. Consider for example Property 5.29a on Trace 5.29(i). There are three
matches of {d ; e[*] ; f}, ending at cycles 3, 4, and 5. One match would
have been enough to satisfy Property 5.29a, because as long as there exists one
match, {d ; e[*] ; f} holds. The fact that there are in fact three matches
does not hurt. Thus, Property 5.29a holds on Trace 5.29(i).

We have just explained that we require at least one match of the right-hand
side for every match of the left-hand side of a suffix implication, and it might
seem that in so doing, we have introduced something new. Actually, the rule
could have been deduced from the parallel we have previously drawn between
a suffix implication and an if-then statement. SERE {a ; b[*] ; c} can be
understood as an infinite “or” between SEREs {a;c}, {a;b;c}, {a;b;b;c},
and so on. So Property 5.28a can be understood as “if {a;c} or {a;b;c} or
{a;b;b;c} or ..., then d”, which clearly should hold only if we see a d every
time the if-part is matched. And Property 5.29a can be understood as “if c,
then {d;f} or {d;e;f} or {d;e;e;f} or ...”, which of course should hold as
long as we have seen at least a single match of the then-part.

==5.10 How not to use SEREs==

[[Файл:Psl fig5.4.png]]

[[Файл:Psl fig5.5.png]]

[[Файл:Psl fig5.6.png]]

[[Файл:Psl fig5.7.png]]

[[Файл:Psl fig5.8.png]]

[[Файл:Psl fig5.9.png]]

[[Файл:Psl fig5.10.png]]

[[Файл:Psl fig5.11.png]]

[[Файл:Psl fig5.12.png]]

[[Файл:Psl fig5.13.png]]

[[Файл:Psl fig5.14.png]]

[[Файл:Psl fig5.15.png]]

[[Файл:Psl fig5.16.png]]

PSL/A Practical Introduction to PSL/SERE Style

2014-01-24T12:42:00Z

Valentin: /* 5.1 Суффиксная импликация (|-> и |=>) */

{{PSL TOC}}

=Стиль SERE=


До этого момента, мы видели свойства PSL, построенные на булевых выражениях и временных операторах в стиле LTL. Другой путь построения свойств использует SERE - Последовательные расширения регулярных выражений. SERE по-сути тоже самое, что и регулярные выражения, как те, которые используются для сопоставления во многих приложениях. Отличие лишь в том, что атом SERE - булево выражение, в то время, как атомы стандартного регулярного выражения - отдельные символы.


SERE обычно заключается в фигурные скобки, и атом SERE обычно разделен точкой с запятой. Например, <code>{a;b;c}</code> - это SERE, и SERE 5.1a - это более сложный SERE. SERE 5.1a описывает последовательность циклов, в которых утверждается <code>(req_out && !ack)</code> на первом цикле, далее <code>(busy && !ack)</code> утверждается нуль или более циклов, показанный последовательным оператором повторения <code>[*]</code>, и в итоге утверждается ack. Таким образом, SERE 5.1a отмечает последовательность циклов, под лейблом “1” в тракте 5.1(i).


Не поддавайтесь искушению в трактовке SERE более, чем показано здесь: SERE 5.1a показывает последовательность циклов под лейблом “2” в тракте 5.1(i). SERE 5.1a не запрещает утверждения занятости в течение последнего цикла SERE. Если важно исключить такое поведение, занятость может быть явно указана, как показано в SERE 5.1b. SERE 5.1b показывает последовательность циклов под лейблом “1”, показанная на тракте 5.1(i), но не показывает последовательность циклов под лейблом “2” в этом же тракте.


Как использовать SERE? Во-первых, SERE может также быть под-свойством. Например, свойство 5.2a выполняется, если существует утверждение <code>req_in && gnt</code>, далее начиная со следующего цикла, мы видим последовательность циклов отмеченных SERE 5.1a. Свойство 5.2a выполняется на тракте 5.2(i).


Примечание: SERE - это свойство, но свойство это не всегда SERE. Таким образом, пока мы можем использовать SERE, как операнд временного оператора, мы не можем вставить временной оператор, такой как <code>always</code> или <code>next</code>, внутрь SERE.


Сейчас предположим, что у нас есть ситуация похожая на свойство 5.2a, но в которой грант (утверждение сигнала <code>gnt</code>) появляется циклом ''позже'' утверждения <code>req_in</code>. Мы можем попробовать заменить булево выражение <code>req_in && gnt</code> временным выражением <code>req_in && next gnt</code>, как в свойстве 5.3a. Однако, вспомним урок раздела 3.4: в свойстве 5.3a текущий цикл лева-ориентированной стороны <tt>(req_in && next gnt)</tt> тот же самый, что и текущий цикл право-ориентированной стороны (потому что они соединены булевым оператором <tt>-></tt>). Таким образом, текущий цикл <code>gnt</code> (который является операндом оператора <code>next</code>) - это тот же текущий цикл для SERE (который также является операндом оператора <code>next</code>). Это немного запутанно, и действительно свойство 5.3а не принадлежит простому подмножеству PSL, которые мы обсуждали в главе 9.


Давайте модифицируем свойство 5.3а, как показано в свойстве 5.3b. Сейчас один оператор <code>next</code> применяется для обоих, <code>gnt</code> и SERE, которые являются операндами оператора <code>-></code>. Свойство 5.3b эквивалентно свойству 5.3a, но оно из просто подмножества, делая более простым отслеживание временной выборки между <code>gnt</code> и SERE. Если мы подразумеваем, что текущий цикл SERE должен быть циклом ''позже'' <code>gnt</code>, мы можем манипулировать свойством 5.3b, добавляя <code>next</code>, как в свойстве 5.3c. Однако, суффиксная импликация операторов предоставляет более простой путь.

{| align=center
! [[Файл:Psl fig5.1.png]]
|-
!(i) SERE 5.1a отмечает 1 и 2. SERE 5.1b отмечает 1, но не 2.
|-
|<pre>
{(req_out && !ack) ; (busy && !ack)[*] ; ack} (5.1a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack && !busy} (5.1b)
</pre>
|-
! Рис. 5.1: Два простых SEREs
|}

{| align=center
! [[Файл:Psl fig5.2.png]]
|-
!(i) Свойство 5.2a выполняется
|-
|<pre>
always ((req_in && gnt) -> (5.2a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
</pre>
|-
! Рис. 5.2: SERE - свойство
|}

{| align=center width=80%
|<pre>
always ((req_in && next gnt) -> (5.3a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
always (req_in -> next (gnt -> (5.3b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}))
always (req_in -> next (gnt -> (5.3c)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack}))
</pre>
|-
! Рис. 5.3: Свойство 5.3a не из простого подмножества. Свойства 5.3b и 5.3c из простого подмножества,
но они сложны для чтения. Эти свойства можно выразить проще, используя суффиксную импликацию.
|}

==5.1 Суффиксная импликация (<code>|-></code> и <code>|=></code>)==


Операторы ''суффиксной импликации'' (<code>|-></code> и <code>|=></code>) предоставляют возможность ссылаться на два SERE таким образом, что право-ориентированная сторона начинает работать, когда лева-сторонняя сторона заканчивает работы. Параллельный оператор суффиксной импликации (<code>|-></code>) интерпретирует “когда лева-ориентированная сторона заканчивает работать” также, как “в том же цикле, когда лева-ориентированная сторона заканчивает работать”, в то время как не параллельный оператор суффиксной импликации (<code>|=></code>) интерпретирует это, как “цикл после цикла, в котором лева-ориентированная сторона завершила работу”. Таким образом, свойство 5.4а эквивалентно свойству 5.3b, и свойство 5.4b эквивалентно свойству 5.3c. Оба свойства 5.4a и 5.4b легче для понимания, чем эквивалентное свойство без суффиксной импликации , и оба принадлежат простому подмножеству из главы 9.

{| align=center
! [[Файл:Psl fig5.4.png]]
|-
|<pre>
always {req_in;gnt} |-> (5.4a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.4b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}

</pre>
|-
! Рис. 5.4: Суффиксная импликация
|}


Напомним, что логический оператор импликации (<code>-></code>) может интерпретироваться, как if-then выражение, с безоговорочно утвержденной else-частью. Суффиксный оператор импликации (<code>|-></code> and <code>|=></code>) может восприниматься также. Разница между логическим оператором импликации (<code>-></code>) и суффиксным оператором импликации (<code>|-></code> and <code>|=></code>) во временных взаимоотношениях между if- и then-частями. В то время, как текущий цикл then-части для оператора логической импликации
(->) тот же, что и для if-части, текущий цикл then-части суффиксного оператора импликации (<code>|-></code> or <code>|=></code>) это первый цикл ''суффикса'' тракта, который остается после того, как сменяется if-часть. Это показано для свойств 5.4a и 5.4b в трактах 5.4(i) и 5.4(ii).

{| align=center
! [[Файл:Psl fig5.5.png]]
|-
! (i) Тракт имеет множественные if-then пары. Свойство 5.5a выполняется.
|-
|<pre>
always {req_in;gnt} |=> (5.5a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Рис. 5.5: if-часть другой if-then пары может начаться перед тем, как if-часть или
then-часть предыдущей if-then пары выполниться
|}


в трактах 5.4(i) и 5.4(ii) присутствует единичное утверждение сигнала <code>req_in</code>. Если бы здесь было множественные утверждения <code>req_in</code>,

Properties 5.6a and 5.6b hold on Trace 5.6(i) because there is no sequence
of cycles matching the left-hand side, thus the else-parts default to true at
every cycle.

{| align=center
! [[Файл:Psl fig5.6.png]]
|-
! (i) Properties 5.6a and 5.6b both hold
|-
|<pre>
always {req_in;gnt} |-> (5.6a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.6b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Fig. 5.6: The else-part of a suffix implication defaults to true
|}

==5.2 Weak and strong SEREs==

Like temporal operators, SEREs come in weak and strong versions, and like
temporal operators, the strong version of a SERE is indicated by an exclama-
tion point (<code>!</code>). Thus, Property 5.7a, whose right-hand side is a weak SERE,
holds even if signal <code>ack</code> is never asserted (as long as the rest of the SERE is
not violated). Property 5.7b, whose right-hand side is a strong SERE, holds
only if we eventually reach a cycle where <code>ack</code> occurs. In other words, the weak
version of a SERE allows us to accept a trace that is “too short”, whereas
the strong version requires that we “reach the end” of the SERE. Thus, while
Property 5.7a holds on Trace 5.7(i) as well as Trace 5.7(ii), Property 5.7b, the
strong version, holds on Trace 5.7(ii) but not on Trace 5.7(i).

{| align=center
! [[Файл:Psl fig5.7.png]]
|-
|<pre>
always {req_in;gnt} |=> (5.7a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.7b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}!
</pre>
|-
! Fig. 5.7: A weak SERE holds even if the trace is “too short”, while a strong SERE
must “reach the end”
|}

==5.3 The <code>never</code> operator applied to a SERE==

Another way to use a SERE is in describing sequences of events that should
never happen. For example, Assertion 5.8a states that signal <code>req</code> should never
be asserted for two consecutive cycles, and thus does not hold on Trace 5.8(i).

As another example, consider Assertion 5.9a. It states that an acknowl-
edged high priority request (assertion of <code>req</code> together with <code>high_pri</code>, followed
a cycle later by <code>ack</code>) cannot be canceled (assertion of <code>cancel</code> the cycle after
<code>ack</code>). Thus it holds on Trace 5.9(i), but not on Trace 5.9(ii).

{| align=center
! [[Файл:Psl fig5.8.png]]
|-
| (i) Assertion 5.8a does not hold
|-
|<pre>
assert never {req;req}; (5.8a)
</pre>
|-
! Fig. 5.8: The never operator
|}

{| align=center
! [[Файл:Psl fig5.9.png]]
|-
| (i) Assertion 5.8a does not hold
|-
|<pre>
assert never {req && high_pri ; ack ; cancel}; (5.9a)
</pre>
|-
! Fig. 5.9: More about the never operator
|}

==5.4 SERE repetition operators (<code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>)==

Up until now, we have seen basic SEREs composed of (possibly repeated)
Boolean expressions separated by semi-colons. In this section, we examine
SERE operators that allow you to build more sophisticated SEREs, using
variations on the SERE repetition operators <code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>.

Consecutive repetition operators provide a shortcut to typing the same
sub-SERE a number of times. The <code>[*n]</code> operator is an abbreviation for
n repetitions of the SERE it is applied to. For example, instead of typing
<code>busy;busy;busy</code> in Assertion 5.10a, we can use the abbreviation <code>busy[*3]</code>,
as in Assertion 5.10b. Assertions 5.10a and 5.10b state that after a request
(assertion of signal <code>req</code>), we expect to see an acknowledge (assertion of signal
<code>ack</code>) followed by three cycles in which signal <code>busy</code> is asserted, followed by
an assertion of signal <code>done</code>. Trace 5.10(i) is an example of a trace on which
Assertions 5.10a and 5.10b hold.

{| align=center
! [[Файл:Psl fig5.10.png]]
|-
|<pre>
assert always {req} |=> {ack;busy;busy;busy;done}; (5.10a)
assert always {req} |=> {ack ; busy[*3] ; done}; (5.10b)
assert always {req} |=> {ack ; busy[*3:5] ; done}; (5.10c)
</pre>
|-
! Fig. 5.10: The <code>[*n]</code> and <code>[*i:j]</code> operators
|}

Instead of a specific number of repetitions, we can specify a range, i
through <code>j</code>, like this: <code>[*i:j]</code>. Thus, Assertion 5.10c is similar to Asser-
tion 5.10b, but instead of requiring exactly three assertions of signal <code>busy</code>,
we require between three and five. Assertion 5.10c holds on Trace 5.10(i) as
well as on Trace 5.10(ii).

The upper bound of a range can be infinity, which is indicated by a <code>$</code> in
the SystemVerilog flavor, by ''null'' in the GDL flavor, and by inf in the Verilog,
VHDL, and SystemC flavors. For instance, the SERE <code>{b[*5:inf]}</code> matches
five or more repetitions of <code>b</code>.

We can repeat not only a Boolean expression, but a SERE as well. For
example, Property 5.11a holds if after an acknowledged request (an assertion
of signal <code>req</code> followed by an assertion of signal <code>ack</code>), we see three data transfers
followed by an assertion of signal <code>d_end</code>, where a data transfer is an assertion
of signal <code>start</code> followed by an assertion of signal <code>busy</code> followed by an assertion
of signal <code>done</code>. Trace 5.11(i) is an example of a trace on which Property 5.11a
holds.

If we omit the <code>n</code>, the resulting SERE matches any number of repetitions of
the Boolean expression or SERE that is being repeated. For example, asserting
Property 5.11b indicates that after an acknowledged request, we expect to see
any number of data transfers followed by an assertion of <code>done</code>. Property 5.11b
holds on Trace 5.11(i), as well as on Traces 5.11(ii) and 5.11(iii).

A <code>[*]</code> repetition matches any number of repetitions, including none. Thus,
Property 5.11b holds on Trace 5.11(iv) as well. If you want to specify any
non-zero number of repetitions, use the <code>[+]</code>. Thus, Property 5.11c is similar
to Property 5.11b, but it requires at least one data transfer before signal done
is asserted. Thus, Property 5.11c does not hold on Trace 5.11(iv), but it does
hold on Traces 5.11(i), 5.11(ii) and 5.11(iii).

Instead of omitting the n, we can omit the Boolean expression or SERE
and let the repetition <code>[*n]</code> stand alone. A stand-alone <code>[*n]</code> is equivalent
to <code>‘true[*n]</code>. In other words, <code>[*n]</code> matches any n cycles (because <code>‘true</code>
holds in all cycles). Another way to think of it is that it allows us to “skip”
<code>n</code> cycles. Thus, Property 5.12a is similar to Property 5.11b, but instead of
the acknowledge (assertion of signal <code>ack</code>) coming immediately following the
request (assertion of signal <code>req</code>), it comes four cycles later. Property 5.12a
holds on Trace 5.12(i).

The nonconsecutive repetition operator (<code>[=n]</code>) provides a way to describe
repetitions that happen on not necessarily consecutive cycles. It can be ap-
plied only to a Boolean expression. For example, to describe the requirement
that after a request (assertion of signal <code>req</code>), we expect to see an acknowledge
(assertion of signal <code>ack</code>) followed by some number of cycles including three
not necessarily consecutive assertions of signal <code>busy</code>, followed by an asser-
tion of signal <code>done</code>, we can code Assertion 5.13a. Assertion 5.13a holds on
Trace 5.13(i). Note the cycles marked “<code>busy[=3]</code>” in Trace 5.13(i). They do
not start with an assertion of <code>busy</code>, nor do they end with one. The noncon-
secutive repetition operator <code>[=n]</code> will match any sequence of cycles in which
there are <code>n</code> not necessarily consecutive repetitions of the Boolean expression
being repeated, including sequences of cycles in which the “padding” is at
the beginning and/or at the end. In other words, it will match any sequence
of cycles in which the number of assertions of the Boolean expression being
repeated is ''equal to'' <code>n</code> (thus the use of the equals sign in <code>[=n]</code>).

If you want to disallow the padding at the end, use the goto repetition op-
erator [->n]. The goto repetition operator [->n] is similar to the nonconsec-
utive repetition operator, except that the sequence of cycles being described
ends with an assertion of the Boolean expression being repeated. In other
words, it will match any sequence of cycles starting at the current cycle and
ending after you “go to” the nth occurrence of the Boolean expression (the
use of the -> is intended to remind you of an arrow instructing you to go to
n). Thus Assertion 5.13b does not hold on Trace 5.13(i), but it does hold on
Trace 5.13(ii) because the third busy is immediately followed by an assertion
of signal done.

The n can be omitted for the goto repetition operator, in which case n
defaults to 1. In other words, b[->] is equivalent to b[->1].

Like the consecutive repetition operators, the nonconsecutive repetition
operator and the goto repetition operator can take a range. Thus, Asser-
tion 5.14a requires three to five not necessarily consecutive assertions of busy
after the assertion of signal ack and before the assertion of done, while Asser-
tion 5.14b requires the same, and in addition that the assertion of signal done
occur immediately after the 3rd, 4th, or 5th assertion of signal busy. Thus As-
sertion 5.14a holds on Traces 5.14(i) and 5.14(ii), while Assertion 5.14b holds
on Trace 5.14(ii) but not on Trace 5.14(i).

==5.5 Concatenation (;) and fusion (:)==

We have already seen the concatenation operator, a semi-colon, which is used
to join two SEREs (or two Boolean expressions, or a Boolean expression and
a SERE) in such a way that the right-hand SERE starts the cycle after the
left-hand SERE ends. The fusion operator, a colon, is used to join two SEREs
(or two Boolean expressions, or a Boolean expression and a SERE) in such a
way that there is a single cycle of overlap between them: the right-hand SERE
starts the same cycle that the left-hand SERE ends.

For example, consider the case that we want to specify the behavior of As-
sertion 5.14b, and in addition, following the assertion of signal done, we should
see a data transfer, which consists of the assertion of signal data for some num-
ber of cycles (might be zero), followed by an assertion of signal d end. Using
the concatenation operator, we can write Assertion 5.15a. Trace 5.15(i) is a
trace on which Assertion 5.15a holds. The first assertion of signal req gets
three cycles of data before the assertion of d end, while the second assertion
of signal req sees four cycles of data before seeing d end.

If the data transfer should start the same cycle as signal done is asserted,
then we can use the fusion operator as in Assertion 5.16a. Trace 5.16(i) is an
example of a trace on which Assertion 5.16a holds. It is similar to Trace 5.15(i),
except that the data transfer starts the same cycle as that in which done is
asserted, rather than the cycle following the assertion of signal done.

Note that while it may be tempting to understand the concatenation op-
erator (;) as a delay, the operator does not necessarily “eat” a cycle. For in-
stance, in the case of the SERE {a ; b[*] ; c}, the b[*] may match zero,
one, or more cycles, as illustrated in Trace 5.17(i). The first match shown in
Trace 5.17(i) is only two cycles long, thus, the second concatenation operator
(;) did not “eat” a delay. A better way to think of it is that concatenation
gives you an ordered list of things to happen – some of them may consume
one cycle, some more, and some no cycles at all.

Further note that fusion requires an overlap of at least one cycle. Thus,
while the {b[*]} in {b[*] ; c} may match an empty sequence of cycles,
replacing the concatenation operator with the fusion operator like this: {b[*]: c}
results in a SERE with at least one assertion of b (otherwise there is
nothing to overlap with the assertion of c). In both cases, the match may
consist of a single cycle. The difference is that in the case of {b[*] ; c} the
single cycle may not include an assertion of b (because there may be zero
assertions of b preceding c), while in the case of {b[*] : c}, the single cycle
must include an assertion of b (which overlaps with the assertion of c).

==5.6 Compound SEREs==

Compound SEREs are SEREs built from other SEREs through operations
other than concatenation and fusion. The available operators allow you to
“and” or “or” together two or more SEREs, as well as to express the situation
where a match of one SERE occurs within a sequence of cycles matched by
another.

Consider the case that we want to say that signal read complete is as-
serted on the last data cycle of every read operation, where we have two kinds
of read operations: a short read consists of an assertion of signal short rd fol-
lowed by eight not necessarily consecutive assertions of data, and a long read
consists of an assertion of signal long rd followed by 32 such assertions. We
could code two separate properties, as shown in Properties 5.18a and 5.18b.
Alternatively, we could use the SERE “or” operator (|) to “or” the two SEREs
together, as in Property 5.18c.

The SERE “and” operator comes in two types: length-matching and non-
length-matching. Both the length-matching (&&) and the non-length-matching
(&) “and” operators match a sequence of cycles if starting at the current cycle,
the left-hand side and the right-hand side are matched. The difference is that
in addition, the length-matching “and” operator requires that the lengths of
the sequences matched by both the left- and right-hand sides are the same,
while the non-length-matching operator matches even if they are different. A
length-matching “and” between SEREs R and S is illustrated in Trace 5.19(i),
and a non-length-matching “and” between SEREs R and S is illustrated in
Traces 5.20(i), 5.20(ii) and 5.20(iii).

When a non-length-matching “and” is used on the left-hand side of a con-
catenation or a fusion, the current cycle of the right-hand side of the concate-
nation or fusion is determined by the longer of the two subsequences making
up the non-length-matching “and”. For instance, in the SERE {{{a;b[*5];c}
& {d[*];e}} ; f}, the current cycle of f is the cycle after the cycle in which
the longer of the two SEREs {a;b[*5];c} and {d[*];e} completes. This is
illustrated in Traces 5.21(i) and 5.21(ii). Note that in each of the traces, sig-
nal f is asserted twice: once after the completion of {a;b[*5];c}, and once
after the completion of {d[*];e}. However, in each trace, only the assertion
of signal f that happens after the completion of the longer of the two SEREs
participates in the “match” of SERE {{{a;b[*5];c} & {d[*];e}} ; f}.

NOTE: A length-matching “and” such as {a;b;c} && {d} is legal, but
makes no sense (because there is no sequence which is both 3 cycles long to
match {a;b;c} and 1 cycle long to match {d}). Many tools will probably issue
a warning for such a SERE.

As an example of the use of the length-matching “and”, consider the case
that a read request (assertion of signal read req) that is granted (assertion of
signal gnt within 5 cycles of the request) should be followed by a data transfer
(assertion of signal data start followed by some number of consecutive as-
sertions of data, followed by an assertion of data end), unless it is canceled.
A cancel is an assertion of signal cancel any time between the assertion of
read req and the assertion of gnt, inclusive. We can express this using As-
sertion 5.22a. Assertion 5.22a holds on Trace 5.22(i): the first read request is
followed by a data transfer, while the second read request is not followed by
a data transfer, but is not required to be since it is canceled.

In the case of Assertion 5.22a, we needed the length-matching “and”.
To see why, consider what would have happened had we used the non-
length-matching “and” as in Assertion 5.22b. In the case of Assertion 5.22b,
the left-hand side SERE {{read req ; [*0:4] ; gnt} & {cancel[=0]}} is
matched not only by the sequence of cycles starting at cycle 2 and ending at
cycle 5, but also by the sequences of cycles starting at cycle 2 and ending at
any of the cycles 6 through 16. Thus, Assertion 5.22b requires that we see a
data transfer starting not only at cycle 6, but also at cycles 7, 8, 9, 10 and so
on. Obviously, this is not what we wanted.

As an example where we want the non-length-matching “and” rather than
the length-matching “and”, consider the case that signal global print req
indicates that we should see a print on each of printers 1, 2, and 3 (comple-
tion of which is indicated by assertions of p1 done, p2 done, and p3 done,
respectively), and that following completion of the last print job, we should
see an assertion of signal print success. We can express this as shown in
Assertion 5.23a. Assertion 5.23a holds on Trace 5.23(i) because following the
assertion of signal global print req, we see assertions of each of the signals
p1 done, p2 done and p3 done, the last of which is followed by an assertion
of print success.

The non-length-matching “and” was needed for Assertion 5.23a. To see
why, consider what would have happened if we had used the length-matching
“and”, as in Assertion 5.23b. Assertion 5.23b does not hold on Trace 5.23(i)
because the use of the length-matching “and” means that p1 done[->],
p2 done[->] and p3 done[->] must all have the same length, i.e., that
p1 done, p2 done and p3 done must all be asserted at the same time.

The SERE within operator is useful if you want to describe a situation
where one SERE occurs within the time frame of another. For instance, sup-
pose that the normal behavior of the design is to complete a high priority
request first, even if there is a pending low priority request that started be-
fore it. However, if signal no nesting is asserted when the low priority re-
quest is issued, then this is prohibited. In other words, the situation shown
in Trace 5.24(i) is not allowed. We can describe the prohibited situation as
shown in Assertion 5.24a. Assertion 5.24a does not hold on Trace 5.24(i)
because there is a match of {high pri begin ; high pri end[->]} that is
entirely enclosed within the match of {(low pri begin && no nesting) ;
low pri end[->]}.

NOTE: If the left and right operands of a within operator are s and t
respectively, then the within operator is simply a shorthand for a length-
matching “and” between {[*] ; s ; [*]} and {t}. That is, s within t is
equivalent to {[*] ; s ; [*]} && {t}.

==5.7 More about suffix implication==

Up until now, we have seen the suffix implication operators (|-> and |=>)
used with SEREs on both the left- and the right-hand sides. While the left-
hand side of a suffix implication operator must be a SERE, the right-hand
side of a suffix implication operator can be any property. Thus, if we want to
express the requirement that whenever we have a request that is acknowledged
(assertion of req followed by an assertion of ack) we should see a grant
(assertion of signal gnt within three cycles of the acknowledge), we can code
as in Assertion 5.25a.

This is illustrated in Trace 5.25(i). In the trace, there are three occurrences
of the SERE {req;ack}. The first is followed by an assertion of ack after two
cycles, the second after three cycles, and the third after a single cycle. Thus,
Assertion 5.25a holds on the trace.

Of course, we could have written Assertion 5.25a entirely in SERE style,
as shown in Assertion 5.25b, or entirely without SEREs, as in Assertion 5.25c.
Assertions 5.25a, 5.25b and 5.25c are equivalent, thus the issue is purely one
of style. Some people prefer using only one style, others find a mix of styles,
depending on the particular property, to be easier to understand.

==5.8 The built-in function ended()==

The built-in function ended() takes a SERE as an argument and returns true
in any cycle where that SERE has just ended.1 For example, Trace 5.26(i) has
been annotated with a waveform labeled ended({a ; b[*] ; c}) to show
the value of the call to ended() at each cycle.

<blockquote>1 - In previous versions of PSL, the role of the built-in function ended() was played by
endpoints. Endpoints are no longer a part of the language – use built-in function
ended() instead.</blockquote>

How is ended() used? Consider that a complete data transfer consists of
an assertion of signal data start followed by some number of assertions of
data, followed by an assertion of data end. Consider further that we have a
signal data transfer complete that should be asserted when a data trans-
fer is completed, and that we would like to specify the correct behavior of
this signal. A good start would be Assertion 5.27a. Assertion 5.27a ensures
that data transfer complete is asserted at the conclusion of every data
transfer. But what about the other direction? That is, what about ensuring
that whenever data transfer complete is asserted, a complete data trans-
fer has indeed concluded? Assertion 5.27a does not ensure this, and thus
it holds on Trace 5.27(i), even though there are “extraneous” assertions of
data transfer complete at cycles 6 and 15. We would like an assertion that
holds on Trace 5.27(ii) but not on 5.27(i).

In order to check the second direction (that there are no extraneous asser-
tions of data transfer complete) we need to switch the direction of the
implication: we need to say that if data transfer complete is asserted,
then we have just seen the conclusion of a complete data transfer. We could
try Assertion 5.27b. However, that doesn’t work. Assertion 5.27b requires
that the SERE {data start ; data[*] ; data end} start the same cycle as
data transfer complete, while we want it to end that cycle.

This is where the built-in function ended() comes in. Using ended(),
we can code what we want as shown in Assertion 5.27c, which states that
whenever we see an assertion of data transfer complete, we must have just
seen the end of SERE {data start ; data[*] ; data end}, and it does not
hold on Trace 5.27(i).

Note that ended() returns a Boolean value. Since the left-hand side of the
suffix implication in Assertion 5.27c consists of a single Boolean expression,
we could have coded Assertion 5.27c equivalently using logical implication as
shown in Assertion 5.27d.

==5.9 Overlapping matches of a SERE==

Up until now, we have been concentrating on explaining the meaning of each
SERE operator, using relatively simple examples. It is now time to introduce
some more complex examples, in order to emphasize that like LTL style prop-
erties, interpreting a SERE style property on a trace can involve examining
overlapping sets of cycles.

Consider Property 5.28a on Traces 5.28(i) and 5.28(ii). There are multiple
matches of {a ; b[*] ; c} on Trace 5.28(i), one match ending at cycle 2,
one ending at cycle 3, and one ending at cycle 4. Property 5.28a does not
hold on Trace 5.28(i), because the matches ending at cycles 2 and 3 do not
have associated assertions of signal d at cycles 3 and 4. A suffix implication
requires that for every match of the left-hand side, the right-hand side holds.
Property 5.28a does hold on Trace 5.28(ii), because signal d is asserted after
each match of {a ; b[*] ; c}.

Note that although Property 5.28a contains an always operator, the
always operator is not the source of the overlapping matches in this case.
Rather, for a single current cycle (cycle 1), there are three separate matches
of the SERE {a ; b[*] ; c}, each ending at a different cycle.

The overlapping can happen on the right-hand side of a suffix implication
as well. Consider for example Property 5.29a on Trace 5.29(i). There are three
matches of {d ; e[*] ; f}, ending at cycles 3, 4, and 5. One match would
have been enough to satisfy Property 5.29a, because as long as there exists one
match, {d ; e[*] ; f} holds. The fact that there are in fact three matches
does not hurt. Thus, Property 5.29a holds on Trace 5.29(i).

We have just explained that we require at least one match of the right-hand
side for every match of the left-hand side of a suffix implication, and it might
seem that in so doing, we have introduced something new. Actually, the rule
could have been deduced from the parallel we have previously drawn between
a suffix implication and an if-then statement. SERE {a ; b[*] ; c} can be
understood as an infinite “or” between SEREs {a;c}, {a;b;c}, {a;b;b;c},
and so on. So Property 5.28a can be understood as “if {a;c} or {a;b;c} or
{a;b;b;c} or ..., then d”, which clearly should hold only if we see a d every
time the if-part is matched. And Property 5.29a can be understood as “if c,
then {d;f} or {d;e;f} or {d;e;e;f} or ...”, which of course should hold as
long as we have seen at least a single match of the then-part.

==5.10 How not to use SEREs==

[[Файл:Psl fig5.4.png]]

[[Файл:Psl fig5.5.png]]

[[Файл:Psl fig5.6.png]]

[[Файл:Psl fig5.7.png]]

[[Файл:Psl fig5.8.png]]

[[Файл:Psl fig5.9.png]]

[[Файл:Psl fig5.10.png]]

[[Файл:Psl fig5.11.png]]

[[Файл:Psl fig5.12.png]]

[[Файл:Psl fig5.13.png]]

[[Файл:Psl fig5.14.png]]

[[Файл:Psl fig5.15.png]]

[[Файл:Psl fig5.16.png]]

PSL/A Practical Introduction to PSL/SERE Style

2014-01-09T16:22:01Z

Valentin: /* Стиль SERE */

{{PSL TOC}}

=Стиль SERE=


До этого момента, мы видели свойства PSL, построенные на булевых выражениях и временных операторах в стиле LTL. Другой путь построения свойств использует SERE - Последовательные расширения регулярных выражений. SERE по-сути тоже самое, что и регулярные выражения, как те, которые используются для сопоставления во многих приложениях. Отличие лишь в том, что атом SERE - булево выражение, в то время, как атомы стандартного регулярного выражения - отдельные символы.


SERE обычно заключается в фигурные скобки, и атом SERE обычно разделен точкой с запятой. Например, <code>{a;b;c}</code> - это SERE, и SERE 5.1a - это более сложный SERE. SERE 5.1a описывает последовательность циклов, в которых утверждается <code>(req_out && !ack)</code> на первом цикле, далее <code>(busy && !ack)</code> утверждается нуль или более циклов, показанный последовательным оператором повторения <code>[*]</code>, и в итоге утверждается ack. Таким образом, SERE 5.1a отмечает последовательность циклов, под лейблом “1” в тракте 5.1(i).


Не поддавайтесь искушению в трактовке SERE более, чем показано здесь: SERE 5.1a показывает последовательность циклов под лейблом “2” в тракте 5.1(i). SERE 5.1a не запрещает утверждения занятости в течение последнего цикла SERE. Если важно исключить такое поведение, занятость может быть явно указана, как показано в SERE 5.1b. SERE 5.1b показывает последовательность циклов под лейблом “1”, показанная на тракте 5.1(i), но не показывает последовательность циклов под лейблом “2” в этом же тракте.


Как использовать SERE? Во-первых, SERE может также быть под-свойством. Например, свойство 5.2a выполняется, если существует утверждение <code>req_in && gnt</code>, далее начиная со следующего цикла, мы видим последовательность циклов отмеченных SERE 5.1a. Свойство 5.2a выполняется на тракте 5.2(i).


Примечание: SERE - это свойство, но свойство это не всегда SERE. Таким образом, пока мы можем использовать SERE, как операнд временного оператора, мы не можем вставить временной оператор, такой как <code>always</code> или <code>next</code>, внутрь SERE.


Сейчас предположим, что у нас есть ситуация похожая на свойство 5.2a, но в которой грант (утверждение сигнала <code>gnt</code>) появляется циклом ''позже'' утверждения <code>req_in</code>. Мы можем попробовать заменить булево выражение <code>req_in && gnt</code> временным выражением <code>req_in && next gnt</code>, как в свойстве 5.3a. Однако, вспомним урок раздела 3.4: в свойстве 5.3a текущий цикл лева-ориентированной стороны <tt>(req_in && next gnt)</tt> тот же самый, что и текущий цикл право-ориентированной стороны (потому что они соединены булевым оператором <tt>-></tt>). Таким образом, текущий цикл <code>gnt</code> (который является операндом оператора <code>next</code>) - это тот же текущий цикл для SERE (который также является операндом оператора <code>next</code>). Это немного запутанно, и действительно свойство 5.3а не принадлежит простому подмножеству PSL, которые мы обсуждали в главе 9.


Давайте модифицируем свойство 5.3а, как показано в свойстве 5.3b. Сейчас один оператор <code>next</code> применяется для обоих, <code>gnt</code> и SERE, которые являются операндами оператора <code>-></code>. Свойство 5.3b эквивалентно свойству 5.3a, но оно из просто подмножества, делая более простым отслеживание временной выборки между <code>gnt</code> и SERE. Если мы подразумеваем, что текущий цикл SERE должен быть циклом ''позже'' <code>gnt</code>, мы можем манипулировать свойством 5.3b, добавляя <code>next</code>, как в свойстве 5.3c. Однако, суффиксная импликация операторов предоставляет более простой путь.

{| align=center
! [[Файл:Psl fig5.1.png]]
|-
!(i) SERE 5.1a отмечает 1 и 2. SERE 5.1b отмечает 1, но не 2.
|-
|<pre>
{(req_out && !ack) ; (busy && !ack)[*] ; ack} (5.1a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack && !busy} (5.1b)
</pre>
|-
! Рис. 5.1: Два простых SEREs
|}

{| align=center
! [[Файл:Psl fig5.2.png]]
|-
!(i) Свойство 5.2a выполняется
|-
|<pre>
always ((req_in && gnt) -> (5.2a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
</pre>
|-
! Рис. 5.2: SERE - свойство
|}

{| align=center width=80%
|<pre>
always ((req_in && next gnt) -> (5.3a)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack})
always (req_in -> next (gnt -> (5.3b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}))
always (req_in -> next (gnt -> (5.3c)
next {(req_out && !ack) ; (busy && !ack)[*] ; ack}))
</pre>
|-
! Рис. 5.3: Свойство 5.3a не из простого подмножества. Свойства 5.3b и 5.3c из простого подмножества,
но они сложны для чтения. Эти свойства можно выразить проще, используя суффиксную импликацию.
|}

==5.1 Суффиксная импликация (<code>|-></code> и <code>|=></code>)==


Операторы ''суффиксной импликации'' (<code>|-></code> и <code>|=></code>) предоставляют возможность ссылаться на два SERE таким образом, что право-ориентированная сторона начинает работать, когда лева-сторонняя сторона заканчивает работы. Параллельный оператор суффиксной импликации (<code>|-></code>) интерпретирует “когда лева-ориентированная сторона заканчивает работать” также, как “в том же цикле, когда лева-ориентированная сторона заканчивает работать”, в то время как не параллельный оператор суффиксной импликации (<code>|=></code>) интерпретирует это, как “цикл после цикла, в котором лева-ориентированная сторона завершила работу”. Таким образом, свойство 5.4а эквивалентно свойству 5.3b, и свойство 5.4b эквивалентно свойству 5.3c. Оба свойства 5.4a и 5.4b легче для понимания, чем эквивалентное свойство без суффиксной импликации , и оба принадлежат простому подмножеству из главы 9.

{| align=center
! [[Файл:Psl fig5.4.png]]
|-
|<pre>
always {req_in;gnt} |-> (5.4a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.4b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}

</pre>
|-
! Рис. 5.4: Суффиксная импликация
|}

Recall that the logical implication operator (<code>-></code>) can be understood as an
if-then expression, with the else-part being implicitly true. The suffix implica-
tion operators (<code>|-></code> and <code>|=></code>) can be understood the same way. The difference
between the logical implication operator (<code>-></code>) and the suffix implication op-
erators (<code>|-></code> and <code>|=></code>) is in the timing relationship between the if- and the
then-parts. While the current cycle of the then-part of a logical implication
operator (->) is the same as the current cycle of its if-part, the current cycle
of the then-part of a suffix implication operator (<code>|-></code> or <code>|=></code>) is the first cycle
of the ''suffix'' of the trace that remains once the if-part has been seen. This is
illustrated for Properties 5.4a and 5.4b in Traces 5.4(i) and 5.4(ii).

{| align=center
! [[Файл:Psl fig5.5.png]]
|-
! (i) A trace having multiple if-then pairs. Property 5.5a holds.
|-
|<pre>
always {req_in;gnt} |=> (5.5a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Fig. 5.5: The if-part of another if-then pair may begin before the if-part or the
then-part of a previous if-then pair has completed
|}

In Traces 5.4(i) and 5.4(ii) there is a single assertion of signal <code>req_in</code>.
If there are multiple assertions of <code>req_in</code>, then of course we will be able to
identify multiple if-then pairs, as shown in Trace 5.5(i). Note that the if-part of
another if-then pair may begin before the if-part or the then-part of a previous
if-then pair has completed. For instance, the second if-then pair starts at cycle
7, before the then-part of the first if-then pair has completed. The third if-
then pair starts at cycle 8, before the then-part of the first if-then pair has
completed, and before the if-part of the second if-then pair has completed.
We have seen this kind of overlapping previously, in Traces 2.2(ii) and 2.3(iii).
Note that in Trace 5.5(i), the assertion of <code>ack</code> at cycle 16 completes the then-
part of the second and of the third if-then pair. For a deeper discussion of this
phenomenon, see Section 13.4.2.

Properties 5.6a and 5.6b hold on Trace 5.6(i) because there is no sequence
of cycles matching the left-hand side, thus the else-parts default to true at
every cycle.

{| align=center
! [[Файл:Psl fig5.6.png]]
|-
! (i) Properties 5.6a and 5.6b both hold
|-
|<pre>
always {req_in;gnt} |-> (5.6a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.6b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
</pre>
|-
! Fig. 5.6: The else-part of a suffix implication defaults to true
|}

==5.2 Weak and strong SEREs==

Like temporal operators, SEREs come in weak and strong versions, and like
temporal operators, the strong version of a SERE is indicated by an exclama-
tion point (<code>!</code>). Thus, Property 5.7a, whose right-hand side is a weak SERE,
holds even if signal <code>ack</code> is never asserted (as long as the rest of the SERE is
not violated). Property 5.7b, whose right-hand side is a strong SERE, holds
only if we eventually reach a cycle where <code>ack</code> occurs. In other words, the weak
version of a SERE allows us to accept a trace that is “too short”, whereas
the strong version requires that we “reach the end” of the SERE. Thus, while
Property 5.7a holds on Trace 5.7(i) as well as Trace 5.7(ii), Property 5.7b, the
strong version, holds on Trace 5.7(ii) but not on Trace 5.7(i).

{| align=center
! [[Файл:Psl fig5.7.png]]
|-
|<pre>
always {req_in;gnt} |=> (5.7a)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}
always {req_in;gnt} |=> (5.7b)
{(req_out && !ack) ; (busy && !ack)[*] ; ack}!
</pre>
|-
! Fig. 5.7: A weak SERE holds even if the trace is “too short”, while a strong SERE
must “reach the end”
|}

==5.3 The <code>never</code> operator applied to a SERE==

Another way to use a SERE is in describing sequences of events that should
never happen. For example, Assertion 5.8a states that signal <code>req</code> should never
be asserted for two consecutive cycles, and thus does not hold on Trace 5.8(i).

As another example, consider Assertion 5.9a. It states that an acknowl-
edged high priority request (assertion of <code>req</code> together with <code>high_pri</code>, followed
a cycle later by <code>ack</code>) cannot be canceled (assertion of <code>cancel</code> the cycle after
<code>ack</code>). Thus it holds on Trace 5.9(i), but not on Trace 5.9(ii).

{| align=center
! [[Файл:Psl fig5.8.png]]
|-
| (i) Assertion 5.8a does not hold
|-
|<pre>
assert never {req;req}; (5.8a)
</pre>
|-
! Fig. 5.8: The never operator
|}

{| align=center
! [[Файл:Psl fig5.9.png]]
|-
| (i) Assertion 5.8a does not hold
|-
|<pre>
assert never {req && high_pri ; ack ; cancel}; (5.9a)
</pre>
|-
! Fig. 5.9: More about the never operator
|}

==5.4 SERE repetition operators (<code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>)==

Up until now, we have seen basic SEREs composed of (possibly repeated)
Boolean expressions separated by semi-colons. In this section, we examine
SERE operators that allow you to build more sophisticated SEREs, using
variations on the SERE repetition operators <code>[*n]</code>, <code>[=n]</code>, and <code>[->n]</code>.

Consecutive repetition operators provide a shortcut to typing the same
sub-SERE a number of times. The <code>[*n]</code> operator is an abbreviation for
n repetitions of the SERE it is applied to. For example, instead of typing
<code>busy;busy;busy</code> in Assertion 5.10a, we can use the abbreviation <code>busy[*3]</code>,
as in Assertion 5.10b. Assertions 5.10a and 5.10b state that after a request
(assertion of signal <code>req</code>), we expect to see an acknowledge (assertion of signal
<code>ack</code>) followed by three cycles in which signal <code>busy</code> is asserted, followed by
an assertion of signal <code>done</code>. Trace 5.10(i) is an example of a trace on which
Assertions 5.10a and 5.10b hold.

{| align=center
! [[Файл:Psl fig5.10.png]]
|-
|<pre>
assert always {req} |=> {ack;busy;busy;busy;done}; (5.10a)
assert always {req} |=> {ack ; busy[*3] ; done}; (5.10b)
assert always {req} |=> {ack ; busy[*3:5] ; done}; (5.10c)
</pre>
|-
! Fig. 5.10: The <code>[*n]</code> and <code>[*i:j]</code> operators
|}

Instead of a specific number of repetitions, we can specify a range, i
through <code>j</code>, like this: <code>[*i:j]</code>. Thus, Assertion 5.10c is similar to Asser-
tion 5.10b, but instead of requiring exactly three assertions of signal <code>busy</code>,
we require between three and five. Assertion 5.10c holds on Trace 5.10(i) as
well as on Trace 5.10(ii).

The upper bound of a range can be infinity, which is indicated by a <code>$</code> in
the SystemVerilog flavor, by ''null'' in the GDL flavor, and by inf in the Verilog,
VHDL, and SystemC flavors. For instance, the SERE <code>{b[*5:inf]}</code> matches
five or more repetitions of <code>b</code>.

We can repeat not only a Boolean expression, but a SERE as well. For
example, Property 5.11a holds if after an acknowledged request (an assertion
of signal <code>req</code> followed by an assertion of signal <code>ack</code>), we see three data transfers
followed by an assertion of signal <code>d_end</code>, where a data transfer is an assertion
of signal <code>start</code> followed by an assertion of signal <code>busy</code> followed by an assertion
of signal <code>done</code>. Trace 5.11(i) is an example of a trace on which Property 5.11a
holds.

If we omit the <code>n</code>, the resulting SERE matches any number of repetitions of
the Boolean expression or SERE that is being repeated. For example, asserting
Property 5.11b indicates that after an acknowledged request, we expect to see
any number of data transfers followed by an assertion of <code>done</code>. Property 5.11b
holds on Trace 5.11(i), as well as on Traces 5.11(ii) and 5.11(iii).

A <code>[*]</code> repetition matches any number of repetitions, including none. Thus,
Property 5.11b holds on Trace 5.11(iv) as well. If you want to specify any
non-zero number of repetitions, use the <code>[+]</code>. Thus, Property 5.11c is similar
to Property 5.11b, but it requires at least one data transfer before signal done
is asserted. Thus, Property 5.11c does not hold on Trace 5.11(iv), but it does
hold on Traces 5.11(i), 5.11(ii) and 5.11(iii).

Instead of omitting the n, we can omit the Boolean expression or SERE
and let the repetition <code>[*n]</code> stand alone. A stand-alone <code>[*n]</code> is equivalent
to <code>‘true[*n]</code>. In other words, <code>[*n]</code> matches any n cycles (because <code>‘true</code>
holds in all cycles). Another way to think of it is that it allows us to “skip”
<code>n</code> cycles. Thus, Property 5.12a is similar to Property 5.11b, but instead of
the acknowledge (assertion of signal <code>ack</code>) coming immediately following the
request (assertion of signal <code>req</code>), it comes four cycles later. Property 5.12a
holds on Trace 5.12(i).

The nonconsecutive repetition operator (<code>[=n]</code>) provides a way to describe
repetitions that happen on not necessarily consecutive cycles. It can be ap-
plied only to a Boolean expression. For example, to describe the requirement
that after a request (assertion of signal <code>req</code>), we expect to see an acknowledge
(assertion of signal <code>ack</code>) followed by some number of cycles including three
not necessarily consecutive assertions of signal <code>busy</code>, followed by an asser-
tion of signal <code>done</code>, we can code Assertion 5.13a. Assertion 5.13a holds on
Trace 5.13(i). Note the cycles marked “<code>busy[=3]</code>” in Trace 5.13(i). They do
not start with an assertion of <code>busy</code>, nor do they end with one. The noncon-
secutive repetition operator <code>[=n]</code> will match any sequence of cycles in which
there are <code>n</code> not necessarily consecutive repetitions of the Boolean expression
being repeated, including sequences of cycles in which the “padding” is at
the beginning and/or at the end. In other words, it will match any sequence
of cycles in which the number of assertions of the Boolean expression being
repeated is ''equal to'' <code>n</code> (thus the use of the equals sign in <code>[=n]</code>).

If you want to disallow the padding at the end, use the goto repetition op-
erator [->n]. The goto repetition operator [->n] is similar to the nonconsec-
utive repetition operator, except that the sequence of cycles being described
ends with an assertion of the Boolean expression being repeated. In other
words, it will match any sequence of cycles starting at the current cycle and
ending after you “go to” the nth occurrence of the Boolean expression (the
use of the -> is intended to remind you of an arrow instructing you to go to
n). Thus Assertion 5.13b does not hold on Trace 5.13(i), but it does hold on
Trace 5.13(ii) because the third busy is immediately followed by an assertion
of signal done.

The n can be omitted for the goto repetition operator, in which case n
defaults to 1. In other words, b[->] is equivalent to b[->1].

Like the consecutive repetition operators, the nonconsecutive repetition
operator and the goto repetition operator can take a range. Thus, Asser-
tion 5.14a requires three to five not necessarily consecutive assertions of busy
after the assertion of signal ack and before the assertion of done, while Asser-
tion 5.14b requires the same, and in addition that the assertion of signal done
occur immediately after the 3rd, 4th, or 5th assertion of signal busy. Thus As-
sertion 5.14a holds on Traces 5.14(i) and 5.14(ii), while Assertion 5.14b holds
on Trace 5.14(ii) but not on Trace 5.14(i).

==5.5 Concatenation (;) and fusion (:)==

We have already seen the concatenation operator, a semi-colon, which is used
to join two SEREs (or two Boolean expressions, or a Boolean expression and
a SERE) in such a way that the right-hand SERE starts the cycle after the
left-hand SERE ends. The fusion operator, a colon, is used to join two SEREs
(or two Boolean expressions, or a Boolean expression and a SERE) in such a
way that there is a single cycle of overlap between them: the right-hand SERE
starts the same cycle that the left-hand SERE ends.

For example, consider the case that we want to specify the behavior of As-
sertion 5.14b, and in addition, following the assertion of signal done, we should
see a data transfer, which consists of the assertion of signal data for some num-
ber of cycles (might be zero), followed by an assertion of signal d end. Using
the concatenation operator, we can write Assertion 5.15a. Trace 5.15(i) is a
trace on which Assertion 5.15a holds. The first assertion of signal req gets
three cycles of data before the assertion of d end, while the second assertion
of signal req sees four cycles of data before seeing d end.

If the data transfer should start the same cycle as signal done is asserted,
then we can use the fusion operator as in Assertion 5.16a. Trace 5.16(i) is an
example of a trace on which Assertion 5.16a holds. It is similar to Trace 5.15(i),
except that the data transfer starts the same cycle as that in which done is
asserted, rather than the cycle following the assertion of signal done.

Note that while it may be tempting to understand the concatenation op-
erator (;) as a delay, the operator does not necessarily “eat” a cycle. For in-
stance, in the case of the SERE {a ; b[*] ; c}, the b[*] may match zero,
one, or more cycles, as illustrated in Trace 5.17(i). The first match shown in
Trace 5.17(i) is only two cycles long, thus, the second concatenation operator
(;) did not “eat” a delay. A better way to think of it is that concatenation
gives you an ordered list of things to happen – some of them may consume
one cycle, some more, and some no cycles at all.

Further note that fusion requires an overlap of at least one cycle. Thus,
while the {b[*]} in {b[*] ; c} may match an empty sequence of cycles,
replacing the concatenation operator with the fusion operator like this: {b[*]: c}
results in a SERE with at least one assertion of b (otherwise there is
nothing to overlap with the assertion of c). In both cases, the match may
consist of a single cycle. The difference is that in the case of {b[*] ; c} the
single cycle may not include an assertion of b (because there may be zero
assertions of b preceding c), while in the case of {b[*] : c}, the single cycle
must include an assertion of b (which overlaps with the assertion of c).

==5.6 Compound SEREs==

Compound SEREs are SEREs built from other SEREs through operations
other than concatenation and fusion. The available operators allow you to
“and” or “or” together two or more SEREs, as well as to express the situation
where a match of one SERE occurs within a sequence of cycles matched by
another.

Consider the case that we want to say that signal read complete is as-
serted on the last data cycle of every read operation, where we have two kinds
of read operations: a short read consists of an assertion of signal short rd fol-
lowed by eight not necessarily consecutive assertions of data, and a long read
consists of an assertion of signal long rd followed by 32 such assertions. We
could code two separate properties, as shown in Properties 5.18a and 5.18b.
Alternatively, we could use the SERE “or” operator (|) to “or” the two SEREs
together, as in Property 5.18c.

The SERE “and” operator comes in two types: length-matching and non-
length-matching. Both the length-matching (&&) and the non-length-matching
(&) “and” operators match a sequence of cycles if starting at the current cycle,
the left-hand side and the right-hand side are matched. The difference is that
in addition, the length-matching “and” operator requires that the lengths of
the sequences matched by both the left- and right-hand sides are the same,
while the non-length-matching operator matches even if they are different. A
length-matching “and” between SEREs R and S is illustrated in Trace 5.19(i),
and a non-length-matching “and” between SEREs R and S is illustrated in
Traces 5.20(i), 5.20(ii) and 5.20(iii).

When a non-length-matching “and” is used on the left-hand side of a con-
catenation or a fusion, the current cycle of the right-hand side of the concate-
nation or fusion is determined by the longer of the two subsequences making
up the non-length-matching “and”. For instance, in the SERE {{{a;b[*5];c}
& {d[*];e}} ; f}, the current cycle of f is the cycle after the cycle in which
the longer of the two SEREs {a;b[*5];c} and {d[*];e} completes. This is
illustrated in Traces 5.21(i) and 5.21(ii). Note that in each of the traces, sig-
nal f is asserted twice: once after the completion of {a;b[*5];c}, and once
after the completion of {d[*];e}. However, in each trace, only the assertion
of signal f that happens after the completion of the longer of the two SEREs
participates in the “match” of SERE {{{a;b[*5];c} & {d[*];e}} ; f}.

NOTE: A length-matching “and” such as {a;b;c} && {d} is legal, but
makes no sense (because there is no sequence which is both 3 cycles long to
match {a;b;c} and 1 cycle long to match {d}). Many tools will probably issue
a warning for such a SERE.

As an example of the use of the length-matching “and”, consider the case
that a read request (assertion of signal read req) that is granted (assertion of
signal gnt within 5 cycles of the request) should be followed by a data transfer
(assertion of signal data start followed by some number of consecutive as-
sertions of data, followed by an assertion of data end), unless it is canceled.
A cancel is an assertion of signal cancel any time between the assertion of
read req and the assertion of gnt, inclusive. We can express this using As-
sertion 5.22a. Assertion 5.22a holds on Trace 5.22(i): the first read request is
followed by a data transfer, while the second read request is not followed by
a data transfer, but is not required to be since it is canceled.

In the case of Assertion 5.22a, we needed the length-matching “and”.
To see why, consider what would have happened had we used the non-
length-matching “and” as in Assertion 5.22b. In the case of Assertion 5.22b,
the left-hand side SERE {{read req ; [*0:4] ; gnt} & {cancel[=0]}} is
matched not only by the sequence of cycles starting at cycle 2 and ending at
cycle 5, but also by the sequences of cycles starting at cycle 2 and ending at
any of the cycles 6 through 16. Thus, Assertion 5.22b requires that we see a
data transfer starting not only at cycle 6, but also at cycles 7, 8, 9, 10 and so
on. Obviously, this is not what we wanted.

As an example where we want the non-length-matching “and” rather than
the length-matching “and”, consider the case that signal global print req
indicates that we should see a print on each of printers 1, 2, and 3 (comple-
tion of which is indicated by assertions of p1 done, p2 done, and p3 done,
respectively), and that following completion of the last print job, we should
see an assertion of signal print success. We can express this as shown in
Assertion 5.23a. Assertion 5.23a holds on Trace 5.23(i) because following the
assertion of signal global print req, we see assertions of each of the signals
p1 done, p2 done and p3 done, the last of which is followed by an assertion
of print success.

The non-length-matching “and” was needed for Assertion 5.23a. To see
why, consider what would have happened if we had used the length-matching
“and”, as in Assertion 5.23b. Assertion 5.23b does not hold on Trace 5.23(i)
because the use of the length-matching “and” means that p1 done[->],
p2 done[->] and p3 done[->] must all have the same length, i.e., that
p1 done, p2 done and p3 done must all be asserted at the same time.

The SERE within operator is useful if you want to describe a situation
where one SERE occurs within the time frame of another. For instance, sup-
pose that the normal behavior of the design is to complete a high priority
request first, even if there is a pending low priority request that started be-
fore it. However, if signal no nesting is asserted when the low priority re-
quest is issued, then this is prohibited. In other words, the situation shown
in Trace 5.24(i) is not allowed. We can describe the prohibited situation as
shown in Assertion 5.24a. Assertion 5.24a does not hold on Trace 5.24(i)
because there is a match of {high pri begin ; high pri end[->]} that is
entirely enclosed within the match of {(low pri begin && no nesting) ;
low pri end[->]}.

NOTE: If the left and right operands of a within operator are s and t
respectively, then the within operator is simply a shorthand for a length-
matching “and” between {[*] ; s ; [*]} and {t}. That is, s within t is
equivalent to {[*] ; s ; [*]} && {t}.

==5.7 More about suffix implication==

Up until now, we have seen the suffix implication operators (|-> and |=>)
used with SEREs on both the left- and the right-hand sides. While the left-
hand side of a suffix implication operator must be a SERE, the right-hand
side of a suffix implication operator can be any property. Thus, if we want to
express the requirement that whenever we have a request that is acknowledged
(assertion of req followed by an assertion of ack) we should see a grant
(assertion of signal gnt within three cycles of the acknowledge), we can code
as in Assertion 5.25a.

This is illustrated in Trace 5.25(i). In the trace, there are three occurrences
of the SERE {req;ack}. The first is followed by an assertion of ack after two
cycles, the second after three cycles, and the third after a single cycle. Thus,
Assertion 5.25a holds on the trace.

Of course, we could have written Assertion 5.25a entirely in SERE style,
as shown in Assertion 5.25b, or entirely without SEREs, as in Assertion 5.25c.
Assertions 5.25a, 5.25b and 5.25c are equivalent, thus the issue is purely one
of style. Some people prefer using only one style, others find a mix of styles,
depending on the particular property, to be easier to understand.

==5.8 The built-in function ended()==

The built-in function ended() takes a SERE as an argument and returns true
in any cycle where that SERE has just ended.1 For example, Trace 5.26(i) has
been annotated with a waveform labeled ended({a ; b[*] ; c}) to show
the value of the call to ended() at each cycle.

<blockquote>1 - In previous versions of PSL, the role of the built-in function ended() was played by
endpoints. Endpoints are no longer a part of the language – use built-in function
ended() instead.</blockquote>

How is ended() used? Consider that a complete data transfer consists of
an assertion of signal data start followed by some number of assertions of
data, followed by an assertion of data end. Consider further that we have a
signal data transfer complete that should be asserted when a data trans-
fer is completed, and that we would like to specify the correct behavior of
this signal. A good start would be Assertion 5.27a. Assertion 5.27a ensures
that data transfer complete is asserted at the conclusion of every data
transfer. But what about the other direction? That is, what about ensuring
that whenever data transfer complete is asserted, a complete data trans-
fer has indeed concluded? Assertion 5.27a does not ensure this, and thus
it holds on Trace 5.27(i), even though there are “extraneous” assertions of
data transfer complete at cycles 6 and 15. We would like an assertion that
holds on Trace 5.27(ii) but not on 5.27(i).

In order to check the second direction (that there are no extraneous asser-
tions of data transfer complete) we need to switch the direction of the
implication: we need to say that if data transfer complete is asserted,
then we have just seen the conclusion of a complete data transfer. We could
try Assertion 5.27b. However, that doesn’t work. Assertion 5.27b requires
that the SERE {data start ; data[*] ; data end} start the same cycle as
data transfer complete, while we want it to end that cycle.

This is where the built-in function ended() comes in. Using ended(),
we can code what we want as shown in Assertion 5.27c, which states that
whenever we see an assertion of data transfer complete, we must have just
seen the end of SERE {data start ; data[*] ; data end}, and it does not
hold on Trace 5.27(i).

Note that ended() returns a Boolean value. Since the left-hand side of the
suffix implication in Assertion 5.27c consists of a single Boolean expression,
we could have coded Assertion 5.27c equivalently using logical implication as
shown in Assertion 5.27d.

==5.9 Overlapping matches of a SERE==

Up until now, we have been concentrating on explaining the meaning of each
SERE operator, using relatively simple examples. It is now time to introduce
some more complex examples, in order to emphasize that like LTL style prop-
erties, interpreting a SERE style property on a trace can involve examining
overlapping sets of cycles.

Consider Property 5.28a on Traces 5.28(i) and 5.28(ii). There are multiple
matches of {a ; b[*] ; c} on Trace 5.28(i), one match ending at cycle 2,
one ending at cycle 3, and one ending at cycle 4. Property 5.28a does not
hold on Trace 5.28(i), because the matches ending at cycles 2 and 3 do not
have associated assertions of signal d at cycles 3 and 4. A suffix implication
requires that for every match of the left-hand side, the right-hand side holds.
Property 5.28a does hold on Trace 5.28(ii), because signal d is asserted after
each match of {a ; b[*] ; c}.

Note that although Property 5.28a contains an always operator, the
always operator is not the source of the overlapping matches in this case.
Rather, for a single current cycle (cycle 1), there are three separate matches
of the SERE {a ; b[*] ; c}, each ending at a different cycle.

The overlapping can happen on the right-hand side of a suffix implication
as well. Consider for example Property 5.29a on Trace 5.29(i). There are three
matches of {d ; e[*] ; f}, ending at cycles 3, 4, and 5. One match would
have been enough to satisfy Property 5.29a, because as long as there exists one
match, {d ; e[*] ; f} holds. The fact that there are in fact three matches
does not hurt. Thus, Property 5.29a holds on Trace 5.29(i).

We have just explained that we require at least one match of the right-hand
side for every match of the left-hand side of a suffix implication, and it might
seem that in so doing, we have introduced something new. Actually, the rule
could have been deduced from the parallel we have previously drawn between
a suffix implication and an if-then statement. SERE {a ; b[*] ; c} can be
understood as an infinite “or” between SEREs {a;c}, {a;b;c}, {a;b;b;c},
and so on. So Property 5.28a can be understood as “if {a;c} or {a;b;c} or
{a;b;b;c} or ..., then d”, which clearly should hold only if we see a d every
time the if-part is matched. And Property 5.29a can be understood as “if c,
then {d;f} or {d;e;f} or {d;e;e;f} or ...”, which of course should hold as
long as we have seen at least a single match of the then-part.

==5.10 How not to use SEREs==

[[Файл:Psl fig5.4.png]]

[[Файл:Psl fig5.5.png]]

[[Файл:Psl fig5.6.png]]

[[Файл:Psl fig5.7.png]]

[[Файл:Psl fig5.8.png]]

[[Файл:Psl fig5.9.png]]

[[Файл:Psl fig5.10.png]]

[[Файл:Psl fig5.11.png]]

[[Файл:Psl fig5.12.png]]

[[Файл:Psl fig5.13.png]]

[[Файл:Psl fig5.14.png]]

[[Файл:Psl fig5.15.png]]

[[Файл:Psl fig5.16.png]]

PSL/A Practical Introduction to PSL/SERE Style

2014-01-06T15:40:28Z

Valentin: /* SERE Style */

PSL/A Practical Introduction to PSL/Weak vs. Strong Temporal Operators

2013-12-30T17:55:21Z

Valentin: /* 4.5 Operators without weak or strong versions */

{{PSL TOC}}

== Слабые временные операторы против сильных временных операторов ==


Временные операторы могут быть ''слабыми'' или ''сильными''. Сильны временной оператор, такой как <code>eventually!</code> показан восклицательным знаком, как частью своего имени. Оператор без восклицательного , такой как <code>next</code>, слабый. До этого времени мы видели только по одной версии каждого оператора, но много операторов, которых мы видели до того, могут иметь слабую и сильную версии. Различие между слабыми и сильными операторами очень важны, когда путь “слишком короткий”, чтобы определить, действительно все ли произошло для удовлетворения свойства. 1 Например, рассматривая спецификацию “каждое утверждения сигнала a должно происходить на три цикла раньше утверждения сигнала <code>b</code>” на тракте 4.1(i). Выполняется спецификация или нет? Утверждение сигнала a в цикле 2 удовлетворяется утверждением сигнала b на цикле 5. Но, что можно сказать про утверждение сигнала a на цикле 9? Это предполагает утверждение сигнала b на цикле 12, но тракт заканчивает до достижения 12-го цикла. Слабые и сильные временные операторы позволяют нам различать случаи, в которых мы можем сказать,что наша спецификация выполняется на тракте 4.1(i), и в которых мы можем сказать, что она не выполняется.


<blockquote>1 - В этой главе мы рассмотрим конечные пути, т.к. как они выглядят с точки зрения моделирования. Для бесконечных путях, т.к. они представлены в формальной верификации, также существует разница между слабыми и сильными операторами. Это мы обсудим в главе 11.</blockquote>


Слабы временной оператор податливый - в случаи, когда тракт заканчивается “слишком быстро”, свойство, использующее слабый оператор, будет выполнятся до тех пор, пока что-нибудь не пойдет ни так. Если бы мы продолжили ход верификации в тракте 4.1(i) еще на несколько циклов, мы могли бы обнаружить, что сигнал b утверждается в цикле 12. Такое ''может'' случится. Таким образом, утверждение 4.1а, которое использует слабый оператор next, выполняется в тракте 4.1(i).


Сильный оператор строгий - в случаи, когда тракт заканчивается “слишком быстро”, свойство, использующее сильный оператор, не будет выполняться, даже если ничего плохого не происходит. Не существует пути узнать, что бы случилось, если бы мы продолжили ход верификации, показанный в тракте 4.1(i), еще несколько циклов, и мы не можем сказать, что свойство выполняется, не имея всей информации. Таким образом, утверждение 4.1b, которое использует сильный оператор <code>next!</code>, не выполняется на тракте 4.1(i).

{| align=center
! [[Файл:Psl fig4.1.png]]
|-
!(i) Утверждение 4.1a выполняется, but 4.1b не выполняется
|-
|<pre>
assert always(a -> next[3] (b)); (4.1a)
assert always(a -> next![3] (b)); (4.1b)
</pre>
|-
! Рис. 4.1: Тракт иллюстрирует идею слабого и сильного оператора
|}


{{Слабый временной оператор податливый, даже при <code>‘false</code>, а сильный временной оператор строгий, даже при <code>‘true</code>. Таким образом, утверждение 4.2а выполняется на тракте 4.2(i), потому что <code>‘false</code> трактуется, как что-то, что может случится в будущем, а утверждение 4.2b не выполняется на тракте 4.2(i), потому что <code>‘true</code> безусловно не трактуется.}}

{| align=center
! [[Файл:Psl fig4.2.png]]
|-
!(i) Утверждение 4.2a выполняется, но 4.2b нет
|-
|<pre>
assert always(a -> next[3] (‘false)); (4.2a)
assert always(a -> next![3] (‘true)); (4.2b)
</pre>
|-
! Рис. 4.2: Слабый временной оператор податливый, даже при <code>‘false</code>, 
а сильный временной оператор строгий, даже при <code>‘true</code>
|}


Ниже мы покажем семейства сильных операторов, в том же порядке, в котором в котором были представлены их слабые аналоги, а также контраст слабых и сильных версий.

=== 4.1 Оператор next! ===


Утверждение 4.3а показывает, что когда бы a не утверждался, b должен утвердиться в следующем цикле. Используя сильную версию оператора <code>next</code>, мы получим утверждение 4.3b, которое дополнительно требует ''be'' a в следующем цикле. Например, пока утверждение 4.3а выполняется на тракте 4.3(i), утверждение 4.3b нет, потому что, даже хотя <code>b</code> утверждается после первых двух утверждений <code>a</code>, тракт заканчивается слишком быстро по отношению к третьему утверждению <code>a</code>.

{| align=center
! [[Файл:Psl fig4.3.png]]
|-
! (i) Утверждение 4.3a выполняется, но 4.3b нет
|-
|<pre>
assert always (a -> next b); (4.3a)
assert always (a -> next! b); (4.3b)
</pre>
|-
! Рис. 4.3: слабый next против сильного next
|}

=== 4.2 Вариации на <code>next!</code>, включая <code>next_event!</code> ===



Сильный оператор <code>next_event!</code> связан с его слабой версией <code>next_event</code>, также как сильный оператор <code>next!</code> связан со своей слабой версией <code>next</code>. Например, утверждение 4.4b не выполняется на тракте 4.4(i), потому что не хватает грантов. Однако, слабая версия, утверждения 4.4а, не выполняется на том же тракте. Оператор <code>next![n]</code> позволяет вам показать, что как минимум <code>n</code> следующих циклов необходимы, и оператор <code>next_event!(b)[n]</code> позволяет вам показать, что как минимум <code>n</code> вхождений в булево событие <code>b</code> необходимы.

{| align=center
! [[Файл:Psl fig4.4.png]]
|-
! (i) Утверждение 4.4a выполняется, но 4.4b нет

|-
|<pre>
assert always (high_pri_req ->
next_event(gnt)(high_pri_ack)); (4.4a)
assert always (high_pri_req ->
next_event!(gnt)(high_pri_ack)); (4.4b)
</pre>
|-
! Рис. 4.4: Слабый <code>next_event</code> против сильного <code>next_event</code>
|}


Вы должны уже сейчас догадываться о значениях операторов <code>next_a![i:j]</code> и <code>next_event_a!(b)[i:j]</code>. Оператор <code>next_a![i:j]</code> выполняется, если существуют минимум ''j'' дополнительных циклов, и его операнд выполняется от ''i-го'' до ''j-ого'' включительно. Оператор <code>next_event_a!(b)[i:j]</code> выполняется, если существует минимум ''j'' дополнительных циклов, на которых выполняется <code>b</code>, и второй оператор выполняется на всех, от ''i-го'' до ''jth'', циклах включительно.


Оператор <code>next_e![i:j]</code> создает свойство, которое выполняется, если его операнд выполняется, как минимум, на одном цикле начиная с ''i-го'' заканчивая ''j-ым'', включительно. Необязательно должно быть ''j'' циклов, если операнд выполняется на некотором цикле между ''i-ым'' и ''j-ым''. Аналогично, оператор <code>next_event_e!(b)[i:j]</code> создает свойство, которое выполняется, если его второй операнд выполняется, как минимум, на одном вхождении в <code>b</code>, начиная от ''i-го'' и заканчивая ''j-ым''. Например, рассмотрим утверждение 4.5b, которое показывает, что запрос (утверждение <code>req</code>) должно быть предопределено (утверждение assertion of <code>ack</code>) на одном из следующих четырех грантах, и в дополнение, тракт не должен заканчиваться до того, как не появится соответствующий грант. Утверждение 4.5b не выполняется на тракте 4.5(i), потому что ни одни из трех показанных грантов не предопределен. Тот факт, что четвертый грант отсутствует неважен, не существует вариантов для четвертого гранта, которые могут изменить наше представление об предопределенности первого, второго и третьего грантов.


Слабая версия утверждения 4.5b выполняется на двух трактах 4.5(i) и Trace 4.5(ii). Существует только один вариант повлиять над слабой версией, показанной в утверждении 4.5a - если бы были четыре гранта, и не один из не был предопределен.

{| align=center
! [[Файл:Psl fig4.5.png]]
|-
|<pre>
assert always (req -> next_event_e(gnt)[1:4](ack)); (4.5a)
assert always (req -> next_event_e!(gnt)[1:4](ack)); (4.5b)
</pre>
|-
! Рис. 4.5: Слабый <code>next_event_e[i:j]</code> против сильного <code>next_event_e[i:j]</code>
|}

=== 4.3 Операторы until и until! ===


Ранее мы видели утверждения подобные утверждению 4.6a, который показывает, что когда бы не утверждался <code>a</code>, далее, начиная со следующего цикла, <code>b</code> должен утвердиться до утверждения <code>c</code>. Например, утверждения 4.6a выполняется в тракте 4.6(i). Но, что касается тракта, подробного Trace 4.6(ii), где <code>c</code> никогда не появляется? Выполняется утверждение 4.6a на тракте 4.6(ii) или нет? Оно выполняется. Суть в том, что оператор <code>until</code> - слабый оператор.


Если мы хотим выразить требования утверждения 4.6a, но в дополнение присутствует <code>c</code>, мы должны использовать сильный оператор. Утверждение 4.6b, которое использует сильный оператор, не выполняется в тракте 4.6(ii).


Оператор <code>until!_</code> сильная версия оператора <code>until_</code>. Оператор <code>until!_</code> выполняется только, если его левый операнд остается утвержденным до конца, ''включая'' цикл, где его правый операнд утвержден, и в дополнение его правый операнд выполняется в конечном итоге.

{| align=center
! [[Файл:Psl fig4.6.png]]
|-
|<pre>
assert always(a -> next (b until c)); (4.6a)
assert always(a -> next (b until! c)); (4.6b)
</pre>
|-
! Fig. 4.6: Сильный until против слабого until
|}

=== 4.4 операторы <code>before!</code> и <code>before!_</code> ===


Акцент, сильной версии оператора <code>before</code>, заключается в его лева-направленности операндов. Например, утверждения 4.7a показывает, что следуя утверждению <code>req</code>, утверждения <code>gnt</code> необходимо, чтобы <code>req</code> утверждался до этого, но будучи слабым выполняется не только в тракте 4.7(ii), но также на тракте 4.7(i), в котором после второго запроса ни грант, ни третий запрос не появляются. Сильная версия, показанная в утверждение 4.7b, требует появления гранта, но не обязательно, что был другой запрос. Таким образом, утверждения 4.7b не выполняется на тракте 4.7(i), но выполняется на 4.7(ii).

{| align=center
! [[Файл:Psl fig4.7.png]]
|-
|<pre>
assert always (req -> next (gnt before req)); (4.7a)
assert always (req -> next (gnt before! req)); (4.7b)
</pre>
|-
! Fig. 4.7: Слабый before против сильного before
|}


Оператор <code>before!_</code> сильная версия оператора <code>before_</code>. Таким образом, утверждение 4.8a выполняется на тракте 4.8(i), в котором первый запрос (утверждение сигнала <code>req</code>) предоставляется (утверждением сигнала <code>gnt</code>), но не второй. Сильная версия утверждения 4.8a, показанная в утверждении 4.8b, не выполняется на тракте Trace 4.8(i), потому что второй запрос не предоставляется. Оба утверждения 4.8а и 4.8b выполняются на тракте 4.8(ii).

{| align=center
! [[Файл:Psl fig4.8.png]]
|-
|<pre>
assert always (req -> next (gnt before_ req)); (4.8a)
assert always (req -> next (gnt before!_ req)); (4.8b)
</pre>
|-
! Fig. 4.8: Слабый <code>before_</code> против сильного <code>before_</code>
|}

=== 4.5 Операторы без слабых или сильных версий ===


Мы видели слабые и сильные версии многих операторов. Оператор <code>eventually!</code> не является сильной версий какого-либо оператора. Другими словами, не существует слабой версии <code>eventually!</code>. Смысл в том, что значение другого сильного оператора может быть широко описано, как требование того, чтобы ничего непредвиденного не должно случиться пока не появится условие прекращения, и в дополнении, в конечном счете условие окончание должно выполниться. Слабая версия далее отказывает требованию, что условие окончание выполнено, оставляя только требование, что ничего не предвиденного не произошло. Оператор <code>eventually!</code>, однако, не содержит идею “чего-либо” непредвиденного, только условия окончания. Более того, не существует вариантов ослабления оператора, без освобождения его значения.


Так как нету слабой версии оператора <code>eventually!</code>, нету сильной версии операторов <code>always</code> и <code>never</code>, для противоположного смысла. В случаи <code>always</code> и <code>never</code>, не существует условия окончания.

PSL/A Practical Introduction to PSL/Weak vs. Strong Temporal Operators

2013-12-30T17:39:01Z

Valentin: /* 4.4 The before! and before!_ operators */

{{PSL TOC}}

== Слабые временные операторы против сильных временных операторов ==


Временные операторы могут быть ''слабыми'' или ''сильными''. Сильны временной оператор, такой как <code>eventually!</code> показан восклицательным знаком, как частью своего имени. Оператор без восклицательного , такой как <code>next</code>, слабый. До этого времени мы видели только по одной версии каждого оператора, но много операторов, которых мы видели до того, могут иметь слабую и сильную версии. Различие между слабыми и сильными операторами очень важны, когда путь “слишком короткий”, чтобы определить, действительно все ли произошло для удовлетворения свойства. 1 Например, рассматривая спецификацию “каждое утверждения сигнала a должно происходить на три цикла раньше утверждения сигнала <code>b</code>” на тракте 4.1(i). Выполняется спецификация или нет? Утверждение сигнала a в цикле 2 удовлетворяется утверждением сигнала b на цикле 5. Но, что можно сказать про утверждение сигнала a на цикле 9? Это предполагает утверждение сигнала b на цикле 12, но тракт заканчивает до достижения 12-го цикла. Слабые и сильные временные операторы позволяют нам различать случаи, в которых мы можем сказать,что наша спецификация выполняется на тракте 4.1(i), и в которых мы можем сказать, что она не выполняется.


<blockquote>1 - В этой главе мы рассмотрим конечные пути, т.к. как они выглядят с точки зрения моделирования. Для бесконечных путях, т.к. они представлены в формальной верификации, также существует разница между слабыми и сильными операторами. Это мы обсудим в главе 11.</blockquote>


Слабы временной оператор податливый - в случаи, когда тракт заканчивается “слишком быстро”, свойство, использующее слабый оператор, будет выполнятся до тех пор, пока что-нибудь не пойдет ни так. Если бы мы продолжили ход верификации в тракте 4.1(i) еще на несколько циклов, мы могли бы обнаружить, что сигнал b утверждается в цикле 12. Такое ''может'' случится. Таким образом, утверждение 4.1а, которое использует слабый оператор next, выполняется в тракте 4.1(i).


Сильный оператор строгий - в случаи, когда тракт заканчивается “слишком быстро”, свойство, использующее сильный оператор, не будет выполняться, даже если ничего плохого не происходит. Не существует пути узнать, что бы случилось, если бы мы продолжили ход верификации, показанный в тракте 4.1(i), еще несколько циклов, и мы не можем сказать, что свойство выполняется, не имея всей информации. Таким образом, утверждение 4.1b, которое использует сильный оператор <code>next!</code>, не выполняется на тракте 4.1(i).

{| align=center
! [[Файл:Psl fig4.1.png]]
|-
!(i) Утверждение 4.1a выполняется, but 4.1b не выполняется
|-
|<pre>
assert always(a -> next[3] (b)); (4.1a)
assert always(a -> next![3] (b)); (4.1b)
</pre>
|-
! Рис. 4.1: Тракт иллюстрирует идею слабого и сильного оператора
|}


{{Слабый временной оператор податливый, даже при <code>‘false</code>, а сильный временной оператор строгий, даже при <code>‘true</code>. Таким образом, утверждение 4.2а выполняется на тракте 4.2(i), потому что <code>‘false</code> трактуется, как что-то, что может случится в будущем, а утверждение 4.2b не выполняется на тракте 4.2(i), потому что <code>‘true</code> безусловно не трактуется.}}

{| align=center
! [[Файл:Psl fig4.2.png]]
|-
!(i) Утверждение 4.2a выполняется, но 4.2b нет
|-
|<pre>
assert always(a -> next[3] (‘false)); (4.2a)
assert always(a -> next![3] (‘true)); (4.2b)
</pre>
|-
! Рис. 4.2: Слабый временной оператор податливый, даже при <code>‘false</code>, 
а сильный временной оператор строгий, даже при <code>‘true</code>
|}


Ниже мы покажем семейства сильных операторов, в том же порядке, в котором в котором были представлены их слабые аналоги, а также контраст слабых и сильных версий.

=== 4.1 Оператор next! ===


Утверждение 4.3а показывает, что когда бы a не утверждался, b должен утвердиться в следующем цикле. Используя сильную версию оператора <code>next</code>, мы получим утверждение 4.3b, которое дополнительно требует ''be'' a в следующем цикле. Например, пока утверждение 4.3а выполняется на тракте 4.3(i), утверждение 4.3b нет, потому что, даже хотя <code>b</code> утверждается после первых двух утверждений <code>a</code>, тракт заканчивается слишком быстро по отношению к третьему утверждению <code>a</code>.

{| align=center
! [[Файл:Psl fig4.3.png]]
|-
! (i) Утверждение 4.3a выполняется, но 4.3b нет
|-
|<pre>
assert always (a -> next b); (4.3a)
assert always (a -> next! b); (4.3b)
</pre>
|-
! Рис. 4.3: слабый next против сильного next
|}

=== 4.2 Вариации на <code>next!</code>, включая <code>next_event!</code> ===



Сильный оператор <code>next_event!</code> связан с его слабой версией <code>next_event</code>, также как сильный оператор <code>next!</code> связан со своей слабой версией <code>next</code>. Например, утверждение 4.4b не выполняется на тракте 4.4(i), потому что не хватает грантов. Однако, слабая версия, утверждения 4.4а, не выполняется на том же тракте. Оператор <code>next![n]</code> позволяет вам показать, что как минимум <code>n</code> следующих циклов необходимы, и оператор <code>next_event!(b)[n]</code> позволяет вам показать, что как минимум <code>n</code> вхождений в булево событие <code>b</code> необходимы.

{| align=center
! [[Файл:Psl fig4.4.png]]
|-
! (i) Утверждение 4.4a выполняется, но 4.4b нет

|-
|<pre>
assert always (high_pri_req ->
next_event(gnt)(high_pri_ack)); (4.4a)
assert always (high_pri_req ->
next_event!(gnt)(high_pri_ack)); (4.4b)
</pre>
|-
! Рис. 4.4: Слабый <code>next_event</code> против сильного <code>next_event</code>
|}


Вы должны уже сейчас догадываться о значениях операторов <code>next_a![i:j]</code> и <code>next_event_a!(b)[i:j]</code>. Оператор <code>next_a![i:j]</code> выполняется, если существуют минимум ''j'' дополнительных циклов, и его операнд выполняется от ''i-го'' до ''j-ого'' включительно. Оператор <code>next_event_a!(b)[i:j]</code> выполняется, если существует минимум ''j'' дополнительных циклов, на которых выполняется <code>b</code>, и второй оператор выполняется на всех, от ''i-го'' до ''jth'', циклах включительно.


Оператор <code>next_e![i:j]</code> создает свойство, которое выполняется, если его операнд выполняется, как минимум, на одном цикле начиная с ''i-го'' заканчивая ''j-ым'', включительно. Необязательно должно быть ''j'' циклов, если операнд выполняется на некотором цикле между ''i-ым'' и ''j-ым''. Аналогично, оператор <code>next_event_e!(b)[i:j]</code> создает свойство, которое выполняется, если его второй операнд выполняется, как минимум, на одном вхождении в <code>b</code>, начиная от ''i-го'' и заканчивая ''j-ым''. Например, рассмотрим утверждение 4.5b, которое показывает, что запрос (утверждение <code>req</code>) должно быть предопределено (утверждение assertion of <code>ack</code>) на одном из следующих четырех грантах, и в дополнение, тракт не должен заканчиваться до того, как не появится соответствующий грант. Утверждение 4.5b не выполняется на тракте 4.5(i), потому что ни одни из трех показанных грантов не предопределен. Тот факт, что четвертый грант отсутствует неважен, не существует вариантов для четвертого гранта, которые могут изменить наше представление об предопределенности первого, второго и третьего грантов.


Слабая версия утверждения 4.5b выполняется на двух трактах 4.5(i) и Trace 4.5(ii). Существует только один вариант повлиять над слабой версией, показанной в утверждении 4.5a - если бы были четыре гранта, и не один из не был предопределен.

{| align=center
! [[Файл:Psl fig4.5.png]]
|-
|<pre>
assert always (req -> next_event_e(gnt)[1:4](ack)); (4.5a)
assert always (req -> next_event_e!(gnt)[1:4](ack)); (4.5b)
</pre>
|-
! Рис. 4.5: Слабый <code>next_event_e[i:j]</code> против сильного <code>next_event_e[i:j]</code>
|}

=== 4.3 Операторы until и until! ===


Ранее мы видели утверждения подобные утверждению 4.6a, который показывает, что когда бы не утверждался <code>a</code>, далее, начиная со следующего цикла, <code>b</code> должен утвердиться до утверждения <code>c</code>. Например, утверждения 4.6a выполняется в тракте 4.6(i). Но, что касается тракта, подробного Trace 4.6(ii), где <code>c</code> никогда не появляется? Выполняется утверждение 4.6a на тракте 4.6(ii) или нет? Оно выполняется. Суть в том, что оператор <code>until</code> - слабый оператор.


Если мы хотим выразить требования утверждения 4.6a, но в дополнение присутствует <code>c</code>, мы должны использовать сильный оператор. Утверждение 4.6b, которое использует сильный оператор, не выполняется в тракте 4.6(ii).


Оператор <code>until!_</code> сильная версия оператора <code>until_</code>. Оператор <code>until!_</code> выполняется только, если его левый операнд остается утвержденным до конца, ''включая'' цикл, где его правый операнд утвержден, и в дополнение его правый операнд выполняется в конечном итоге.

{| align=center
! [[Файл:Psl fig4.6.png]]
|-
|<pre>
assert always(a -> next (b until c)); (4.6a)
assert always(a -> next (b until! c)); (4.6b)
</pre>
|-
! Fig. 4.6: Сильный until против слабого until
|}

=== 4.4 операторы <code>before!</code> и <code>before!_</code> ===


Акцент, сильной версии оператора <code>before</code>, заключается в его лева-направленности операндов. Например, утверждения 4.7a показывает, что следуя утверждению <code>req</code>, утверждения <code>gnt</code> необходимо, чтобы <code>req</code> утверждался до этого, но будучи слабым выполняется не только в тракте 4.7(ii), но также на тракте 4.7(i), в котором после второго запроса ни грант, ни третий запрос не появляются. Сильная версия, показанная в утверждение 4.7b, требует появления гранта, но не обязательно, что был другой запрос. Таким образом, утверждения 4.7b не выполняется на тракте 4.7(i), но выполняется на 4.7(ii).

{| align=center
! [[Файл:Psl fig4.7.png]]
|-
|<pre>
assert always (req -> next (gnt before req)); (4.7a)
assert always (req -> next (gnt before! req)); (4.7b)
</pre>
|-
! Fig. 4.7: Слабый before против сильного before
|}


Оператор <code>before!_</code> сильная версия оператора <code>before_</code>. Таким образом, утверждение 4.8a выполняется на тракте 4.8(i), в котором первый запрос (утверждение сигнала <code>req</code>) предоставляется (утверждением сигнала <code>gnt</code>), но не второй. Сильная версия утверждения 4.8a, показанная в утверждении 4.8b, не выполняется на тракте Trace 4.8(i), потому что второй запрос не предоставляется. Оба утверждения 4.8а и 4.8b выполняются на тракте 4.8(ii).

{| align=center
! [[Файл:Psl fig4.8.png]]
|-
|<pre>
assert always (req -> next (gnt before_ req)); (4.8a)
assert always (req -> next (gnt before!_ req)); (4.8b)
</pre>
|-
! Fig. 4.8: Слабый <code>before_</code> против сильного <code>before_</code>
|}

=== 4.5 Operators without weak or strong versions ===

We have seen weak and strong versions of many operators. The <code>eventually!</code>
operator is not a strong version of some other operator. In other words, there
is no weak version of <code>eventually!</code>. The reason is that the meaning of other
strong operators can be broadly described as requiring that nothing bad must
happen up until some terminating condition, and in addition, the terminating condition must eventually occur. The weak versions then waive the requirement that the terminating condition eventually occur, leaving only the requirement that nothing bad must happen. The <code>eventually!</code> operator, however, contains no idea of a bad “something”, only a terminating condition.
Therefore, there is no way to weaken it without emptying it completely of
meaning.

Just as there is no weak version of <code>eventually!</code>, there is no strong version
of the operators <code>always</code> and <code>never</code>, for the opposite reason. In the case of
<code>always</code> and <code>never</code>, there is no terminating condition to waive.

PSL/A Practical Introduction to PSL/Weak vs. Strong Temporal Operators

2013-12-30T17:18:18Z

Valentin: /* 4.3 The until! and until! operators */

{{PSL TOC}}

== Слабые временные операторы против сильных временных операторов ==


Временные операторы могут быть ''слабыми'' или ''сильными''. Сильны временной оператор, такой как <code>eventually!</code> показан восклицательным знаком, как частью своего имени. Оператор без восклицательного , такой как <code>next</code>, слабый. До этого времени мы видели только по одной версии каждого оператора, но много операторов, которых мы видели до того, могут иметь слабую и сильную версии. Различие между слабыми и сильными операторами очень важны, когда путь “слишком короткий”, чтобы определить, действительно все ли произошло для удовлетворения свойства. 1 Например, рассматривая спецификацию “каждое утверждения сигнала a должно происходить на три цикла раньше утверждения сигнала <code>b</code>” на тракте 4.1(i). Выполняется спецификация или нет? Утверждение сигнала a в цикле 2 удовлетворяется утверждением сигнала b на цикле 5. Но, что можно сказать про утверждение сигнала a на цикле 9? Это предполагает утверждение сигнала b на цикле 12, но тракт заканчивает до достижения 12-го цикла. Слабые и сильные временные операторы позволяют нам различать случаи, в которых мы можем сказать,что наша спецификация выполняется на тракте 4.1(i), и в которых мы можем сказать, что она не выполняется.


<blockquote>1 - В этой главе мы рассмотрим конечные пути, т.к. как они выглядят с точки зрения моделирования. Для бесконечных путях, т.к. они представлены в формальной верификации, также существует разница между слабыми и сильными операторами. Это мы обсудим в главе 11.</blockquote>


Слабы временной оператор податливый - в случаи, когда тракт заканчивается “слишком быстро”, свойство, использующее слабый оператор, будет выполнятся до тех пор, пока что-нибудь не пойдет ни так. Если бы мы продолжили ход верификации в тракте 4.1(i) еще на несколько циклов, мы могли бы обнаружить, что сигнал b утверждается в цикле 12. Такое ''может'' случится. Таким образом, утверждение 4.1а, которое использует слабый оператор next, выполняется в тракте 4.1(i).


Сильный оператор строгий - в случаи, когда тракт заканчивается “слишком быстро”, свойство, использующее сильный оператор, не будет выполняться, даже если ничего плохого не происходит. Не существует пути узнать, что бы случилось, если бы мы продолжили ход верификации, показанный в тракте 4.1(i), еще несколько циклов, и мы не можем сказать, что свойство выполняется, не имея всей информации. Таким образом, утверждение 4.1b, которое использует сильный оператор <code>next!</code>, не выполняется на тракте 4.1(i).

{| align=center
! [[Файл:Psl fig4.1.png]]
|-
!(i) Утверждение 4.1a выполняется, but 4.1b не выполняется
|-
|<pre>
assert always(a -> next[3] (b)); (4.1a)
assert always(a -> next![3] (b)); (4.1b)
</pre>
|-
! Рис. 4.1: Тракт иллюстрирует идею слабого и сильного оператора
|}


{{Слабый временной оператор податливый, даже при <code>‘false</code>, а сильный временной оператор строгий, даже при <code>‘true</code>. Таким образом, утверждение 4.2а выполняется на тракте 4.2(i), потому что <code>‘false</code> трактуется, как что-то, что может случится в будущем, а утверждение 4.2b не выполняется на тракте 4.2(i), потому что <code>‘true</code> безусловно не трактуется.}}

{| align=center
! [[Файл:Psl fig4.2.png]]
|-
!(i) Утверждение 4.2a выполняется, но 4.2b нет
|-
|<pre>
assert always(a -> next[3] (‘false)); (4.2a)
assert always(a -> next![3] (‘true)); (4.2b)
</pre>
|-
! Рис. 4.2: Слабый временной оператор податливый, даже при <code>‘false</code>, 
а сильный временной оператор строгий, даже при <code>‘true</code>
|}


Ниже мы покажем семейства сильных операторов, в том же порядке, в котором в котором были представлены их слабые аналоги, а также контраст слабых и сильных версий.

=== 4.1 Оператор next! ===


Утверждение 4.3а показывает, что когда бы a не утверждался, b должен утвердиться в следующем цикле. Используя сильную версию оператора <code>next</code>, мы получим утверждение 4.3b, которое дополнительно требует ''be'' a в следующем цикле. Например, пока утверждение 4.3а выполняется на тракте 4.3(i), утверждение 4.3b нет, потому что, даже хотя <code>b</code> утверждается после первых двух утверждений <code>a</code>, тракт заканчивается слишком быстро по отношению к третьему утверждению <code>a</code>.

{| align=center
! [[Файл:Psl fig4.3.png]]
|-
! (i) Утверждение 4.3a выполняется, но 4.3b нет
|-
|<pre>
assert always (a -> next b); (4.3a)
assert always (a -> next! b); (4.3b)
</pre>
|-
! Рис. 4.3: слабый next против сильного next
|}

=== 4.2 Вариации на <code>next!</code>, включая <code>next_event!</code> ===



Сильный оператор <code>next_event!</code> связан с его слабой версией <code>next_event</code>, также как сильный оператор <code>next!</code> связан со своей слабой версией <code>next</code>. Например, утверждение 4.4b не выполняется на тракте 4.4(i), потому что не хватает грантов. Однако, слабая версия, утверждения 4.4а, не выполняется на том же тракте. Оператор <code>next![n]</code> позволяет вам показать, что как минимум <code>n</code> следующих циклов необходимы, и оператор <code>next_event!(b)[n]</code> позволяет вам показать, что как минимум <code>n</code> вхождений в булево событие <code>b</code> необходимы.

{| align=center
! [[Файл:Psl fig4.4.png]]
|-
! (i) Утверждение 4.4a выполняется, но 4.4b нет

|-
|<pre>
assert always (high_pri_req ->
next_event(gnt)(high_pri_ack)); (4.4a)
assert always (high_pri_req ->
next_event!(gnt)(high_pri_ack)); (4.4b)
</pre>
|-
! Рис. 4.4: Слабый <code>next_event</code> против сильного <code>next_event</code>
|}


Вы должны уже сейчас догадываться о значениях операторов <code>next_a![i:j]</code> и <code>next_event_a!(b)[i:j]</code>. Оператор <code>next_a![i:j]</code> выполняется, если существуют минимум ''j'' дополнительных циклов, и его операнд выполняется от ''i-го'' до ''j-ого'' включительно. Оператор <code>next_event_a!(b)[i:j]</code> выполняется, если существует минимум ''j'' дополнительных циклов, на которых выполняется <code>b</code>, и второй оператор выполняется на всех, от ''i-го'' до ''jth'', циклах включительно.


Оператор <code>next_e![i:j]</code> создает свойство, которое выполняется, если его операнд выполняется, как минимум, на одном цикле начиная с ''i-го'' заканчивая ''j-ым'', включительно. Необязательно должно быть ''j'' циклов, если операнд выполняется на некотором цикле между ''i-ым'' и ''j-ым''. Аналогично, оператор <code>next_event_e!(b)[i:j]</code> создает свойство, которое выполняется, если его второй операнд выполняется, как минимум, на одном вхождении в <code>b</code>, начиная от ''i-го'' и заканчивая ''j-ым''. Например, рассмотрим утверждение 4.5b, которое показывает, что запрос (утверждение <code>req</code>) должно быть предопределено (утверждение assertion of <code>ack</code>) на одном из следующих четырех грантах, и в дополнение, тракт не должен заканчиваться до того, как не появится соответствующий грант. Утверждение 4.5b не выполняется на тракте 4.5(i), потому что ни одни из трех показанных грантов не предопределен. Тот факт, что четвертый грант отсутствует неважен, не существует вариантов для четвертого гранта, которые могут изменить наше представление об предопределенности первого, второго и третьего грантов.


Слабая версия утверждения 4.5b выполняется на двух трактах 4.5(i) и Trace 4.5(ii). Существует только один вариант повлиять над слабой версией, показанной в утверждении 4.5a - если бы были четыре гранта, и не один из не был предопределен.

{| align=center
! [[Файл:Psl fig4.5.png]]
|-
|<pre>
assert always (req -> next_event_e(gnt)[1:4](ack)); (4.5a)
assert always (req -> next_event_e!(gnt)[1:4](ack)); (4.5b)
</pre>
|-
! Рис. 4.5: Слабый <code>next_event_e[i:j]</code> против сильного <code>next_event_e[i:j]</code>
|}

=== 4.3 Операторы until и until! ===


Ранее мы видели утверждения подобные утверждению 4.6a, который показывает, что когда бы не утверждался <code>a</code>, далее, начиная со следующего цикла, <code>b</code> должен утвердиться до утверждения <code>c</code>. Например, утверждения 4.6a выполняется в тракте 4.6(i). Но, что касается тракта, подробного Trace 4.6(ii), где <code>c</code> никогда не появляется? Выполняется утверждение 4.6a на тракте 4.6(ii) или нет? Оно выполняется. Суть в том, что оператор <code>until</code> - слабый оператор.


Если мы хотим выразить требования утверждения 4.6a, но в дополнение присутствует <code>c</code>, мы должны использовать сильный оператор. Утверждение 4.6b, которое использует сильный оператор, не выполняется в тракте 4.6(ii).


Оператор <code>until!_</code> сильная версия оператора <code>until_</code>. Оператор <code>until!_</code> выполняется только, если его левый операнд остается утвержденным до конца, ''включая'' цикл, где его правый операнд утвержден, и в дополнение его правый операнд выполняется в конечном итоге.

{| align=center
! [[Файл:Psl fig4.6.png]]
|-
|<pre>
assert always(a -> next (b until c)); (4.6a)
assert always(a -> next (b until! c)); (4.6b)
</pre>
|-
! Fig. 4.6: Сильный until против слабого until
|}

=== 4.4 The <code>before!</code> and <code>before!_</code> operators ===

The emphasis of the strong versions of the <code>before</code> operators is on their lefthand operand. For example, Assertion 4.7a states that following an assertion
of <code>req</code>, an assertion of <code>gnt</code> is required before <code>req</code> can be asserted again, but
being weak holds not only on Trace 4.7(ii), but also on Trace 4.7(i), in which
after the second request neither a grant nor a third request ever arrives. The
strong version, shown in Assertion 4.7b, requires that a grant eventually be
given, but not necessarily that another request be seen. Thus, Assertion 4.7b
does not hold on Trace 4.7(i), but holds on Trace 4.7(ii).

{| align=center
! [[Файл:Psl fig4.7.png]]
|-
|<pre>
assert always (req -> next (gnt before req)); (4.7a)
assert always (req -> next (gnt before! req)); (4.7b)
</pre>
|-
! Fig. 4.7: Weak vs. strong before
|}

The <code>before!_</code> operator is the strong version of the <code>before_</code> operator. Thus,
Assertion 4.8a holds on Trace 4.8(i), in which the first request (assertion of
signal <code>req</code>) is granted (assertion of signal <code>gnt</code>) but the second is not. The
strong version of Assertion 4.8a, shown in Assertion 4.8b, does not hold on
Trace 4.8(i) because the second request is not granted. Both Assertion 4.8a
and 4.8b hold on Trace 4.8(ii).

{| align=center
! [[Файл:Psl fig4.8.png]]
|-
|<pre>
assert always (req -> next (gnt before_ req)); (4.8a)
assert always (req -> next (gnt before!_ req)); (4.8b)
</pre>
|-
! Fig. 4.8: Weak vs. strong <code>before_</code>
|}

=== 4.5 Operators without weak or strong versions ===

We have seen weak and strong versions of many operators. The <code>eventually!</code>
operator is not a strong version of some other operator. In other words, there
is no weak version of <code>eventually!</code>. The reason is that the meaning of other
strong operators can be broadly described as requiring that nothing bad must
happen up until some terminating condition, and in addition, the terminating condition must eventually occur. The weak versions then waive the requirement that the terminating condition eventually occur, leaving only the requirement that nothing bad must happen. The <code>eventually!</code> operator, however, contains no idea of a bad “something”, only a terminating condition.
Therefore, there is no way to weaken it without emptying it completely of
meaning.

Just as there is no weak version of <code>eventually!</code>, there is no strong version
of the operators <code>always</code> and <code>never</code>, for the opposite reason. In the case of
<code>always</code> and <code>never</code>, there is no terminating condition to waive.

PSL/A Practical Introduction to PSL/Weak vs. Strong Temporal Operators

2013-12-30T16:52:47Z

Valentin: /* 4.2 Вариации на next!, включая next_event! */

{{PSL TOC}}

== Слабые временные операторы против сильных временных операторов ==


Временные операторы могут быть ''слабыми'' или ''сильными''. Сильны временной оператор, такой как <code>eventually!</code> показан восклицательным знаком, как частью своего имени. Оператор без восклицательного , такой как <code>next</code>, слабый. До этого времени мы видели только по одной версии каждого оператора, но много операторов, которых мы видели до того, могут иметь слабую и сильную версии. Различие между слабыми и сильными операторами очень важны, когда путь “слишком короткий”, чтобы определить, действительно все ли произошло для удовлетворения свойства. 1 Например, рассматривая спецификацию “каждое утверждения сигнала a должно происходить на три цикла раньше утверждения сигнала <code>b</code>” на тракте 4.1(i). Выполняется спецификация или нет? Утверждение сигнала a в цикле 2 удовлетворяется утверждением сигнала b на цикле 5. Но, что можно сказать про утверждение сигнала a на цикле 9? Это предполагает утверждение сигнала b на цикле 12, но тракт заканчивает до достижения 12-го цикла. Слабые и сильные временные операторы позволяют нам различать случаи, в которых мы можем сказать,что наша спецификация выполняется на тракте 4.1(i), и в которых мы можем сказать, что она не выполняется.


<blockquote>1 - В этой главе мы рассмотрим конечные пути, т.к. как они выглядят с точки зрения моделирования. Для бесконечных путях, т.к. они представлены в формальной верификации, также существует разница между слабыми и сильными операторами. Это мы обсудим в главе 11.</blockquote>


Слабы временной оператор податливый - в случаи, когда тракт заканчивается “слишком быстро”, свойство, использующее слабый оператор, будет выполнятся до тех пор, пока что-нибудь не пойдет ни так. Если бы мы продолжили ход верификации в тракте 4.1(i) еще на несколько циклов, мы могли бы обнаружить, что сигнал b утверждается в цикле 12. Такое ''может'' случится. Таким образом, утверждение 4.1а, которое использует слабый оператор next, выполняется в тракте 4.1(i).


Сильный оператор строгий - в случаи, когда тракт заканчивается “слишком быстро”, свойство, использующее сильный оператор, не будет выполняться, даже если ничего плохого не происходит. Не существует пути узнать, что бы случилось, если бы мы продолжили ход верификации, показанный в тракте 4.1(i), еще несколько циклов, и мы не можем сказать, что свойство выполняется, не имея всей информации. Таким образом, утверждение 4.1b, которое использует сильный оператор <code>next!</code>, не выполняется на тракте 4.1(i).

{| align=center
! [[Файл:Psl fig4.1.png]]
|-
!(i) Утверждение 4.1a выполняется, but 4.1b не выполняется
|-
|<pre>
assert always(a -> next[3] (b)); (4.1a)
assert always(a -> next![3] (b)); (4.1b)
</pre>
|-
! Рис. 4.1: Тракт иллюстрирует идею слабого и сильного оператора
|}


{{Слабый временной оператор податливый, даже при <code>‘false</code>, а сильный временной оператор строгий, даже при <code>‘true</code>. Таким образом, утверждение 4.2а выполняется на тракте 4.2(i), потому что <code>‘false</code> трактуется, как что-то, что может случится в будущем, а утверждение 4.2b не выполняется на тракте 4.2(i), потому что <code>‘true</code> безусловно не трактуется.}}

{| align=center
! [[Файл:Psl fig4.2.png]]
|-
!(i) Утверждение 4.2a выполняется, но 4.2b нет
|-
|<pre>
assert always(a -> next[3] (‘false)); (4.2a)
assert always(a -> next![3] (‘true)); (4.2b)
</pre>
|-
! Рис. 4.2: Слабый временной оператор податливый, даже при <code>‘false</code>, 
а сильный временной оператор строгий, даже при <code>‘true</code>
|}


Ниже мы покажем семейства сильных операторов, в том же порядке, в котором в котором были представлены их слабые аналоги, а также контраст слабых и сильных версий.

=== 4.1 Оператор next! ===


Утверждение 4.3а показывает, что когда бы a не утверждался, b должен утвердиться в следующем цикле. Используя сильную версию оператора <code>next</code>, мы получим утверждение 4.3b, которое дополнительно требует ''be'' a в следующем цикле. Например, пока утверждение 4.3а выполняется на тракте 4.3(i), утверждение 4.3b нет, потому что, даже хотя <code>b</code> утверждается после первых двух утверждений <code>a</code>, тракт заканчивается слишком быстро по отношению к третьему утверждению <code>a</code>.

{| align=center
! [[Файл:Psl fig4.3.png]]
|-
! (i) Утверждение 4.3a выполняется, но 4.3b нет
|-
|<pre>
assert always (a -> next b); (4.3a)
assert always (a -> next! b); (4.3b)
</pre>
|-
! Рис. 4.3: слабый next против сильного next
|}

=== 4.2 Вариации на <code>next!</code>, включая <code>next_event!</code> ===



Сильный оператор <code>next_event!</code> связан с его слабой версией <code>next_event</code>, также как сильный оператор <code>next!</code> связан со своей слабой версией <code>next</code>. Например, утверждение 4.4b не выполняется на тракте 4.4(i), потому что не хватает грантов. Однако, слабая версия, утверждения 4.4а, не выполняется на том же тракте. Оператор <code>next![n]</code> позволяет вам показать, что как минимум <code>n</code> следующих циклов необходимы, и оператор <code>next_event!(b)[n]</code> позволяет вам показать, что как минимум <code>n</code> вхождений в булево событие <code>b</code> необходимы.

{| align=center
! [[Файл:Psl fig4.4.png]]
|-
! (i) Утверждение 4.4a выполняется, но 4.4b нет

|-
|<pre>
assert always (high_pri_req ->
next_event(gnt)(high_pri_ack)); (4.4a)
assert always (high_pri_req ->
next_event!(gnt)(high_pri_ack)); (4.4b)
</pre>
|-
! Рис. 4.4: Слабый <code>next_event</code> против сильного <code>next_event</code>
|}


Вы должны уже сейчас догадываться о значениях операторов <code>next_a![i:j]</code> и <code>next_event_a!(b)[i:j]</code>. Оператор <code>next_a![i:j]</code> выполняется, если существуют минимум ''j'' дополнительных циклов, и его операнд выполняется от ''i-го'' до ''j-ого'' включительно. Оператор <code>next_event_a!(b)[i:j]</code> выполняется, если существует минимум ''j'' дополнительных циклов, на которых выполняется <code>b</code>, и второй оператор выполняется на всех, от ''i-го'' до ''jth'', циклах включительно.


Оператор <code>next_e![i:j]</code> создает свойство, которое выполняется, если его операнд выполняется, как минимум, на одном цикле начиная с ''i-го'' заканчивая ''j-ым'', включительно. Необязательно должно быть ''j'' циклов, если операнд выполняется на некотором цикле между ''i-ым'' и ''j-ым''. Аналогично, оператор <code>next_event_e!(b)[i:j]</code> создает свойство, которое выполняется, если его второй операнд выполняется, как минимум, на одном вхождении в <code>b</code>, начиная от ''i-го'' и заканчивая ''j-ым''. Например, рассмотрим утверждение 4.5b, которое показывает, что запрос (утверждение <code>req</code>) должно быть предопределено (утверждение assertion of <code>ack</code>) на одном из следующих четырех грантах, и в дополнение, тракт не должен заканчиваться до того, как не появится соответствующий грант. Утверждение 4.5b не выполняется на тракте 4.5(i), потому что ни одни из трех показанных грантов не предопределен. Тот факт, что четвертый грант отсутствует неважен, не существует вариантов для четвертого гранта, которые могут изменить наше представление об предопределенности первого, второго и третьего грантов.


Слабая версия утверждения 4.5b выполняется на двух трактах 4.5(i) и Trace 4.5(ii). Существует только один вариант повлиять над слабой версией, показанной в утверждении 4.5a - если бы были четыре гранта, и не один из не был предопределен.

{| align=center
! [[Файл:Psl fig4.5.png]]
|-
|<pre>
assert always (req -> next_event_e(gnt)[1:4](ack)); (4.5a)
assert always (req -> next_event_e!(gnt)[1:4](ack)); (4.5b)
</pre>
|-
! Рис. 4.5: Слабый <code>next_event_e[i:j]</code> против сильного <code>next_event_e[i:j]</code>
|}

=== 4.3 The until! and until! operators ===

We have previously seen assertions like Assertion 4.6a, which states that whenever <code>a</code> is asserted, then starting the next cycle <code>b</code> should be asserted until <code>c</code> is
asserted. For example, Assertion 4.6a holds on Trace 4.6(i). But what about
a trace like that shown in Trace 4.6(ii), where <code>c</code> never arrives? Does Assertion 4.6a hold on Trace 4.6(ii) or not? It does. The reason is that the <code>until</code>
operator is a weak operator.

If we want to express the requirement of Assertion 4.6a, but in addition
insist that <code>c</code> eventually occur, we need to use a strong operator. Assertion 4.6b,
which uses a strong operator, does not hold on Trace 4.6(ii).

The <code>until!_</code> operator is the strong version of the <code>until_</code> operator. The
<code>until!_</code> operator holds only if its left operand stays asserted up to and ''including''
the cycle where its right operand is asserted, and in addition its right
operand eventually holds.

{| align=center
! [[Файл:Psl fig4.6.png]]
|-
|<pre>
assert always(a -> next (b until c)); (4.6a)
assert always(a -> next (b until! c)); (4.6b)
</pre>
|-
! Fig. 4.6: Weak vs. strong until
|}

=== 4.4 The <code>before!</code> and <code>before!_</code> operators ===

The emphasis of the strong versions of the <code>before</code> operators is on their lefthand operand. For example, Assertion 4.7a states that following an assertion
of <code>req</code>, an assertion of <code>gnt</code> is required before <code>req</code> can be asserted again, but
being weak holds not only on Trace 4.7(ii), but also on Trace 4.7(i), in which
after the second request neither a grant nor a third request ever arrives. The
strong version, shown in Assertion 4.7b, requires that a grant eventually be
given, but not necessarily that another request be seen. Thus, Assertion 4.7b
does not hold on Trace 4.7(i), but holds on Trace 4.7(ii).

{| align=center
! [[Файл:Psl fig4.7.png]]
|-
|<pre>
assert always (req -> next (gnt before req)); (4.7a)
assert always (req -> next (gnt before! req)); (4.7b)
</pre>
|-
! Fig. 4.7: Weak vs. strong before
|}

The <code>before!_</code> operator is the strong version of the <code>before_</code> operator. Thus,
Assertion 4.8a holds on Trace 4.8(i), in which the first request (assertion of
signal <code>req</code>) is granted (assertion of signal <code>gnt</code>) but the second is not. The
strong version of Assertion 4.8a, shown in Assertion 4.8b, does not hold on
Trace 4.8(i) because the second request is not granted. Both Assertion 4.8a
and 4.8b hold on Trace 4.8(ii).

{| align=center
! [[Файл:Psl fig4.8.png]]
|-
|<pre>
assert always (req -> next (gnt before_ req)); (4.8a)
assert always (req -> next (gnt before!_ req)); (4.8b)
</pre>
|-
! Fig. 4.8: Weak vs. strong <code>before_</code>
|}

=== 4.5 Operators without weak or strong versions ===

We have seen weak and strong versions of many operators. The <code>eventually!</code>
operator is not a strong version of some other operator. In other words, there
is no weak version of <code>eventually!</code>. The reason is that the meaning of other
strong operators can be broadly described as requiring that nothing bad must
happen up until some terminating condition, and in addition, the terminating condition must eventually occur. The weak versions then waive the requirement that the terminating condition eventually occur, leaving only the requirement that nothing bad must happen. The <code>eventually!</code> operator, however, contains no idea of a bad “something”, only a terminating condition.
Therefore, there is no way to weaken it without emptying it completely of
meaning.

Just as there is no weak version of <code>eventually!</code>, there is no strong version
of the operators <code>always</code> and <code>never</code>, for the opposite reason. In the case of
<code>always</code> and <code>never</code>, there is no terminating condition to waive.

PSL/A Practical Introduction to PSL/Weak vs. Strong Temporal Operators

2013-12-29T16:26:47Z

Valentin: /* Слабые временные операторы против сильных временных операторов */

{{PSL TOC}}

== Слабые временные операторы против сильных временных операторов ==


Временные операторы могут быть ''слабыми'' или ''сильными''. Сильны временной оператор, такой как <code>eventually!</code> показан восклицательным знаком, как частью своего имени. Оператор без восклицательного , такой как <code>next</code>, слабый. До этого времени мы видели только по одной версии каждого оператора, но много операторов, которых мы видели до того, могут иметь слабую и сильную версии. Различие между слабыми и сильными операторами очень важны, когда путь “слишком короткий”, чтобы определить, действительно все ли произошло для удовлетворения свойства. 1 Например, рассматривая спецификацию “каждое утверждения сигнала a должно происходить на три цикла раньше утверждения сигнала <code>b</code>” на тракте 4.1(i). Выполняется спецификация или нет? Утверждение сигнала a в цикле 2 удовлетворяется утверждением сигнала b на цикле 5. Но, что можно сказать про утверждение сигнала a на цикле 9? Это предполагает утверждение сигнала b на цикле 12, но тракт заканчивает до достижения 12-го цикла. Слабые и сильные временные операторы позволяют нам различать случаи, в которых мы можем сказать,что наша спецификация выполняется на тракте 4.1(i), и в которых мы можем сказать, что она не выполняется.


<blockquote>1 - В этой главе мы рассмотрим конечные пути, т.к. как они выглядят с точки зрения моделирования. Для бесконечных путях, т.к. они представлены в формальной верификации, также существует разница между слабыми и сильными операторами. Это мы обсудим в главе 11.</blockquote>


Слабы временной оператор податливый - в случаи, когда тракт заканчивается “слишком быстро”, свойство, использующее слабый оператор, будет выполнятся до тех пор, пока что-нибудь не пойдет ни так. Если бы мы продолжили ход верификации в тракте 4.1(i) еще на несколько циклов, мы могли бы обнаружить, что сигнал b утверждается в цикле 12. Такое ''может'' случится. Таким образом, утверждение 4.1а, которое использует слабый оператор next, выполняется в тракте 4.1(i).


Сильный оператор строгий - в случаи, когда тракт заканчивается “слишком быстро”, свойство, использующее сильный оператор, не будет выполняться, даже если ничего плохого не происходит. Не существует пути узнать, что бы случилось, если бы мы продолжили ход верификации, показанный в тракте 4.1(i), еще несколько циклов, и мы не можем сказать, что свойство выполняется, не имея всей информации. Таким образом, утверждение 4.1b, которое использует сильный оператор <code>next!</code>, не выполняется на тракте 4.1(i).

{| align=center
! [[Файл:Psl fig4.1.png]]
|-
!(i) Утверждение 4.1a выполняется, but 4.1b не выполняется
|-
|<pre>
assert always(a -> next[3] (b)); (4.1a)
assert always(a -> next![3] (b)); (4.1b)
</pre>
|-
! Рис. 4.1: Тракт иллюстрирует идею слабого и сильного оператора
|}


{{Слабый временной оператор податливый, даже при <code>‘false</code>, а сильный временной оператор строгий, даже при <code>‘true</code>. Таким образом, утверждение 4.2а выполняется на тракте 4.2(i), потому что <code>‘false</code> трактуется, как что-то, что может случится в будущем, а утверждение 4.2b не выполняется на тракте 4.2(i), потому что <code>‘true</code> безусловно не трактуется.}}

{| align=center
! [[Файл:Psl fig4.2.png]]
|-
!(i) Утверждение 4.2a выполняется, но 4.2b нет
|-
|<pre>
assert always(a -> next[3] (‘false)); (4.2a)
assert always(a -> next![3] (‘true)); (4.2b)
</pre>
|-
! Рис. 4.2: Слабый временной оператор податливый, даже при <code>‘false</code>, 
а сильный временной оператор строгий, даже при <code>‘true</code>
|}


Ниже мы покажем семейства сильных операторов, в том же порядке, в котором в котором были представлены их слабые аналоги, а также контраст слабых и сильных версий.

=== 4.1 Оператор next! ===


Утверждение 4.3а показывает, что когда бы a не утверждался, b должен утвердиться в следующем цикле. Используя сильную версию оператора <code>next</code>, мы получим утверждение 4.3b, которое дополнительно требует ''be'' a в следующем цикле. Например, пока утверждение 4.3а выполняется на тракте 4.3(i), утверждение 4.3b нет, потому что, даже хотя <code>b</code> утверждается после первых двух утверждений <code>a</code>, тракт заканчивается слишком быстро по отношению к третьему утверждению <code>a</code>.

{| align=center
! [[Файл:Psl fig4.3.png]]
|-
! (i) Утверждение 4.3a выполняется, но 4.3b нет
|-
|<pre>
assert always (a -> next b); (4.3a)
assert always (a -> next! b); (4.3b)
</pre>
|-
! Рис. 4.3: слабый next против сильного next
|}

=== 4.2 Вариации на <code>next!</code>, включая <code>next_event!</code> ===



Сильный оператор <code>next_event!</code> связан с его слабой версией <code>next_event</code>, также как сильный оператор <code>next!</code> связан со своей слабой версией <code>next</code>. Например, утверждение 4.4b не выполняется на тракте 4.4(i), потому что не хватает грантов. Однако, слабая версия, утверждения 4.4а, не выполняется на том же тракте. Оператор <code>next![n]</code> позволяет вам показать, что как минимум <code>n</code> следующих циклов необходимы, и оператор <code>next_event!(b)[n]</code> позволяет вам показать, что как минимум <code>n</code> вхождений в булево событие <code>b</code> необходимы.

{| align=center
! [[Файл:Psl fig4.4.png]]
|-
! (i) Утверждение 4.4a выполняется, но 4.4b нет

|-
|<pre>
assert always (high_pri_req ->
next_event(gnt)(high_pri_ack)); (4.4a)
assert always (high_pri_req ->
next_event!(gnt)(high_pri_ack)); (4.4b)
</pre>
|-
! Рис. 4.4: Слабый <code>next_event</code> против сильного <code>next_event</code>
|}


Вы должны уже сейчас догадываться о значениях операторов <code>next_a![i:j]</code> и <code>next_event_a!(b)[i:j]</code>. Оператор <code>next_a![i:j]</code> выполняется, если существуют минимум ''j'' дополнительных циклов, и его операнд выполняется от ''i-го'' до ''j-ого'' включительно. Оператор <code>next_event_a!(b)[i:j]</code> выполняется, если существует минимум ''j'' дополнительных циклов, на которых выполняется <code>b</code>, и второй оператор выполняется на всех, от ''i-го'' до ''jth'', циклах включительно.

The <code>next_e![i:j]</code> operator creates a property that holds if its operand
holds on at least one of the ''ith'' through ''jth'' next cycles, inclusive. There
do not have to be ''j'' cycles if the operand holds on some cycle between the
ith and the ''jth'', inclusive. Similarly, the <code>next_event_e!(b)[i:j]</code> operator
creates a property that holds if its second operand holds on at least one of
the ith through ''j'' th next occurrences of <code>b</code>, inclusive. There do not have to be
''j'' occurrences if the second operand holds on some occurrence between the ''ith''
and the ''jth'', inclusive. For example, consider Assertion 4.5b, which states that
a request (assertion of <code>req</code>) must be acknowledged (assertion of <code>ack</code>) on one of
the next four grants, and that in addition, the trace must not end before there
is an appropriate grant. Assertion 4.5b does not hold on Trace 4.5(i) because
none of the three grants shown is acknowledged. However, it does hold on
Trace 4.5(ii) because at least one of the first, second, third or fourth grants
is acknowledged. The fact that the fourth grant does not occur is immaterial
– there is no way for a fourth grant to change the fact that we know for sure
that one of the first, second, third or fourth grants is acknowledged.

The weak version of Assertion 4.5b holds on both Trace 4.5(i) and
Trace 4.5(ii). The only way to violate the weak version shown in Assertion 4.5a
is for there to be four grants, none of which are acknowledged.

{| align=center
! [[Файл:Psl fig4.5.png]]
|-
|<pre>
assert always (req -> next_event_e(gnt)[1:4](ack)); (4.5a)
assert always (req -> next_event_e!(gnt)[1:4](ack)); (4.5b)
</pre>
|-
! Fig. 4.5: Weak vs. strong <code>next_event_e[i:j]</code>
|}

=== 4.3 The until! and until! operators ===

We have previously seen assertions like Assertion 4.6a, which states that whenever <code>a</code> is asserted, then starting the next cycle <code>b</code> should be asserted until <code>c</code> is
asserted. For example, Assertion 4.6a holds on Trace 4.6(i). But what about
a trace like that shown in Trace 4.6(ii), where <code>c</code> never arrives? Does Assertion 4.6a hold on Trace 4.6(ii) or not? It does. The reason is that the <code>until</code>
operator is a weak operator.

If we want to express the requirement of Assertion 4.6a, but in addition
insist that <code>c</code> eventually occur, we need to use a strong operator. Assertion 4.6b,
which uses a strong operator, does not hold on Trace 4.6(ii).

The <code>until!_</code> operator is the strong version of the <code>until_</code> operator. The
<code>until!_</code> operator holds only if its left operand stays asserted up to and ''including''
the cycle where its right operand is asserted, and in addition its right
operand eventually holds.

{| align=center
! [[Файл:Psl fig4.6.png]]
|-
|<pre>
assert always(a -> next (b until c)); (4.6a)
assert always(a -> next (b until! c)); (4.6b)
</pre>
|-
! Fig. 4.6: Weak vs. strong until
|}

=== 4.4 The <code>before!</code> and <code>before!_</code> operators ===

The emphasis of the strong versions of the <code>before</code> operators is on their lefthand operand. For example, Assertion 4.7a states that following an assertion
of <code>req</code>, an assertion of <code>gnt</code> is required before <code>req</code> can be asserted again, but
being weak holds not only on Trace 4.7(ii), but also on Trace 4.7(i), in which
after the second request neither a grant nor a third request ever arrives. The
strong version, shown in Assertion 4.7b, requires that a grant eventually be
given, but not necessarily that another request be seen. Thus, Assertion 4.7b
does not hold on Trace 4.7(i), but holds on Trace 4.7(ii).

{| align=center
! [[Файл:Psl fig4.7.png]]
|-
|<pre>
assert always (req -> next (gnt before req)); (4.7a)
assert always (req -> next (gnt before! req)); (4.7b)
</pre>
|-
! Fig. 4.7: Weak vs. strong before
|}

The <code>before!_</code> operator is the strong version of the <code>before_</code> operator. Thus,
Assertion 4.8a holds on Trace 4.8(i), in which the first request (assertion of
signal <code>req</code>) is granted (assertion of signal <code>gnt</code>) but the second is not. The
strong version of Assertion 4.8a, shown in Assertion 4.8b, does not hold on
Trace 4.8(i) because the second request is not granted. Both Assertion 4.8a
and 4.8b hold on Trace 4.8(ii).

{| align=center
! [[Файл:Psl fig4.8.png]]
|-
|<pre>
assert always (req -> next (gnt before_ req)); (4.8a)
assert always (req -> next (gnt before!_ req)); (4.8b)
</pre>
|-
! Fig. 4.8: Weak vs. strong <code>before_</code>
|}

=== 4.5 Operators without weak or strong versions ===

We have seen weak and strong versions of many operators. The <code>eventually!</code>
operator is not a strong version of some other operator. In other words, there
is no weak version of <code>eventually!</code>. The reason is that the meaning of other
strong operators can be broadly described as requiring that nothing bad must
happen up until some terminating condition, and in addition, the terminating condition must eventually occur. The weak versions then waive the requirement that the terminating condition eventually occur, leaving only the requirement that nothing bad must happen. The <code>eventually!</code> operator, however, contains no idea of a bad “something”, only a terminating condition.
Therefore, there is no way to weaken it without emptying it completely of
meaning.

Just as there is no weak version of <code>eventually!</code>, there is no strong version
of the operators <code>always</code> and <code>never</code>, for the opposite reason. In the case of
<code>always</code> and <code>never</code>, there is no terminating condition to waive.

PSL/A Practical Introduction to PSL/Weak vs. Strong Temporal Operators

2013-12-29T15:14:25Z

Valentin: /* Слабые временные операторы против сильных временных операторов */

PSL/A Practical Introduction to PSL/Weak vs. Strong Temporal Operators

2013-12-24T17:42:35Z

Valentin: /* Weak vs. Strong Temporal Operators */

PSL/The designers guide to VHDL/18.3 Embedded PSL in VHDL

2013-12-24T17:24:05Z

Valentin: /* 18.3 PSL встроенный в VHDL */

{{PSL TOC}}

== 18.3 PSL встроенный в VHDL ==


PSL — это язык спецификации свойств стандарта IEEE (IEEE Std 1850). Это позволяет спецификацию временных свойств модели, которые могут быть верифицированы, как статические (используя формальный доказательный инструмент) или динамические (используя проверки моделирования). VHDL допускает встроенный PSL, как часть модели VHDL. Это делает проект верификации намного более естественным, и упрощает разработку и сопровождение моделей. Так как PSL довольно обширный язык, мы не будем описывать все его особенности в деталях. Мы опишем путь, по которому PSL может быть встроен в VHDL. Для полного описания PSL и его использования в проектах верификации, заинтересованный читатель может посмотреть другие публикации. (Например, ''A Practical Introduction to PSL'' [4].)


Мы можем включать в VHDL свойства PSL, последовательности, декларации времени в декларативной части entity, архитектуру, оператор block (смотрите главу 23), оператор generate или декларацию пакета. Далее мы можем использовать декларированные свойства и последовательности в директивах PSL, написанных в соответствующих операторных частях.


Любые свойства, которые мы пишем в PSL декларациях и директивах, должны соответствовать простому подмножеству правил PSL. На практике, это означает, что мы можем только писать свойства, в которых время движется вперед, слева направо через свойство. Два примера из стандарта PSL показывают это. Первый, следующее свойство в простом подмножестве:

always (a -> next[3] b)


Это свойство показывает, что если <code>a</code> имеет значение <code>true</code>, то через три цикла <code>b</code> примет такое же значение; это значит, что время идет вперед три цикла, если мы выполняем свойство слева направо. Следующее свойство не относиться к простому подмножеству:

always ((a && next[3] b) -> c)


Это свойство показывает, что если <code>a</code> имеет значение <code>true</code> и <code>b</code> принимает значение <code>true</code> через три цикла, то далее <code>c</code> должен принять значение <code>true</code> в то же время, что и <code>a</code>. Проблема в этом свойстве заключается в том, что время двигается в обратном направлении от принятия значения <code>b</code> до принятия значения <code>c</code>. Инструмент для проверки таких свойств куда, как более сложный, чем для простого подмножества.


Директивы PSL нуждаются в спецификации времени, которая определяется, когда временное выражение рассчитано. Мы можем включить выражение времени в директиву. Однако, в то время, как такое же время подходит для всех директив проекта, проще включить декларацию времени по-умолчанию. Если мы напишем деклрацию времени по-умолчанию в области проекта, это подойдет для любых директив PSL, написанных в данном регионе. Наибольшее, мы можем включить одну декларацию времени по-умолчанию в данную область.

<blockquote>
'''ПРИМЕР 18.8''' ''Конвейерный связанные утверждения''
----

В своей книге ''Assertion-Based Design'' [7], Foster ''et al''. описывает образец верификации для системы, в которой конвейерная связность. В этом примере, система может принимать до 16 запросов, при подтверждении любого из них. Система считает количество запросов, их подтверждение, и включает утверждение, что для каждого запроса с данным подсчетом запросов, существует подтверждение с таким же счетом в течение 100 временных циклов.

<source lang="vhdl">
library ieee; context ieee.ieee_std_context;
entity slave is
port ( clk, reset : in std_ulogic;
req : in std_ulogic;
ack : out std_ulogic;
... );
end entity slave;
architecture pipelined of slave is
signal req_cnt, ack_cnt : unsigned(3 downto 0);
default clock is rising_edge(clk);
property all_requests_acked is
forall C in {0 to 15}:
always {req and req_cnt = C} |=>
{[*0 to 99]; ack and ack_cnt = C};
begin
req_ack_counter : process (clk) is
begin
if rising_edge(clk) then
if reset = '1' then
req_cnt <= "0000"; ack_cnt <= "0000";
else
if req = '1' then req_cnt <= req_cnt + 1; end if;
if ack = '1' then ack_cnt <= ack_cnt + 1; end if;
end if;
end if;
end process req_ack_counter;
...
assert all_requests_acked;
end architecture pipelined;
</source>


Счетчики запросов и подтверждения выполняются, используя сигналы <code>req_cnt</code> и <code>ack_cnt</code> и процесс <code>req_ack_counter</code>. Мы декларируем свойство <code>all_requests_acked</code>, которое выражает условие верификации для проекта. Мы, также, включаем декларацию времени по-умолчанию для архитектуры. Это подходит для утверждения директив, которые мы писали в области деклараций архитектуры, утверждая, что условие верификации выполняется.
</blockquote>


Существует один случай, где встроенный в VHDL PSL может привести к двусмысленности. И PSL, и VHDL включают в себя выражения утверждений, но их смысл разный. Если мы напишем выражение вида:

assert not (a and b) report "a and b are both true";


оно может быть интерпретирована, как регулярное параллельное выражение VHDL утверждения, которое проверяется, когда <code>a</code> или <code>b</code> меняют значение. Также, оно может быть интерпретировано, как директива утверждения PSL, которая предполагает свойство <code>not (a and b)</code>, выполняющееся во времени 0. В интересах совместимости с более ранними версиями языка, VHDL интерпретирует такие двусмысленные выражения, как регулярные параллельные выражения VHDL утверждений. Если мы действительно хотим написать директиву PSL утверждения такого вида, мы можем модифицировать свойство, таким образом получить однозначное PSL свойство, например:

assert next[0] not (a and b) report "a and b are both true";


В PSL код верификации может быть написан в блоках верификации (<code>vunit</code>, <code>vprop</code> и
<code>vmode</code> блоки), которые связаны с экземплярами entity и архитектур VHDL. VHDL применяет такие блоки верификации, как первичные блоки проекта. Таким образом, они могут быть декларированы в файлах VHDL проекта и проанализированы в библиотеках VHDL проекта.


Блок верификации может включать в себя обязательную информацию, которая определяет компонент образца, для которого применяется директива. Также, мы можем связать блок верификации, как часть конфигураций проекта. Единственное место, для того чтобы сделать это - декларация конфигураций, представленных в главе 13. Если мы хотим связать один и более блоков верификации к головному entity в декларации конфигураций, мы подключаем связывающую информацию, в соответствии со следующим синтаксическим правилом:

configuration_declaration ⇐
'''configuration''' identifier '''of''' ''entity''_name '''is'''
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
block_configuration
'''end''' [ '''configuration''' ] [ identifier ] ;


Всякий раз, когда в декларации конфигурации экземпляра, либо в головном уровне иерархии проекта или как экземпляра компонента в более большом проекте, названные блоки верификации интерпретируются в контексте entity и архитектуры. Это означает, что имена, используемые в блоках верификации интерпретируются в контексте entity.

<blockquote>'''Пример 18.9''' ''Связанный блок верификации в декларации конфигураций''
----

предположим, что у нас есть блок верификации, который обеспечивает два выхода Q и Q_n, которые дополняют друг друга при переднем фронте сигнала clk. Блок верификации:

'''vunit''' complementary_outputs {
'''assert always''' Q = '''not''' Q_n;
}


Мы можем связать этот блок верификации с различными частями проекта. Например, модель gatelevel триггера D может быть описана так:

<source lang="vhdl">
entity D_FF is
port ( clk, reset, D : in bit;
Q, Q_n : out bit );
end entity D_FF;

architecture gate_level of D_FF is
component and2 is ...
...
begin
G1 : and2 ...
...
end architecture gate_level;
</source>


Декларация конфигураций для триггера D может связать блок верификации с головным entity:

<source lang="vhdl">
configuration fast_sim of D_FF is
use vunit complementary_outputs;
for gate_level
for all : and2
...
end for;
...
end for;
end configuration fast_sim;
</source>


Далее мы можем подтвердить конфигурации в проекте и для каждого экземпляра, блок верификации <code>complementary_outputs</code> будет связан с экземпляром entity и архитектуры.

</blockquote>


Мы, также, можем связать блок верификации с экземплярами компонентов, которые конфигурируются покомпонентной конфигурацией, вложенной в декларацию конфигураций. Полная форма конфигурации компонента предполагает компоненты, связанные с entity и архитектурой, и архитектура дополнительно конфигурируется:

component_configuration ⇐
'''for''' component_specification
binding_indication ;
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
[ block_configuration ]
'''end for''' ;


В этом случаи, блоки верификации связаны с экземплярами определенными в декларации компонентов.

<blockquote>
'''Пример 18.10''' ''Связанный блок верификации в конфигурации компонента''
----

Предположим, мы создаем регистр сдвига parallel-in/serial-out внутри RTL описания:

<source lang="vhdl">
entity system is
...
end entity system;

architecture RTL of system is
component shift_reg is
port ( clk, reset, D : in bit_vector;
Q, Q_n : out bit );
end component shift_reg;
...
begin
serializer : shift_reg ...;
...
end architecture RTL;
</source>


Мы можем написать декларацию конфигураций, которая свяжет entity и архитектуру с экземпляром компонента, а также свяжет блок complementary_outputs верификации, Пример 18.9.

<source lang="vhdl">
configuration verifying of system is
for RTL
for serializer : shift_reg
use entity work.shift_reg(RTL);
use vunit complementary_outputs;
end for;
end for;
end configuration verifying;
</source>


В этом случаи, утверждение в блоке верификации применяется для выходов Q и Q_n регистра сдвига связанного entity с сериализатором экземпляра компонента.

</blockquote>


Третье место, в котором мы можем применить блок верификации в VHDL проекте, это в спецификации конфигураций в архитектуре, где подтверждаются компоненты. Дополненное правило синтаксиса для спецификации конфигураций, снова предполагает связь компонентов с entity и архитектурой:

configuration_specification ⇐
'''for''' component_specification
binding_indication ;
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
'''end for''' ;


Это похоже на форму конфигурации компонентов, но без вложенных конфигураций для архитектуры.

<blockquote>
'''Пример 18.11''' ''Использование блока верификации в спецификации конфигураций''
----

Мы можем пересмотреть архитектуру из примера 18.10 для включения связанной информации напрямую, а не в отдельной конфигурации. Архитектура:

<source lang="vhdl">
architecture RTL of system is
component shift_reg is
...
end component shift_reg;

for serializer : shift_reg
use entity work.shift_reg(RTL);
use vunit complementary_outputs;
end for;
begin
serializer : shift_reg ...;
...
end architecture RTL;
</source>
</blockquote>


В то время, как блок верификации может включать связанную информацию, как часть своей декларации, существует возможность того, что эта информация может конфликтовать со связанной информацией, которую мы написали в конфигурациях. VHDL предотвращает такие конфликты, делая не полноправным привязывание блока верификации к конфигурациям, если он уже содержит связанную информацию. Следовательно, нужно писать привязку верификации в конфигурациях для общих блоков верификации, но не для каких-либо конкретных. В любом случаи, появится ошибка, если мы привяжем блок верификации с экземпляром компонента, у которого нету связи в entity и архитектуре.


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


Немного дополнительных аспектов для PSL встроенного в VHDL. Первое, у PSL есть богатый набор зарезервированных слов, некоторые из которых могут конфликтовать с идентификаторами VHDL. Следующие PSL слова зарезервированы VHDL, и не могут использоваться, как идентификаторы:

assert
assume
assume_guarantee
cover
default
fairness
property
restrict
restrict_guarantee
sequence
strong
vmode
vprop
vunit


Другие зарезервированные PSL слова только считаются таковыми, если в VHDL коде, они появляются в PSL декларациях и директивах. Они могут использоваться, как VHDL идентификаторы, но такие идентификаторы скрыты для деклараций и директив PSL. Например, мы можем полноправно написать следующую декларацию:

function rose ( x : boolean ) return boolean is ...;

Но если мы декларируем последовательность:

sequence cover_fifo_empty is
{reset_n && rose(cnt = 0)};

Ссылка на <code>rose</code> в декларации последовательности является в PSL встроенной функции, а не к декларации, написанной в VHDL.


Второе, PSL включает особенности для декларирования и экземпляров макросов, и разрешение директив препроцессора. Эти особенности могут использоваться только в блоках верификации PSL.

<blockquote>
'''VHDL-87, -93, и -2002'''
----

Эти версии VHDL не позволяют PSL встраиваться в VHDL модели. Код PSL должен быть написан в отдельном блоке верификации и иметь связь с проектом VHDL, который использует определенные инструментарием значения.
</blockquote>

PSL/The designers guide to VHDL/18.3 Embedded PSL in VHDL

2013-12-24T10:16:27Z

Valentin: /* 18.3 PSL встроенный в VHDL */

{{PSL TOC}}

== 18.3 PSL встроенный в VHDL ==


PSL — это язык спецификации свойств стандарта IEEE (IEEE Std 1850). Это позволяет спецификацию временных свойств модели, которые могут быть верифицированы, как статические (используя формальный доказательный инструмент) или динамические (используя проверки моделирования). VHDL допускает встроенный PSL, как часть модели VHDL. Это делает проект верификации намного более естественным, и упрощает разработку и сопровождение моделей. Так как PSL довольно обширный язык, мы не будем описывать все его особенности в деталях. Мы опишем путь, по которому PSL может быть встроен в VHDL. Для полного описания PSL и его использования в проектах верификации, заинтересованный читатель может посмотреть другие публикации. (Например, ''A Practical Introduction to PSL'' [4].)


Мы можем включать в VHDL свойства PSL, последовательности, декларации времени в декларативной части entity, архитектуру, оператор block (смотрите главу 23), оператор generate или декларацию пакета. Далее мы можем использовать декларированные свойства и последовательности в директивах PSL, написанных в соответствующих операторных частях.


Любые свойства, которые мы пишем в PSL декларациях и директивах, должны соответствовать простому подмножеству правил PSL. На практике, это означает, что мы можем только писать свойства, в которых время движется вперед, слева направо через свойство. Два примера из стандарта PSL показывают это. Первый, следующее свойство в простом подмножестве:

always (a -> next[3] b)


Это свойство показывает, что если <code>a</code> имеет значение <code>true</code>, то через три цикла <code>b</code> примет такое же значение; это значит, что время идет вперед три цикла, если мы выполняем свойство слева направо. Следующее свойство не относиться к простому подмножеству:

always ((a && next[3] b) -> c)


Это свойство показывает, что если <code>a</code> имеет значение <code>true</code> и <code>b</code> принимает значение <code>true</code> через три цикла, то далее <code>c</code> должен принять значение <code>true</code> в то же время, что и <code>a</code>. Проблема в этом свойстве заключается в том, что время двигается в обратном направлении от принятия значения <code>b</code> до принятия значения <code>c</code>. Инструмент для проверки таких свойств куда, как более сложный, чем для простого подмножества.


Директивы PSL нуждаются в спецификации времени, которая определяется, когда временное выражение рассчитано. Мы можем включить выражение времени в директиву. Однако, в то время, как такое же время подходит для всех директив проекта, проще включить декларацию времени по-умолчанию. Если мы напишем деклрацию времени по-умолчанию в области проекта, это подойдет для любых директив PSL, написанных в данном регионе. Наибольшее, мы можем включить одну декларацию времени по-умолчанию в данную область.

<blockquote>
'''ПРИМЕР 18.8''' ''Конвейерный связанные утверждения''
----

В своей книге ''Assertion-Based Design'' [7], Foster ''et al''. описывает образец верификации для системы, в которой конвейерная связность. В этом примере, система может принимать до 16 запросов, при подтверждении любого из них. Система считает количество запросов, их подтверждение, и включает утверждение, что для каждого запроса с данным подсчетом запросов, существует подтверждение с таким же счетом в течение 100 временных циклов.

<source lang="vhdl">
library ieee; context ieee.ieee_std_context;
entity slave is
port ( clk, reset : in std_ulogic;
req : in std_ulogic;
ack : out std_ulogic;
... );
end entity slave;
architecture pipelined of slave is
signal req_cnt, ack_cnt : unsigned(3 downto 0);
default clock is rising_edge(clk);
property all_requests_acked is
forall C in {0 to 15}:
always {req and req_cnt = C} |=>
{[*0 to 99]; ack and ack_cnt = C};
begin
req_ack_counter : process (clk) is
begin
if rising_edge(clk) then
if reset = '1' then
req_cnt <= "0000"; ack_cnt <= "0000";
else
if req = '1' then req_cnt <= req_cnt + 1; end if;
if ack = '1' then ack_cnt <= ack_cnt + 1; end if;
end if;
end if;
end process req_ack_counter;
...
assert all_requests_acked;
end architecture pipelined;
</source>


Счетчики запросов и подтверждения выполняются, используя сигналы <code>req_cnt</code> и <code>ack_cnt</code> и процесс <code>req_ack_counter</code>. Мы декларируем свойство <code>all_requests_acked</code>, которое выражает условие верификации для проекта. Мы, также, включаем декларацию времени по-умолчанию для архитектуры. Это подходит для утверждения директив, которые мы писали в области деклараций архитектуры, утверждая, что условие верификации выполняется.
</blockquote>


Существует один случай, где встроенный в VHDL PSL может привести к двусмысленности. И PSL, и VHDL включают в себя выражения утверждений, но их смысл разный. Если мы напишем выражение вида:

assert not (a and b) report "a and b are both true";


оно может быть интерпретирована, как регулярное параллельное выражение VHDL утверждения, которое проверяется, когда <code>a</code> или <code>b</code> меняют значение. Также, оно может быть интерпретировано, как директива утверждения PSL, которая предполагает свойство <code>not (a and b)</code>, выполняющееся во времени 0. В интересах совместимости с более ранними версиями языка, VHDL интерпретирует такие двусмысленные выражения, как регулярные параллельные выражения VHDL утверждений. Если мы действительно хотим написать директиву PSL утверждения такого вида, мы можем модифицировать свойство, таким образом получить однозначное PSL свойство, например:

assert next[0] not (a and b) report "a and b are both true";


В PSL код верификации может быть написан в блоках верификации (<code>vunit</code>, <code>vprop</code> и
<code>vmode</code> блоки), которые связаны с экземплярами entity и архитектур VHDL. VHDL применяет такие блоки верификации, как первичные блоки проекта. Таким образом, они могут быть декларированы в файлах VHDL проекта и проанализированы в библиотеках VHDL проекта.


Блок верификации может включать в себя обязательную информацию, которая определяет компонент образца, для которого применяется директива. Также, мы можем связать блок верификации, как часть конфигураций проекта. Единственное место, для того чтобы сделать это - декларация конфигураций, представленных в главе 13. Если мы хотим связать один и более блоков верификации к головному entity в декларации конфигураций, мы подключаем связывающую информацию, в соответствии со следующим синтаксическим правилом:

configuration_declaration ⇐
'''configuration''' identifier '''of''' ''entity''_name '''is'''
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
block_configuration
'''end''' [ '''configuration''' ] [ identifier ] ;


Всякий раз, когда в декларации конфигурации экземпляра, либо в головном уровне иерархии проекта или как экземпляра компонента в более большом проекте, названные блоки верификации интерпретируются в контексте entity и архитектуры. Это означает, что имена, используемые в блоках верификации интерпретируются в контексте entity.

<blockquote>'''Пример 18.9''' ''Связанный блок верификации в декларации конфигураций''
----

предположим, что у нас есть блок верификации, который обеспечивает два выхода Q и Q_n, которые дополняют друг друга при переднем фронте сигнала clk. Блок верификации:

'''vunit''' complementary_outputs {
'''assert always''' Q = '''not''' Q_n;
}


Мы можем связать этот блок верификации с различными частями проекта. Например, модель gatelevel триггера D может быть описана так:

<source lang="vhdl">
entity D_FF is
port ( clk, reset, D : in bit;
Q, Q_n : out bit );
end entity D_FF;

architecture gate_level of D_FF is
component and2 is ...
...
begin
G1 : and2 ...
...
end architecture gate_level;
</source>


Декларация конфигураций для триггера D может связать блок верификации с головным entity:

<source lang="vhdl">
configuration fast_sim of D_FF is
use vunit complementary_outputs;
for gate_level
for all : and2
...
end for;
...
end for;
end configuration fast_sim;
</source>


Далее мы можем подтвердить конфигурации в проекте и для каждого экземпляра, блок верификации <code>complementary_outputs</code> будет связан с экземпляром entity и архитектуры.

</blockquote>


Мы, также, можем связать блок верификации с экземплярами компонентов, которые конфигурируются покомпонентной конфигурацией, вложенной в декларацию конфигураций. Полная форма конфигурации компонента предполагает компоненты, связанные с entity и архитектурой, и архитектура дополнительно конфигурируется:

component_configuration ⇐
'''for''' component_specification
binding_indication ;
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
[ block_configuration ]
'''end for''' ;


В этом случаи, блоки верификации связаны с экземплярами определенными в декларации компонентов.

<blockquote>
'''Пример 18.10''' ''Связанный блок верификации в конфигурации компонента''
----

Предположим, мы создаем регистр сдвига parallel-in/serial-out внутри RTL описания:

<source lang="vhdl">
entity system is
...
end entity system;

architecture RTL of system is
component shift_reg is
port ( clk, reset, D : in bit_vector;
Q, Q_n : out bit );
end component shift_reg;
...
begin
serializer : shift_reg ...;
...
end architecture RTL;
</source>


Мы можем написать декларацию конфигураций, которая свяжет entity и архитектуру с экземпляром компонента, а также свяжет блок complementary_outputs верификации, Пример 18.9.

<source lang="vhdl">
configuration verifying of system is
for RTL
for serializer : shift_reg
use entity work.shift_reg(RTL);
use vunit complementary_outputs;
end for;
end for;
end configuration verifying;
</source>


В этом случаи, утверждение в блоке верификации применяется для выходов Q и Q_n регистра сдвига связанного entity с сериализатором экземпляра компонента.

</blockquote>


Третье место, в котором мы можем применить блок верификации в VHDL проекте, это в спецификации конфигураций в архитектуре, где подтверждаются компоненты. Дополненное правило синтаксиса для спецификации конфигураций, снова предполагает связь компонентов с entity и архитектурой:

configuration_specification ⇐
'''for''' component_specification
binding_indication ;
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
'''end for''' ;


Это похоже на форму конфигурации компонентов, но без вложенных конфигураций для архитектуры.

<blockquote>
'''Пример 18.11''' ''Использование блока верификации в спецификации конфигураций''
----

Мы можем пересмотреть архитектуру из примера 18.10 для включения связанной информации напрямую, а не в отдельной конфигурации. Архитектура:

<source lang="vhdl">
architecture RTL of system is
component shift_reg is
...
end component shift_reg;

for serializer : shift_reg
use entity work.shift_reg(RTL);
use vunit complementary_outputs;
end for;
begin
serializer : shift_reg ...;
...
end architecture RTL;
</source>
</blockquote>


In addition to binding verification units directly in their declaration or indirectly in
configurations, VHDL allows a tool to bind additional verification units through
implementation-defined means. That might include command-line options, script commands, or selection using a graphical user interface.

There are a couple of further points to make about PSL embedded in VHDL. First, PSL
has a rich set of reserved words, some of which may conflict with VHDL identifiers. The
following PSL keywords are VHDL reserved words, and cannot be used as identifiers:

assert
assume
assume_guarantee
cover
default
fairness
property
restrict
restrict_guarantee
sequence
strong
vmode
vprop
vunit

Other PSL reserved words are only recognized as such within VHDL code when they
occur in PSL declarations and directives. They can be used as VHDL identifiers, but such
identifiers are hidden within PSL declarations and directives. For example, we can legally
write the following declaration:

function rose ( x : boolean ) return boolean is ...;

But if we then declare a sequence:

sequence cover_fifo_empty is
{reset_n && rose(cnt = 0)};

The reference to <code>rose</code> in the sequence declaration is to the PSL built-in function, not to
the declaration written in VHDL.

Second, PSL includes features for declaring and instantiating macros, and allows for
preprocessor directives. These features can only be used in PSL verification units, not in
other VHDL design units.

<blockquote>
'''VHDL-87, -93, and -2002'''
----
These versions of VHDL do not allow PSL to be embedded within VHDL models. PSL
code must be written in separate verification units and bound to the VHDL design us-
ing tool-defined means.
</blockquote>

PSL/The designers guide to VHDL/18.3 Embedded PSL in VHDL

2013-12-10T08:04:42Z

Valentin: /* 18.3 PSL встроенный в VHDL */

{{PSL TOC}}

== 18.3 PSL встроенный в VHDL ==


PSL — это язык спецификации свойств стандарта IEEE (IEEE Std 1850). Это позволяет спецификацию временных свойств модели, которые могут быть верифицированы, как статические (используя формальный доказательный инструмент) или динамические (используя проверки моделирования). VHDL допускает встроенный PSL, как часть модели VHDL. Это делает проект верификации намного более естественным, и упрощает разработку и сопровождение моделей. Так как PSL довольно обширный язык, мы не будем описывать все его особенности в деталях. Мы опишем путь, по которому PSL может быть встроен в VHDL. Для полного описания PSL и его использования в проектах верификации, заинтересованный читатель может посмотреть другие публикации. (Например, ''A Practical Introduction to PSL'' [4].)


Мы можем включать в VHDL свойства PSL, последовательности, декларации времени в декларативной части entity, архитектуру, оператор block (смотрите главу 23), оператор generate или декларацию пакета. Далее мы можем использовать декларированные свойства и последовательности в директивах PSL, написанных в соответствующих операторных частях.


Любые свойства, которые мы пишем в PSL декларациях и директивах, должны соответствовать простому подмножеству правил PSL. На практике, это означает, что мы можем только писать свойства, в которых время движется вперед, слева направо через свойство. Два примера из стандарта PSL показывают это. Первый, следующее свойство в простом подмножестве:

always (a -> next[3] b)


Это свойство показывает, что если <code>a</code> имеет значение <code>true</code>, то через три цикла <code>b</code> примет такое же значение; это значит, что время идет вперед три цикла, если мы выполняем свойство слева направо. Следующее свойство не относиться к простому подмножеству:

always ((a && next[3] b) -> c)


Это свойство показывает, что если <code>a</code> имеет значение <code>true</code> и <code>b</code> принимает значение <code>true</code> через три цикла, то далее <code>c</code> должен принять значение <code>true</code> в то же время, что и <code>a</code>. Проблема в этом свойстве заключается в том, что время двигается в обратном направлении от принятия значения <code>b</code> до принятия значения <code>c</code>. Инструмент для проверки таких свойств куда, как более сложный, чем для простого подмножества.


Директивы PSL нуждаются в спецификации времени, которая определяется, когда временное выражение рассчитано. Мы можем включить выражение времени в директиву. Однако, в то время, как такое же время подходит для всех директив проекта, проще включить декларацию времени по-умолчанию. Если мы напишем деклрацию времени по-умолчанию в области проекта, это подойдет для любых директив PSL, написанных в данном регионе. Наибольшее, мы можем включить одну декларацию времени по-умолчанию в данную область.

<blockquote>
'''ПРИМЕР 18.8''' ''Конвейерный связанные утверждения''
----

В своей книге ''Assertion-Based Design'' [7], Foster ''et al''. описывает образец верификации для системы, в которой конвейерная связность. В этом примере, система может принимать до 16 запросов, при подтверждении любого из них. Система считает количество запросов, их подтверждение, и включает утверждение, что для каждого запроса с данным подсчетом запросов, существует подтверждение с таким же счетом в течение 100 временных циклов.

<source lang="vhdl">
library ieee; context ieee.ieee_std_context;
entity slave is
port ( clk, reset : in std_ulogic;
req : in std_ulogic;
ack : out std_ulogic;
... );
end entity slave;
architecture pipelined of slave is
signal req_cnt, ack_cnt : unsigned(3 downto 0);
default clock is rising_edge(clk);
property all_requests_acked is
forall C in {0 to 15}:
always {req and req_cnt = C} |=>
{[*0 to 99]; ack and ack_cnt = C};
begin
req_ack_counter : process (clk) is
begin
if rising_edge(clk) then
if reset = '1' then
req_cnt <= "0000"; ack_cnt <= "0000";
else
if req = '1' then req_cnt <= req_cnt + 1; end if;
if ack = '1' then ack_cnt <= ack_cnt + 1; end if;
end if;
end if;
end process req_ack_counter;
...
assert all_requests_acked;
end architecture pipelined;
</source>


Счетчики запросов и подтверждения выполняются, используя сигналы <code>req_cnt</code> и <code>ack_cnt</code> и процесс <code>req_ack_counter</code>. Мы декларируем свойство <code>all_requests_acked</code>, которое выражает условие верификации для проекта. Мы, также, включаем декларацию времени по-умолчанию для архитектуры. Это подходит для утверждения директив, которые мы писали в области деклараций архитектуры, утверждая, что условие верификации выполняется.
</blockquote>


Существует один случай, где встроенный в VHDL PSL может привести к двусмысленности. И PSL, и VHDL включают в себя выражения утверждений, но их смысл разный. Если мы напишем выражение вида:

assert not (a and b) report "a and b are both true";


оно может быть интерпретирована, как регулярное параллельное выражение VHDL утверждения, которое проверяется, когда <code>a</code> или <code>b</code> меняют значение. Также, оно может быть интерпретировано, как директива утверждения PSL, которая предполагает свойство <code>not (a and b)</code>, выполняющееся во времени 0. В интересах совместимости с более ранними версиями языка, VHDL интерпретирует такие двусмысленные выражения, как регулярные параллельные выражения VHDL утверждений. Если мы действительно хотим написать директиву PSL утверждения такого вида, мы можем модифицировать свойство, таким образом получить однозначное PSL свойство, например:

assert next[0] not (a and b) report "a and b are both true";


В PSL код верификации может быть написан в блоках верификации (<code>vunit</code>, <code>vprop</code> и
<code>vmode</code> блоки), которые связаны с экземплярами entity и архитектур VHDL. VHDL применяет такие блоки верификации, как первичные блоки проекта. Таким образом, они могут быть декларированы в файлах VHDL проекта и проанализированы в библиотеках VHDL проекта.


Блок верификации может включать в себя обязательную информацию, которая определяет компонент образца, для которого применяется директива. Также, мы можем связать блок верификации, как часть конфигураций проекта. Единственное место, для того чтобы сделать это - декларация конфигураций, представленных в главе 13. Если мы хотим связать один и более блоков верификации к головному entity в декларации конфигураций, мы подключаем связывающую информацию, в соответствии со следующим синтаксическим правилом:

configuration_declaration ⇐
'''configuration''' identifier '''of''' ''entity''_name '''is'''
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
block_configuration
'''end''' [ '''configuration''' ] [ identifier ] ;


Всякий раз, когда в декларации конфигурации экземпляра, либо в головном уровне иерархии проекта или как экземпляра компонента в более большом проекте, названные блоки верификации интерпретируются в контексте entity и архитектуры. Это означает, что имена, используемые в блоках верификации интерпретируются в контексте entity.

<blockquote>'''Пример 18.9''' ''Связанный блок верификации в декларации конфигураций''
----

предположим, что у нас есть блок верификации, который обеспечивает два выхода Q и Q_n, которые дополняют друг друга при переднем фронте сигнала clk. Блок верификации:

'''vunit''' complementary_outputs {
'''assert always''' Q = '''not''' Q_n;
}


Мы можем связать этот блок верификации с различными частями проекта. Например, модель gatelevel триггера D может быть описана так:

<source lang="vhdl">
entity D_FF is
port ( clk, reset, D : in bit;
Q, Q_n : out bit );
end entity D_FF;

architecture gate_level of D_FF is
component and2 is ...
...
begin
G1 : and2 ...
...
end architecture gate_level;
</source>


Декларация конфигураций для триггера D может связать блок верификации с головным entity:

<source lang="vhdl">
configuration fast_sim of D_FF is
use vunit complementary_outputs;
for gate_level
for all : and2
...
end for;
...
end for;
end configuration fast_sim;
</source>


Далее мы можем подтвердить конфигурации в проекте и для каждого экземпляра, блок верификации <code>complementary_outputs</code> будет связан с экземпляром entity и архитектуры.

</blockquote>


Мы, также, можем связать блок верификации с экземплярами компонентов, которые конфигурируются покомпонентной конфигурацией, вложенной в декларацию конфигураций. Полная форма конфигурации компонента предполагает компоненты, связанные с entity и архитектурой, и архитектура дополнительно конфигурируется:

component_configuration ⇐
'''for''' component_specification
binding_indication ;
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
[ block_configuration ]
'''end for''' ;


В этом случаи, блоки верификации связаны с экземплярами определенными в декларации компонентов.

<blockquote>
'''Пример 18.10''' ''Связанный блок верификации в конфигурации компонента''
----

Предположим, мы создаем регистр сдвига parallel-in/serial-out внутри RTL описания:

<source lang="vhdl">
entity system is
...
end entity system;

architecture RTL of system is
component shift_reg is
port ( clk, reset, D : in bit_vector;
Q, Q_n : out bit );
end component shift_reg;
...
begin
serializer : shift_reg ...;
...
end architecture RTL;
</source>


Мы можем написать декларацию конфигураций, которая свяжет entity и архитектуру с экземпляром компонента, а также свяжет блок complementary_outputs верификации, Пример 18.9.

<source lang="vhdl">
configuration verifying of system is
for RTL
for serializer : shift_reg
use entity work.shift_reg(RTL);
use vunit complementary_outputs;
end for;
end for;
end configuration verifying;
</source>

In this case, the assertion in the verification unit applies to the Q and Q_n outputs
of the shift register entity bound to the serializer component instance.

</blockquote>

The third place in which we can bind verification units in a VHDL design is in a con-
figuration specification in the architecture where components are instantiated. The aug-
mented syntax rule for a configuration specification, again assuming components are
bound to an entity and architecture, is

configuration_specification ⇐
'''for''' component_specification
binding_indication ;
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
'''end for''' ;

This is similar to the form in a component configuration, but without the nested configuration for the architecture.

<blockquote>
'''EXAMPLE 18.11''' ''Binding a verification unit in a configuration specification''
----
We can revise the architecture of Example 18.10 to include the binding information
directly, rather than in a separate configuration. The revised architecture is

<source lang="vhdl">
architecture RTL of system is
component shift_reg is
...
end component shift_reg;

for serializer : shift_reg
use entity work.shift_reg(RTL);
use vunit complementary_outputs;
end for;
begin
serializer : shift_reg ...;
...
end architecture RTL;
</source>
</blockquote>

Since a verification unit may include binding information as part of its declaration,
there is potential for that information to conflict with binding information we write inconfiguration. VHDL prevents such conflict by making it illegal to bind a verification unit
in a configuration if the declaration of the unit already includes binding information.
Hence, we would normally only write verification bindings in configurations for general-purpose verification units, and not for those written with particular instances in mind. In
any case, it would be an error if we wrote a verification unit binding for a component
instance that had no bound entity and architecture.

In addition to binding verification units directly in their declaration or indirectly in
configurations, VHDL allows a tool to bind additional verification units through
implementation-defined means. That might include command-line options, script commands, or selection using a graphical user interface.

There are a couple of further points to make about PSL embedded in VHDL. First, PSL
has a rich set of reserved words, some of which may conflict with VHDL identifiers. The
following PSL keywords are VHDL reserved words, and cannot be used as identifiers:

assert
assume
assume_guarantee
cover
default
fairness
property
restrict
restrict_guarantee
sequence
strong
vmode
vprop
vunit

Other PSL reserved words are only recognized as such within VHDL code when they
occur in PSL declarations and directives. They can be used as VHDL identifiers, but such
identifiers are hidden within PSL declarations and directives. For example, we can legally
write the following declaration:

function rose ( x : boolean ) return boolean is ...;

But if we then declare a sequence:

sequence cover_fifo_empty is
{reset_n && rose(cnt = 0)};

The reference to <code>rose</code> in the sequence declaration is to the PSL built-in function, not to
the declaration written in VHDL.

Second, PSL includes features for declaring and instantiating macros, and allows for
preprocessor directives. These features can only be used in PSL verification units, not in
other VHDL design units.

<blockquote>
'''VHDL-87, -93, and -2002'''
----
These versions of VHDL do not allow PSL to be embedded within VHDL models. PSL
code must be written in separate verification units and bound to the VHDL design us-
ing tool-defined means.
</blockquote>

PSL/The designers guide to VHDL/18.3 Embedded PSL in VHDL

2013-12-06T10:40:38Z

Valentin: /* 18.3 PSL встроенный в VHDL */

{{PSL TOC}}

== 18.3 PSL встроенный в VHDL ==


PSL — это язык спецификации свойств стандарта IEEE (IEEE Std 1850). Это позволяет спецификацию временных свойств модели, которые могут быть верифицированы, как статические (используя формальный доказательный инструмент) или динамические (используя проверки моделирования). VHDL допускает встроенный PSL, как часть модели VHDL. Это делает проект верификации намного более естественным, и упрощает разработку и сопровождение моделей. Так как PSL довольно обширный язык, мы не будем описывать все его особенности в деталях. Мы опишем путь, по которому PSL может быть встроен в VHDL. Для полного описания PSL и его использования в проектах верификации, заинтересованный читатель может посмотреть другие публикации. (Например, ''A Practical Introduction to PSL'' [4].)


Мы можем включать в VHDL свойства PSL, последовательности, декларации времени в декларативной части entity, архитектуру, оператор block (смотрите главу 23), оператор generate или декларацию пакета. Далее мы можем использовать декларированные свойства и последовательности в директивах PSL, написанных в соответствующих операторных частях.


Любые свойства, которые мы пишем в PSL декларациях и директивах, должны соответствовать простому подмножеству правил PSL. На практике, это означает, что мы можем только писать свойства, в которых время движется вперед, слева направо через свойство. Два примера из стандарта PSL показывают это. Первый, следующее свойство в простом подмножестве:

always (a -> next[3] b)


Это свойство показывает, что если <code>a</code> имеет значение <code>true</code>, то через три цикла <code>b</code> примет такое же значение; это значит, что время идет вперед три цикла, если мы выполняем свойство слева направо. Следующее свойство не относиться к простому подмножеству:

always ((a && next[3] b) -> c)


Это свойство показывает, что если <code>a</code> имеет значение <code>true</code> и <code>b</code> принимает значение <code>true</code> через три цикла, то далее <code>c</code> должен принять значение <code>true</code> в то же время, что и <code>a</code>. Проблема в этом свойстве заключается в том, что время двигается в обратном направлении от принятия значения <code>b</code> до принятия значения <code>c</code>. Инструмент для проверки таких свойств куда, как более сложный, чем для простого подмножества.


Директивы PSL нуждаются в спецификации времени, которая определяется, когда временное выражение рассчитано. Мы можем включить выражение времени в директиву. Однако, в то время, как такое же время подходит для всех директив проекта, проще включить декларацию времени по-умолчанию. Если мы напишем деклрацию времени по-умолчанию в области проекта, это подойдет для любых директив PSL, написанных в данном регионе. Наибольшее, мы можем включить одну декларацию времени по-умолчанию в данную область.

<blockquote>
'''ПРИМЕР 18.8''' ''Конвейерный связанные утверждения''
----

В своей книге ''Assertion-Based Design'' [7], Foster ''et al''. описывает образец верификации для системы, в которой конвейерная связность. В этом примере, система может принимать до 16 запросов, при подтверждении любого из них. Система считает количество запросов, их подтверждение, и включает утверждение, что для каждого запроса с данным подсчетом запросов, существует подтверждение с таким же счетом в течение 100 временных циклов.

<source lang="vhdl">
library ieee; context ieee.ieee_std_context;
entity slave is
port ( clk, reset : in std_ulogic;
req : in std_ulogic;
ack : out std_ulogic;
... );
end entity slave;
architecture pipelined of slave is
signal req_cnt, ack_cnt : unsigned(3 downto 0);
default clock is rising_edge(clk);
property all_requests_acked is
forall C in {0 to 15}:
always {req and req_cnt = C} |=>
{[*0 to 99]; ack and ack_cnt = C};
begin
req_ack_counter : process (clk) is
begin
if rising_edge(clk) then
if reset = '1' then
req_cnt <= "0000"; ack_cnt <= "0000";
else
if req = '1' then req_cnt <= req_cnt + 1; end if;
if ack = '1' then ack_cnt <= ack_cnt + 1; end if;
end if;
end if;
end process req_ack_counter;
...
assert all_requests_acked;
end architecture pipelined;
</source>


Счетчики запросов и подтверждения выполняются, используя сигналы <code>req_cnt</code> и <code>ack_cnt</code> и процесс <code>req_ack_counter</code>. Мы декларируем свойство <code>all_requests_acked</code>, которое выражает условие верификации для проекта. Мы, также, включаем декларацию времени по-умолчанию для архитектуры. Это подходит для утверждения директив, которые мы писали в области деклараций архитектуры, утверждая, что условие верификации выполняется.
</blockquote>


Существует один случай, где встроенный в VHDL PSL может привести к двусмысленности. И PSL, и VHDL включают в себя выражения утверждений, но их смысл разный. Если мы напишем выражение вида:

assert not (a and b) report "a and b are both true";


оно может быть интерпретирована, как регулярное параллельное выражение VHDL утверждения, которое проверяется, когда <code>a</code> или <code>b</code> меняют значение. Также, оно может быть интерпретировано, как директива утверждения PSL, которая предполагает свойство <code>not (a and b)</code>, выполняющееся во времени 0. В интересах совместимости с более ранними версиями языка, VHDL интерпретирует такие двусмысленные выражения, как регулярные параллельные выражения VHDL утверждений. Если мы действительно хотим написать директиву PSL утверждения такого вида, мы можем модифицировать свойство, таким образом получить однозначное PSL свойство, например:

assert next[0] not (a and b) report "a and b are both true";


В PSL код верификации может быть написан в блоках верификации (<code>vunit</code>, <code>vprop</code> и
<code>vmode</code> блоки), которые связаны с экземплярами entity и архитектур VHDL. VHDL применяет такие блоки верификации, как первичные блоки проекта. Таким образом, они могут быть декларированы в файлах VHDL проекта и проанализированы в библиотеках VHDL проекта.


Блок верификации может включать в себя обязательную информацию, которая определяет компонент образца, для которого применяется директива. Также, мы можем связать блок верификации, как часть конфигураций проекта. Единственное место, для того чтобы сделать это - декларация конфигураций, представленных в главе 13. Если мы хотим связать один и более блоков верификации к головному entity в декларации конфигураций, мы подключаем связывающую информацию, в соответствии со следующим синтаксическим правилом:

configuration_declaration ⇐
'''configuration''' identifier '''of''' ''entity''_name '''is'''
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
block_configuration
'''end''' [ '''configuration''' ] [ identifier ] ;


Всякий раз, когда в декларации конфигурации экземпляра, либо в головном уровне иерархии проекта или как экземпляра компонента в более большом проекте, названные блоки верификации интерпретируются в контексте entity и архитектуры. Это означает, что имена, используемые в блоках верификации интерпретируются в контексте entity.

<blockquote>'''EXAMPLE 18.9''' ''Binding a verification unit in a configuration declaration''
----
Suppose we have a verification unit that ensures two outputs named Q and Q_n are
complementary when sampled on rising edges of a signal named clk. The verification
unit is

'''vunit''' complementary_outputs {
'''assert always''' Q = '''not''' Q_n;
}

We can bind this verification unit to various parts of a design. For example, a gatelevel model of a D flipflop might be described as follows:

<source lang="vhdl">
entity D_FF is
port ( clk, reset, D : in bit;
Q, Q_n : out bit );
end entity D_FF;

architecture gate_level of D_FF is
component and2 is ...
...
begin
G1 : and2 ...
...
end architecture gate_level;
</source>

A configuration declaration for the D flipflop can bind the verification unit to the top-level entity as follows:

<source lang="vhdl">
configuration fast_sim of D_FF is
use vunit complementary_outputs;
for gate_level
for all : and2
...
end for;
...
end for;
end configuration fast_sim;
</source>

We could then instantiate the configuration in a design, and for each instance, the
verification unit <code>complementary_outputs</code> would be bound to the instantiated entity
and architecture.

</blockquote>

We can also bind verification units to component instances that are configured bycomponent configuration nested within a configuration declaration. The augmented form
of component configuration, assuming the components are bound to an entity and archi-
tecture, and the architecture is further configured, is

component_configuration ⇐
'''for''' component_specification
binding_indication ;
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
[ block_configuration ]
'''end for''' ;

In this case, the named verification units are bound to the instances specified in the
component configuration.

<blockquote>
'''EXAMPLE 18.10''' ''Binding a verification unit in a component configuration''
----
Suppose we instantiate a parallel-in/serial-out shift register within an RTL design:

<source lang="vhdl">
entity system is
...
end entity system;

architecture RTL of system is
component shift_reg is
port ( clk, reset, D : in bit_vector;
Q, Q_n : out bit );
end component shift_reg;
...
begin
serializer : shift_reg ...;
...
end architecture RTL;
</source>

We can write a configuration declaration that binds an entity and architecture to
the component instance and that also binds the complementary_outputs verification
unit shown in Example 18.9:

<source lang="vhdl">
configuration verifying of system is
for RTL
for serializer : shift_reg
use entity work.shift_reg(RTL);
use vunit complementary_outputs;
end for;
end for;
end configuration verifying;
</source>

In this case, the assertion in the verification unit applies to the Q and Q_n outputs
of the shift register entity bound to the serializer component instance.

</blockquote>

The third place in which we can bind verification units in a VHDL design is in a con-
figuration specification in the architecture where components are instantiated. The aug-
mented syntax rule for a configuration specification, again assuming components are
bound to an entity and architecture, is

configuration_specification ⇐
'''for''' component_specification
binding_indication ;
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
'''end for''' ;

This is similar to the form in a component configuration, but without the nested configuration for the architecture.

<blockquote>
'''EXAMPLE 18.11''' ''Binding a verification unit in a configuration specification''
----
We can revise the architecture of Example 18.10 to include the binding information
directly, rather than in a separate configuration. The revised architecture is

<source lang="vhdl">
architecture RTL of system is
component shift_reg is
...
end component shift_reg;

for serializer : shift_reg
use entity work.shift_reg(RTL);
use vunit complementary_outputs;
end for;
begin
serializer : shift_reg ...;
...
end architecture RTL;
</source>
</blockquote>

Since a verification unit may include binding information as part of its declaration,
there is potential for that information to conflict with binding information we write inconfiguration. VHDL prevents such conflict by making it illegal to bind a verification unit
in a configuration if the declaration of the unit already includes binding information.
Hence, we would normally only write verification bindings in configurations for general-purpose verification units, and not for those written with particular instances in mind. In
any case, it would be an error if we wrote a verification unit binding for a component
instance that had no bound entity and architecture.

In addition to binding verification units directly in their declaration or indirectly in
configurations, VHDL allows a tool to bind additional verification units through
implementation-defined means. That might include command-line options, script commands, or selection using a graphical user interface.

There are a couple of further points to make about PSL embedded in VHDL. First, PSL
has a rich set of reserved words, some of which may conflict with VHDL identifiers. The
following PSL keywords are VHDL reserved words, and cannot be used as identifiers:

assert
assume
assume_guarantee
cover
default
fairness
property
restrict
restrict_guarantee
sequence
strong
vmode
vprop
vunit

Other PSL reserved words are only recognized as such within VHDL code when they
occur in PSL declarations and directives. They can be used as VHDL identifiers, but such
identifiers are hidden within PSL declarations and directives. For example, we can legally
write the following declaration:

function rose ( x : boolean ) return boolean is ...;

But if we then declare a sequence:

sequence cover_fifo_empty is
{reset_n && rose(cnt = 0)};

The reference to <code>rose</code> in the sequence declaration is to the PSL built-in function, not to
the declaration written in VHDL.

Second, PSL includes features for declaring and instantiating macros, and allows for
preprocessor directives. These features can only be used in PSL verification units, not in
other VHDL design units.

<blockquote>
'''VHDL-87, -93, and -2002'''
----
These versions of VHDL do not allow PSL to be embedded within VHDL models. PSL
code must be written in separate verification units and bound to the VHDL design us-
ing tool-defined means.
</blockquote>

PSL/The designers guide to VHDL/18.3 Embedded PSL in VHDL

2013-12-06T07:29:54Z

Valentin: /* 18.3 PSL встроенный в VHDL */

PSL/The designers guide to VHDL/18.3 Embedded PSL in VHDL

2013-12-02T10:56:06Z

Valentin: /* 18.3 PSL встроенный в VHDL */

PSL/The designers guide to VHDL/18.3 Embedded PSL in VHDL

2013-11-28T10:16:14Z

Valentin: /* 18.3 Embedded PSL in VHDL */

{{PSL TOC}}

== 18.3 PSL встроенный в VHDL ==

PSL is the IEEE Standard Property Specification Language (IEEE Std 1850). It allows specification of temporal properties of a model that can be verified either statically (using a
formal proof tool) or dynamically (using simulation checkers). VHDL allows PSL code to
be embedded as part of a VHDL model. This makes design for verification a much more
natural activity, and simplifies development and maintenance of models. Since PSL is itself
a significant language, we won’t describe all of its features in detail in this book. Instead,
we will just describe the way in which PSL can be embedded in VHDL. For a full description of PSL and its use in verifying designs, the interested reader is referred to other published books on the subject. (See, for example, ''A Practical Introduction to PSL'' [4].)

In VHDL we can include PSL property, sequence, and default clock declarations in
the declarative part of an entity, architecture, block statement (see Chapter 23), generate
statement, or package declaration. We can then use the declared properties and sequences
in PSL directives written in the corresponding statement parts.

Any properties that we write in PSL declarations and directives must conform to PSL’s
simple subset rules. In practice, this means that we can only write properties in which time
moves forward from left to right through the property. Two examples from the PSL standard illustrate this. First, the following property is in the simple subset:

always (a -> next[3] b)

This property states that if <code>a</code> is true, then three cycles later, <code>b</code> is true; that is, time moves
forward three cycles as we scan the property left to right. In contrast, the following property is not in the simple subset:

always ((a && next[3] b) -> c)

This property states that if <code>a</code> is true and <code>b</code> is true three cycles later, then <code>c</code> must have
been true at the time <code>a</code> was true. The problem with this property is that time goes backward from <code>b</code> being true to <code>c</code> being true. A tool to check such a property is much more
complex than one to check properties in the simple subset.

PSL directives require specification of a clock that determines when temporal expressions are evaluated. We can include a clock expression in a directive. However, since the
same clock usually applies to all directives in a design, it is simpler to include a default
clock declaration. If we write a default clock declaration in a region of a design, it applies
to any PSL directives written in that region. We can include at most one default clock declaration in any given region.

<blockquote>
'''EXAMPLE 18.8''' ''Pipelined handshake assertion''
----
In their book ''Assertion-Based Design'' [7], Foster ''et al''. describe a verification pattern
for a system in which handshaking is pipelined. In their example, a system can receive
up to 16 requests before acknowledging any of them. The system counts the number
of requests and acknowledgments and includes an assertion that, for every request
with a given request count, there is an acknowledgment with the same count within
100 clock cycles. We can describe the system in VHDL as follows:

<source lang="vhdl">
library ieee; context ieee.ieee_std_context;
entity slave is
port ( clk, reset : in std_ulogic;
req : in std_ulogic;
ack : out std_ulogic;
... );
end entity slave;
architecture pipelined of slave is
signal req_cnt, ack_cnt : unsigned(3 downto 0);
default clock is rising_edge(clk);
property all_requests_acked is
forall C in {0 to 15}:
always {req and req_cnt = C} |=>
{[*0 to 99]; ack and ack_cnt = C};
begin
req_ack_counter : process (clk) is
begin
if rising_edge(clk) then
if reset = '1' then
req_cnt <= "0000"; ack_cnt <= "0000";
else
if req = '1' then req_cnt <= req_cnt + 1; end if;
if ack = '1' then ack_cnt <= ack_cnt + 1; end if;
end if;
end if;
end process req_ack_counter;
...
assert all_requests_acked;
end architecture pipelined;
</source>

The counters for requests and acknowledgments are implemented using the signals <code>req_cnt</code> and <code>ack_cnt</code> and the process <code>req_ack_counter</code>. We declare a property,
<code>all_requests_acked</code> that expresses the verification condition for the design. We also
include a default clock declaration for the architecture. It applies to the assert directive
that we write in the statement part of the architecture, asserting that the verification
condition holds.
</blockquote>

There is one case where embedding of PSL within VHDL may lead to ambiguity. Both
PSL and VHDL include assert statements, but their meanings differ. If we write a statement
of the form

assert not (a and b) report "a and b are both true";

it could be interpreted as a regular VHDL concurrent assertion statement that is to be
checked whenever either of <code>a</code> or <code>b</code> changes value. Alternatively, it could be interpreted as
a PSL assert directive that requires the property <code>not (a and b)</code> to hold at time 0. In the
interest of backward compatibility with earlier versions of the language, VHDL interprets
such ambiguous statements as regular VHDL concurrent assertion statements. If we really
want to write a PSL assert directive of this form, we could modify the property so thatis unambiguously a PSL property, for example:

assert next[0] not (a and b) report "a and b are both true";

In PSL, verification code can be written in verification units (<code>vunit</code>, <code>vprop</code> and
<code>vmode</code> units) that are bound to instances of VHDL entities and architectures. VHDL considers such verification units as primary design units. Thus, they can be declared in VHDL design files and analyzed into VHDL design libraries.

A verification unit can include binding information that identifies a component instance to which directives apply. Alternatively, we can bind a verification unit as part of
the configuration of a design. One place to do that is in a configuration declaration, introduced in Chapter 13. If we want to bind one or more verification units to the top-level
entity in a configuration declaration, we include binding information according to the following synax rule:

configuration_declaration ⇐
'''configuration''' identifier '''of''' ''entity''_name '''is'''
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
block_configuration
'''end''' [ '''configuration''' ] [ identifier ] ;

Whenever the configuration declaration is instantiated, either at the top-level of a design hierarchy or as a component instance within a larger design, the named verification
units are bound to the instance of the named entity and architecture. That means the
names used in the verification units are interpreted in the context of the entity instance.

<blockquote>'''EXAMPLE 18.9''' ''Binding a verification unit in a configuration declaration''
----
Suppose we have a verification unit that ensures two outputs named Q and Q_n are
complementary when sampled on rising edges of a signal named clk. The verification
unit is

'''vunit''' complementary_outputs {
'''assert always''' Q = '''not''' Q_n;
}

We can bind this verification unit to various parts of a design. For example, a gatelevel model of a D flipflop might be described as follows:

<source lang="vhdl">
entity D_FF is
port ( clk, reset, D : in bit;
Q, Q_n : out bit );
end entity D_FF;

architecture gate_level of D_FF is
component and2 is ...
...
begin
G1 : and2 ...
...
end architecture gate_level;
</source>

A configuration declaration for the D flipflop can bind the verification unit to the top-level entity as follows:

<source lang="vhdl">
configuration fast_sim of D_FF is
use vunit complementary_outputs;
for gate_level
for all : and2
...
end for;
...
end for;
end configuration fast_sim;
</source>

We could then instantiate the configuration in a design, and for each instance, the
verification unit <code>complementary_outputs</code> would be bound to the instantiated entity
and architecture.

</blockquote>

We can also bind verification units to component instances that are configured bycomponent configuration nested within a configuration declaration. The augmented form
of component configuration, assuming the components are bound to an entity and archi-
tecture, and the architecture is further configured, is

component_configuration ⇐
'''for''' component_specification
binding_indication ;
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
[ block_configuration ]
'''end for''' ;

In this case, the named verification units are bound to the instances specified in the
component configuration.

<blockquote>
'''EXAMPLE 18.10''' ''Binding a verification unit in a component configuration''
----
Suppose we instantiate a parallel-in/serial-out shift register within an RTL design:

<source lang="vhdl">
entity system is
...
end entity system;

architecture RTL of system is
component shift_reg is
port ( clk, reset, D : in bit_vector;
Q, Q_n : out bit );
end component shift_reg;
...
begin
serializer : shift_reg ...;
...
end architecture RTL;
</source>

We can write a configuration declaration that binds an entity and architecture to
the component instance and that also binds the complementary_outputs verification
unit shown in Example 18.9:

<source lang="vhdl">
configuration verifying of system is
for RTL
for serializer : shift_reg
use entity work.shift_reg(RTL);
use vunit complementary_outputs;
end for;
end for;
end configuration verifying;
</source>

In this case, the assertion in the verification unit applies to the Q and Q_n outputs
of the shift register entity bound to the serializer component instance.

</blockquote>

The third place in which we can bind verification units in a VHDL design is in a con-
figuration specification in the architecture where components are instantiated. The aug-
mented syntax rule for a configuration specification, again assuming components are
bound to an entity and architecture, is

configuration_specification ⇐
'''for''' component_specification
binding_indication ;
{ '''use vunit''' ''verification_unit''_name { , ... } ; }
'''end for''' ;

This is similar to the form in a component configuration, but without the nested configuration for the architecture.

<blockquote>
'''EXAMPLE 18.11''' ''Binding a verification unit in a configuration specification''
----
We can revise the architecture of Example 18.10 to include the binding information
directly, rather than in a separate configuration. The revised architecture is

<source lang="vhdl">
architecture RTL of system is
component shift_reg is
...
end component shift_reg;

for serializer : shift_reg
use entity work.shift_reg(RTL);
use vunit complementary_outputs;
end for;
begin
serializer : shift_reg ...;
...
end architecture RTL;
</source>
</blockquote>

Since a verification unit may include binding information as part of its declaration,
there is potential for that information to conflict with binding information we write inconfiguration. VHDL prevents such conflict by making it illegal to bind a verification unit
in a configuration if the declaration of the unit already includes binding information.
Hence, we would normally only write verification bindings in configurations for general-purpose verification units, and not for those written with particular instances in mind. In
any case, it would be an error if we wrote a verification unit binding for a component
instance that had no bound entity and architecture.

In addition to binding verification units directly in their declaration or indirectly in
configurations, VHDL allows a tool to bind additional verification units through
implementation-defined means. That might include command-line options, script commands, or selection using a graphical user interface.

There are a couple of further points to make about PSL embedded in VHDL. First, PSL
has a rich set of reserved words, some of which may conflict with VHDL identifiers. The
following PSL keywords are VHDL reserved words, and cannot be used as identifiers:

assert
assume
assume_guarantee
cover
default
fairness
property
restrict
restrict_guarantee
sequence
strong
vmode
vprop
vunit

Other PSL reserved words are only recognized as such within VHDL code when they
occur in PSL declarations and directives. They can be used as VHDL identifiers, but such
identifiers are hidden within PSL declarations and directives. For example, we can legally
write the following declaration:

function rose ( x : boolean ) return boolean is ...;

But if we then declare a sequence:

sequence cover_fifo_empty is
{reset_n && rose(cnt = 0)};

The reference to <code>rose</code> in the sequence declaration is to the PSL built-in function, not to
the declaration written in VHDL.

Second, PSL includes features for declaring and instantiating macros, and allows for
preprocessor directives. These features can only be used in PSL verification units, not in
other VHDL design units.

<blockquote>
'''VHDL-87, -93, and -2002'''
----
These versions of VHDL do not allow PSL to be embedded within VHDL models. PSL
code must be written in separate verification units and bound to the VHDL design us-
ing tool-defined means.
</blockquote>

PSL/A Practical Introduction to PSL/Some Philosophy/ru

2013-11-25T11:04:35Z

Valentin: /* 3.5 Reporting a failure */

{{PSL TOC}}

== Немного философии ==


Мы рассмотрели немного основ PSL и получили ощущение того, как используется. Перед тем как продолжить, мы обсудим некоторые концепции в корне PSL.

=== 3.1 Утверждения против свойств ===


Как мы уже видели, утверждения PSL состоят из ключевого слова assert плюс ''свойства'' PSL для утверждения, разделенных точкой с запятой. Например, в утверждении <code>assert always (a -> next b);</code>, свойство - <code>always (a -> next b)</code>. Свойство выполняется или не выполняется в данном тракте. Утверждение, с другой стороны, указывает программе верификации, что свойство было утверждено, и требуется выполнение. Далее в книге мы будем внимательно рассматривать отличия между свойствами, которые просто описывают поведения, и утверждения,которые устанавливают требования. Например, мы можем сказать, что утверждение <code>assert always (a -> next b);</code> требует, чтобы когда бы сигнал <code>a</code> не утверждался, сигнал <code>b</code> должен будет утвердиться в следующем цикле. Однако, мы никогда не скажем такого о свойстве <code>always (a -> next b)</code>, по двум причинам. Первая - потому что если свойство используется в предположении (<code>assume always (a -> next b);</code>), то нету никаких требований. Вторая - потому что свойство может использоваться, как под-свойство более сложного свойства, и если так, то не может исходить требований от него самого.

=== 3.2 Понятие времени ===


Когда Булево утверждение встроено в код, который выполняется, как в простом утверждении Java или (моделирования) VHDL, понятие времени не нуждается в определении - утверждение проверяется всякий раз, когда заявление, содержащее утверждение выполняется. Для более сложных утверждений PSL, которые, во-первых, находяться отдельно от кода (таким образом понятие “исполнение” чужое для них), и во-вторых охватывает множество шагов во времени, понятию времени необходими уелить больше внимания.


PSL предполагает, что время дискретно, таким образом, время состоит из последовательности оцененных циклов. Значение свойства PSL определенно по отношению к такой последовательности циклов. В этой книге, мы будем называть такую последовательность циклов ''трактом''.


PSL не указывает как идет время - т.е. не указывает, как данная последовательность циклов получается из проекта под верификацией. Это значит, что последовательность циклов, для двух программ верификации, необязательно совпадет. Например, симулятор, базирующийся на циклах видит последовательность значений сигнала подсчитанную цикл за циклом, в то время, как симулятор базирующийся на изменениях, запущенный для этого же проекта, видит более детализированную последовательность значений сигнала.


Тем не менее, существует путь гарантировать, что значение свойства PSL не влияет на степень детализации времени, с точки зрения программ верификации. Свойства PSL могут быть модифицированы, используя ''временное выражение'' для того, чтобы показать, что время должно быть получено во временных циклах временного выражения. В случаи временного свойства, результат программы базирующейся на циклах должен быть такой же, как и для программы базирующейся на изменениях. PSL допускает спецификацию ''времени по-умолчанию'', таким образом, что время не должно быть упомянуто отдельно для каждого свойства. Далее в этой книге мы предполагаем однократный тактовый проект под модель, базирующуюся на циклах, таким образом в большинстве примеров опущены явные упоминания о времени.

===3.3 Проекты и тракты ===


Цель свойства PSL описать желаемое поведение проекта. Как правило, это удобно для проверки отдельных трактов проекта. Фундаментальный язык, который используется в данной книге, применяет данный подход, и таким образом, на протяжении данной книги мы будем интересоваться выполняется ли некое свойство в этом тракте или нет. Фундаментальный язык подходит, как для статической (формальной), так и для динамической (базирующейся на моделировании) верификации.


Другой подход, используется дополнительным ветвлением расширения, используется дерево структуры, которое представляет несколько путей. Этот подход подходить только для формальной верификации, и, очень кратко, затрагивается в главе 11.

=== 3.4 Текущий цикл, субтракты, модульность ===


Когда свойство PSL состоит из двух и больше под-свойств, оно проверяется на тракте, иногда это необходимо для понятия значения под-свойств на субтрактах. ''Текущий цикл'' это имя мы дали первому циклу тракта или субтракта, на котором мы оцениваем свойство или под-свойство.


Предполагая, что циклы тракта нумеруются, начиная с 0, текущий цикл утверждения - 0. Текущий цикл под-свойства, какого-нибудь вшитого свойства, зависит от своего использования во вшитом свойстве. Операнды Булевого оператора получают такой же текущий цикл, как и родительское свойство. Операнды временных операторов получают текущий цикл, который связан с текущим циклом родительского свойства, в случаи, если это указано временным оператором. Например, оператор next увеличивает текущий цикл на один, оператор always создает “несколько экземпляров” под-свойства, каждый из которых получает текущий цикл, который соответствует текущему циклу или некоторому будущему циклу.


Примечание: Очень важно понять, что термин “несколько экземпляров” предназначен для смысла, который используется для понимания оператора <code>always</code>. ''Не'' предназначем показать, что каждый экземпляр существует; причем это не значит, что программе реализации PSL надо создать много экземпляров проверки утверждения, порождение нескольких экземпляров процесса или в любом другом случаи слова “несколько экземпляров” означают актуальные экземпляры чего-либо. Наоборот, существуют множество эффективных реализаций PSL, в которых оператор <code>always</code> не создает нескольких экземпляров. Термин “несколько экземпляров” - это хороший способ усилить понятие того, как работает оператор <code>always</code>, наивная и неэффективная реализация могжет также реализовывать несколько экземпляров проверки или процесса.


Возвращаясь к нашему основному пункту рассмотрения, рассмотрим утверждение <code>assert always (a -> next b);</code>. Текущий цикл <code>always (a -> next b)</code> - 0. Выполнение <code>always (a -> next b)</code> в цикле 0, зависит от выполнения под-свойства <code>(a -> next b)</code> в каждом цикле с нулевого. Текущий цикл для частной оценки под-свойства <code>(a -> next b)</code> будет некий цикл ''N''. В итоге, для того, чтобы определить действительно ли под-свойство <code>(a -> next b)</code> выполняется в цикле ''N'', мы должны оценить под-свойство a и следующий b с текущим циклом ''N'', что значит, что нам надо оценить под-свойство b с текущим циклом ''N'' + 1.


Для того чтобы сделать обсуждения конкретней, давайте рассмотрим наше утверждение, утверждение 3.1а на тракте 3.1(i). Сигнал а выполняется в циклах 4 и 8. Сигнал b выполняется в цикле 5, <code>next b</code> выполняется в цикле 4. Это показано в тракте 3.1(ii), аннотированная версия тракта 3.1(i). В то время, как а выполняется в циклах 4 и 8, и <code>next b</code> выполняется в цикле 4, мы получаем, что <code>(a -> next b)</code> выполняется во всех циклах, а цикл 8,как показано на тракте 3.1(ii). (Запомните, что в других частях по умолчанию справедливо, что <code>(a -> next b)</code> выполняется во всех циклах, где <code>a</code> не выполняется, и в дополнение во всех циклах где <code>a</code> выполняется и <code>next b</code> тоже.) Все свойство <code>always (a -> next b)</code> выполняется в циклах 9, 10, 11, 12, 13 (потому что в этих циклах <code>(a -> next b)</code> выполняется “сейчас” и во всех следующих циклах). Таким образом, утверждение 3.1a не выполняется на тракте 3.1(i) (потому что оно не выполняется в цикле 0 - первом цикле тракта).

{| align=center
! [[Файл:Psl fig3.1.png]]
|-
|<pre>
assert always (a -> next b); (3.1a)
</pre>
|-
! Рис. 3.1: Конкретный пример
|}


Приведенное выше описание кажется простым. Однако, идея модульности скрывает некоторые тонкие моменты, например, что значение свойства <code>a</code> зависит только от текущего цикла. Таким образом, утверждение 3.2а выполняется нна тракте 3.2(i), потому что сигнал <code>a</code> выполняется в цикле 0. Если вы хотите выразить тот факт, что <code>a</code> должен выполняться в каждом цикле, вы должны использовать оператор <code>always</code>, как в утверждении 3.2b. Утверждение 3.2b не выполняется на тракте 3.2(i).


Другой тонкий момент, что свойство может выполняться в суффиксе тракта,а не на самом тракте. Таким образом, свойство <code>always a</code> выполняется на субтракте тракта 3.2(i), начиная с циклов 12, 13, 14. Это будет важно, если мы используем свойство <code>always a</code>, как под-свойство какого-либо друо свойства. Например, утверждение 3.2c выполняется на тракте 3.2(i), потому что свойство <code>always a</code> выполняется на 12''ти'' следующих циклах.


Последнее, циклы вовлеченные в в подсчет левой стороны логической импликации могут прекрываться с циклами вовлеченными в подсчет правой стороны логической импликации. Например, рассмотрим утверждение 3.3a на тракте 3.3(i). Утверждение 3.3a выполняется на тракте 3.3(i), потому что под-свойство <code>(a && next[6] (b)) -> (c && next[2] (d))</code> выполняется на всех циклах. Оно выполняется в цикле 2, потому что левая сторона <code>(a && next[6] (b))</code> выполняется и в дополнение правая сторона <code>(c && next[2] (d))</code>, тоже выполняется. Оно выполняется во всех других циклах, потому что, если часть “if” логического исполнения не выполняется, то по-умолчанию часть “else” принимает значение правда

{| align=center
! [[Файл:Psl fig3.2.png]]
|-
!(i) Утверждение 3.2a и 3.2c выполняются, но 3.2b нет
|-
|<pre>
assert a; (3.2a)
assert always a; (3.2b)
assert next[12] (always a); (3.2c)
</pre>
|-
! Рис. 3.2: Важность оператора always
|}

{| align=center
! [[Файл:Psl fig3.3.png]]
|-
!(i) Иллюстрация перекрытие левой и правой стороны 
утверждение 3.3a. Утверждение 3.3a выполняется.
|-
|<pre>
assert always ((a && next[6](b)) -> (c && next[2](d))); (3.3a)
</pre>
|-
! Рис. 3.3: Текущий цикл
|}


Предварительно, например в рассматриваемых утверждениях 2.2а и 2.3b, мы видели случаи, где были перекрытия между циклами вовлеченными в удовлетворение двух разных случаев левой стороны логической импликации. Эти перекрытия вызваны присутствием оператора <code>always</code> в свойстве. Если мы удалим этот оператор, вопрос перекрытия исчезнет из утверждений 2.2a и 2.3b. Перекрытие утверждения 3.3а отличается от перекрытия утверждений 2.2a и 2.3b, и это очень важно: утверждение 3.3a написано таким образом, что циклы вовлеченные в подсчет левой стороны логической импликации перекрываются с циклами правой логической импликации: подсчитывая часть “if” логической вовлекают рассматриваемый текущий цикл, а также “предстоящие” шесть циклов, в то время как подсчет части “then” логической импликации вовлекает рассматриваемый текущий цикл и также “предстоящие” два цикла. Таким образом,перекрытие появляется от самой логической импликации. Такой стиль PSL свойств, обычно, труден для новых пользователей PSL, и вообще это не интуитивный способ использования языка. Поэтому, такие свойства не рекомендуется использовать, и <code>простое подмножество</code> ограничений языка PSL не позволяет использование таких свойств. Мы обсудим простое подмножество в деталях поздней. На данный момент, запомните, что если вы написали свойство, в котором циклы вовлечены в подсчет левой стороны одного оператора перекрываются в течение более одного цикла с циклами вовлеченными для подсчета правой стороны того же оператора, то вы написали свойство не относящиеся к простому подмножеству.

=== 3.5 Сообщение об ошибке ===


Рассмотрим утверждение 3.4а на тракте, показаном на рисунке 3.4. Очевидно, утверждение 3.4a не выполняется на нем. Сейчас рассмотрим четыре разных вида инструментов верификации, каждый из которых, выдает сообщение об ошибке утверждения 3.4a, индикаций сигнала, называемого “failure” в трактах 3.4(i), 3.4(ii), 3.4(iii) и 3.4(iv). Инструмент 1 выдал сообщение об ошибке на цикле 4, наиболее ранний выриант,на котором это можно выявить. Инструмент 2 выдал сообщение на цикле 4, а также на цикле 7, когда <code>b</code> утверждается второй раз. Инструмент 3 выдал сообщение в конце тракта, и инструмент 4 выдал сообщение на цикле 11,когда утверждается <code>a</code>.


Какой инструмент сработал правильно? Правильный ответ - все они. PSL определяет выполняется ли свойство в тракте - вот и все. ничего не сказано о том, когда инструмент, динамический или статический, должен выдать сообщение по результатам анализов. Таким образом, нету смысла в вопросе - какой инструмент правильный? Все они показали, что свойство не выполняется на тракте, поэтому все они верны. Индикация ошибки показанная на все тракте может пониматься, как помощь для дебага, помогая пользователям понять,где находиться ошибка на тракте. Пока PSL показывает эти ошибки на трактах, он делает свою работу.

{| align=center
! [[Файл:Psl fig3.4.png]]
|-
|<pre>
assert always (a -> never b); (3.4a)
</pre>
|-
! Рис. 3.4: Четыре инструмент,выдающих сообщение об ошибке утверждения 3.4a на одном и том же тракте
|}

PSL/A Practical Introduction to PSL/Some Philosophy/ru

2013-11-25T10:50:09Z

Valentin: /* 3.4 Текущий цикл, субтракты, модульность */

{{PSL TOC}}

== Немного философии ==


Мы рассмотрели немного основ PSL и получили ощущение того, как используется. Перед тем как продолжить, мы обсудим некоторые концепции в корне PSL.

=== 3.1 Утверждения против свойств ===


Как мы уже видели, утверждения PSL состоят из ключевого слова assert плюс ''свойства'' PSL для утверждения, разделенных точкой с запятой. Например, в утверждении <code>assert always (a -> next b);</code>, свойство - <code>always (a -> next b)</code>. Свойство выполняется или не выполняется в данном тракте. Утверждение, с другой стороны, указывает программе верификации, что свойство было утверждено, и требуется выполнение. Далее в книге мы будем внимательно рассматривать отличия между свойствами, которые просто описывают поведения, и утверждения,которые устанавливают требования. Например, мы можем сказать, что утверждение <code>assert always (a -> next b);</code> требует, чтобы когда бы сигнал <code>a</code> не утверждался, сигнал <code>b</code> должен будет утвердиться в следующем цикле. Однако, мы никогда не скажем такого о свойстве <code>always (a -> next b)</code>, по двум причинам. Первая - потому что если свойство используется в предположении (<code>assume always (a -> next b);</code>), то нету никаких требований. Вторая - потому что свойство может использоваться, как под-свойство более сложного свойства, и если так, то не может исходить требований от него самого.

=== 3.2 Понятие времени ===


Когда Булево утверждение встроено в код, который выполняется, как в простом утверждении Java или (моделирования) VHDL, понятие времени не нуждается в определении - утверждение проверяется всякий раз, когда заявление, содержащее утверждение выполняется. Для более сложных утверждений PSL, которые, во-первых, находяться отдельно от кода (таким образом понятие “исполнение” чужое для них), и во-вторых охватывает множество шагов во времени, понятию времени необходими уелить больше внимания.


PSL предполагает, что время дискретно, таким образом, время состоит из последовательности оцененных циклов. Значение свойства PSL определенно по отношению к такой последовательности циклов. В этой книге, мы будем называть такую последовательность циклов ''трактом''.


PSL не указывает как идет время - т.е. не указывает, как данная последовательность циклов получается из проекта под верификацией. Это значит, что последовательность циклов, для двух программ верификации, необязательно совпадет. Например, симулятор, базирующийся на циклах видит последовательность значений сигнала подсчитанную цикл за циклом, в то время, как симулятор базирующийся на изменениях, запущенный для этого же проекта, видит более детализированную последовательность значений сигнала.


Тем не менее, существует путь гарантировать, что значение свойства PSL не влияет на степень детализации времени, с точки зрения программ верификации. Свойства PSL могут быть модифицированы, используя ''временное выражение'' для того, чтобы показать, что время должно быть получено во временных циклах временного выражения. В случаи временного свойства, результат программы базирующейся на циклах должен быть такой же, как и для программы базирующейся на изменениях. PSL допускает спецификацию ''времени по-умолчанию'', таким образом, что время не должно быть упомянуто отдельно для каждого свойства. Далее в этой книге мы предполагаем однократный тактовый проект под модель, базирующуюся на циклах, таким образом в большинстве примеров опущены явные упоминания о времени.

===3.3 Проекты и тракты ===


Цель свойства PSL описать желаемое поведение проекта. Как правило, это удобно для проверки отдельных трактов проекта. Фундаментальный язык, который используется в данной книге, применяет данный подход, и таким образом, на протяжении данной книги мы будем интересоваться выполняется ли некое свойство в этом тракте или нет. Фундаментальный язык подходит, как для статической (формальной), так и для динамической (базирующейся на моделировании) верификации.


Другой подход, используется дополнительным ветвлением расширения, используется дерево структуры, которое представляет несколько путей. Этот подход подходить только для формальной верификации, и, очень кратко, затрагивается в главе 11.

=== 3.4 Текущий цикл, субтракты, модульность ===


Когда свойство PSL состоит из двух и больше под-свойств, оно проверяется на тракте, иногда это необходимо для понятия значения под-свойств на субтрактах. ''Текущий цикл'' это имя мы дали первому циклу тракта или субтракта, на котором мы оцениваем свойство или под-свойство.


Предполагая, что циклы тракта нумеруются, начиная с 0, текущий цикл утверждения - 0. Текущий цикл под-свойства, какого-нибудь вшитого свойства, зависит от своего использования во вшитом свойстве. Операнды Булевого оператора получают такой же текущий цикл, как и родительское свойство. Операнды временных операторов получают текущий цикл, который связан с текущим циклом родительского свойства, в случаи, если это указано временным оператором. Например, оператор next увеличивает текущий цикл на один, оператор always создает “несколько экземпляров” под-свойства, каждый из которых получает текущий цикл, который соответствует текущему циклу или некоторому будущему циклу.


Примечание: Очень важно понять, что термин “несколько экземпляров” предназначен для смысла, который используется для понимания оператора <code>always</code>. ''Не'' предназначем показать, что каждый экземпляр существует; причем это не значит, что программе реализации PSL надо создать много экземпляров проверки утверждения, порождение нескольких экземпляров процесса или в любом другом случаи слова “несколько экземпляров” означают актуальные экземпляры чего-либо. Наоборот, существуют множество эффективных реализаций PSL, в которых оператор <code>always</code> не создает нескольких экземпляров. Термин “несколько экземпляров” - это хороший способ усилить понятие того, как работает оператор <code>always</code>, наивная и неэффективная реализация могжет также реализовывать несколько экземпляров проверки или процесса.


Возвращаясь к нашему основному пункту рассмотрения, рассмотрим утверждение <code>assert always (a -> next b);</code>. Текущий цикл <code>always (a -> next b)</code> - 0. Выполнение <code>always (a -> next b)</code> в цикле 0, зависит от выполнения под-свойства <code>(a -> next b)</code> в каждом цикле с нулевого. Текущий цикл для частной оценки под-свойства <code>(a -> next b)</code> будет некий цикл ''N''. В итоге, для того, чтобы определить действительно ли под-свойство <code>(a -> next b)</code> выполняется в цикле ''N'', мы должны оценить под-свойство a и следующий b с текущим циклом ''N'', что значит, что нам надо оценить под-свойство b с текущим циклом ''N'' + 1.


Для того чтобы сделать обсуждения конкретней, давайте рассмотрим наше утверждение, утверждение 3.1а на тракте 3.1(i). Сигнал а выполняется в циклах 4 и 8. Сигнал b выполняется в цикле 5, <code>next b</code> выполняется в цикле 4. Это показано в тракте 3.1(ii), аннотированная версия тракта 3.1(i). В то время, как а выполняется в циклах 4 и 8, и <code>next b</code> выполняется в цикле 4, мы получаем, что <code>(a -> next b)</code> выполняется во всех циклах, а цикл 8,как показано на тракте 3.1(ii). (Запомните, что в других частях по умолчанию справедливо, что <code>(a -> next b)</code> выполняется во всех циклах, где <code>a</code> не выполняется, и в дополнение во всех циклах где <code>a</code> выполняется и <code>next b</code> тоже.) Все свойство <code>always (a -> next b)</code> выполняется в циклах 9, 10, 11, 12, 13 (потому что в этих циклах <code>(a -> next b)</code> выполняется “сейчас” и во всех следующих циклах). Таким образом, утверждение 3.1a не выполняется на тракте 3.1(i) (потому что оно не выполняется в цикле 0 - первом цикле тракта).

{| align=center
! [[Файл:Psl fig3.1.png]]
|-
|<pre>
assert always (a -> next b); (3.1a)
</pre>
|-
! Рис. 3.1: Конкретный пример
|}


Приведенное выше описание кажется простым. Однако, идея модульности скрывает некоторые тонкие моменты, например, что значение свойства <code>a</code> зависит только от текущего цикла. Таким образом, утверждение 3.2а выполняется нна тракте 3.2(i), потому что сигнал <code>a</code> выполняется в цикле 0. Если вы хотите выразить тот факт, что <code>a</code> должен выполняться в каждом цикле, вы должны использовать оператор <code>always</code>, как в утверждении 3.2b. Утверждение 3.2b не выполняется на тракте 3.2(i).


Другой тонкий момент, что свойство может выполняться в суффиксе тракта,а не на самом тракте. Таким образом, свойство <code>always a</code> выполняется на субтракте тракта 3.2(i), начиная с циклов 12, 13, 14. Это будет важно, если мы используем свойство <code>always a</code>, как под-свойство какого-либо друо свойства. Например, утверждение 3.2c выполняется на тракте 3.2(i), потому что свойство <code>always a</code> выполняется на 12''ти'' следующих циклах.


Последнее, циклы вовлеченные в в подсчет левой стороны логической импликации могут прекрываться с циклами вовлеченными в подсчет правой стороны логической импликации. Например, рассмотрим утверждение 3.3a на тракте 3.3(i). Утверждение 3.3a выполняется на тракте 3.3(i), потому что под-свойство <code>(a && next[6] (b)) -> (c && next[2] (d))</code> выполняется на всех циклах. Оно выполняется в цикле 2, потому что левая сторона <code>(a && next[6] (b))</code> выполняется и в дополнение правая сторона <code>(c && next[2] (d))</code>, тоже выполняется. Оно выполняется во всех других циклах, потому что, если часть “if” логического исполнения не выполняется, то по-умолчанию часть “else” принимает значение правда

{| align=center
! [[Файл:Psl fig3.2.png]]
|-
!(i) Утверждение 3.2a и 3.2c выполняются, но 3.2b нет
|-
|<pre>
assert a; (3.2a)
assert always a; (3.2b)
assert next[12] (always a); (3.2c)
</pre>
|-
! Рис. 3.2: Важность оператора always
|}

{| align=center
! [[Файл:Psl fig3.3.png]]
|-
!(i) Иллюстрация перекрытие левой и правой стороны 
утверждение 3.3a. Утверждение 3.3a выполняется.
|-
|<pre>
assert always ((a && next[6](b)) -> (c && next[2](d))); (3.3a)
</pre>
|-
! Рис. 3.3: Текущий цикл
|}


Предварительно, например в рассматриваемых утверждениях 2.2а и 2.3b, мы видели случаи, где были перекрытия между циклами вовлеченными в удовлетворение двух разных случаев левой стороны логической импликации. Эти перекрытия вызваны присутствием оператора <code>always</code> в свойстве. Если мы удалим этот оператор, вопрос перекрытия исчезнет из утверждений 2.2a и 2.3b. Перекрытие утверждения 3.3а отличается от перекрытия утверждений 2.2a и 2.3b, и это очень важно: утверждение 3.3a написано таким образом, что циклы вовлеченные в подсчет левой стороны логической импликации перекрываются с циклами правой логической импликации: подсчитывая часть “if” логической вовлекают рассматриваемый текущий цикл, а также “предстоящие” шесть циклов, в то время как подсчет части “then” логической импликации вовлекает рассматриваемый текущий цикл и также “предстоящие” два цикла. Таким образом,перекрытие появляется от самой логической импликации. Такой стиль PSL свойств, обычно, труден для новых пользователей PSL, и вообще это не интуитивный способ использования языка. Поэтому, такие свойства не рекомендуется использовать, и <code>простое подмножество</code> ограничений языка PSL не позволяет использование таких свойств. Мы обсудим простое подмножество в деталях поздней. На данный момент, запомните, что если вы написали свойство, в котором циклы вовлечены в подсчет левой стороны одного оператора перекрываются в течение более одного цикла с циклами вовлеченными для подсчета правой стороны того же оператора, то вы написали свойство не относящиеся к простому подмножеству.

=== 3.5 Reporting a failure ===

Consider Assertion 3.4a on the traces shown in Figure 3.4. Obviously, Assertion
3.4a does not hold on them. Now consider four different verification tools,
each of which reports the failure of Assertion 3.4a as indicated by the signal
called “failure” in Traces 3.4(i), 3.4(ii), 3.4(iii) and 3.4(iv). Tool 1 reports a
failure at cycle 4, the earliest that it can be detected. Tool 2 reports a failure
at cycle 4, but also at cycle 7, when <code>b</code> is asserted for a second time. Tool 3
reports a failure at the end of the trace, and Tool 4 reports a failure at cycle
1, when <code>a</code> is asserted.

Which tool is correct? The answer is that they all are. PSL defines whether
or not a property holds on a trace – that is all. It says nothing about when
a tool, dynamic or static, should report on the results of the analysis. Thus,
there is no meaning in asking whether Tool 1, 2, 3 or 4 is correct. All of
them indicate that the property fails on the trace, so all are correct. The
failure indications shown along the trace can be thought of as debugging aids,
hinting to the user where to look along the trace for the failure. As far as PSL
is concerned, as long as a tool indicates correctly whether or not a property
holds on a trace, it has done its job.

{| align=center
! [[Файл:Psl fig3.4.png]]
|-
|<pre>
assert always (a -> never b); (3.4a)
</pre>
|-
! Fig. 3.4: Four different tools reporting the failure of Assertion 3.4a on the same trace
|}

PSL/A Practical Introduction to PSL/Some Philosophy/ru

2013-11-25T09:29:21Z

Valentin: /* 3.4 Current cycle, sub-traces, and modularity */

{{PSL TOC}}

== Немного философии ==


Мы рассмотрели немного основ PSL и получили ощущение того, как используется. Перед тем как продолжить, мы обсудим некоторые концепции в корне PSL.

=== 3.1 Утверждения против свойств ===


Как мы уже видели, утверждения PSL состоят из ключевого слова assert плюс ''свойства'' PSL для утверждения, разделенных точкой с запятой. Например, в утверждении <code>assert always (a -> next b);</code>, свойство - <code>always (a -> next b)</code>. Свойство выполняется или не выполняется в данном тракте. Утверждение, с другой стороны, указывает программе верификации, что свойство было утверждено, и требуется выполнение. Далее в книге мы будем внимательно рассматривать отличия между свойствами, которые просто описывают поведения, и утверждения,которые устанавливают требования. Например, мы можем сказать, что утверждение <code>assert always (a -> next b);</code> требует, чтобы когда бы сигнал <code>a</code> не утверждался, сигнал <code>b</code> должен будет утвердиться в следующем цикле. Однако, мы никогда не скажем такого о свойстве <code>always (a -> next b)</code>, по двум причинам. Первая - потому что если свойство используется в предположении (<code>assume always (a -> next b);</code>), то нету никаких требований. Вторая - потому что свойство может использоваться, как под-свойство более сложного свойства, и если так, то не может исходить требований от него самого.

=== 3.2 Понятие времени ===


Когда Булево утверждение встроено в код, который выполняется, как в простом утверждении Java или (моделирования) VHDL, понятие времени не нуждается в определении - утверждение проверяется всякий раз, когда заявление, содержащее утверждение выполняется. Для более сложных утверждений PSL, которые, во-первых, находяться отдельно от кода (таким образом понятие “исполнение” чужое для них), и во-вторых охватывает множество шагов во времени, понятию времени необходими уелить больше внимания.


PSL предполагает, что время дискретно, таким образом, время состоит из последовательности оцененных циклов. Значение свойства PSL определенно по отношению к такой последовательности циклов. В этой книге, мы будем называть такую последовательность циклов ''трактом''.


PSL не указывает как идет время - т.е. не указывает, как данная последовательность циклов получается из проекта под верификацией. Это значит, что последовательность циклов, для двух программ верификации, необязательно совпадет. Например, симулятор, базирующийся на циклах видит последовательность значений сигнала подсчитанную цикл за циклом, в то время, как симулятор базирующийся на изменениях, запущенный для этого же проекта, видит более детализированную последовательность значений сигнала.


Тем не менее, существует путь гарантировать, что значение свойства PSL не влияет на степень детализации времени, с точки зрения программ верификации. Свойства PSL могут быть модифицированы, используя ''временное выражение'' для того, чтобы показать, что время должно быть получено во временных циклах временного выражения. В случаи временного свойства, результат программы базирующейся на циклах должен быть такой же, как и для программы базирующейся на изменениях. PSL допускает спецификацию ''времени по-умолчанию'', таким образом, что время не должно быть упомянуто отдельно для каждого свойства. Далее в этой книге мы предполагаем однократный тактовый проект под модель, базирующуюся на циклах, таким образом в большинстве примеров опущены явные упоминания о времени.

===3.3 Проекты и тракты ===


Цель свойства PSL описать желаемое поведение проекта. Как правило, это удобно для проверки отдельных трактов проекта. Фундаментальный язык, который используется в данной книге, применяет данный подход, и таким образом, на протяжении данной книги мы будем интересоваться выполняется ли некое свойство в этом тракте или нет. Фундаментальный язык подходит, как для статической (формальной), так и для динамической (базирующейся на моделировании) верификации.


Другой подход, используется дополнительным ветвлением расширения, используется дерево структуры, которое представляет несколько путей. Этот подход подходить только для формальной верификации, и, очень кратко, затрагивается в главе 11.

=== 3.4 Текущий цикл, субтракты, модульность ===


Когда свойство PSL состоит из двух и больше под-свойств, оно проверяется на тракте, иногда это необходимо для понятия значения под-свойств на субтрактах. ''Текущий цикл'' это имя мы дали первому циклу тракта или субтракта, на котором мы оцениваем свойство или под-свойство.


Предполагая, что циклы тракта нумеруются, начиная с 0, текущий цикл утверждения - 0. Текущий цикл под-свойства, какого-нибудь вшитого свойства, зависит от своего использования во вшитом свойстве. Операнды Булевого оператора получают такой же текущий цикл, как и родительское свойство. Операнды временных операторов получают текущий цикл, который связан с текущим циклом родительского свойства, в случаи, если это указано временным оператором. Например, оператор next увеличивает текущий цикл на один, оператор always создает “несколько экземпляров” под-свойства, каждый из которых получает текущий цикл, который соответствует текущему циклу или некоторому будущему циклу.


Примечание: Очень важно понять, что термин “несколько экземпляров” предназначен для смысла, который используется для понимания оператора <code>always</code>. ''Не'' предназначем показать, что каждый экземпляр существует; причем это не значит, что программе реализации PSL надо создать много экземпляров проверки утверждения, порождение нескольких экземпляров процесса или в любом другом случаи слова “несколько экземпляров” означают актуальные экземпляры чего-либо. Наоборот, существуют множество эффективных реализаций PSL, в которых оператор <code>always</code> не создает нескольких экземпляров. Термин “несколько экземпляров” - это хороший способ усилить понятие того, как работает оператор <code>always</code>, наивная и неэффективная реализация могжет также реализовывать несколько экземпляров проверки или процесса.


Возвращаясь к нашему основному пункту рассмотрения, рассмотрим утверждение <code>assert always (a -> next b);</code>. Текущий цикл <code>always (a -> next b)</code> - 0. Выполнение <code>always (a -> next b)</code> в цикле 0, зависит от выполнения под-свойства <code>(a -> next b)</code> в каждом цикле с нулевого. Текущий цикл для частной оценки под-свойства <code>(a -> next b)</code> будет некий цикл ''N''. В итоге, для того, чтобы определить действительно ли под-свойство <code>(a -> next b)</code> выполняется в цикле ''N'', мы должны оценить под-свойство a и следующий b с текущим циклом ''N'', что значит, что нам надо оценить под-свойство b с текущим циклом ''N'' + 1.


Для того чтобы сделать обсуждения конкретней, давайте рассмотрим наше утверждение, утверждение 3.1а на тракте 3.1(i). Сигнал а выполняется в циклах 4 и 8. Сигнал b выполняется в цикле 5, <code>next b</code> выполняется в цикле 4. Это показано в тракте 3.1(ii), аннотированная версия тракта 3.1(i). В то время, как а выполняется в циклах 4 и 8, и <code>next b</code> выполняется в цикле 4, мы получаем, что <code>(a -> next b)</code> выполняется во всех циклах, а цикл 8,как показано на тракте 3.1(ii). (Запомните, что в других частях по умолчанию справедливо, что <code>(a -> next b)</code> выполняется во всех циклах, где <code>a</code> не выполняется, и в дополнение во всех циклах где <code>a</code> выполняется и <code>next b</code> тоже.) Все свойство <code>always (a -> next b)</code> выполняется в циклах 9, 10, 11, 12, 13 (потому что в этих циклах <code>(a -> next b)</code> выполняется “сейчас” и во всех следующих циклах). Таким образом, утверждение 3.1a не выполняется на тракте 3.1(i) (потому что оно не выполняется в цикле 0 - первом цикле тракта).

{| align=center
! [[Файл:Psl fig3.1.png]]
|-
|<pre>
assert always (a -> next b); (3.1a)
</pre>
|-
! Рис. 3.1: Конкретный пример
|}


Приведенное выше описание кажется простым. Однако, идея модульности скрывает некоторые тонкие моменты, например, что значение свойства <code>a</code> зависит только от текущего цикла. Таким образом, утверждение 3.2а выполняется нна тракте 3.2(i), потому что сигнал <code>a</code> выполняется в цикле 0. Если вы хотите выразить тот факт, что <code>a</code> должен выполняться в каждом цикле, вы должны использовать оператор <code>always</code>, как в утверждении 3.2b. Утверждение 3.2b не выполняется на тракте 3.2(i).


Другой тонкий момент, что свойство может выполняться в суффиксе тракта,а не на самом тракте. Таким образом, свойство <code>always a</code> выполняется на субтракте тракта 3.2(i), начиная с циклов 12, 13, 14. Это будет важно, если мы используем свойство <code>always a</code>, как под-свойство какого-либо друо свойства. Например, утверждение 3.2c выполняется на тракте 3.2(i), потому что свойство <code>always a</code> выполняется на 12''ти'' следующих циклах.

Finally, the cycles involved in calculating the left-hand side of a logical
implication may overlap those involved in calculating the right-hand side of
a logical implication. For example, consider Assertion 3.3a on Trace 3.3(i).
Assertion 3.3a holds on Trace 3.3(i) because the sub-property <code>(a && next[6] (b)) -> (c && next[2] (d))</code>
holds at all cycles. It holds at cycle 2 because
the left-hand side <code>(a && next[6] (b))</code> holds and in addition the right-hand
side <code>(c && next[2] (d))</code> holds. It holds at all other cycles because if the
“if” part of a logical implication does not hold, then the “else” part defaults
to true.

{| align=center
! [[Файл:Psl fig3.2.png]]
|-
!(i) Assertions 3.2a and 3.2c hold, but 3.2b does not
|-
|<pre>
assert a; (3.2a)
assert always a; (3.2b)
assert next[12] (always a); (3.2c)
</pre>
|-
! Fig. 3.2: The importance of the always operator
|}

{| align=center
! [[Файл:Psl fig3.3.png]]
|-
!(i) An illustration of the overlap between the left- and right-hand sides of 
Assertion 3.3a. Assertion 3.3a holds.
|-
|<pre>
assert always ((a && next[6](b)) -> (c && next[2](d))); (3.3a)
</pre>
|-
! Fig. 3.3: The current cycle
|}

Previously, for example in examining Assertions 2.2a and 2.3b, we have
seen cases where there is an overlap between the cycles involved in satisfying
two different occurrences of the left-hand side of a logical implication. These
overlaps are caused by the presence of the <code>always</code> operator in the property.
If we remove the always operator, the issue of overlap disappears from Assertions
2.2a and 2.3b. The overlap of Assertion 3.3a is different from the overlap
of Assertions 2.2a and 2.3b in a very important way: Assertion 3.3a is written
in such a way that the cycles involved in calculating the left-hand side of the
logical implication overlap those involved in calculating the right-hand side of
the logical implication: calculating the “if” part of the logical implication involves
examining the current cycle and also “looking ahead” six cycles, while
calculating the “then” part of the logical implication involves examining the
current cycle and also “looking ahead” two cycles. Thus the overlap results
from the logical implication itself. This style of PSL property is usually very
confusing to new users of PSL, and indeed it is not an intuitive way to use
the language. For this reason, such properties are not recommended, and the
<code>simple subset</code> of PSL restricts the language in such a way that such properties
are not allowed. We discuss the simple subset in more detail later. For now,
remember that if you have written a property in which the cycles involved in
calculating the left-hand side of an operator overlap for more than one cycle
with those involved in calculating the right-hand side of the same operator,
you have not written a property that is in the simple subset.

=== 3.5 Reporting a failure ===

Consider Assertion 3.4a on the traces shown in Figure 3.4. Obviously, Assertion
3.4a does not hold on them. Now consider four different verification tools,
each of which reports the failure of Assertion 3.4a as indicated by the signal
called “failure” in Traces 3.4(i), 3.4(ii), 3.4(iii) and 3.4(iv). Tool 1 reports a
failure at cycle 4, the earliest that it can be detected. Tool 2 reports a failure
at cycle 4, but also at cycle 7, when <code>b</code> is asserted for a second time. Tool 3
reports a failure at the end of the trace, and Tool 4 reports a failure at cycle
1, when <code>a</code> is asserted.

Which tool is correct? The answer is that they all are. PSL defines whether
or not a property holds on a trace – that is all. It says nothing about when
a tool, dynamic or static, should report on the results of the analysis. Thus,
there is no meaning in asking whether Tool 1, 2, 3 or 4 is correct. All of
them indicate that the property fails on the trace, so all are correct. The
failure indications shown along the trace can be thought of as debugging aids,
hinting to the user where to look along the trace for the failure. As far as PSL
is concerned, as long as a tool indicates correctly whether or not a property
holds on a trace, it has done its job.

{| align=center
! [[Файл:Psl fig3.4.png]]
|-
|<pre>
assert always (a -> never b); (3.4a)
</pre>
|-
! Fig. 3.4: Four different tools reporting the failure of Assertion 3.4a on the same trace
|}

PSL/A Practical Introduction to PSL/Some Philosophy/ru

2013-11-25T07:25:29Z

Valentin: /* 3.3 Designs and traces */

PSL/A Practical Introduction to PSL/Some Philosophy/ru

2013-11-15T18:56:19Z

Valentin: /* 3.2 Понятие времени */

PSL/A Practical Introduction to PSL/Some Philosophy/ru

2013-11-15T10:54:41Z

Valentin: /* 3.2 Понятие времени */

PSL/A Practical Introduction to PSL/Some Philosophy/ru

2013-11-15T09:22:43Z

Valentin: /* 3.2 The notion of time */

PSL/A Practical Introduction to PSL/Some Philosophy/ru

2013-11-15T08:43:24Z

Valentin: /* 3.1 Утверждения против свойств */

PSL/A Practical Introduction to PSL/Some Philosophy/ru

2013-11-13T10:59:37Z

Valentin: /* Some Philosophy */

PSL/A Practical Introduction to PSL/Basic Temporal Properties/ru

2013-11-13T10:16:41Z

Valentin: /* 2.5 eventually! */

{{PSL TOC}}
==Основные временные свойства While==


В то время как Булевый слой состоит из Булевых выражений, которые выполняются или не выполняются в данном цикле, временной слой предоставляет путь для описания взаимоотношений между Булевыми выражениями по времени. PSL утверждение обычно представлено только в одном направлении - вперед, от первого цикла (также можно двигаться в обратном направлении, используя встроенные функции, такие как <code>prev()</code>, <code>rose()</code> и <code>fell()</code>). Таким образом, простое PSL утверждение <code>assert a;</code> показывает, что a должно утверждаться в самом первом цикле, в то время как PSL утверждение <code>assert always a</code>, показывает, что a должно утверждаться в перовм цикле и в каждом следующем цикле, а это значит, что в каждом цикле.


Комбинированием временных операторов различными путями, мы можем установить свойства, такие как “каждый запрос получает подтверждение”, “каждому подтвержденному запросу предоставляется от четырех до семи циклов, в случаи, если запрос не приостановится первым”, “две последовательные записи не должны располагать по одному и тому же адресу” и “когда мы видим запрос на чтение с тэгом i, на следующих четырех передах данных ожидается увидеть тэг <code>i</code>”.


Временной слой состоит из фундаментального языка (FL) и дополнительного расширения ветвления (OBE). FL используется для выражения свойств одного тракта, а также используется для моделирования или формальной верификации. OBE используется для выражения свойств, относящихся к набору трактов, например, “существует тракт, такой как ...”, и также используется для формальной верификации. В этой книге мы сконцентрируемся на фундаментальном языке.


Фундаментальный язык состоит из двух комплементарных стилей - LTL стиль, названный из-за временной логики LTL, на которой базируется PSL, и SERE стиля, названного из-за последовательного расширения регулярных выражений PSL, или SEREs. В этой главе мы представим основные временные операторы LTL стиля. Мы предоставим то, что будет достаточно для понимания основной идеи, и чтобы дать некий контекст, для философских замечаний,обсуждаемых далее.


В этой книге, мы широко используем примеры. Каждый пример свойства или утверждения связан с временной диаграммой (которую мы называем ''тракт'') сгруппирован вместе на рисунке. Такой рисунок будет содержать один или более трактов, нумерованных в скобках строчными римскими цифрами, одного или более свойств, нумерованных добавление строчной буквы к номеру рисунка. Например, Рисунок 2.1 содержит тракт 2.1(i) и утверждения 2.1а, 2.1b, 2.1c.

===2.1 Операторы <code>always</code> и <code>never</code> ===


Нам уже встречались основные временные операторы <code>always</code> и <code>never</code>. Большинство свойств PSL начинаются с одного или с другого. Это, потому что “голое” (Булево) PSL свойство относится только к первому циклу тракта. Например, утверждение 2.1a требует только того, чтобы Булево выражение <code>!(a && b)</code> выполнялось в первом цикле. Таким образом, утверждение 2.1а выполняется в тракте 2.1(i), потому что Булево выражение <code>!(a && b)</code> выполняется в цикле 0. Для того, чтобы сформулировать, что мы хотим, чтобы оно выполнялось в каждом цикле проекта, мы должны добавить временной оператор <code>always</code>, и получить утверждение 2.1b. Утверждение 2.1b не поддерживает тракт 2.1(i), потому что Булево выражение <code>!(a && b)</code> не выполняется в цикле 5. Эквивалентно, мы можем поменять оператор <code>always</code> и Булево отрицание <code>!</code> с <code>never</code>, чтобы получить утверждение 2.1с.

{| align=center
! [[Файл:Psl fig 02.1.png]]
|-
!(i) Утверждение 2.1a выполняется, но 2.1b and 2.1c нет
|-
|<pre>
assert !(a && b); (2.1a)
assert always !(a && b); (2.1b)
assert never (a && b); (2.1c)
</pre>
|-
! Рис. 2.1: Операторы always и never
|}


Оба утверждения 2.1b и 2.1c показывают, что сигналы a и b взаимоисключающиеся. Очевидно, все, что может использоваться с оператором <code>always</code>, может также использоваться с оператором <code>never</code> и наоборот, происходит простое отрицанием операнда, когда происходит переключение между <code>always</code> и <code>never</code>. PSL, для удобства, предоставляет два варианта использования, иногда более удобно описать свойство положительным (если свойство выполняется на всех циклах), а иногда удобней отрицательным (если свойство не выполняется ни в каком цикле). В общем, существует много путей описания свойств в PSL. Мы рассмотрим другие примеры далее.

===2.2 Оператор <code>next</code> ===


Другой временной оператор - это оператор <code>next</code>. Он показывает, что свойство свойство должно выполняться, если его операнд выполняется в следующем цикле. Например, утверждение 2.2a показывает, что когда бы a не выполнялось, b должно выполниться в следующем цикле. Утверждение 2.2a использует другой важный оператор, логический оператор импликации (<code>-></code>). В то время как оператор логической импликации Булевый, а не временной (он не свяжет два подсвойства по времени), это играет очень важную роль во многих временных свойствах. Логическая импликация <code>prop1 -> prop2</code> выполняется, если prop1 не выполняется или prop2 выполняется. Это хорошо представляется, если принять это, как выражение вида if-then, с частью else. <code>prop1 -> prop2</code> можно понимать, как если prop1, то далее следует prop2, иначе возвращается значение правда. Таким образом, под-свойство <code>a -> next b</code>, в нашем примере, выполняется, если a не выполняется (потому что свойство по умолчание имеет значение правда) или, если a выполняется, а также и next b выполняется. Добавляя оператор always, мы получаем свойство, которое выполняется, если под-свойство <code>a -> next b</code> выполняется в каждом цикле. Таким образом, утверждение 2.2а показывает, что когда бы ни выполнялось <code>a</code>, <code>b</code> должно выполняться в следующем цикле. Утверждение 2.2а выполняется по сигналу <code>b</code>. Это показано в “if” и “then” примечании на тракте 2.2(ii). “Дополнительные” утверждения сигнала <code>b</code> на циклах 1 и 10, спровоцированы утверждение 2.2а, потому что в нем ничего не сказано о значениях b в цикле, кроме того, что следует из из утверждения <code>a</code>.


Отметим, что циклы вовлеченные в выполнение одного утверждения сигнала, могут перекрываться с теми,которые вовлечены в выполнение другого утверждения. Например, учитывая тракт 2.2(iii), который является простым трактом 2.2(ii) с if-then пронумерованными парами. Имеем четыре утверждения сигнала <code>a</code> на тракте 2.2(iii), и таким образом четыре связанных цикла, в которых <code>b</code> должен утверждаться. Каждая пара циклов (утверждение <code>a</code> следует из утверждения <code>b</code>) нумерованы в тракте 2.2(iii). Рассматривая пары 2 и 3. Сигнал a утверждается в 4 цикле пары 2, таким образом сигнал b должен утвердиться в 5 цикле, для того, чтобы утверждение 2.2а выполнялось. Сигнал а утверждается в цикле 5 пары 3, таким образом требуется утверждение сигнала b в 6 цикле. Пары 2 и 3 перекрываются, потому что, в то время как мы ищем утверждение сигнала <code>b</code> в 5 цикле, для выполнения утверждения <code>a</code> в 4 цикле, также, мы видим дополнительное утверждение сигнала <code>a</code>, который рассматривается.


Утверждение 2.2а не выполняется в тракте 2.2(iv), потому что третье утверждение сигнала <code>a</code>, в цикле 5, т.к. отсутствует утверждение сигнала <code>b</code> в следующем цикле.

{| align=center
! [[Файл:Psl fig 02.2.png]]
|-
|<pre>
assert always (a -> next b); (2.2a)
</pre>
|-
! Рис.2.2: Операторы next и логическая импликация
|}

=== 2.3 вариации <code>next</code>, включая <code>next_event</code> ===


Свойство <code>next</code> выполняется, если его операнд выполняется в следующем цикле. Вариации оператора <code>next</code> позволяют указывать ''n-й'' следующий цикл и диапазоны будущих циклов. Свойство <code>next[n]</code> выполняется, если его операнд выполняется в ''n-й'' следующий цикл. Например, утверждение 2.3а показывает, что когда бы сигнал <code>a</code> не выполнялся, сигнал <code>b</code> выполниться тремя циклами позже. Утверждение 2.3а выполняется в тактах 2.3(i), 2.3(iii), 2.3(iv), но не выполняется в трактах 2.3(ii) или 2.3(v), потому что отсутствует утверждение сигнала <code>b</code> в цикле 7, и не выполняется в тракте 2.3(vi), потому что отсутствует утверждение сигнала <code>b</code> в цикле 5.

{| align=center
! [[Файл:Psl fig 02.3.png]]
|-
!
|-
|<pre>
assert always (a -> next[3] (b)); (2.3a)
assert always (a -> next_a[3:5] (b)); (2.3b)
assert always (a -> next_e[3:5] (b)); (2.3c)
</pre>
|-
! Рис. 2.3: Операторы <code>next[n]</code>, <code>next_a[i:j]</code> и <code>next_e[i:j]</code>
|}


Свойство next_a[i:j] выполняется если его операнд выполняется во ''всех'' циклах от ''i-го'' следующего, до ''j-го'' следующего цикла включительно. Например, утверждение 2.3b показывает, что когда бы сигнал a не выполнялся, сигнал b выполняется тремя, четырьмя, пятью циклами позже. Выполняется в тракте 2.3(iii) и не выполняется в трактах 2.3(i),
2.3(ii), 2.3(iv), 2.3(v) или 2.3(vi).


Ранее мы обсуждали то факт, что циклы, вовлеченные в выполнение одного утверждения сигнала, могут перекрываться с циклами, вовлеченными для выполнения других утверждений сигнала. Тракт 2.3(iii) был представлен, чтобы с акцентировать это для утверждения 2.3b. Сигнал <code>b</code> должен утверждаться в циклах с 5 до 7 (помечено “1”), в связи с утверждением сигнала a в цикле 2, и должен утверждаться в циклах с 7 до 9 (помечено “2”), в связи с утверждением в цикле 4.


Свойство next_e[i:j] выполняется, если ''существует'' цикл со следующего <code>i</code> до следующих <code>j</code> циклов, в которых выполняются операнды. Например, утверждение 2.3с показывает, что когда бы сигнал <code>a</code> не выполнялся, сигнал <code>b</code> выполняется тремя, четырьмя или пятью циклами позже. Нету ничего в утверждении 2.3с, что предотвращает единичное утверждение сигнала <code>b</code> из выполнения многочисленных утверждений сигнала <code>a</code>, таким образом это выполняется в тракте 2.3(vi), потому что утверждение сигнала <code>b</code>, в цикле 7, появляется через 5 циклов после утверждения сигнала <code>a</code> в цикле 2, и через три цикла после утверждения сигнала <code>a</code> в цикле 4.


Утверждение 2.3с также выполняется на трактах 2.3(i), 2.3(iii), 2.3(iv) и 2.3(v), т.к. есть достаточное количество утверждений сигнала <code>b</code> в соответствующее время. В трактах 2.3(i), 2.3(iii) и 2.3(iv) более, чем достаточно утверждений сигнал <code>b</code> для выполнения утвержденного свойства (в тракте 2.3(i) утверждения сигнала <code>b</code> в цикле 7 достаточно, потому что проходит 5 циклов после утверждения сигнала <code>a</code> в цикле 2, и три цикла после утверждения сигнала <code>a</code> в цикле 4). В тракте 2.3(v) достаточно утверждений сигнала <code>b</code> для выполнения требований утверждения 2.3c.


Оператор <code>next_event</code> концептуально расширенный оператор <code>next</code>. В то время как <code>next</code> относиться к следующему циклу, <code>next_event</code> относиться к следующему циклу, в котором выполняется некоторое Булево условие. Например, утверждение 2.4а выражает требование того, что когда бы ни принимался запрос с высоким приоритетом (сигнал <code>high_pri_req</code> утвержден), то следующим (утверждение сигнала <code>gnt</code>) должен быть, также, запрос с высоким приоритетом (сигнал <code>high_pri_ack</code> утвержден). Утверждение 2.4а выполняется в тракте 2.4(i). Существует два утверждения сигнала <code>high_pri_req</code>, первое в цикле 1 и второе в цикле 10. Связанные утверждения <code>gnt</code> встречаются в циклах 4 и 11, соответственно, и <code>high_pri_ack</code> выполняется в этих циклах.


Оператор <code>next_event</code> включает текущие циклы. Это значит, утверждения сигнала <code>b</code> в текущем цикле должно считаться следующим утверждением сигнала <code>b</code> в свойстве <code>next_event(b)(p)</code>. Например, рассмотрим тракт 2.4(ii). Тракт 2.4(ii) так же, как тракт 2.4(i) ожидает, что существуют дополнительные утверждения <code>high_pri_req</code> в цикле 8 и два дополнительных утверждения <code>gnt</code> в циклах 8 и 9, одно из которых связанно с <code>high_pri_ack</code>. Утверждение 2.4а выполняется на тракте Trace 2.4(ii), потому что утверждение <code>gnt</code> в цикле 8 считается следующим утверждением <code>gnt</code> для утверждения <code>high_pri_req</code> в цикле 8. Если вы хотите исключить текущий цикл, можно вставить оператор <code>next</code> для перемещения текущего цикла оператора <code>next_event</code> на один цикл далее, как в утверждении 2.4b. Утверждение 2.4b не выполняется в тракте 2.4(ii). Потому что вставка оператора <code>next</code> привела к смене циклов утверждений <code>gnt</code>, с циклов 4, 8 и 11 для утверждения 2.4a на циклы 4, 9 и 11 для утверждения 2.4b, а в цикле 9 нету утверждений <code>high_pri_ack</code> в тракте 2.4(ii).

{| align=center
! [[Файл:Psl fig 02.4i.png]]
|-
! (i) Assertions 2.4a and 2.4b hold
|-
! [[Файл:Psl fig 02.4ii.png]]
|-
! (ii) Утверждение 2.4a выполняется, а 2.4b нет
|-
|<pre>
assert always (high_pri_req -> (2.4a)
next_event(gnt)(high_pri_ack));

assert always (high_pri_req -> (2.4b)
next next_event(gnt)(high_pri_ack));
</pre>
|-
! Рис. 2.4: <code>next_event</code>
|}


Так как мы можем использовать <code>next[i]</code> для индикации ''i-го'' следующего цикла, мы можем использовать <code>next_event(b)[i]</code> для индикации ''i-го'' вхождения сигнала <code>b</code>. Например, для выражения требования,что всегда выдается запрос (signal <code>req</code> утвержден), готовность <code>signal_last</code> должна быть утверждена на четвертом утверждении сигнала <code>ready</code>. Утверждение 2.5а выполняется на тракте 2.5(i). Для первого утверждения <code>req</code>, в цикле 1, четыре утверждения <code>ready</code> происходят немедленно в следующих циклах. Для второго утверждения <code>req</code>, в цикле 7, четыре утверждения <code>ready</code> не происходят немедленно и не происходят последовательно - они распространяются через семь циклов, пресекаясь с циклами, в которых <code>ready</code> не подтвержден. Однако, отметим,что в обоих случаях, сигнал <code>last_ready</code> утверждается на четвертом утверждении <code>ready</code>, таким образом утверждение 2.5a выполняется в тракте 2.5(i).

{| align=center
! [[Файл:Psl fig 02.5.png]]
|-
! (i) Утверждение 2.5a выполняется
|-
|<pre>
assert always (req -> (2.5a)
next event(ready)[4](last ready));
</pre>
|-
! Рис. 2.5: next event[n]
|}


Как и с <code>next_a[i:j]</code> и <code>next_e[i:j]</code>, оператор <code>next_event</code> также появляется в форме, которая позволяет выражать ''весь'' диапазон следующих циклов, или ''наличие'' будущего цикла в этом диапазоне. Форма <code>next_event_a(b)[i:j](f)</code> показывает, что мы ожидаем выполнения <code>f</code> на всех ''i-х'' через ''j-е'' вхождения <code>b</code>. Например, утверждение 2.6a показывает, что когда мы видим запрос на чтение (утверждение сигнала <code>read_request</code>) с тэгом эквивалентным <code>i</code>, далее на следующих четырех передачах данных (утверждение сигнала <code>data</code>), мы ожидаем увидеть тэг <code>i</code>. Утверждение 2.6а использует конструкцию <code>forall</code>, которую мы рассмотрим в деталях позже. Сейчас достаточно сказать, что утверждение 2.6а показывает требование, что должно выполняться для всех возможных значениях сигнала <code>tag[2:0]</code>. Утверждение 2.6а выполняется в тракте 2.6(i), потому что после первого утверждения сигнала <code>read_request</code>, где значение <code>tag[2:0]</code> 4, значение <code>tag[2:0]</code>, также, 4 на четырех следующих утверждениях сигнала <code>data</code> (в циклах 5, 9, 10 и 11). Более того, на втором утверждении сигнала <code>read_request</code>, где <code>tag[2:0]</code> имеет значение 5, значение <code>tag[2:0]</code>, также, 5 на следующих четырех утверждениях сигнала <code>data</code> (циклы с 17 по 20).


Для того, чтобы указать, что мы ожидаем чего-либо в одном из следующих циклов с ''i-го'' по ''j-й'', мы можем использовать оператор <code>next_event_e(b)[i:j](f)</code>, который показывает, что мы ожидаем выполнения <code>f</code> в одном из циклов, с ''i-го'' по ''j-й'', вхождения <code>b</code>. Например, рассмотри опять утверждение 2.4a. Оно требует того, что когда бы ни приходил запрос высокого приоритета, следующим должен обработаться запрос с высоким приоритетом. Предположим вместо этого, что мы требуем, чтобы один из следующих ''двух'' грантов был для запроса с высоким приоритетом. Мы можем выразить это, используя утверждение 2.7a. Утверждение 2.7a выполняется в тракте 2.7(i), потому что всегда, когда сигнал <code>high_pri_req</code> утверждается, сигнал <code>high_pri_ack</code> утверждается на одном из следующих двух утверждений <code>gnt</code>.


Синтаксис спецификации диапазона для всех операторов, включая тех, которые мы еще не рассматривали, зависит от фундаментального языка. В вариантах Verilog, SystemVerilog и SystemC, это код <code>[i:j]</code>. Для VHDL - это код <code>[i to j]</code>. Для GDL это - <code>[i..j]</code>.

{| align=center
! [[Файл:Psl fig 02.6.png|600px]]
|-
! (i) Утверждение 2.6a выполняется
|-
|<pre>
assert forall i in {0:7}: (2.6a)
always ((read_request && tag[2:0]==i) ->
next_event_a(data)[1:4](tag[2:0]==i));
</pre>
|-
! Рис. 2.6 <code>next_event a[i:j]</code>
|}

=== 2.4 Операторы <code>until</code> и <code>before</code> ===

{| align=center
! [[Файл:Psl fig 02.7.png|400px]]
|-
! (i) Утверждение 2.7a выполняется
|-
|<pre>
assert always (high_pri_req -> (2.7a)
next_event_e(gnt)[1:2](high_pri_ack));
</pre>
|-
! Рис. 2.7: <code>next_event e[i:j]</code>
|}


Оператор <code>until</code> предоставляет другой путь движения вперед, здесь накладываются требования на циклы, в которые мы движемся. Например, утверждение 2.8а показывает, что когда бы сигнал <code>req</code> не был утвержден, далее, начиная со следующего цикла, сигнал <code>busy</code> должен быть утвержден до тех пор, пока не утвердиться сигнал <code>done</code>. Утверждение 2.8а требует, чтобы <code>busy</code> был утвержден до, но необязательно включая, цикла, в котором утверждается <code>done</code>. Для включения этого цикла, используется оператор <code>until_</code>. Подчеркивание (<code>_</code>) служит для того, чтобы указать дополнительный цикл, для которого мы требуем, чтобы <code>busy</code> оставался утвержденным, таким образом утверждение 2.8b показывает, что кода бы сигнал <code>req</code> не утверждался, далее, начиная со следующего цикла, <code>busy</code> должен быть утвержден, и должен оставаться в таком состоянии до цикла, в котором утверждается <code>done</code>, включительно. Например, утверждение 2.8а выполняется на тракте 2.8(i), а утверждение 2.8b нет, потому что <code>busy</code>не утверждается в циклах 4 и 10. Оба утверждения 2.8a и 2.8b выполняются на тракте 2.8(ii): утверждение 2.8a не запрещает утверждения сигнала <code>busy</code> в циклах 4 и 10 - это просто не требуется.


Если сигнал <code>done</code> утверждается на следующем цикле после утверждения <code>req</code>, утверждение 2.8a не требует, чтобы сигнал <code>busy</code>, в принципе, утверждался, в отличие от утверждения 2.8b. То есть, утверждение 2.8а выполняется на тракте 2.8(iii) - факт того, что <code>done</code> утверждается немедленно после утверждения <code>req</code>, не оставляет циклов для утверждения <code>busy</code>. Утверждение 2.8b не выполняется в тракте 2.8(iii), из-за пропущенного утверждения <code>busy</code> в цикле, в котором утверждается <code>done</code>.

{| align=center
! [[Файл:Psl fig 02.8.png|600px]]
|-
!
|-
|<pre>
assert always (req -> next (busy until done)); (2.8a)
assert always (req -> next(busy until_ done)); (2.8b)
</pre>
|-
! Рис. 2.8: Операторы <code>until</code> и <code>until_</code>
|}


Семейство операторов <code>before</code> предоставляет легкий путь для показания требований, чтобы некоторый сигнал утверждался перед каким-либо другим сигналом. Например, предположим, что у нас есть импульсный сигнал <code>req</code>, и мы имеем требование, что перед тем, как мы сможем сделать второй запрос, первый должен быть определен. Мы можем выразить это в PSL используя утверждение 2.9а. Нам нужен оператор <code>next</code> для передвижения на один цикл вперед, таким образом <code>req</code> в (<code>ack before req</code>) точно будет ссылаться на другие <code>req</code>, а не на тот, который был только что. Чтобы это понять, исследуем недостаточную версию этой спецификации. Рассматривая утверждение 2.9b. Оно требует, чтобы (<code>ack before req</code>) выполнялось на каждом цикле, в котором выполняется <code>req</code>. Например, цикл 1 тракта 2.9(i). Сигнал <code>req</code> утверждается. Поэтому, (<code>ack before req</code>) должен утвердиться в цикле 1. Однако, этого не происходит, потому что, начав с первого цикла и следуя далее, изначально мы увидим утверждения сигнала <code>req</code> (в цикле 1), и только после этого утверждение сигнала <code>ack</code> (в цикле 3) - таким образом <code>req</code> утверждается перед <code>ack</code>, а не наоборот. Утверждение 2.9а, с другой стороны, показывает, что мы хотим: в цикле 1, например, мы требуем выполнения <code>next</code> (<code>ack before req</code>). Поэтому, мы требуем, чтобы (<code>ack before req</code>) выполнлся на цикле 2. Начиная с цикла 2 и двигаясь вперед, изначально мы увидим утверждение <code>ack</code> (на цикле 3), и только после этого утверждение <code>req</code> (в цикле 6).

{| align=center
! [[Файл:Psl fig 02.9.png|600px]]
|-
|<pre>
assert always (req -> next (ack before req)); (2.9a)
assert always (req -> (ack before req)); (2.9b)
assert always (req -> next (ack before_ req)); (2.9c)
assert always (req -> (ack || next (ack before req))); (2.9d)
</pre>
|-
! Рис. 2.9 Операторы <code>before</code> и <code>before_</code>
|}


Оператор <code>before</code> требует, чтобы первый операнд выполнялся строго перед вторым. Для того, чтобы показать, что что-то должно выполниться перед или в том же цикле, как и что-либо иное, используется оператор <code>before_</code>. Подчеркивание (<code>_</code>) предназначено для представления цикла, в котором мы допускаем прекрытие между левой и правой сторонами. Например, для того чтобы показать, что поведениее соответствует тем, которые показаны в тракте 2.9(i) и в тракте Trace 2.9(ii), используется утверждение 2.9с.


Что если утверждению <code>ack</code> позволенно выполниться не вместе со следующим утверждением <code>req</code>, но вместе с установленным запросом? Другими словами, что если в дополнение к поведению, показаному в тракте 2.9(i), мы хотим допустить поведение показанное в тракте 2.9(iii)? Как было отмечно ранее, утверждение 2.9b это не ответ. Скорее, мы напишем код утверждения 2.9d.

===2.5 Оператор <code>eventually!</code>===


Оператор <code>eventually!</code> позволяет показать, что что-либо должно произойти в будущем, без конкретного уточнения когда. Например, утверждение 2.10а показывает, что каждый запрос (утверждение <code>req</code>) должен следовать в то же время, что и установленный (assertion of <code>ack</code>). Нету ничего в утверждении 2.10а, чтобы предотвратить единичного установления из удовлетворяющих требования для множественных запросов, таким образом утверждение 2.10а выполняется на тракте 2.10(i). Мы проверили этот вопрос спецификации взаимно однозначных соответствий между сигналами в разделе 13.4.2.


Восклицательный знак (<code>!</code>) в операторе <code>eventually!</code> показывает, что это сильный оператор. Обсуждения сильных и слабых оператров пойдет в главе 4.

{| align=center
! [[Файл:Psl fig 02.10.png|600px]]
|-
! (i) Утверждение 2.10a выполняется
|-
|<pre>
assert always (req -> eventually! ack); (2.10a)
</pre>
|-
! Рис. 2.10: Оператор <code>eventually!</code>
|}

PSL/A Practical Introduction to PSL/Basic Temporal Properties/ru

2013-11-13T10:03:10Z

Valentin: /* 2.4 The until and before operators */

{{PSL TOC}}
==Основные временные свойства While==


В то время как Булевый слой состоит из Булевых выражений, которые выполняются или не выполняются в данном цикле, временной слой предоставляет путь для описания взаимоотношений между Булевыми выражениями по времени. PSL утверждение обычно представлено только в одном направлении - вперед, от первого цикла (также можно двигаться в обратном направлении, используя встроенные функции, такие как <code>prev()</code>, <code>rose()</code> и <code>fell()</code>). Таким образом, простое PSL утверждение <code>assert a;</code> показывает, что a должно утверждаться в самом первом цикле, в то время как PSL утверждение <code>assert always a</code>, показывает, что a должно утверждаться в перовм цикле и в каждом следующем цикле, а это значит, что в каждом цикле.


Комбинированием временных операторов различными путями, мы можем установить свойства, такие как “каждый запрос получает подтверждение”, “каждому подтвержденному запросу предоставляется от четырех до семи циклов, в случаи, если запрос не приостановится первым”, “две последовательные записи не должны располагать по одному и тому же адресу” и “когда мы видим запрос на чтение с тэгом i, на следующих четырех передах данных ожидается увидеть тэг <code>i</code>”.


Временной слой состоит из фундаментального языка (FL) и дополнительного расширения ветвления (OBE). FL используется для выражения свойств одного тракта, а также используется для моделирования или формальной верификации. OBE используется для выражения свойств, относящихся к набору трактов, например, “существует тракт, такой как ...”, и также используется для формальной верификации. В этой книге мы сконцентрируемся на фундаментальном языке.


Фундаментальный язык состоит из двух комплементарных стилей - LTL стиль, названный из-за временной логики LTL, на которой базируется PSL, и SERE стиля, названного из-за последовательного расширения регулярных выражений PSL, или SEREs. В этой главе мы представим основные временные операторы LTL стиля. Мы предоставим то, что будет достаточно для понимания основной идеи, и чтобы дать некий контекст, для философских замечаний,обсуждаемых далее.


В этой книге, мы широко используем примеры. Каждый пример свойства или утверждения связан с временной диаграммой (которую мы называем ''тракт'') сгруппирован вместе на рисунке. Такой рисунок будет содержать один или более трактов, нумерованных в скобках строчными римскими цифрами, одного или более свойств, нумерованных добавление строчной буквы к номеру рисунка. Например, Рисунок 2.1 содержит тракт 2.1(i) и утверждения 2.1а, 2.1b, 2.1c.

===2.1 Операторы <code>always</code> и <code>never</code> ===


Нам уже встречались основные временные операторы <code>always</code> и <code>never</code>. Большинство свойств PSL начинаются с одного или с другого. Это, потому что “голое” (Булево) PSL свойство относится только к первому циклу тракта. Например, утверждение 2.1a требует только того, чтобы Булево выражение <code>!(a && b)</code> выполнялось в первом цикле. Таким образом, утверждение 2.1а выполняется в тракте 2.1(i), потому что Булево выражение <code>!(a && b)</code> выполняется в цикле 0. Для того, чтобы сформулировать, что мы хотим, чтобы оно выполнялось в каждом цикле проекта, мы должны добавить временной оператор <code>always</code>, и получить утверждение 2.1b. Утверждение 2.1b не поддерживает тракт 2.1(i), потому что Булево выражение <code>!(a && b)</code> не выполняется в цикле 5. Эквивалентно, мы можем поменять оператор <code>always</code> и Булево отрицание <code>!</code> с <code>never</code>, чтобы получить утверждение 2.1с.

{| align=center
! [[Файл:Psl fig 02.1.png]]
|-
!(i) Утверждение 2.1a выполняется, но 2.1b and 2.1c нет
|-
|<pre>
assert !(a && b); (2.1a)
assert always !(a && b); (2.1b)
assert never (a && b); (2.1c)
</pre>
|-
! Рис. 2.1: Операторы always и never
|}


Оба утверждения 2.1b и 2.1c показывают, что сигналы a и b взаимоисключающиеся. Очевидно, все, что может использоваться с оператором <code>always</code>, может также использоваться с оператором <code>never</code> и наоборот, происходит простое отрицанием операнда, когда происходит переключение между <code>always</code> и <code>never</code>. PSL, для удобства, предоставляет два варианта использования, иногда более удобно описать свойство положительным (если свойство выполняется на всех циклах), а иногда удобней отрицательным (если свойство не выполняется ни в каком цикле). В общем, существует много путей описания свойств в PSL. Мы рассмотрим другие примеры далее.

===2.2 Оператор <code>next</code> ===


Другой временной оператор - это оператор <code>next</code>. Он показывает, что свойство свойство должно выполняться, если его операнд выполняется в следующем цикле. Например, утверждение 2.2a показывает, что когда бы a не выполнялось, b должно выполниться в следующем цикле. Утверждение 2.2a использует другой важный оператор, логический оператор импликации (<code>-></code>). В то время как оператор логической импликации Булевый, а не временной (он не свяжет два подсвойства по времени), это играет очень важную роль во многих временных свойствах. Логическая импликация <code>prop1 -> prop2</code> выполняется, если prop1 не выполняется или prop2 выполняется. Это хорошо представляется, если принять это, как выражение вида if-then, с частью else. <code>prop1 -> prop2</code> можно понимать, как если prop1, то далее следует prop2, иначе возвращается значение правда. Таким образом, под-свойство <code>a -> next b</code>, в нашем примере, выполняется, если a не выполняется (потому что свойство по умолчание имеет значение правда) или, если a выполняется, а также и next b выполняется. Добавляя оператор always, мы получаем свойство, которое выполняется, если под-свойство <code>a -> next b</code> выполняется в каждом цикле. Таким образом, утверждение 2.2а показывает, что когда бы ни выполнялось <code>a</code>, <code>b</code> должно выполняться в следующем цикле. Утверждение 2.2а выполняется по сигналу <code>b</code>. Это показано в “if” и “then” примечании на тракте 2.2(ii). “Дополнительные” утверждения сигнала <code>b</code> на циклах 1 и 10, спровоцированы утверждение 2.2а, потому что в нем ничего не сказано о значениях b в цикле, кроме того, что следует из из утверждения <code>a</code>.


Отметим, что циклы вовлеченные в выполнение одного утверждения сигнала, могут перекрываться с теми,которые вовлечены в выполнение другого утверждения. Например, учитывая тракт 2.2(iii), который является простым трактом 2.2(ii) с if-then пронумерованными парами. Имеем четыре утверждения сигнала <code>a</code> на тракте 2.2(iii), и таким образом четыре связанных цикла, в которых <code>b</code> должен утверждаться. Каждая пара циклов (утверждение <code>a</code> следует из утверждения <code>b</code>) нумерованы в тракте 2.2(iii). Рассматривая пары 2 и 3. Сигнал a утверждается в 4 цикле пары 2, таким образом сигнал b должен утвердиться в 5 цикле, для того, чтобы утверждение 2.2а выполнялось. Сигнал а утверждается в цикле 5 пары 3, таким образом требуется утверждение сигнала b в 6 цикле. Пары 2 и 3 перекрываются, потому что, в то время как мы ищем утверждение сигнала <code>b</code> в 5 цикле, для выполнения утверждения <code>a</code> в 4 цикле, также, мы видим дополнительное утверждение сигнала <code>a</code>, который рассматривается.


Утверждение 2.2а не выполняется в тракте 2.2(iv), потому что третье утверждение сигнала <code>a</code>, в цикле 5, т.к. отсутствует утверждение сигнала <code>b</code> в следующем цикле.

{| align=center
! [[Файл:Psl fig 02.2.png]]
|-
|<pre>
assert always (a -> next b); (2.2a)
</pre>
|-
! Рис.2.2: Операторы next и логическая импликация
|}

=== 2.3 вариации <code>next</code>, включая <code>next_event</code> ===


Свойство <code>next</code> выполняется, если его операнд выполняется в следующем цикле. Вариации оператора <code>next</code> позволяют указывать ''n-й'' следующий цикл и диапазоны будущих циклов. Свойство <code>next[n]</code> выполняется, если его операнд выполняется в ''n-й'' следующий цикл. Например, утверждение 2.3а показывает, что когда бы сигнал <code>a</code> не выполнялся, сигнал <code>b</code> выполниться тремя циклами позже. Утверждение 2.3а выполняется в тактах 2.3(i), 2.3(iii), 2.3(iv), но не выполняется в трактах 2.3(ii) или 2.3(v), потому что отсутствует утверждение сигнала <code>b</code> в цикле 7, и не выполняется в тракте 2.3(vi), потому что отсутствует утверждение сигнала <code>b</code> в цикле 5.

{| align=center
! [[Файл:Psl fig 02.3.png]]
|-
!
|-
|<pre>
assert always (a -> next[3] (b)); (2.3a)
assert always (a -> next_a[3:5] (b)); (2.3b)
assert always (a -> next_e[3:5] (b)); (2.3c)
</pre>
|-
! Рис. 2.3: Операторы <code>next[n]</code>, <code>next_a[i:j]</code> и <code>next_e[i:j]</code>
|}


Свойство next_a[i:j] выполняется если его операнд выполняется во ''всех'' циклах от ''i-го'' следующего, до ''j-го'' следующего цикла включительно. Например, утверждение 2.3b показывает, что когда бы сигнал a не выполнялся, сигнал b выполняется тремя, четырьмя, пятью циклами позже. Выполняется в тракте 2.3(iii) и не выполняется в трактах 2.3(i),
2.3(ii), 2.3(iv), 2.3(v) или 2.3(vi).


Ранее мы обсуждали то факт, что циклы, вовлеченные в выполнение одного утверждения сигнала, могут перекрываться с циклами, вовлеченными для выполнения других утверждений сигнала. Тракт 2.3(iii) был представлен, чтобы с акцентировать это для утверждения 2.3b. Сигнал <code>b</code> должен утверждаться в циклах с 5 до 7 (помечено “1”), в связи с утверждением сигнала a в цикле 2, и должен утверждаться в циклах с 7 до 9 (помечено “2”), в связи с утверждением в цикле 4.


Свойство next_e[i:j] выполняется, если ''существует'' цикл со следующего <code>i</code> до следующих <code>j</code> циклов, в которых выполняются операнды. Например, утверждение 2.3с показывает, что когда бы сигнал <code>a</code> не выполнялся, сигнал <code>b</code> выполняется тремя, четырьмя или пятью циклами позже. Нету ничего в утверждении 2.3с, что предотвращает единичное утверждение сигнала <code>b</code> из выполнения многочисленных утверждений сигнала <code>a</code>, таким образом это выполняется в тракте 2.3(vi), потому что утверждение сигнала <code>b</code>, в цикле 7, появляется через 5 циклов после утверждения сигнала <code>a</code> в цикле 2, и через три цикла после утверждения сигнала <code>a</code> в цикле 4.


Утверждение 2.3с также выполняется на трактах 2.3(i), 2.3(iii), 2.3(iv) и 2.3(v), т.к. есть достаточное количество утверждений сигнала <code>b</code> в соответствующее время. В трактах 2.3(i), 2.3(iii) и 2.3(iv) более, чем достаточно утверждений сигнал <code>b</code> для выполнения утвержденного свойства (в тракте 2.3(i) утверждения сигнала <code>b</code> в цикле 7 достаточно, потому что проходит 5 циклов после утверждения сигнала <code>a</code> в цикле 2, и три цикла после утверждения сигнала <code>a</code> в цикле 4). В тракте 2.3(v) достаточно утверждений сигнала <code>b</code> для выполнения требований утверждения 2.3c.


Оператор <code>next_event</code> концептуально расширенный оператор <code>next</code>. В то время как <code>next</code> относиться к следующему циклу, <code>next_event</code> относиться к следующему циклу, в котором выполняется некоторое Булево условие. Например, утверждение 2.4а выражает требование того, что когда бы ни принимался запрос с высоким приоритетом (сигнал <code>high_pri_req</code> утвержден), то следующим (утверждение сигнала <code>gnt</code>) должен быть, также, запрос с высоким приоритетом (сигнал <code>high_pri_ack</code> утвержден). Утверждение 2.4а выполняется в тракте 2.4(i). Существует два утверждения сигнала <code>high_pri_req</code>, первое в цикле 1 и второе в цикле 10. Связанные утверждения <code>gnt</code> встречаются в циклах 4 и 11, соответственно, и <code>high_pri_ack</code> выполняется в этих циклах.


Оператор <code>next_event</code> включает текущие циклы. Это значит, утверждения сигнала <code>b</code> в текущем цикле должно считаться следующим утверждением сигнала <code>b</code> в свойстве <code>next_event(b)(p)</code>. Например, рассмотрим тракт 2.4(ii). Тракт 2.4(ii) так же, как тракт 2.4(i) ожидает, что существуют дополнительные утверждения <code>high_pri_req</code> в цикле 8 и два дополнительных утверждения <code>gnt</code> в циклах 8 и 9, одно из которых связанно с <code>high_pri_ack</code>. Утверждение 2.4а выполняется на тракте Trace 2.4(ii), потому что утверждение <code>gnt</code> в цикле 8 считается следующим утверждением <code>gnt</code> для утверждения <code>high_pri_req</code> в цикле 8. Если вы хотите исключить текущий цикл, можно вставить оператор <code>next</code> для перемещения текущего цикла оператора <code>next_event</code> на один цикл далее, как в утверждении 2.4b. Утверждение 2.4b не выполняется в тракте 2.4(ii). Потому что вставка оператора <code>next</code> привела к смене циклов утверждений <code>gnt</code>, с циклов 4, 8 и 11 для утверждения 2.4a на циклы 4, 9 и 11 для утверждения 2.4b, а в цикле 9 нету утверждений <code>high_pri_ack</code> в тракте 2.4(ii).

{| align=center
! [[Файл:Psl fig 02.4i.png]]
|-
! (i) Assertions 2.4a and 2.4b hold
|-
! [[Файл:Psl fig 02.4ii.png]]
|-
! (ii) Утверждение 2.4a выполняется, а 2.4b нет
|-
|<pre>
assert always (high_pri_req -> (2.4a)
next_event(gnt)(high_pri_ack));

assert always (high_pri_req -> (2.4b)
next next_event(gnt)(high_pri_ack));
</pre>
|-
! Рис. 2.4: <code>next_event</code>
|}


Так как мы можем использовать <code>next[i]</code> для индикации ''i-го'' следующего цикла, мы можем использовать <code>next_event(b)[i]</code> для индикации ''i-го'' вхождения сигнала <code>b</code>. Например, для выражения требования,что всегда выдается запрос (signal <code>req</code> утвержден), готовность <code>signal_last</code> должна быть утверждена на четвертом утверждении сигнала <code>ready</code>. Утверждение 2.5а выполняется на тракте 2.5(i). Для первого утверждения <code>req</code>, в цикле 1, четыре утверждения <code>ready</code> происходят немедленно в следующих циклах. Для второго утверждения <code>req</code>, в цикле 7, четыре утверждения <code>ready</code> не происходят немедленно и не происходят последовательно - они распространяются через семь циклов, пресекаясь с циклами, в которых <code>ready</code> не подтвержден. Однако, отметим,что в обоих случаях, сигнал <code>last_ready</code> утверждается на четвертом утверждении <code>ready</code>, таким образом утверждение 2.5a выполняется в тракте 2.5(i).

{| align=center
! [[Файл:Psl fig 02.5.png]]
|-
! (i) Утверждение 2.5a выполняется
|-
|<pre>
assert always (req -> (2.5a)
next event(ready)[4](last ready));
</pre>
|-
! Рис. 2.5: next event[n]
|}


Как и с <code>next_a[i:j]</code> и <code>next_e[i:j]</code>, оператор <code>next_event</code> также появляется в форме, которая позволяет выражать ''весь'' диапазон следующих циклов, или ''наличие'' будущего цикла в этом диапазоне. Форма <code>next_event_a(b)[i:j](f)</code> показывает, что мы ожидаем выполнения <code>f</code> на всех ''i-х'' через ''j-е'' вхождения <code>b</code>. Например, утверждение 2.6a показывает, что когда мы видим запрос на чтение (утверждение сигнала <code>read_request</code>) с тэгом эквивалентным <code>i</code>, далее на следующих четырех передачах данных (утверждение сигнала <code>data</code>), мы ожидаем увидеть тэг <code>i</code>. Утверждение 2.6а использует конструкцию <code>forall</code>, которую мы рассмотрим в деталях позже. Сейчас достаточно сказать, что утверждение 2.6а показывает требование, что должно выполняться для всех возможных значениях сигнала <code>tag[2:0]</code>. Утверждение 2.6а выполняется в тракте 2.6(i), потому что после первого утверждения сигнала <code>read_request</code>, где значение <code>tag[2:0]</code> 4, значение <code>tag[2:0]</code>, также, 4 на четырех следующих утверждениях сигнала <code>data</code> (в циклах 5, 9, 10 и 11). Более того, на втором утверждении сигнала <code>read_request</code>, где <code>tag[2:0]</code> имеет значение 5, значение <code>tag[2:0]</code>, также, 5 на следующих четырех утверждениях сигнала <code>data</code> (циклы с 17 по 20).


Для того, чтобы указать, что мы ожидаем чего-либо в одном из следующих циклов с ''i-го'' по ''j-й'', мы можем использовать оператор <code>next_event_e(b)[i:j](f)</code>, который показывает, что мы ожидаем выполнения <code>f</code> в одном из циклов, с ''i-го'' по ''j-й'', вхождения <code>b</code>. Например, рассмотри опять утверждение 2.4a. Оно требует того, что когда бы ни приходил запрос высокого приоритета, следующим должен обработаться запрос с высоким приоритетом. Предположим вместо этого, что мы требуем, чтобы один из следующих ''двух'' грантов был для запроса с высоким приоритетом. Мы можем выразить это, используя утверждение 2.7a. Утверждение 2.7a выполняется в тракте 2.7(i), потому что всегда, когда сигнал <code>high_pri_req</code> утверждается, сигнал <code>high_pri_ack</code> утверждается на одном из следующих двух утверждений <code>gnt</code>.


Синтаксис спецификации диапазона для всех операторов, включая тех, которые мы еще не рассматривали, зависит от фундаментального языка. В вариантах Verilog, SystemVerilog и SystemC, это код <code>[i:j]</code>. Для VHDL - это код <code>[i to j]</code>. Для GDL это - <code>[i..j]</code>.

{| align=center
! [[Файл:Psl fig 02.6.png|600px]]
|-
! (i) Утверждение 2.6a выполняется
|-
|<pre>
assert forall i in {0:7}: (2.6a)
always ((read_request && tag[2:0]==i) ->
next_event_a(data)[1:4](tag[2:0]==i));
</pre>
|-
! Рис. 2.6 <code>next_event a[i:j]</code>
|}

=== 2.4 Операторы <code>until</code> и <code>before</code> ===

{| align=center
! [[Файл:Psl fig 02.7.png|400px]]
|-
! (i) Утверждение 2.7a выполняется
|-
|<pre>
assert always (high_pri_req -> (2.7a)
next_event_e(gnt)[1:2](high_pri_ack));
</pre>
|-
! Рис. 2.7: <code>next_event e[i:j]</code>
|}


Оператор <code>until</code> предоставляет другой путь движения вперед, здесь накладываются требования на циклы, в которые мы движемся. Например, утверждение 2.8а показывает, что когда бы сигнал <code>req</code> не был утвержден, далее, начиная со следующего цикла, сигнал <code>busy</code> должен быть утвержден до тех пор, пока не утвердиться сигнал <code>done</code>. Утверждение 2.8а требует, чтобы <code>busy</code> был утвержден до, но необязательно включая, цикла, в котором утверждается <code>done</code>. Для включения этого цикла, используется оператор <code>until_</code>. Подчеркивание (<code>_</code>) служит для того, чтобы указать дополнительный цикл, для которого мы требуем, чтобы <code>busy</code> оставался утвержденным, таким образом утверждение 2.8b показывает, что кода бы сигнал <code>req</code> не утверждался, далее, начиная со следующего цикла, <code>busy</code> должен быть утвержден, и должен оставаться в таком состоянии до цикла, в котором утверждается <code>done</code>, включительно. Например, утверждение 2.8а выполняется на тракте 2.8(i), а утверждение 2.8b нет, потому что <code>busy</code>не утверждается в циклах 4 и 10. Оба утверждения 2.8a и 2.8b выполняются на тракте 2.8(ii): утверждение 2.8a не запрещает утверждения сигнала <code>busy</code> в циклах 4 и 10 - это просто не требуется.


Если сигнал <code>done</code> утверждается на следующем цикле после утверждения <code>req</code>, утверждение 2.8a не требует, чтобы сигнал <code>busy</code>, в принципе, утверждался, в отличие от утверждения 2.8b. То есть, утверждение 2.8а выполняется на тракте 2.8(iii) - факт того, что <code>done</code> утверждается немедленно после утверждения <code>req</code>, не оставляет циклов для утверждения <code>busy</code>. Утверждение 2.8b не выполняется в тракте 2.8(iii), из-за пропущенного утверждения <code>busy</code> в цикле, в котором утверждается <code>done</code>.

{| align=center
! [[Файл:Psl fig 02.8.png|600px]]
|-
!
|-
|<pre>
assert always (req -> next (busy until done)); (2.8a)
assert always (req -> next(busy until_ done)); (2.8b)
</pre>
|-
! Рис. 2.8: Операторы <code>until</code> и <code>until_</code>
|}


Семейство операторов <code>before</code> предоставляет легкий путь для показания требований, чтобы некоторый сигнал утверждался перед каким-либо другим сигналом. Например, предположим, что у нас есть импульсный сигнал <code>req</code>, и мы имеем требование, что перед тем, как мы сможем сделать второй запрос, первый должен быть определен. Мы можем выразить это в PSL используя утверждение 2.9а. Нам нужен оператор <code>next</code> для передвижения на один цикл вперед, таким образом <code>req</code> в (<code>ack before req</code>) точно будет ссылаться на другие <code>req</code>, а не на тот, который был только что. Чтобы это понять, исследуем недостаточную версию этой спецификации. Рассматривая утверждение 2.9b. Оно требует, чтобы (<code>ack before req</code>) выполнялось на каждом цикле, в котором выполняется <code>req</code>. Например, цикл 1 тракта 2.9(i). Сигнал <code>req</code> утверждается. Поэтому, (<code>ack before req</code>) должен утвердиться в цикле 1. Однако, этого не происходит, потому что, начав с первого цикла и следуя далее, изначально мы увидим утверждения сигнала <code>req</code> (в цикле 1), и только после этого утверждение сигнала <code>ack</code> (в цикле 3) - таким образом <code>req</code> утверждается перед <code>ack</code>, а не наоборот. Утверждение 2.9а, с другой стороны, показывает, что мы хотим: в цикле 1, например, мы требуем выполнения <code>next</code> (<code>ack before req</code>). Поэтому, мы требуем, чтобы (<code>ack before req</code>) выполнлся на цикле 2. Начиная с цикла 2 и двигаясь вперед, изначально мы увидим утверждение <code>ack</code> (на цикле 3), и только после этого утверждение <code>req</code> (в цикле 6).

{| align=center
! [[Файл:Psl fig 02.9.png|600px]]
|-
|<pre>
assert always (req -> next (ack before req)); (2.9a)
assert always (req -> (ack before req)); (2.9b)
assert always (req -> next (ack before_ req)); (2.9c)
assert always (req -> (ack || next (ack before req))); (2.9d)
</pre>
|-
! Рис. 2.9 Операторы <code>before</code> и <code>before_</code>
|}


Оператор <code>before</code> требует, чтобы первый операнд выполнялся строго перед вторым. Для того, чтобы показать, что что-то должно выполниться перед или в том же цикле, как и что-либо иное, используется оператор <code>before_</code>. Подчеркивание (<code>_</code>) предназначено для представления цикла, в котором мы допускаем прекрытие между левой и правой сторонами. Например, для того чтобы показать, что поведениее соответствует тем, которые показаны в тракте 2.9(i) и в тракте Trace 2.9(ii), используется утверждение 2.9с.


Что если утверждению <code>ack</code> позволенно выполниться не вместе со следующим утверждением <code>req</code>, но вместе с установленным запросом? Другими словами, что если в дополнение к поведению, показаному в тракте 2.9(i), мы хотим допустить поведение показанное в тракте 2.9(iii)? Как было отмечно ранее, утверждение 2.9b это не ответ. Скорее, мы напишем код утверждения 2.9d.

===2.5 <code>eventually!</code>===

The <code>eventually!</code> operator allows you to specify that something must occur in
the future without saying exactly when. For example, Assertion 2.10a states
that every request (assertion of <code>req</code>) must be followed at some time with
an acknowledge (assertion of <code>ack</code>). There is nothing in Assertion 2.10a to
prevent a single acknowledge from satisfying the requirement for multiple
requests, thus Assertion 2.10a holds on Trace 2.10(i). We examine the issue
of specifying a one-to-one correspondence between signals in Section 13.4.2.

The exclamation point (<code>!</code>) of the <code>eventually!</code> operator indicates that it
is a strong operator. We discuss weak vs. strong temporal operators in detail
in Chapter 4.

{| align=center
! [[Файл:Psl fig 02.10.png|600px]]
|-
! (i) Assertion 2.10a holds
|-
|<pre>
assert always (req -> eventually! ack); (2.10a)
</pre>
|-
! Fig. 2.10: The <code>eventually!</code> operator
|}

PSL/A Practical Introduction to PSL/Basic Temporal Properties/ru

2013-11-10T15:51:48Z

Valentin: /* 2.3 вариации next, включая next_event */

{{PSL TOC}}
==Основные временные свойства While==


В то время как Булевый слой состоит из Булевых выражений, которые выполняются или не выполняются в данном цикле, временной слой предоставляет путь для описания взаимоотношений между Булевыми выражениями по времени. PSL утверждение обычно представлено только в одном направлении - вперед, от первого цикла (также можно двигаться в обратном направлении, используя встроенные функции, такие как <code>prev()</code>, <code>rose()</code> и <code>fell()</code>). Таким образом, простое PSL утверждение <code>assert a;</code> показывает, что a должно утверждаться в самом первом цикле, в то время как PSL утверждение <code>assert always a</code>, показывает, что a должно утверждаться в перовм цикле и в каждом следующем цикле, а это значит, что в каждом цикле.


Комбинированием временных операторов различными путями, мы можем установить свойства, такие как “каждый запрос получает подтверждение”, “каждому подтвержденному запросу предоставляется от четырех до семи циклов, в случаи, если запрос не приостановится первым”, “две последовательные записи не должны располагать по одному и тому же адресу” и “когда мы видим запрос на чтение с тэгом i, на следующих четырех передах данных ожидается увидеть тэг <code>i</code>”.


Временной слой состоит из фундаментального языка (FL) и дополнительного расширения ветвления (OBE). FL используется для выражения свойств одного тракта, а также используется для моделирования или формальной верификации. OBE используется для выражения свойств, относящихся к набору трактов, например, “существует тракт, такой как ...”, и также используется для формальной верификации. В этой книге мы сконцентрируемся на фундаментальном языке.


Фундаментальный язык состоит из двух комплементарных стилей - LTL стиль, названный из-за временной логики LTL, на которой базируется PSL, и SERE стиля, названного из-за последовательного расширения регулярных выражений PSL, или SEREs. В этой главе мы представим основные временные операторы LTL стиля. Мы предоставим то, что будет достаточно для понимания основной идеи, и чтобы дать некий контекст, для философских замечаний,обсуждаемых далее.


В этой книге, мы широко используем примеры. Каждый пример свойства или утверждения связан с временной диаграммой (которую мы называем ''тракт'') сгруппирован вместе на рисунке. Такой рисунок будет содержать один или более трактов, нумерованных в скобках строчными римскими цифрами, одного или более свойств, нумерованных добавление строчной буквы к номеру рисунка. Например, Рисунок 2.1 содержит тракт 2.1(i) и утверждения 2.1а, 2.1b, 2.1c.

===2.1 Операторы <code>always</code> и <code>never</code> ===


Нам уже встречались основные временные операторы <code>always</code> и <code>never</code>. Большинство свойств PSL начинаются с одного или с другого. Это, потому что “голое” (Булево) PSL свойство относится только к первому циклу тракта. Например, утверждение 2.1a требует только того, чтобы Булево выражение <code>!(a && b)</code> выполнялось в первом цикле. Таким образом, утверждение 2.1а выполняется в тракте 2.1(i), потому что Булево выражение <code>!(a && b)</code> выполняется в цикле 0. Для того, чтобы сформулировать, что мы хотим, чтобы оно выполнялось в каждом цикле проекта, мы должны добавить временной оператор <code>always</code>, и получить утверждение 2.1b. Утверждение 2.1b не поддерживает тракт 2.1(i), потому что Булево выражение <code>!(a && b)</code> не выполняется в цикле 5. Эквивалентно, мы можем поменять оператор <code>always</code> и Булево отрицание <code>!</code> с <code>never</code>, чтобы получить утверждение 2.1с.

{| align=center
! [[Файл:Psl fig 02.1.png]]
|-
!(i) Утверждение 2.1a выполняется, но 2.1b and 2.1c нет
|-
|<pre>
assert !(a && b); (2.1a)
assert always !(a && b); (2.1b)
assert never (a && b); (2.1c)
</pre>
|-
! Рис. 2.1: Операторы always и never
|}


Оба утверждения 2.1b и 2.1c показывают, что сигналы a и b взаимоисключающиеся. Очевидно, все, что может использоваться с оператором <code>always</code>, может также использоваться с оператором <code>never</code> и наоборот, происходит простое отрицанием операнда, когда происходит переключение между <code>always</code> и <code>never</code>. PSL, для удобства, предоставляет два варианта использования, иногда более удобно описать свойство положительным (если свойство выполняется на всех циклах), а иногда удобней отрицательным (если свойство не выполняется ни в каком цикле). В общем, существует много путей описания свойств в PSL. Мы рассмотрим другие примеры далее.

===2.2 Оператор <code>next</code> ===


Другой временной оператор - это оператор <code>next</code>. Он показывает, что свойство свойство должно выполняться, если его операнд выполняется в следующем цикле. Например, утверждение 2.2a показывает, что когда бы a не выполнялось, b должно выполниться в следующем цикле. Утверждение 2.2a использует другой важный оператор, логический оператор импликации (<code>-></code>). В то время как оператор логической импликации Булевый, а не временной (он не свяжет два подсвойства по времени), это играет очень важную роль во многих временных свойствах. Логическая импликация <code>prop1 -> prop2</code> выполняется, если prop1 не выполняется или prop2 выполняется. Это хорошо представляется, если принять это, как выражение вида if-then, с частью else. <code>prop1 -> prop2</code> можно понимать, как если prop1, то далее следует prop2, иначе возвращается значение правда. Таким образом, под-свойство <code>a -> next b</code>, в нашем примере, выполняется, если a не выполняется (потому что свойство по умолчание имеет значение правда) или, если a выполняется, а также и next b выполняется. Добавляя оператор always, мы получаем свойство, которое выполняется, если под-свойство <code>a -> next b</code> выполняется в каждом цикле. Таким образом, утверждение 2.2а показывает, что когда бы ни выполнялось <code>a</code>, <code>b</code> должно выполняться в следующем цикле. Утверждение 2.2а выполняется по сигналу <code>b</code>. Это показано в “if” и “then” примечании на тракте 2.2(ii). “Дополнительные” утверждения сигнала <code>b</code> на циклах 1 и 10, спровоцированы утверждение 2.2а, потому что в нем ничего не сказано о значениях b в цикле, кроме того, что следует из из утверждения <code>a</code>.


Отметим, что циклы вовлеченные в выполнение одного утверждения сигнала, могут перекрываться с теми,которые вовлечены в выполнение другого утверждения. Например, учитывая тракт 2.2(iii), который является простым трактом 2.2(ii) с if-then пронумерованными парами. Имеем четыре утверждения сигнала <code>a</code> на тракте 2.2(iii), и таким образом четыре связанных цикла, в которых <code>b</code> должен утверждаться. Каждая пара циклов (утверждение <code>a</code> следует из утверждения <code>b</code>) нумерованы в тракте 2.2(iii). Рассматривая пары 2 и 3. Сигнал a утверждается в 4 цикле пары 2, таким образом сигнал b должен утвердиться в 5 цикле, для того, чтобы утверждение 2.2а выполнялось. Сигнал а утверждается в цикле 5 пары 3, таким образом требуется утверждение сигнала b в 6 цикле. Пары 2 и 3 перекрываются, потому что, в то время как мы ищем утверждение сигнала <code>b</code> в 5 цикле, для выполнения утверждения <code>a</code> в 4 цикле, также, мы видим дополнительное утверждение сигнала <code>a</code>, который рассматривается.


Утверждение 2.2а не выполняется в тракте 2.2(iv), потому что третье утверждение сигнала <code>a</code>, в цикле 5, т.к. отсутствует утверждение сигнала <code>b</code> в следующем цикле.

{| align=center
! [[Файл:Psl fig 02.2.png]]
|-
|<pre>
assert always (a -> next b); (2.2a)
</pre>
|-
! Рис.2.2: Операторы next и логическая импликация
|}

=== 2.3 вариации <code>next</code>, включая <code>next_event</code> ===


Свойство <code>next</code> выполняется, если его операнд выполняется в следующем цикле. Вариации оператора <code>next</code> позволяют указывать ''n-й'' следующий цикл и диапазоны будущих циклов. Свойство <code>next[n]</code> выполняется, если его операнд выполняется в ''n-й'' следующий цикл. Например, утверждение 2.3а показывает, что когда бы сигнал <code>a</code> не выполнялся, сигнал <code>b</code> выполниться тремя циклами позже. Утверждение 2.3а выполняется в тактах 2.3(i), 2.3(iii), 2.3(iv), но не выполняется в трактах 2.3(ii) или 2.3(v), потому что отсутствует утверждение сигнала <code>b</code> в цикле 7, и не выполняется в тракте 2.3(vi), потому что отсутствует утверждение сигнала <code>b</code> в цикле 5.

{| align=center
! [[Файл:Psl fig 02.3.png]]
|-
!
|-
|<pre>
assert always (a -> next[3] (b)); (2.3a)
assert always (a -> next_a[3:5] (b)); (2.3b)
assert always (a -> next_e[3:5] (b)); (2.3c)
</pre>
|-
! Рис. 2.3: Операторы <code>next[n]</code>, <code>next_a[i:j]</code> и <code>next_e[i:j]</code>
|}


Свойство next_a[i:j] выполняется если его операнд выполняется во ''всех'' циклах от ''i-го'' следующего, до ''j-го'' следующего цикла включительно. Например, утверждение 2.3b показывает, что когда бы сигнал a не выполнялся, сигнал b выполняется тремя, четырьмя, пятью циклами позже. Выполняется в тракте 2.3(iii) и не выполняется в трактах 2.3(i),
2.3(ii), 2.3(iv), 2.3(v) или 2.3(vi).


Ранее мы обсуждали то факт, что циклы, вовлеченные в выполнение одного утверждения сигнала, могут перекрываться с циклами, вовлеченными для выполнения других утверждений сигнала. Тракт 2.3(iii) был представлен, чтобы с акцентировать это для утверждения 2.3b. Сигнал <code>b</code> должен утверждаться в циклах с 5 до 7 (помечено “1”), в связи с утверждением сигнала a в цикле 2, и должен утверждаться в циклах с 7 до 9 (помечено “2”), в связи с утверждением в цикле 4.


Свойство next_e[i:j] выполняется, если ''существует'' цикл со следующего <code>i</code> до следующих <code>j</code> циклов, в которых выполняются операнды. Например, утверждение 2.3с показывает, что когда бы сигнал <code>a</code> не выполнялся, сигнал <code>b</code> выполняется тремя, четырьмя или пятью циклами позже. Нету ничего в утверждении 2.3с, что предотвращает единичное утверждение сигнала <code>b</code> из выполнения многочисленных утверждений сигнала <code>a</code>, таким образом это выполняется в тракте 2.3(vi), потому что утверждение сигнала <code>b</code>, в цикле 7, появляется через 5 циклов после утверждения сигнала <code>a</code> в цикле 2, и через три цикла после утверждения сигнала <code>a</code> в цикле 4.


Утверждение 2.3с также выполняется на трактах 2.3(i), 2.3(iii), 2.3(iv) и 2.3(v), т.к. есть достаточное количество утверждений сигнала <code>b</code> в соответствующее время. В трактах 2.3(i), 2.3(iii) и 2.3(iv) более, чем достаточно утверждений сигнал <code>b</code> для выполнения утвержденного свойства (в тракте 2.3(i) утверждения сигнала <code>b</code> в цикле 7 достаточно, потому что проходит 5 циклов после утверждения сигнала <code>a</code> в цикле 2, и три цикла после утверждения сигнала <code>a</code> в цикле 4). В тракте 2.3(v) достаточно утверждений сигнала <code>b</code> для выполнения требований утверждения 2.3c.


Оператор <code>next_event</code> концептуально расширенный оператор <code>next</code>. В то время как <code>next</code> относиться к следующему циклу, <code>next_event</code> относиться к следующему циклу, в котором выполняется некоторое Булево условие. Например, утверждение 2.4а выражает требование того, что когда бы ни принимался запрос с высоким приоритетом (сигнал <code>high_pri_req</code> утвержден), то следующим (утверждение сигнала <code>gnt</code>) должен быть, также, запрос с высоким приоритетом (сигнал <code>high_pri_ack</code> утвержден). Утверждение 2.4а выполняется в тракте 2.4(i). Существует два утверждения сигнала <code>high_pri_req</code>, первое в цикле 1 и второе в цикле 10. Связанные утверждения <code>gnt</code> встречаются в циклах 4 и 11, соответственно, и <code>high_pri_ack</code> выполняется в этих циклах.


Оператор <code>next_event</code> включает текущие циклы. Это значит, утверждения сигнала <code>b</code> в текущем цикле должно считаться следующим утверждением сигнала <code>b</code> в свойстве <code>next_event(b)(p)</code>. Например, рассмотрим тракт 2.4(ii). Тракт 2.4(ii) так же, как тракт 2.4(i) ожидает, что существуют дополнительные утверждения <code>high_pri_req</code> в цикле 8 и два дополнительных утверждения <code>gnt</code> в циклах 8 и 9, одно из которых связанно с <code>high_pri_ack</code>. Утверждение 2.4а выполняется на тракте Trace 2.4(ii), потому что утверждение <code>gnt</code> в цикле 8 считается следующим утверждением <code>gnt</code> для утверждения <code>high_pri_req</code> в цикле 8. Если вы хотите исключить текущий цикл, можно вставить оператор <code>next</code> для перемещения текущего цикла оператора <code>next_event</code> на один цикл далее, как в утверждении 2.4b. Утверждение 2.4b не выполняется в тракте 2.4(ii). Потому что вставка оператора <code>next</code> привела к смене циклов утверждений <code>gnt</code>, с циклов 4, 8 и 11 для утверждения 2.4a на циклы 4, 9 и 11 для утверждения 2.4b, а в цикле 9 нету утверждений <code>high_pri_ack</code> в тракте 2.4(ii).

{| align=center
! [[Файл:Psl fig 02.4i.png]]
|-
! (i) Assertions 2.4a and 2.4b hold
|-
! [[Файл:Psl fig 02.4ii.png]]
|-
! (ii) Утверждение 2.4a выполняется, а 2.4b нет
|-
|<pre>
assert always (high_pri_req -> (2.4a)
next_event(gnt)(high_pri_ack));

assert always (high_pri_req -> (2.4b)
next next_event(gnt)(high_pri_ack));
</pre>
|-
! Рис. 2.4: <code>next_event</code>
|}


Так как мы можем использовать <code>next[i]</code> для индикации ''i-го'' следующего цикла, мы можем использовать <code>next_event(b)[i]</code> для индикации ''i-го'' вхождения сигнала <code>b</code>. Например, для выражения требования,что всегда выдается запрос (signal <code>req</code> утвержден), готовность <code>signal_last</code> должна быть утверждена на четвертом утверждении сигнала <code>ready</code>. Утверждение 2.5а выполняется на тракте 2.5(i). Для первого утверждения <code>req</code>, в цикле 1, четыре утверждения <code>ready</code> происходят немедленно в следующих циклах. Для второго утверждения <code>req</code>, в цикле 7, четыре утверждения <code>ready</code> не происходят немедленно и не происходят последовательно - они распространяются через семь циклов, пресекаясь с циклами, в которых <code>ready</code> не подтвержден. Однако, отметим,что в обоих случаях, сигнал <code>last_ready</code> утверждается на четвертом утверждении <code>ready</code>, таким образом утверждение 2.5a выполняется в тракте 2.5(i).

{| align=center
! [[Файл:Psl fig 02.5.png]]
|-
! (i) Утверждение 2.5a выполняется
|-
|<pre>
assert always (req -> (2.5a)
next event(ready)[4](last ready));
</pre>
|-
! Рис. 2.5: next event[n]
|}


Как и с <code>next_a[i:j]</code> и <code>next_e[i:j]</code>, оператор <code>next_event</code> также появляется в форме, которая позволяет выражать ''весь'' диапазон следующих циклов, или ''наличие'' будущего цикла в этом диапазоне. Форма <code>next_event_a(b)[i:j](f)</code> показывает, что мы ожидаем выполнения <code>f</code> на всех ''i-х'' через ''j-е'' вхождения <code>b</code>. Например, утверждение 2.6a показывает, что когда мы видим запрос на чтение (утверждение сигнала <code>read_request</code>) с тэгом эквивалентным <code>i</code>, далее на следующих четырех передачах данных (утверждение сигнала <code>data</code>), мы ожидаем увидеть тэг <code>i</code>. Утверждение 2.6а использует конструкцию <code>forall</code>, которую мы рассмотрим в деталях позже. Сейчас достаточно сказать, что утверждение 2.6а показывает требование, что должно выполняться для всех возможных значениях сигнала <code>tag[2:0]</code>. Утверждение 2.6а выполняется в тракте 2.6(i), потому что после первого утверждения сигнала <code>read_request</code>, где значение <code>tag[2:0]</code> 4, значение <code>tag[2:0]</code>, также, 4 на четырех следующих утверждениях сигнала <code>data</code> (в циклах 5, 9, 10 и 11). Более того, на втором утверждении сигнала <code>read_request</code>, где <code>tag[2:0]</code> имеет значение 5, значение <code>tag[2:0]</code>, также, 5 на следующих четырех утверждениях сигнала <code>data</code> (циклы с 17 по 20).


Для того, чтобы указать, что мы ожидаем чего-либо в одном из следующих циклов с ''i-го'' по ''j-й'', мы можем использовать оператор <code>next_event_e(b)[i:j](f)</code>, который показывает, что мы ожидаем выполнения <code>f</code> в одном из циклов, с ''i-го'' по ''j-й'', вхождения <code>b</code>. Например, рассмотри опять утверждение 2.4a. Оно требует того, что когда бы ни приходил запрос высокого приоритета, следующим должен обработаться запрос с высоким приоритетом. Предположим вместо этого, что мы требуем, чтобы один из следующих ''двух'' грантов был для запроса с высоким приоритетом. Мы можем выразить это, используя утверждение 2.7a. Утверждение 2.7a выполняется в тракте 2.7(i), потому что всегда, когда сигнал <code>high_pri_req</code> утверждается, сигнал <code>high_pri_ack</code> утверждается на одном из следующих двух утверждений <code>gnt</code>.


Синтаксис спецификации диапазона для всех операторов, включая тех, которые мы еще не рассматривали, зависит от фундаментального языка. В вариантах Verilog, SystemVerilog и SystemC, это код <code>[i:j]</code>. Для VHDL - это код <code>[i to j]</code>. Для GDL это - <code>[i..j]</code>.

{| align=center
! [[Файл:Psl fig 02.6.png|600px]]
|-
! (i) Утверждение 2.6a выполняется
|-
|<pre>
assert forall i in {0:7}: (2.6a)
always ((read_request && tag[2:0]==i) ->
next_event_a(data)[1:4](tag[2:0]==i));
</pre>
|-
! Рис. 2.6 <code>next_event a[i:j]</code>
|}

=== 2.4 The <code>until</code> and <code>before</code> operators ===

{| align=center
! [[Файл:Psl fig 02.7.png|400px]]
|-
! (i) Assertion 2.7a holds
|-
|<pre>
assert always (high_pri_req -> (2.7a)
next_event_e(gnt)[1:2](high_pri_ack));
</pre>
|-
! Fig. 2.7: <code>next_event e[i:j]</code>
|}

The <code>until</code> operator provides another way to move forward, this time while
putting a requirement on the cycles in which we are moving. For example,
Assertion 2.8a states that whenever signal <code>req</code> is asserted, then, starting at
the next cycle, signal <code>busy</code> must be asserted up until signal <code>done is</code> asserted.
Assertion 2.8a requires that <code>busy</code> will be asserted up to, but not necessarily
including, the cycle where <code>done</code> is asserted. In order to include the cycle where
<code>done</code> is asserted, use the operator <code>until_</code>. The underscore (<code>_</code>) is intended to
represent the extra cycle in which we require that <code>busy</code> should stay asserted,
so Assertion 2.8b states that whenever signal <code>req</code> is asserted, then starting
from the next cycle, <code>busy</code> must be asserted and must stay asserted up until
and including the cycle where done is asserted. For example, Assertion 2.8a
holds on Trace 2.8(i), but Assertion 2.8b does not, because <code>busy</code> is not asserted at cycles 4 and 10. Both Assertions 2.8a and 2.8b hold on Trace 2.8(ii):
Assertion 2.8a does not prohibit the assertion of busy at cycles 4 and 10 – it
just does not require it.

If signal done is asserted the cycle after signal <code>req</code> is asserted, Assertion 2.8a does not require that signal <code>busy</code> be asserted at all, while Assertion 2.8b does. That is, Assertion 2.8a holds on Trace 2.8(iii) – the fact that
done happens immediately after <code>req</code> leaves no cycles on which busy needs to
be asserted. Assertion 2.8b does not hold on Trace 2.8(iii) because of a missing
assertion of <code>busy</code> in the cycle in which <code>done</code> is asserted.

{| align=center
! [[Файл:Psl fig 02.8.png|600px]]
|-
!
|-
|<pre>
assert always (req -> next (busy until done)); (2.8a)
assert always (req -> next(busy until_ done)); (2.8b)
</pre>
|-
! Fig. 2.8: The <code>until</code> and <code>until_</code> operators
|}

The <code>before</code> family of operators provides an easy way to state that we
require some signal to be asserted before some other signal. For example, suppose that we have a pulsed signal called <code>req</code>, and we have the requirement that
before we can make a second request, the first must be acknowledged. We can
express this in PSL using Assertion 2.9a. We need the <code>next</code> to take us forward
one cycle so that the <code>req</code> in (<code>ack before req</code>) is sure to refer to some other
<code>req</code>, and not the one we have just seen. To understand this, let us examine a
flawed version of the same specification. Consider Assertion 2.9b. It requires
that (<code>ack before req</code>) hold at every cycle in which <code>req</code> holds. Consider,
for example, cycle 1 of Trace 2.9(i). Signal <code>req</code> is asserted. Therefore, (<code>ack before req</code>) must hold at cycle 1. However, it does not, because starting at
cycle 1 and looking forward, we first see an assertion of signal <code>req</code> (at cycle 1),
and only afterwards an assertion of signal <code>ack</code> (at cycle 3) – so <code>req</code> is asserted
before <code>ack</code>, and not the other way around. Assertion 2.9a, on the other hand,
states what we want: at cycle 1, for example, we require <code>next</code> (<code>ack before req</code>) to hold. Therefore, we require that (<code>ack before req</code>) hold at cycle 2.
Starting at cycle 2 and looking forward, we first see an assertion of <code>ack</code> (at
cycle 3), and only afterwards an assertion of <code>req</code> (at cycle 6).

{| align=center
! [[Файл:Psl fig 02.9.png|600px]]
|-
|<pre>
assert always (req -> next (ack before req)); (2.9a)
assert always (req -> (ack before req)); (2.9b)
assert always (req -> next (ack before_ req)); (2.9c)
assert always (req -> (ack || next (ack before req))); (2.9d)
</pre>
|-
! Fig. 2.9 The <code>before</code> and <code>before_</code> operators
|}

The <code>before</code> operator requires that its first operand happen strictly before
its second. In order to specify that something must happen before or at the
same cycle as something else, use <code>before_</code>. The underscore (<code>_</code>) is intended
to represent the cycle in which we allow an overlap between the left and
right sides. For example, in order to specify that behavior like that shown
in Trace 2.9(i) is allowed, and that in addition behavior like that shown in
Trace 2.9(ii) is allowed, use Assertion 2.9c.

What if the assertion of <code>ack</code> is allowed to come, not together with the next
assertion of <code>req</code>, but rather together with the request being acknowledged?
In other words, what if in addition to the behavior shown in Trace 2.9(i), we
want to allow the behavior shown in Trace 2.9(iii)? As we have seen previously,
Assertion 2.9b is not the answer. Rather, we can code Assertion 2.9d.

===2.5 <code>eventually!</code>===

The <code>eventually!</code> operator allows you to specify that something must occur in
the future without saying exactly when. For example, Assertion 2.10a states
that every request (assertion of <code>req</code>) must be followed at some time with
an acknowledge (assertion of <code>ack</code>). There is nothing in Assertion 2.10a to
prevent a single acknowledge from satisfying the requirement for multiple
requests, thus Assertion 2.10a holds on Trace 2.10(i). We examine the issue
of specifying a one-to-one correspondence between signals in Section 13.4.2.

The exclamation point (<code>!</code>) of the <code>eventually!</code> operator indicates that it
is a strong operator. We discuss weak vs. strong temporal operators in detail
in Chapter 4.

{| align=center
! [[Файл:Psl fig 02.10.png|600px]]
|-
! (i) Assertion 2.10a holds
|-
|<pre>
assert always (req -> eventually! ack); (2.10a)
</pre>
|-
! Fig. 2.10: The <code>eventually!</code> operator
|}

PSL/A Practical Introduction to PSL/Basic Temporal Properties/ru

2013-11-08T14:25:46Z

Valentin: /* 2.3 вариации next, включая next_event */

{{PSL TOC}}
==Основные временные свойства While==


В то время как Булевый слой состоит из Булевых выражений, которые выполняются или не выполняются в данном цикле, временной слой предоставляет путь для описания взаимоотношений между Булевыми выражениями по времени. PSL утверждение обычно представлено только в одном направлении - вперед, от первого цикла (также можно двигаться в обратном направлении, используя встроенные функции, такие как <code>prev()</code>, <code>rose()</code> и <code>fell()</code>). Таким образом, простое PSL утверждение <code>assert a;</code> показывает, что a должно утверждаться в самом первом цикле, в то время как PSL утверждение <code>assert always a</code>, показывает, что a должно утверждаться в перовм цикле и в каждом следующем цикле, а это значит, что в каждом цикле.


Комбинированием временных операторов различными путями, мы можем установить свойства, такие как “каждый запрос получает подтверждение”, “каждому подтвержденному запросу предоставляется от четырех до семи циклов, в случаи, если запрос не приостановится первым”, “две последовательные записи не должны располагать по одному и тому же адресу” и “когда мы видим запрос на чтение с тэгом i, на следующих четырех передах данных ожидается увидеть тэг <code>i</code>”.


Временной слой состоит из фундаментального языка (FL) и дополнительного расширения ветвления (OBE). FL используется для выражения свойств одного тракта, а также используется для моделирования или формальной верификации. OBE используется для выражения свойств, относящихся к набору трактов, например, “существует тракт, такой как ...”, и также используется для формальной верификации. В этой книге мы сконцентрируемся на фундаментальном языке.


Фундаментальный язык состоит из двух комплементарных стилей - LTL стиль, названный из-за временной логики LTL, на которой базируется PSL, и SERE стиля, названного из-за последовательного расширения регулярных выражений PSL, или SEREs. В этой главе мы представим основные временные операторы LTL стиля. Мы предоставим то, что будет достаточно для понимания основной идеи, и чтобы дать некий контекст, для философских замечаний,обсуждаемых далее.


В этой книге, мы широко используем примеры. Каждый пример свойства или утверждения связан с временной диаграммой (которую мы называем ''тракт'') сгруппирован вместе на рисунке. Такой рисунок будет содержать один или более трактов, нумерованных в скобках строчными римскими цифрами, одного или более свойств, нумерованных добавление строчной буквы к номеру рисунка. Например, Рисунок 2.1 содержит тракт 2.1(i) и утверждения 2.1а, 2.1b, 2.1c.

===2.1 Операторы <code>always</code> и <code>never</code> ===


Нам уже встречались основные временные операторы <code>always</code> и <code>never</code>. Большинство свойств PSL начинаются с одного или с другого. Это, потому что “голое” (Булево) PSL свойство относится только к первому циклу тракта. Например, утверждение 2.1a требует только того, чтобы Булево выражение <code>!(a && b)</code> выполнялось в первом цикле. Таким образом, утверждение 2.1а выполняется в тракте 2.1(i), потому что Булево выражение <code>!(a && b)</code> выполняется в цикле 0. Для того, чтобы сформулировать, что мы хотим, чтобы оно выполнялось в каждом цикле проекта, мы должны добавить временной оператор <code>always</code>, и получить утверждение 2.1b. Утверждение 2.1b не поддерживает тракт 2.1(i), потому что Булево выражение <code>!(a && b)</code> не выполняется в цикле 5. Эквивалентно, мы можем поменять оператор <code>always</code> и Булево отрицание <code>!</code> с <code>never</code>, чтобы получить утверждение 2.1с.

{| align=center
! [[Файл:Psl fig 02.1.png]]
|-
!(i) Утверждение 2.1a выполняется, но 2.1b and 2.1c нет
|-
|<pre>
assert !(a && b); (2.1a)
assert always !(a && b); (2.1b)
assert never (a && b); (2.1c)
</pre>
|-
! Рис. 2.1: Операторы always и never
|}


Оба утверждения 2.1b и 2.1c показывают, что сигналы a и b взаимоисключающиеся. Очевидно, все, что может использоваться с оператором <code>always</code>, может также использоваться с оператором <code>never</code> и наоборот, происходит простое отрицанием операнда, когда происходит переключение между <code>always</code> и <code>never</code>. PSL, для удобства, предоставляет два варианта использования, иногда более удобно описать свойство положительным (если свойство выполняется на всех циклах), а иногда удобней отрицательным (если свойство не выполняется ни в каком цикле). В общем, существует много путей описания свойств в PSL. Мы рассмотрим другие примеры далее.

===2.2 Оператор <code>next</code> ===


Другой временной оператор - это оператор <code>next</code>. Он показывает, что свойство свойство должно выполняться, если его операнд выполняется в следующем цикле. Например, утверждение 2.2a показывает, что когда бы a не выполнялось, b должно выполниться в следующем цикле. Утверждение 2.2a использует другой важный оператор, логический оператор импликации (<code>-></code>). В то время как оператор логической импликации Булевый, а не временной (он не свяжет два подсвойства по времени), это играет очень важную роль во многих временных свойствах. Логическая импликация <code>prop1 -> prop2</code> выполняется, если prop1 не выполняется или prop2 выполняется. Это хорошо представляется, если принять это, как выражение вида if-then, с частью else. <code>prop1 -> prop2</code> можно понимать, как если prop1, то далее следует prop2, иначе возвращается значение правда. Таким образом, под-свойство <code>a -> next b</code>, в нашем примере, выполняется, если a не выполняется (потому что свойство по умолчание имеет значение правда) или, если a выполняется, а также и next b выполняется. Добавляя оператор always, мы получаем свойство, которое выполняется, если под-свойство <code>a -> next b</code> выполняется в каждом цикле. Таким образом, утверждение 2.2а показывает, что когда бы ни выполнялось <code>a</code>, <code>b</code> должно выполняться в следующем цикле. Утверждение 2.2а выполняется по сигналу <code>b</code>. Это показано в “if” и “then” примечании на тракте 2.2(ii). “Дополнительные” утверждения сигнала <code>b</code> на циклах 1 и 10, спровоцированы утверждение 2.2а, потому что в нем ничего не сказано о значениях b в цикле, кроме того, что следует из из утверждения <code>a</code>.


Отметим, что циклы вовлеченные в выполнение одного утверждения сигнала, могут перекрываться с теми,которые вовлечены в выполнение другого утверждения. Например, учитывая тракт 2.2(iii), который является простым трактом 2.2(ii) с if-then пронумерованными парами. Имеем четыре утверждения сигнала <code>a</code> на тракте 2.2(iii), и таким образом четыре связанных цикла, в которых <code>b</code> должен утверждаться. Каждая пара циклов (утверждение <code>a</code> следует из утверждения <code>b</code>) нумерованы в тракте 2.2(iii). Рассматривая пары 2 и 3. Сигнал a утверждается в 4 цикле пары 2, таким образом сигнал b должен утвердиться в 5 цикле, для того, чтобы утверждение 2.2а выполнялось. Сигнал а утверждается в цикле 5 пары 3, таким образом требуется утверждение сигнала b в 6 цикле. Пары 2 и 3 перекрываются, потому что, в то время как мы ищем утверждение сигнала <code>b</code> в 5 цикле, для выполнения утверждения <code>a</code> в 4 цикле, также, мы видим дополнительное утверждение сигнала <code>a</code>, который рассматривается.


Утверждение 2.2а не выполняется в тракте 2.2(iv), потому что третье утверждение сигнала <code>a</code>, в цикле 5, т.к. отсутствует утверждение сигнала <code>b</code> в следующем цикле.

{| align=center
! [[Файл:Psl fig 02.2.png]]
|-
|<pre>
assert always (a -> next b); (2.2a)
</pre>
|-
! Рис.2.2: Операторы next и логическая импликация
|}

=== 2.3 вариации <code>next</code>, включая <code>next_event</code> ===


Свойство <code>next</code> выполняется, если его операнд выполняется в следующем цикле. Вариации оператора <code>next</code> позволяют указывать ''n-й'' следующий цикл и диапазоны будущих циклов. Свойство <code>next[n]</code> выполняется, если его операнд выполняется в ''n-й'' следующий цикл. Например, утверждение 2.3а показывает, что когда бы сигнал <code>a</code> не выполнялся, сигнал <code>b</code> выполниться тремя циклами позже. Утверждение 2.3а выполняется в тактах 2.3(i), 2.3(iii), 2.3(iv), но не выполняется в трактах 2.3(ii) или 2.3(v), потому что отсутствует утверждение сигнала <code>b</code> в цикле 7, и не выполняется в тракте 2.3(vi), потому что отсутствует утверждение сигнала <code>b</code> в цикле 5.

{| align=center
! [[Файл:Psl fig 02.3.png]]
|-
!
|-
|<pre>
assert always (a -> next[3] (b)); (2.3a)
assert always (a -> next_a[3:5] (b)); (2.3b)
assert always (a -> next_e[3:5] (b)); (2.3c)
</pre>
|-
! Рис. 2.3: Операторы <code>next[n]</code>, <code>next_a[i:j]</code> и <code>next_e[i:j]</code>
|}


Свойство next_a[i:j] выполняется если его операнд выполняется во ''всех'' циклах от ''i-го'' следующего, до ''j-го'' следующего цикла включительно. Например, утверждение 2.3b показывает, что когда бы сигнал a не выполнялся, сигнал b выполняется тремя, четырьмя, пятью циклами позже. Выполняется в тракте 2.3(iii) и не выполняется в трактах 2.3(i),
2.3(ii), 2.3(iv), 2.3(v) или 2.3(vi).


Ранее мы обсуждали то факт, что циклы, вовлеченные в выполнение одного утверждения сигнала, могут перекрываться с циклами, вовлеченными для выполнения других утверждений сигнала. Тракт 2.3(iii) был представлен, чтобы с акцентировать это для утверждения 2.3b. Сигнал <code>b</code> должен утверждаться в циклах с 5 до 7 (помечено “1”), в связи с утверждением сигнала a в цикле 2, и должен утверждаться в циклах с 7 до 9 (помечено “2”), в связи с утверждением в цикле 4.


Свойство next_e[i:j] выполняется, если ''существует'' цикл со следующего <code>i</code> до следующих <code>j</code> циклов, в которых выполняются операнды. Например, утверждение 2.3с показывает, что когда бы сигнал <code>a</code> не выполнялся, сигнал <code>b</code> выполняется тремя, четырьмя или пятью циклами позже. Нету ничего в утверждении 2.3с, что предотвращает единичное утверждение сигнала <code>b</code> из выполнения многочисленных утверждений сигнала <code>a</code>, таким образом это выполняется в тракте 2.3(vi), потому что утверждение сигнала <code>b</code>, в цикле 7, появляется через 5 циклов после утверждения сигнала <code>a</code> в цикле 2, и через три цикла после утверждения сигнала <code>a</code> в цикле 4.


Утверждение 2.3с также выполняется на трактах 2.3(i), 2.3(iii), 2.3(iv) и 2.3(v), т.к. есть достаточное количество утверждений сигнала <code>b</code> в соответствующее время. В трактах 2.3(i), 2.3(iii) и 2.3(iv) более, чем достаточно утверждений сигнал <code>b</code> для выполнения утвержденного свойства (в тракте 2.3(i) утверждения сигнала <code>b</code> в цикле 7 достаточно, потому что проходит 5 циклов после утверждения сигнала <code>a</code> в цикле 2, и три цикла после утверждения сигнала <code>a</code> в цикле 4). В тракте 2.3(v) достаточно утверждений сигнала <code>b</code> для выполнения требований утверждения 2.3c.


Оператор <code>next_event</code> концептуально расширенный оператор <code>next</code>. В то время как <code>next</code> относиться к следующему циклу, <code>next_event</code> относиться к следующему циклу, в котором выполняется некоторое Булево условие. Например, утверждение 2.4а выражает требование того, что когда бы ни принимался запрос с высоким приоритетом (сигнал <code>high_pri_req</code> утвержден), то следующим (утверждение сигнала <code>gnt</code>) должен быть, также, запрос с высоким приоритетом (сигнал <code>high_pri_ack</code> утвержден). Утверждение 2.4а выполняется в тракте 2.4(i). Существует два утверждения сигнала <code>high_pri_req</code>, первое в цикле 1 и второе в цикле 10. Связанные утверждения <code>gnt</code> встречаются в циклах 4 и 11, соответственно, и <code>high_pri_ack</code> выполняется в этих циклах.


Оператор <code>next_event</code> включает текущие циклы. Это значит, утверждения сигнала <code>b</code> в текущем цикле должно считаться следующим утверждением сигнала <code>b</code> в свойстве <code>next_event(b)(p)</code>. Например, рассмотрим тракт 2.4(ii). Тракт 2.4(ii) так же, как тракт 2.4(i) ожидает, что существуют дополнительные утверждения <code>high_pri_req</code> в цикле 8 и два дополнительных утверждения <code>gnt</code> в циклах 8 и 9, одно из которых связанно с <code>high_pri_ack</code>. Утверждение 2.4а выполняется на тракте Trace 2.4(ii), потому что утверждение <code>gnt</code> в цикле 8 считается следующим утверждением <code>gnt</code> для утверждения <code>high_pri_req</code> в цикле 8. Если вы хотите исключить текущий цикл, можно вставить оператор <code>next</code> для перемещения текущего цикла оператора <code>next_event</code> на один цикл далее, как в утверждении 2.4b. Утверждение 2.4b не выполняется в тракте 2.4(ii). Потому что вставка оператора <code>next</code> привела к смене циклов утверждений <code>gnt</code>, с циклов 4, 8 и 11 для утверждения 2.4a на циклы 4, 9 и 11 для утверждения 2.4b, а в цикле 9 нету утверждений <code>high_pri_ack</code> в тракте 2.4(ii).

{| align=center
! [[Файл:Psl fig 02.4i.png]]
|-
! (i) Assertions 2.4a and 2.4b hold
|-
! [[Файл:Psl fig 02.4ii.png]]
|-
! (ii) Утверждение 2.4a выполняется, а 2.4b нет
|-
|<pre>
assert always (high_pri_req -> (2.4a)
next_event(gnt)(high_pri_ack));

assert always (high_pri_req -> (2.4b)
next next_event(gnt)(high_pri_ack));
</pre>
|-
! Рис. 2.4: <code>next_event</code>
|}

Just as we can use <code>next[i]</code> to indicate the ''ith'' next cycle, we can use
<code>next_event(b)[i]</code> to indicate the ''ith'' occurrence of <code>b</code>. For example, in order
to express the requirement that every time a request is issued (signal <code>req</code> is
asserted), <code>signal_last</code> ready must be asserted on the fourth assertion of signal
<code>ready</code>, we can code Assertion 2.5a. Assertion 2.5a holds on Trace 2.5(i). For
the first assertion of <code>req</code>, at cycle 1, the four assertions of <code>ready</code> happen
to come immediately and in consecutive cycles. For the second assertion of
<code>req</code>, at cycle 7, the four assertions of <code>ready</code> do not happen immediately and
do not happen consecutively either – they are spread out over seven cycles,
interspersed with cycles in which <code>ready</code> is deasserted. However, the point is
that in both cases, signal <code>last_ready</code> is asserted on the fourth assertion of
<code>ready</code>, thus Assertion 2.5a holds on Trace 2.5(i).

{| align=center
! [[Файл:Psl fig 02.5.png]]
|-
! (i) Assertion 2.5a holds
|-
|<pre>
assert always (req -> (2.5a)
next event(ready)[4](last ready));
</pre>
|-
! Fig. 2.5: next event[n]
|}

As with <code>next_a[i:j]</code> and <code>next_e[i:j]</code>, the <code>next_event</code> operator also
comes in forms that allow it to indicate ''all'' of a range of future cycles, or the ''existence''
of a future cycle in such a range. The form <code>next_event_a(b)[i:j](f)</code>
indicates that we expect <code>f</code> to hold on all of the ''ith'' through ''jth'' occurrences
of <code>b</code>. For example, Assertion 2.6a indicates that when we see a read request
(assertion of signal <code>read_request</code>) with tag equal to <code>i</code>, then on the next four
data transfers (assertion of signal <code>data</code>), we expect to see tag <code>i</code>. Assertion 2.6a
uses the <code>forall</code> construct, which we will examine in detail later. For now, suffice
it to say that Assertion 2.6a states a requirement that must hold for all
possible values of the signal <code>tag[2:0]</code>. Assertion 2.6a holds on Trace 2.6(i)
because after the first assertion of signal <code>read_request</code>, where <code>tag[2:0]</code> has
the value 4, the value of <code>tag[2:0]</code> is also 4 on the next four assertions of
signal <code>data</code> (at cycles 5, 9, 10 and 11). Likewise, on the second assertion of
signal <code>read_request</code>, where <code>tag[2:0]</code> has the value 5, the value of <code>tag[2:0]</code>
is also 5 on the next four assertions of signal <code>data</code> (at cycles 17 through 20).

In order to indicate that we expect something to happen on one of the next
''ith'' to ''jth'' cycles, we can use the <code>next_event_e(b)[i:j](f)</code> operator, which
indicates that we expect <code>f</code> to hold on one of the ''ith'' through ''jth'' occurrences of
<code>b</code>. For example, consider again Assertion 2.4a. It requires that whenever a high
priority request is received, the next grant must be to a high priority requester.
Suppose instead that we require that one of the next ''two'' grants be to a high
priority requester. We can express this using Assertion 2.7a. Assertion 2.7a
holds on Trace 2.7(i) because every time that signal <code>high_pri_req</code> is asserted,
signal <code>high_pri_ack</code> is asserted on one of the next two assertions of <code>gnt</code>.

The syntax of the range specification for all operators – including those
we have not yet seen – is flavor dependent. In the Verilog, SystemVerilog and
SystemC flavors, it is <code>[i:j]</code>. In the VHDL flavor it is <code>[i to j]</code>. In the GDL
flavor it is <code>[i..j]</code>.

{| align=center
! [[Файл:Psl fig 02.6.png|600px]]
|-
! (i) Assertion 2.6a holds
|-
|<pre>
assert forall i in {0:7}: (2.6a)
always ((read_request && tag[2:0]==i) ->
next_event_a(data)[1:4](tag[2:0]==i));
</pre>
|-
! Fig. 2.6 <code>next_event a[i:j]</code>
|}

=== 2.4 The <code>until</code> and <code>before</code> operators ===

{| align=center
! [[Файл:Psl fig 02.7.png|400px]]
|-
! (i) Assertion 2.7a holds
|-
|<pre>
assert always (high_pri_req -> (2.7a)
next_event_e(gnt)[1:2](high_pri_ack));
</pre>
|-
! Fig. 2.7: <code>next_event e[i:j]</code>
|}

The <code>until</code> operator provides another way to move forward, this time while
putting a requirement on the cycles in which we are moving. For example,
Assertion 2.8a states that whenever signal <code>req</code> is asserted, then, starting at
the next cycle, signal <code>busy</code> must be asserted up until signal <code>done is</code> asserted.
Assertion 2.8a requires that <code>busy</code> will be asserted up to, but not necessarily
including, the cycle where <code>done</code> is asserted. In order to include the cycle where
<code>done</code> is asserted, use the operator <code>until_</code>. The underscore (<code>_</code>) is intended to
represent the extra cycle in which we require that <code>busy</code> should stay asserted,
so Assertion 2.8b states that whenever signal <code>req</code> is asserted, then starting
from the next cycle, <code>busy</code> must be asserted and must stay asserted up until
and including the cycle where done is asserted. For example, Assertion 2.8a
holds on Trace 2.8(i), but Assertion 2.8b does not, because <code>busy</code> is not asserted at cycles 4 and 10. Both Assertions 2.8a and 2.8b hold on Trace 2.8(ii):
Assertion 2.8a does not prohibit the assertion of busy at cycles 4 and 10 – it
just does not require it.

If signal done is asserted the cycle after signal <code>req</code> is asserted, Assertion 2.8a does not require that signal <code>busy</code> be asserted at all, while Assertion 2.8b does. That is, Assertion 2.8a holds on Trace 2.8(iii) – the fact that
done happens immediately after <code>req</code> leaves no cycles on which busy needs to
be asserted. Assertion 2.8b does not hold on Trace 2.8(iii) because of a missing
assertion of <code>busy</code> in the cycle in which <code>done</code> is asserted.

{| align=center
! [[Файл:Psl fig 02.8.png|600px]]
|-
!
|-
|<pre>
assert always (req -> next (busy until done)); (2.8a)
assert always (req -> next(busy until_ done)); (2.8b)
</pre>
|-
! Fig. 2.8: The <code>until</code> and <code>until_</code> operators
|}

The <code>before</code> family of operators provides an easy way to state that we
require some signal to be asserted before some other signal. For example, suppose that we have a pulsed signal called <code>req</code>, and we have the requirement that
before we can make a second request, the first must be acknowledged. We can
express this in PSL using Assertion 2.9a. We need the <code>next</code> to take us forward
one cycle so that the <code>req</code> in (<code>ack before req</code>) is sure to refer to some other
<code>req</code>, and not the one we have just seen. To understand this, let us examine a
flawed version of the same specification. Consider Assertion 2.9b. It requires
that (<code>ack before req</code>) hold at every cycle in which <code>req</code> holds. Consider,
for example, cycle 1 of Trace 2.9(i). Signal <code>req</code> is asserted. Therefore, (<code>ack before req</code>) must hold at cycle 1. However, it does not, because starting at
cycle 1 and looking forward, we first see an assertion of signal <code>req</code> (at cycle 1),
and only afterwards an assertion of signal <code>ack</code> (at cycle 3) – so <code>req</code> is asserted
before <code>ack</code>, and not the other way around. Assertion 2.9a, on the other hand,
states what we want: at cycle 1, for example, we require <code>next</code> (<code>ack before req</code>) to hold. Therefore, we require that (<code>ack before req</code>) hold at cycle 2.
Starting at cycle 2 and looking forward, we first see an assertion of <code>ack</code> (at
cycle 3), and only afterwards an assertion of <code>req</code> (at cycle 6).

{| align=center
! [[Файл:Psl fig 02.9.png|600px]]
|-
|<pre>
assert always (req -> next (ack before req)); (2.9a)
assert always (req -> (ack before req)); (2.9b)
assert always (req -> next (ack before_ req)); (2.9c)
assert always (req -> (ack || next (ack before req))); (2.9d)
</pre>
|-
! Fig. 2.9 The <code>before</code> and <code>before_</code> operators
|}

The <code>before</code> operator requires that its first operand happen strictly before
its second. In order to specify that something must happen before or at the
same cycle as something else, use <code>before_</code>. The underscore (<code>_</code>) is intended
to represent the cycle in which we allow an overlap between the left and
right sides. For example, in order to specify that behavior like that shown
in Trace 2.9(i) is allowed, and that in addition behavior like that shown in
Trace 2.9(ii) is allowed, use Assertion 2.9c.

What if the assertion of <code>ack</code> is allowed to come, not together with the next
assertion of <code>req</code>, but rather together with the request being acknowledged?
In other words, what if in addition to the behavior shown in Trace 2.9(i), we
want to allow the behavior shown in Trace 2.9(iii)? As we have seen previously,
Assertion 2.9b is not the answer. Rather, we can code Assertion 2.9d.

===2.5 <code>eventually!</code>===

The <code>eventually!</code> operator allows you to specify that something must occur in
the future without saying exactly when. For example, Assertion 2.10a states
that every request (assertion of <code>req</code>) must be followed at some time with
an acknowledge (assertion of <code>ack</code>). There is nothing in Assertion 2.10a to
prevent a single acknowledge from satisfying the requirement for multiple
requests, thus Assertion 2.10a holds on Trace 2.10(i). We examine the issue
of specifying a one-to-one correspondence between signals in Section 13.4.2.

The exclamation point (<code>!</code>) of the <code>eventually!</code> operator indicates that it
is a strong operator. We discuss weak vs. strong temporal operators in detail
in Chapter 4.

{| align=center
! [[Файл:Psl fig 02.10.png|600px]]
|-
! (i) Assertion 2.10a holds
|-
|<pre>
assert always (req -> eventually! ack); (2.10a)
</pre>
|-
! Fig. 2.10: The <code>eventually!</code> operator
|}

PSL/A Practical Introduction to PSL/Basic Temporal Properties/ru

2013-11-01T17:40:18Z

Valentin: /* 2.3 вариации next, включая next_event */

PSL/A Practical Introduction to PSL/Basic Temporal Properties/ru

2013-10-31T10:29:34Z

Valentin: /* 2.3 вариации next, включая next_event */

PSL/A Practical Introduction to PSL/Basic Temporal Properties/ru

2013-10-31T09:43:43Z

Valentin: /* 2.3 Variations on next including next_event */

PSL/A Practical Introduction to PSL/Basic Temporal Properties/ru

2013-10-31T09:04:30Z

Valentin: /* 2.2 Оператор next */

PSL/A Practical Introduction to PSL/Basic Temporal Properties/ru

2013-10-26T15:00:05Z

Valentin: /* Основные временные свойства While */

PSL/A Practical Introduction to PSL/Basic Temporal Properties/ru

2013-10-25T10:15:09Z

Valentin: /* Basic Temporal Properties While */

PSL/A Practical Introduction to PSL/Introduction/ru

2013-10-25T09:35:29Z

Valentin:

{{PSL TOC}}


PSL - это язык спецификации свойств. Это средство выразить ''свойства'' проекта и, в дополнение, показать, как программы верификации должны использовать эти свойства. Например, свойство может быть ''утверждение'' - это означает, что проект в спорных ситуациях должен вести себя так, как описано в свойстве. Свойство, также, может быть ''предположение'' - это означает, что проект в спорных ситуациях ожидает входных данных, чтобы вести себя так, как описано в свойстве. PSL, также, предоставляет другие директивы, например средства определения сценариев, которые должны быть ''покрыты''.


PSL гораздо больше, чем просто язык утверждений. Тем не менее, утверждения - это сердце PSL, и многие пользователи PSL используют его только из-за возможностей утверждений. Таким образом, перед тем как мы разберем весь язык, пару слов о том, что на самом деле дают нам эти утверждения. Многие языки программирования (например Java) и языки описания аппаратуры (например VHDL) содержат утверждающие конструкции. Утверждающие конструкции предоставляются пользователю возможность во время выполнения или во время моделирования, что нужное условие выполняется и выдать сообщение об ошибке или предупреждении, если оно не выполняется. PSL утверждения похожи по своей сущности, но куда как более масштабные. В дополнение к простым Булевым условиям, PSL условия могут содержат ''временные'' операторы, которые разрешают пользователю описывать отношения по времени. Например, PSL утверждение <code>assert always (a -> next b);</code> показывает, что когда бы сигнал а не принимал значение, сигнал b должен принять значение в следующем цикле.


Java и VHDL утверждения встраиваются в исполняемый код, и должны быть проверены, когда достигается точка выполнения,на которой они появляются. PSL утверждения, с другой стороны, типично располагаются отдельно, и делают утверждения ''о'' коде, не являясь его частью. (Пока некоторые программы поддерживают встроенные PSL утверждения, встроенное утверждение по-прежнему не является частью кода, в том смысле, что нет возможности поместить PSL утверждение внутрь исполняемого утверждения. Встроенные PSL утверждения располагаются рядом с кодом и они определены, но не являются частью кода.)


PSL был создан, чтобы быть математически строгим, с результатом таким, что спецификация PSL точная и автоматически русифицируемая. Таким образом, аппаратная спецификация написанная на PSL читается машиной и может использоваться как вход для программ верификации. В дополнение, PSL был создам для легкого чтения и записи, таким образом PSL спецификация читается человеком и используется для документации, в целях уточнения спорных моментов из английской спецификации.


Окончательное определение PSL можно найти в IEEE Std 1850-2005. В этой книге, нашей целью является получить более спокойное, легко воспринимаемое представление языка, а также углубиться в изучение его тонкостей. Мы покроем весь PSL, а также, для полноты, включим BNF и формальную семантику, в качестве приложений.


Структура языка PSL базируется на четырех слоях - Булевый слой, временной слой, слой верификации и слой моделирования - и представляются в нескольких вариантах, что влияет на синтаксис в ограниченной форме. Четыре слоя это:


* ''Булевый слой'' состоит из Булевых выражений, это выражения, значения которого могут быть правда или ложь. Например, <code>a</code> Булево выражение. PSL интерпретирует высокий уровень сигнала, как правда, а <code>a</code> низкий уровень, как ложь, независимо от того, какой уровень для сигнала, считается активным. Таким образом, если сигнал <code>a</code> активный-высокий, Булево выражение <code>a</code> имеет значение правда, когда <code>a</code> утверждается, и ложь, когда не утверждается. А если сигнал b активный-низкий, Булево выражение <code>b</code> принимает значение ложь, когда <code>b</code> утверждается, и правда, когда не утверждается. Далее в этой книге, мы будем считать, что все сигналы имеют активный высокий уровень, если не указано иначе. Конечно, проще принять активный низкий уровень для примера свойств за счет перехода a из <code>!a</code> и наоборот. Булевый слой состоит из Булевых выражений определенного варианта. Например, <code>a && !b</code> - это Булево выражение в варианте Verilog, означает, что <code>a</code> утверждается, а <code>b</code> нет, <code>a[31:0]==b[31:0]</code> - это Булево выражение варианта Verilog, означает, что 32-х битные векторы <code>a[31:0]</code> и <code>b[31:0]</code> эквивалентны, и <code>addr1[127:0]==128’b0</code> - это булево выражение варианта Verilog, означает, что 128-и битный вектор <code>addr1[127:0]</code> имеет нулевое значение.


* ''Временной слой'' состоит из временных свойств, которые описывают взаимоотношения между Булевыми выражениями по времени. Например, <code>always (req -> next ack)</code> временное свойство, выражающее, что когда бы ни (<code>always</code>) не утверждался сигнал <code>req</code>, далее (<code>-></code>) в следующем цикле (<code>next</code>), утверждается сигнал <code>ack</code>.


* слой верификации состоит из директив, которые описывают, как временные свойства должны использоваться программами верификации. Например, утверждение <code>always (req -> next ack);</code> - это директива верификации, которая говорит программе верифицировать, что свойство <code>always (req -> next ack);</code> выполняется. Другая директива верификации включает инструкцию предположения, а не верификации, того что конкретное временное свойство выполняется или определяет критерий зоны покрытия. Слой верификации также предоставляет возможность группировать PSL утверждения в ''verification units''.

{| align=center
|
<source lang="vhdl">
vunit example1 {
assert never (a and b);
}
</source>
|<source lang="vhdl">
vunit example1 {
assert never (a && b);
}
</source>
|-
! (i) VHDL вариант
! (ii) Verilog вариант
|-
!colspan=2| Рис. 1.1: Один и тот же vunit в двух различных вариантах
|}


* ''Слой моделирования'' предоставляет возможности моделирования поведения входов проекта, и декларировать и передавать поведение вспомогательным сигналам и переменным. Эта часть слоя моделирования - просто подмножество какого-либо варианта. Например, декларация вспомогательных сигналов в варианте Verilog предполагает синтаксис Verilog.


Пять вариантов PSL соответствуют языкам описания аппаратуры Verilog и VHDL, языку GDL, языку описания среды RuleBase, и SystemVerilog и SystemC. Т.к. все варианты имеют некоторое влияние на синтаксис - например, это влияет на синтаксис Булевых выражений - большинство языков имеют схожий синтаксис.


Рисунок 1.1 показывает спецификацию PSL для VHDL и Verilog вариантов. В каждом случаи, в спецификации говориться, что сигналы a и b взаимоисключающиеся. Пока PSL пользователь не проводит много времени, думая о границах между слоями, мы будем указывать на них в первом примере. Булевы выражения <code>a and b</code> в VHDL варианте и <code>a && b</code> в Verilog варианте, принадлежать Булевому слою и описывают ситуацию, в которой оба сигнала <code>a</code> и <code>b</code> утверждаются. Ключевое слово never относиться к временному слою и показывает, что Булево выражение не ожидает своего выполнения в цикле. Вместе, ключево слово never и Булевы выражения <code>a and b</code> в VHDL варианте или <code>a && b</code> в Verilog варианте, формируют ''свойство''. Ключевое слово assert принадлежит слою верификации и инструктирует программу верификации на проверку того, что свойство выполняется в ходе тестирования проекта. Ключевое слово vunit также принадлежит слою верификации и представляет имя юнита верификации (<code>example1</code>). Слой, моделирования в данном примере, не используется.


Далее в книге, и\мы будем использовать Verilog вариант, если не указано иное. В основном мы сфокусируем наше внимание на временном слое, который является сердцем языка, и будем широко использовать Булевый слой. В глава 10 кратко обговорим различые аспекты Булевого слоя, слоя моделирования и слоя верификации, не затронутые в других главах. Также, мы сделаем предположение, что <code>‘true</code> был определен, как <code>1’b1</code> (т.е. Verilog выражение, которое выполняется в каждом цикле) и, что <code>‘false</code> опреден, как <code>1’b0</code> (т.е. Verilog выражение, которое не выполняется).

PSL/A Practical Introduction to PSL/Introduction/ru

2013-10-25T08:18:29Z

Valentin:

{{PSL TOC}}


PSL - это язык спецификации свойств. Это средство выразить ''свойства'' проекта и, в дополнение, показать, как программы верификации должны использовать эти свойства. Например, свойство может быть ''утверждение'' - это означает, что проект в спорных ситуациях должен вести себя так, как описано в свойстве. Свойство, также, может быть ''предположение'' - это означает, что проект в спорных ситуациях ожидает входных данных, чтобы вести себя так, как описано в свойстве. PSL, также, предоставляет другие директивы, например средства определения сценариев, которые должны быть ''покрыты''.


PSL гораздо больше, чем просто язык утверждений. Тем не менее, утверждения - это сердце PSL, и многие пользователи PSL используют его только из-за возможностей утверждений. Таким образом, перед тем как мы разберем весь язык, пару слов о том, что на самом деле дают нам эти утверждения. Многие языки программирования (например Java) и языки описания аппаратуры (например VHDL) содержат утверждающие конструкции. Утверждающие конструкции предоставляются пользователю возможность во время выполнения или во время моделирования, что нужное условие выполняется и выдать сообщение об ошибке или предупреждении, если оно не выполняется. PSL утверждения похожи по своей сущности, но куда как более масштабные. В дополнение к простым Булевым условиям, PSL условия могут содержат ''временные'' операторы, которые разрешают пользователю описывать отношения по времени. Например, PSL утверждение <code>assert always (a -> next b);</code> показывает, что когда бы сигнал а не принимал значение, сигнал b должен принять значение в следующем цикле.


Java и VHDL утверждения встраиваются в исполняемый код, и должны быть проверены, когда достигается точка выполнения,на которой они появляются. PSL утверждения, с другой стороны, типично располагаются отдельно, и делают утверждения ''о'' коде, не являясь его частью. (Пока некоторые программы поддерживают встроенные PSL утверждения, встроенное утверждение по-прежнему не является частью кода, в том смысле, что нет возможности поместить PSL утверждение внутрь исполняемого утверждения. Встроенные PSL утверждения располагаются рядом с кодом и они определены, но не являются частью кода.)


PSL был создан, чтобы быть математически строгим, с результатом таким, что спецификация PSL точная и автоматически русифицируемая. Таким образом, аппаратная спецификация написанная на PSL читается машиной и может использоваться как вход для программ верификации. В дополнение, PSL был создам для легкого чтения и записи, таким образом PSL спецификация читается человеком и используется для документации, в целях уточнения спорных моментов из английской спецификации.


Окончательное определение PSL можно найти в IEEE Std 1850-2005. В этой книге, нашей целью является получить более спокойное, легко воспринимаемое представление языка, а также углубиться в изучение его тонкостей. Мы покроем весь PSL, а также, для полноты, включим BNF и формальную семантику, в качестве приложений.


Структура языка PSL базируется на четырех слоях - Булевый слой, временной слой, слой верификации и слой моделирования - и представляются в нескольких вариантах, что влияет на синтаксис в ограниченной форме. Четыре слоя это:


* ''Булевый слой'' состоит из Булевых выражений, это выражения, значения которого могут быть правда или ложь. Например, <code>a</code> Булево выражение. PSL интерпретирует высокий уровень сигнала, как правда, а <code>a</code> низкий уровень, как ложь, независимо от того, какой уровень для сигнала, считается активным. Таким образом, если сигнал <code>a</code> активный-высокий, Булево выражение <code>a</code> имеет значение правда, когда <code>a</code> утверждается, и ложь, когда не утверждается. А если сигнал b активный-низкий, Булево выражение <code>b</code> принимает значение ложь, когда <code>b</code> утверждается, и правда, когда не утверждается. Далее в этой книге, мы будем считать, что все сигналы имеют активный высокий уровень, если не указано иначе. Конечно, проще принять активный низкий уровень для примера свойств за счет перехода a из <code>!a</code> и наоборот. Булевый слой состоит из Булевых выражений определенного варианта. Например, <code>a && !b</code> - это Булево выражение в варианте Verilog, означает, что <code>a</code> утверждается, а <code>b</code> нет, <code>a[31:0]==b[31:0]</code> - это Булево выражение варианта Verilog, означает, что 32-х битные векторы <code>a[31:0]</code> и <code>b[31:0]</code> эквивалентны, и <code>addr1[127:0]==128’b0</code> - это булево выражение варианта Verilog, означает, что 128-и битный вектор <code>addr1[127:0]</code> имеет нулевое значение.

* The ''temporal layer'' consists of temporal properties which describe the relationships between Boolean expressions over time. For example, <code>always (req -> next ack)</code> is a temporal property expressing the fact that whenever (<code>always</code>) signal <code>req</code> is asserted, then (<code>-></code>) at the next cycle (<code>next</code>), signal ack is asserted.

* The ''verification layer'' consists of directives which describe how the temporal properties should be used by verification tools. For example, assert <code>always (req -> next ack);</code> is a verification directive that tells the tools to verify that the property <code>always (req -> next ack)</code> holds. Other verification directives include an instruction to assume, rather than verify, that a particular temporal property holds, or to specify coverage criteria. The verification layer also provides a means to group PSL statements into ''verification units''.

{| align=center
|
<source lang="vhdl">
vunit example1 {
assert never (a and b);
}
</source>
|<source lang="vhdl">
vunit example1 {
assert never (a && b);
}
</source>
|-
! (i) VHDL flavor
! (ii) Verilog flavor
|-
!colspan=2| Fig. 1.1: The same vunit in two different flavors
|}

* The ''modeling layer'' provides a means to model behavior of design inputs, and to declare and give behavior to auxiliary signals and variables. This part of the modeling layer is simply a subset of the underlying flavor. For instance, the declaration of auxiliary signals in the Verilog flavor follows Verilog syntax.

The five flavors of PSL correspond to the hardware description languages
Verilog and VHDL, to the language GDL, the environment description language of the RuleBase model checker, and to SystemVerilog and SystemC.
While the flavor has some influence over the syntax – for instance, it affects
the syntax of Boolean expressions – the vast majority of the language is the
same across flavors.

Figure 1.1 shows a PSL specification in the VHDL and Verilog flavors. In
each case, the specification states that signals a and b are mutually exclusive.
While a PSL user typically does not spend a lot of time thinking about the
boundaries between the various layers, we will point them out in this first
example. The Boolean expressions a and b in the VHDL flavor and <code>a && b</code>
in the Verilog flavor belong to the Boolean layer and describe the situation
in which both signal <code>a</code> and signal <code>b</code> are asserted. The keyword never belongs
to the temporal layer and indicates that the Boolean expression is expected
to hold in no cycle. Together, the temporal keyword never and the Boolean
expressions <code>a and b</code> in the VHDL flavor or <code>a && b</code> in the Verilog flavor form
a ''property''. The keyword assert belongs to the verification layer and instructs
the verification tool to check that the property holds in the design under test.
The keyword vunit also belongs to the verification layer and introduces the
name of the verification unit (<code>example1</code>). The modeling layer is not used in
this example.

In the remainder of this book we use the Verilog flavor unless stated otherwise. We focus almost exclusively on the temporal layer, which is the heart of
the language and makes extensive use of the Boolean layer. Chapter 10 briefly
discusses various aspects of the Boolean, modeling and verification layers not
covered elsewhere. Throughout, we will assume that <code>‘true</code> has been defined to
be <code>1’b1</code> (i.e., a Verilog expression that holds at every cycle) and that <code>‘false</code>
has been defined to be <code>1’b0</code> (i.e., a Verilog expression that does not hold at
any cycle).

PSL/A Practical Introduction to PSL/Introduction/ru

2013-10-23T17:07:16Z

Valentin:

PSL/IEEE Standard 1850-2010 for Property Specification Language (PSL)

2013-10-23T16:23:30Z

Valentin: /* 4.4 Semantics */

{{PSL TOC}}

== 1. Обзор ==

=== 1.1 Возможность ===


Этот стандарт определяет язык свойств спецификации (PSL), который формально описывает поведение электронных систем. Этот стандарт специфицирует синтаксис и семантику для PSL, а также разъясняет, как PSL взаимодействует с различными стандартами языков описания электронных систем.

===1.2 Назначение===


Назначение этого стандарта заключается в том, чтобы предоставить четкий язык для формальной спецификации поведения электронных систем, который будет совместим с множеством языков описания электронных систем, включая IEEE Std 1076TM (VHDL®),1 IEEE Std 1364TM (Verilog®), IEEE Std 1800TM (SystemVerilog®), и IEEE Std 1666TM (SystemC®), способствуя общему потоку верификации и спецификации для проектов описанных на разных и смешанных языках.


Этот стандарт создает обновленный IEEE стандарт базирующийся на IEEE Std 1850-2005. Обновленный стандарт усовершенствует IEEE стандарт, адресные опечатки, незначительные технические вопросы и предполагаемого расширения непосредственно связанных свойств, для дальнейшего использования и облегчения моделирования.

==== 1.2.1 Происхождение ====


Сложность проектов с очень большой степенью интеграции (VLSI) выросла до такого уровня, что традиционные подходы начали достигать своего предела, а издержки верификации достигли 60%-70% от ресурсов разработки. Потребность в более продвинутой методологии верификации, с улучшенной наблюдаемостью поведения проекта и улучшенной контролируемостью (способностью контроля) процесса верификации, стала критической. За последние 10 лет, методология, базирующаяся на понятии "свойств", была определена, как мощная парадигма верификации, которая способна обеспечить повышение производительности (эффективности), повышенное качество проекта, и значительно ускорить время выхода на рынок (time to market), увеличить число производителей (higher value to engineers?) и пользователей электронных продуктов. Свойства, используемые в данном контексте, являются краткие, декларативные/описательные (declarative), выразительные/ясные/точные (expressive) и однозначные спецификации желаемого поведения системы, которые используются для проведения процесса верификации. IEEE 1850 PSL стандартный язык для описания (спецификации) поведения электронной системы, используя свойства. PSL облегчает верификацию основанную на свойствах (property-based verification) с использованием как моделирования так и формальной верификации, что позволяет повысить эффективность функциональной верификации.

====1.2.2 Мотивация====


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


IEEE PSL был создан, чтобы устранить эти недостатки. Это дает архитектуре проекта стандарт, означающий спецификацию свойств проекта
используемых краткий синтаксис с простой формальной семантикой. Аналогичным образом, позволяется RTL-исполнителю определить цели проекта в проверяемых формах, пока разрешается верификации подтвердить, что выполнение окончено и его спецификация определена через ''динамическую'' ( моделирование) и статическую (формальную) верификацию. Более того, он предоставляет средства для определения качества процесса верификации, через создание полной функциональной модели построения на формально специфицированных свойствах. В дополнение, он предоставляет стандартные средства для аппаратуры проекта и инженера верификации при создании строгой и исполняемой машиной спецификации проекта.

====1.2.3 Цели====


PSL был специально создан для исполнения следующих общих аппаратных функциональных требований:
* Легко обучать, чиать и писать
* Краткий синтаксис
* Строго определенная формальная семантика
* Выразительная мощность, позволяющая специфицировать большие классы реальных проектов
* Известные эффективные алгоритмы моделирования, такие же как формальная верификация

===1.3 Использование===


PSL язык для формальной спецификации аппаратуры. Он используется для описания свойств, которые требуют поддержки в проекте под верификацию. PSL предоставляет средства для написания спецификаций, которые легко читаются и математически точны. Это предназначение используется для функциональной спецификации, с одной стороны, и как вход в программы функциональной верификации, с другой. Таким образом, спецификация PSL - это исполняемая спецификация для аппаратного проекта.

====1.3.1 Функциональная спецификация====


PSL может использоваться для выделения требований относительно общего поведения проекта, также как допущения о среде, в которой ожидается обработка проекта. PSL также может выделять внутреннее поведение требований и допущений, которые возникают в процессе обработки проекта. Доступными являются более эффективная функциональная верификация и продолжения обработки самого проекта.


Один из важных аспектов использования PSL - это использование для документации, как вместо, так и совместно с английской спецификацией. Спецификация PSL может описать простые инварианты (например: сигналы <code>read_enable</code> и
<code>write_enable</code> никогда не используются в одно время), также как многотактовое поведение (например: правильное поведение интерфейса с поддержкой протокола шины или правильное поведение конвейерных операций).


Спецификация PSL состоит из ''утверждений'' относительно ''свойства'' проекта под набором ''допущений''. ''Свойство'' строится из трех видов элементов: ''Булевы выражения'', которые описывают поведение в одно цикле; ''последовательные выражения'', которые могут описывать многотактовое поведение; и ''временные операторы'', которые описывают временные взаимоотношения между Булевыми выражениями и последовательностями. Например, Булево выражение в Verilog:

ena || enb


Это выражение описывает цикл, в котором, по крайней мере, один из сигналов <code>ena</code> и <code>enb</code> активен. Последовательное выражение PSL

{req; ack; !cancel}


описывает последовательность циклов, такую, что если <code>req</code> активен в первом цикле, <code>ack</code> активен во втором цикле, а <code>cancel</code> неактивен в третьем цикле. Следующее свойство получается, применяя временные операторы <code>always</code> и <code>|=></code> к этим выражениям,

always {req;ack;!cancel} |=> (ena || enb)


это значит, что всегда (в каждом цикле), если встречается последовательность <code>{req;ack;!cancel}</code>, то либо <code>ena</code>, либо <code>enb</code> активен в течение цикла после окончания последовательности. Добавляя директиву <code>assert</code> следующей:

assert always {req;ack;!cancel} |=> (ena || enb);


завершается спецификация, указывая, что это свойство ожидается в проекте и что потребности это ожидания нужно верифицировать.

====1.3.2 Функциональная верификация====


PSL также может использоваться, как вход для программ верификации, как для верификации моделированием, так и для формальной верификации, используется проверка модели или теоретическое доказательство. Каждый вариант обсуждается в следующих пунктах.

=====1.3.2.1 Моделирование=====


Спецификация PSL также может использоваться для автоматического генерирования проверок поведения моделирования. Это может быть реализовано, например, прямой интеграцией проверок в программе моделирования; интерпретацией свойств PSL в тестовую автоматизированную программу, которая сопровождает симулятор; генерированием HDL контроллеров, которые моделируются рядом с проектом; или анализом путей пройденных во время моделирования.


Например, следующие PSL свойства:

Свойство 1: always (req -> next !req)


означает, что сигнал <code>req</code> пульсирующий сигнал, т.е. если он принимает высокие значения в одном цикле,то он примет низкие значения в следующем цикле. Такое свойство может быть легко проверенно, используя проверки моделирования, написанные на каком-нибудь HDL, который имеет функциональность конечного автомат (FSM), показанный на Рисунке 1.

{| align=center
! [[Файл:Std psl fig01.png|300px]]
|-
!Рисунок 1—Простой FSM, который проверяет свойство 1
|}


Для более сложных свойств, чем то что представлено на рисунке 1, писать вручную соответствующие проверки - это кропотливый труд, подверженный ошибкам, и содержание набора таких проверок для постоянно изменяющегося проекта - это очень трудоемкое задание. Вместо этого, спецификация PSL может использоваться, как вход для программы, которая автоматически генерирует проверки, поддающиеся моделированию.


Хотя в принципе, все свойства PSL могут быть проверены при окончание моделирования, исполнение проверок, часто, значительно проще для подмножеств, называемых ''простые подмножества'' PSL. Неформально, в этих подмножествах, состав временных свойств ограничен для обеспечения того, что бы время ''двигалось вперед'' слева направо через свойство, как это делается на временной диаграмме. (Смотрите 4.4.4 для формального понимания простых подмножеств.)

Например, свойство

Свойство 2: always (a -> next[3] b)


которое означает, что если <code>a</code> принимает значения, то <code>b</code> примет значение через три цикла, принадлежит простому подмножеству, потому что <code>a</code> появляется слева от <code>b</code> в свойстве и, также, появляется слева от <code>b</code> на временной диаграмме любой поведенческой модели, что не нарушает свойство. Рисунок 2 показывает пример такой временной диаграммы.

{| align=center
! [[Файл:Std psl fig02.png|400px]]
|-
! Рисунок 2—Вариант удовлетворяющий свойство 2
|}


Пример свойства не принадлежащего этому подмножеству

Свойство 3: always ((a && next[3] b) -> c)

которое значит, что если <code>a</code> принимает значение и <code>b</code> принимает значение через три цикла, то <code>c</code> принимает значение в том же цикле, что и <code>a</code>. Это свойство не принадлежит простому подмножеству, потому что хотя <code>c</code> появляется справа от <code>a</code> и <code>b</code> в свойстве, он появляется слева от <code>b</code> и <code>a</code> на временной диаграмме, и это не нарушает свойство. Рисунок 3 показывает пример такой временной диаграммы.

{| align=center
! [[Файл:Std psl fig03.png|400px]]
|-
! Рисунок 3 3—Вариант, удовлетворяющий свойство 3
|}

=====1.3.2.2 Формальная верификация=====


PSL это расширение стандарта временной логики Линейной временной логике (LTL) и Вычисляемого логического дерева (CTL). Спецификация в PSL фундаментального языка (соответственно, PSL дополнительного ветвления) может быть ''скомпилирована'' в виде чистого LTL (соответственно, CTL), возможно с некоторым вспомогательным HDL- кодом, известным, как ''спутник''.

== 3. Определения, сокращения и аббревиатуры ==

<--
For the purposes of this document, the following terms and definitions apply. The IEEE Standards Diction-
ary: Glossary of Terms & Definitions should be referenced for terms not defined in this clause.6
-->
Цели этого документа - текущие термины и определения. IEEE словарь стандартов: Cловарь терминов и определений должен ссылаться на условия неопределенные в этом пункте.6

===3.1 Определения (Definitions) ===


Этот подпункт определяет термины, используемые в этом стандарте.


'''утверждение (assertion)''': значит, что данное свойство требуется выполнить и указать программе функциональной верификации, чтобы убедиться, что оно выполняется.


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


'''асинхронное свойство (asynchronous property)''': Свойство, временной контекст которого эквивалентен значению Правда.


'''поведение (behavior)''': Путь.


'''Булевы (выражения) (Boolean (expression))''': Выражения, которые принимают на выходе логические значения.


'''проверка (checker)''': Вспомогательный процесс (обычно применяемый, как конечный автомат), который проверяет моделирование проекта и сообщения об ошибках, когда утвержденное свойство не выполняется. Проверка может быть представлена в том же HDL-коде, что и проект или в какой-либо другой форме, которая может ссылаться на моделирование проекта.


'''завершение (completes)''': Термин используемый для определения последнего цикла пути, который удовлетворяет последовательности выражений или свойств.


'''вычисленный путь (computation path)''': Правопреемство состояний проекта, такое что проект может актуально переходить из каждого состояния на пути к его преемнику.


'''ограничение (constraint)''': Состояние ( обычно для входного сигнала), которое ограничивает набор поведений, которые следует рассматривать. Ограничение может представлять реальные требования (т.е. временные требования) в среде, в которой используется проект, или может представлять искусственные ограничения (т.е. настройки режима) наложенные в порядке разделения задания функциональной верификации.


'''счетчик (count)''': Число или диапазон.


'''зона покрытия (coverage)''': Мера возникновения определенного поведения в течение (обычно динамическое) функциональной верификации и поэтому расчет сложности (динамического) процесса функциональной верификации.


'''цикл (cycle)''': Оценочный цикл.


'''описания (describes)''': Термин, используемый для определения набора поведений, для которого Булевы выражения, последовательные выражения или выполняемые свойства.


'''проект (design)''': Модель кусочка аппаратуры, описанная на некотором языке описания аппаратуры (HDL). Проект типично включает в себя набор входов, выходов, элементов состояния и комбинационных функций, которые рассчитывают следующие состояние и выходы из текущего состояния и входов.


'''поведение проекта (design behavior)''': Рассчитанный путь для данного проекта.


'''динамическая верификация (dynamic verification)''': Процесс верификации, такой как моделирование, в котором свойство проверяется
отдельно, конечные поведения проекта, которые обычно получаются динамическим проведением проекта через конечное число оценочных циклов. В общем, динамическая верификация не дает вывода о выполняющемся свойстве поведения, через которое свойство еще не было проверено.


'''оценка (evaluation)''': Процесс проведения проекта итеративным принятием значений на его входы, рассчитывая его следующие состояния и выходные значения, время опережения, и назначение переменных состояний и выходов своих следующих значений.


'''оценочный цикл (evaluation cycle)''': Одна итерация оценочного процесса. На одном оценочном цикле, состояние проекта пересчитывается ( и может быть изменено).


'''расширения (данного пути) (extension (of a given path))''': Путь, который начинается с точного правопреемства состояний в данном пути.



* '''False''' — Интерпритация определённых значений определённых типов в HDL языках. В SystemVerilog и Verilog стилях, битовые значения 1’b0, 1 ’bx, и 1’bz интерпретируются как логическое значение False. В VHDL стиле, значения STD.Standard.Boolean’(False) и STD.Standard.Bit’(‘0’), также как значения IEEE.std_logic_1164.std_logic’( ‘0’), IEEE.std_logic_1164.std_logic’(‘L’), IEEE.std_logic_1164.std_logic’(‘X’), и IEEE.std_logic_1164.std_logic’(‘Z’) все интерпретируются как логическое значение False. В SystemC стиле, значение 'false' типа bool и любой литерал типа integer с числовым значением 0 интерпретируется как значение False. В GDL стиле, значение типа Boolean 'false' и значение типа bit 0B оба интерпретируются как логическое значение False.


'''конечный диапазон (finite range)''': Диапазон с большой конечной границей.


'''формальная верификация (formal verification)''': Процесс функциональной верификации, в котором анализ дизайна и выхода свойства логически разъясняет о выполняемое свойство для все поведений проекта. Если свойство продекларировано значение "правда" программой формальной верификации, моделирование не может сделать его значение "ложным". Если свойство не выполняется для каждого поведения, то процесс формальной верификации должен предоставить специфический контрпример свойства, если это возможно.


'''функциональная верификация (functional verification)''': Процесс подтверждения того, что для данного проекта и данного набора ограничений, свойство, которое требует выполнение в этом проекте, действительно выполняется в соответствие с данными ограничениями.


'''исполнение (holds)''': Термин используемый для разъяснения значения Булевых выражений, последовательных выражений или свойств.


'''обязательное исполнение(holds tightly)''': Термин используемый для разъяснения значения последовательных выражений. Последовательные выражения оцениваются на конечной стадии (поведение).


'''живучие свойства (liveness property)''': Свойства, которые указывают на случайность, которая не ограничена во времени. Грубо говоря, живучие свойства утверждает, что что-то “хорошее” в конечном счете произошло. Более формально, живучие свойство - это свойство, для которого любая конечная стадия может быть продолжена до стадии удовлетворения свойства. Например, свойство “когда-либо сигнал req принимает значение, сигнал ack принимает значение через некоторое время” это живучие свойство.


'''логический тип (logic type)''': Тип данных HDL, который включает значения, которые интерпретируются, как логические значения. Логический тип, также, включает значения, которые не интерпретируются, как логические значения. Как логический тип, обычно, представляет многозначную логику.


'''логическое значение (logical value)''': Значение из набора {True, False}.


'''проверка на модели (model checking)''': Тип формальной верификации.


'''число (number)''': Неотрицательное целочисленное значение, и статично подсчитанное выражение полученное, как выражение.


''' (occurs)''': Термин используемый для индикации того, что Булево выражение выполняется в данном цикле.


'''occurrence (of a Boolean expression)''': Цикл, в котором выполняется Булево выражение.


'''стадия (путь) (path)''': Правопреемственность состояний проекта, ???


'''положительный счетчик (positive count)''': Положительное число или положительный диапазон.


'''положительное число (positive number)''': Число, которое больше нуля (0).


'''положительный диапазон (positive range)''': Диапазон с нижней границей большей нуля (0).


'''префикс (данной стадии) (prefix (of a given path))''': Стадия в которую расширяется данная стадия.


'''свойство (property)''': Набор логических и временных взаимоотношений между и среди подчиненных Булевых выражений, последовательных выражений и других свойств, которые в совокупности представляют набор поведений.


'''диапазон (range)''': Набор последовательных чисел, от нижней до верней границы, включительно, такой, что нижняя граница меньше или равна верхней. В частности, это предполагает случай, в котором нижняя граница эквивалентна верхней. Также, пара статически подсчитанных целочисленных выражений представляются, как наборы последовательных чисел, где левая выражения является нижней границей, а правое выражение верхней границей набора. Диапазон может описывать набор значении и переменное число циклов или повторяющихся событий.


'''ограничение (restriction)''': Утверждение, что проект ограничивается данным последовательным выражением, и директива программе функциональной верификации рассматривать только стадию, на которой выполняется данное последовательное выражение.


'''защищенное свойство (safety property)''': Свойство, которое указывает инвариантность по состояниям в проекте. Инвариантность - это необязательно ограниченность в один цикл, но ограниченность по времени. Грубо говоря, защищенное свойство показывает, что ничего “плохого” не произошло. Более формально, защищенное свойство - это свойство, для которого любая стадия имеющая навязывающееся свойство получает конечный префикс, такой ,что каждое расширение префикса навязывается свойству. Например, свойство “когда-либо сигнал req принимает значение, сигнал ack принимает значение через три цикла”, является защищенным свойством.


'''последовательность (sequence)''': Последовательное выражение, которое может напрямую использоваться в течение свойства или директивы.


'''последовательное выражение (sequential expression)''': Законченный набор терминов, который представляет набор поведений.

'''последовательные регулярно расширяемые выражения (sequential extended regular expression)''': Форма последовательных выражений и компонентов последовательностей.


'''начало (starts)''': Термин используемый для идентификации первого цикла пути, который удовлетворяет последовательное выражение.


'''строго перед (strictly before)''': Перед, и не в этом же цикле.


'''сильный оператор (strong operator)''': Временной оператор, неотрицательное использование которого, обычно, создает живучие свойства.


'''временное выражение (temporal expression)''': Выражение, которое включает один или более временных операторов.


'''временной оператор (temporal operator)''' Оператор, который представляет временные ( т.е. ориентированные во времени) взаимоотношения между операндами.


'''условие завершения (terminating condition)''': Булево выражение, появление которого, приводит к завершению свойства.


'''свойство завершения (terminating property)''': Свойство, выполнение которого, приводит к завершению другого свойства.


* '''True''': Интерпритация определённых значений определённых типов в HDL языках.
** В SystemVerilog и Verilog стилях, битовые значение 1'b1 интерпретируется как логическое значение True.
** В VHDL стиле, значения STD.Standard.Boolean'(True), STD.Standard.Bit'('1'), IEEE.std_logic_1164.std_logic'('1'), и IEEE.std_logic_1164.std_logic'('H') интерпретируются как логическое значение True.
** В SystemC стиле, значение 'true' типа bool и любой литерал типа integer с ненулевым числовым значением интерпретируется как логическое значение True.
** В GDL стиле, значение типа Boolean 'true' и значение типа bit 1B интерпретируются как логическое значение True.


'''неизвестное значение (unknown value)''': Значение (многозначного) логического типа, отличное от 0 и 1.


'''слабый оператор (weak operator)''': Временной оператор, неотрицательное использование которого не создает живучего свойства.

== 3.2 Сокращения и аббревиатуры ==

* ABV — утверждения, базирующиеся на верификации
* BNF — расширенная форма Бакуса-Наура
* cpp — C препроцессор
* CTL — вычисляемое логическое дерево
* EDA — авторматизация проектирования
* FL — фундаметальный язык
* FSM — конечный автомат
* GDL — общий язык описания
* HDL — язык описания аппаратуры
* iff — если, и только если
* LTL — линейная временная логика
* PSL — язык спецификации свойств
* OBE — дополнительное расширение ветвления
* RTL — уровень регистровых передач
* SERE — последовательное расширенное регулярное выражение
* VHDL — VHSIC язык описания аппаратуры
* VHSIC — высоко скоростная интегральная схема

==== 4.1.1 Слои (Layers) ====
PSL состоит из четырёх слоёв: булевый (Boolean), временной (temporal), верификационный (verification), и модельный (modeling).

===== 4.1.1.1 Булевый слой (Boolean layer) =====


Булевый слой используется для создания выражений, которые, в свою очередь, используются другими слоями. Хотя этот слой содержит выражения над многими типами, он называется как булевый слой, потому что он является поставщиком булевых (логических) выражений для основы (сердца) языка — временнОго слоя. Выражения булевого слоя выполняются в едином (одиночном) цикле выполнения.

===== 4.1.1.2 ВременнОй слой (Temporal layer) =====

Временной слой является основой языка; он используется для описания свойств проекта. Он называется временным, потому что, в дополнение к простым свойствам, таким как "сигналы a и b являются взаимноисключающими", он может также описывать свойства включающие сложные временные отношения между сигналами, например "если сигнал c устанавливается, тогда сигнал d должен установиться прежде, чем сигнал e установится, но не позже более восьми периодов синхросигнала". ВременнЫе выражения выполняются в течении серии циклов выполнения.

===== 4.1.1.3 Верификационный слой (Verification layer) =====


Верификационный слой используется для того чтобы сказать верификационному инструменту (САПР), что делать с свойствами описанными во временном слое. Например, верификационный слой включает директивы, которые говорят инструменту (САПР) чтобы верифицировал (verify) то, что свойство удерживает (hold) или проверил (check) то, что заданная последовательность покрыта некоторым тестирующим случаем.

===== 4.1.1.4 Моделирующий слой (Modeling layer) =====


Моделирующий слой (Modeling layer) используется для моделирования поведения входов проекта (для инструментов (САПР), таких как инструменты (САПР) для формальной верификации, которые не используют тестов) и для моделирования дополнительной аппаратуры, которая не является частью проекта, но необходима для верификации.

==== 4.1.2 Стили/Варианты (Flavors) ====


PSL идёт с пятью вариантами/стилями (flavors): один для каждого HDL языка SystemVerilog, Verilog, VHDL, SystemC, и GDL. Синтаксис каждого варианта (стиля) соответствует синтаксису соответствующего HDL языка в ряде конкретных областей — данный стиль PSL совместим с соответствующим синтаксисом HDL-языка в этой области.

{| class=standard align=center
|+ Влияние стиля на слои PSL
!rowspan=2| Слой ||colspan=5 | HDL
|-
! SystemVerilog || Verolog || VHDL || SystemC || GDL
|-
| Булевый || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}}
|-
| Модельный || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}}
|-
| Временной || i:j || i:j || i to j || i:j || i..j
|-

|}

=== 4.2 Лексическая структура ===


Этот подпункт определяет идентификаторы, ключевые слова, операторы, макросы и комментарии, используемые в PSL.

==== 4.2.1 Идентификаторы (Identifiers) ====


Идентификаторы в PSL состоят из символа латинского алфавита, за которым следует ноль или более символов латинского алфавита; каждый последующий символ алфавита может по желанию предшествовать одному символу подчеркивания. Например:

mutex
Read_Transaction
L_123


PSL идентификаторы являются чувстительными к регистру в SystemVerilog, Verilog, и SystemC вариантах/стилях и не чувствительными к регистру в VHDL и GDL вариантах.

==== 4.2.2 Ключевые слова ====

{|
|<poem> A
E
next!
rose
AF
EF
next_a
AG
EG
next_a!
</poem>
| <poem> sequence
AX
abort
EX
next_e
stable
always
ended
next_e!
string
</poem>
| <poem>anda
eventually!
next_event
strong
assert
next_event!
sync_abort
assume
F
next_event_a
</poem>
| <poem>async_abort
fairness
next_event_a!
toe
before
fell
next_event_e
before!
for
next_event_e!
</poem>
| <poem> U
before!_
forall
nondet
union
before_
nondet_vector
until
bitvector
bit
</poem>
| <poem> G
notc
until!
boolean
numeric
until!_
hdltype
until_
clock
onehot
</poem>
| <poem>const
in
onehot0
vmode
countones
inf
ord
vpkg
cover
inherit
</poem>
| <poem> vprop
isb
property
vunit
default
isunknown
prev
W
report
mutable
</poem>
| <poem> within
restrict
restrict!
never
X
next
X!</poem>
|}

*a and is a keyword only in the VHDL flavor; see the flavor macro AND_OP (4.3.2.6).
*b is is a keyword only in the VHDL flavor; see the flavor macro DEF_SYM (4.3.2.9).
*c not is a keyword only in the VHDL flavor; see the flavor macro NOT_OP (4.3.2.6).
*d or is a keyword only in the VHDL flavor; see the flavor macro OR_OP (4.3.2.6).
*e to is a keyword only in the VHDL flavor; see the flavor macro RANGE_SYM (4.3.2.7).

==== 4.2.3 Операторы ====

===== 4.2.3.1 Операторы HDL языка =====

Для заданного стиля PSL, операторы основного HDL языка имеют наивысший преоритет. В частности это включает логические, арифметические операторы и операторы отношения языка HDL. Логические операции HDL языка для отрицания, конъюнкции и дизъюнкции булевых (логических) значений могут использоваться в PSL для отрицания, конъюнкции и дизъюнкции свойств. В таких приложениях, эти операторы имеют их обычный приоритет и ассоциативность, как если бы PSL свойства,....

===== 4.2.3.2 Операторы фундаментального языка =====


Различные операторы доступны в PSL. Каждый оператор имеет приоритет по отношению к другим операторам. В общем операторы с большим приоритетом получают доступ к свои операндам, раньше, чем операнды с меньшим приоритетом. Если два оператора имеют одинаковый приоритет и появляются в последовательности, то они получают доступ к свои операндам в соответствие с ассоциативностью операторов. Лева-ассоциативные оператор получает доступ к своим операндам слева на право в порядке появления в тексте, право-ассоциативные операторы получают доступ к своим операндам справа на лева в порядке появления в тексте.

{| class=standard align=center
|+ Таблица приоритетов и ассоциативности двух операторов фундаментального языка
|-
! Оператор класс || Ассоциативность ||colspan=2| Операторы
|-
| ''(наивысший приоритет)''

HDL операторы
| || ||
|-
| Оператор объединения || left || union ||
|-
| Оператор времени || left || @ ||
|-
| SERE повторяющийся оператор || left || [* ] [+] [= ] [-> ] ||
|-
| Последовательный предельный оператор || left || within ||
|-
| Последовательный оператор И || left || & || &&
|-
| Последовательный оператор ИЛИ || left || <nowiki>|</nowiki> ||
|-
| Последовательный оператор слияния || left || : ||
|-
| Последовательный оператор конкатенации || left || ; ||
|-
| Операторы прерывания фундаментального языка || left || abort sync_abort || async_abort
|-
| Операторы фундаментального языка, указывающие местонахождение || right || next* || eventually!
|-
| || || X X! || F
|-
| Операторы фундаментального языка, показывающие границы || right || U || W
|-
| || || until* || before*
|-
| Последовательный оператор импликации || right || <nowiki>|-></nowiki> || <nowiki>|=></nowiki>
|-
| Булевы операторы импликации || right || -> || <->
|-
| Неизменные операторы фундаментального языка ''(низший приоритет)'' || right || always G || never
|-
|}


Примечание - Обозначение next* представляет семейство next-операторов, которое включает операторы: next, next!,
next_a, next_a!, next_e, next_e!, next_event, next_event!, next_event_a! и
next_event_e!. Обозначение until* представляет семейство until-операторов, которое включает операторы: until,
until!, until_ и until!_. Обозначение before* представляет семейство before-операторов, которое включает операторы: before, before!, before_, and before!_.7

====== 4.2.3.2.1 Объединительные операторы ======


Для любого стиля PSL, FL оператор со следующим наибольшим приоритетом после HDL операторов является тот, который используется для обозначения недетерминированного выражения:

union union оператор

Оператор union является лева-ассоциативным.

====== 4.2.3.2.2 Операторы времени ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это оператор времени, который используется для связи временного выражения со свойством или последовательностью:

@ clock event

Временной оператор лева-ассоциативный.

====== 4.2.3.2.3 SERE операторы повторов (repetition operators) ======


Для любого стиля PSL, FL операторы со следующим наибольшим приоритетом являются операторами повторов, которые используются для создания последовательных расширенных регулярных выражений (Sequential Extended Regular Expressions — SEREs). Эти операторы следующие:

[* ] последовательное повторение (consecutive repetition)
[+] последовательное повторение (consecutive repetition)
[= ] не последовательное повторение (non-consecutive repetition)
[-> ] goto repetition

SERE операторы повторения являются лева-ассоциативными.

====== 4.2.3.2.4 Последовательный предельный оператор ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это последовательный предельный оператор, который используется для описания поведения, в котором одна последовательность появляется в ходе другой, или в пределах интервала ограниченного временем.

within последовательность within оператор

Последовательный предельный оператор лева-ассоциативный.

====== 4.2.3.2.5 Последовательные операторы конъюнкции ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетов - это последовательные операторы конъюнкции, которые описывают поведение состоящие из параллельных стадий. Это следующие операторы:

& последовательная конъюнкция без сопоставления длинны
&& последовательная конъюнкция с сопоставлением длины

Последовательные операторы конъюнкции лева-ассоциативные.

====== 4.2.3.2.6 Последовательный оператор дизъюнкции ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это последовательный оператор дизъюнкции, который используются для описания поведения состоящего из альтернативных стадий:

| последовательная дизъюнкция

Последовательный оператор дизъюнкции лева-ассоциативный.

====== 4.2.3.2.7 Последовательный оператор слияния ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это последовательный оператор слияния, который используется для описания поведения, в котором более поздняя последовательность начинает выполняться в том же цикле, в котором заканчивает выполняться более ранняя.

: последовательное слияние

Последовательный оператор слияния лева-ассоциативный.

====== 4.2.3.2.8 Последовательный оператор конкатенации ======


Для любого варианта PSL, оператор фундаментального со следующим наивысшим приоритетом - это последовательный оператор конкатенации, который используется, чтобы описывать поведение, в котором одна последовательность следует за другой:

; последовательная конкатенация

Последовательный оператор конкатенации лева-ассоциативный.

====== 4.2.3.2.9 Операторы прерывания фундаментального языка ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом - это операторы прерывания фундаментального языка, которые используются для описания поведения, в котором условие вызывает текущие и будущие процессы, которые будут прерваны:

sync_abort немедленное завершение текущего и следующего процесса, синхронизовано по времени
async_abort немедленное прерывание текущего и следующего процесса, независт от времени
abort эквивалентно to async_abort

Операторы прерывания фундаментального языка лева-ассоциативные.

====== 4.2.3.2.10 Операторы местонахождения фундаментального языка ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, в котором операнды используются в будущем. Это следующие операторы:
eventually! правый операнд выполняется через некоторое время в неопределенном будущем
next* правый операнд выполняется в некотором специфицированном будущем времени или диапазоне будущего времени
операторы местонахождения фундаментального языка право-ассоциативные.

====== 4.2.3.2.11 Граничные операторы ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые описывают поведение, в котором одно свойство выполняется в некотором цикле или во всех циклах перед выполнением следующего слова. Это следующие операторы:

until* левый операнд выполняется в любое время до выполнения правого операнда
before* левый операнд выполняется через некоторое время после выполнения правого

Граничные операторы фундаментального языка право-ассоциативные.

====== 4.2.3.2.12 Суффиксные операторы импликации ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, состоящего из свойства, которое выполняется в конце данной последовательности. Это следующие операторы:

|-> суффиксная импликация с перекрытием
|=> суффиксная импликация без перекрытия


Операторы суффиксной импликации право-ассоциативные.


Примечание - Свойство фундаментального языка {r} (f) - это альтернативная форма (и имеет такую же семантику) для свойства фундаментального языка {r} |-> f.

====== 4.2.3.2.13 Операторы логической импликации ======


Для любого варианта PSL, операторый фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, состоящего из Булевых выражений, последовательности или свойства, которое выполняется, если выполняется другое Булево выражение, последовательность или свойство.

-> логическая IF импикация
<-> логическая IFF импликация


Операторы логической импликации право-ассоциативные.

====== 4.2.3.2.14 Операторы неизменности фундаментального языка ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, в котором выполняется или не выполняется глобально.

always правый операнд выполняется глобально
never правый операнд не выполняется глобально

Операторы неизменности фундаментального языка право-ассоциативные.

===== 4.2.3.3 Операторы дополнительного расширенного ветвления (OBE) =====

{| class=standard align=center
|+ Таблица 3—OBE оператор, приоритет и ассоциативность
|-
! Класс оператора || Ассоциативность ||colspan=2| Операторы
|-
| (наивысший приоритет) HDL операторы || || ||
|-
| OBE операторы местонахождения ||left || AX AG AF A [ U ] || EX EG EF E [ U ]
|-
| Операторы Булевой импликации (низший приоритет) || right || -> || <->
|}

====== 4.2.3.3.1 OBE операторы местонахождения ======


Для любого варианта PSL, OBE операторы являются следующими операторами с наивысшим приоритетом, после HDL операторов, они используются для указания, когда подчиненное свойство должно выполняться, если выполняется старшее свойство. Это следующие операторы:

AX на всех путях, на следующем состоянии каждого пути
AG на всех путях, на каждом состоянии любого пути
AF на всех путях, на некотором будущем состоянии каждого пути
EX на некотором пути, на следующем состоянии пути
EG на некотором пути, на всех состояния пути
EF на некотором пути , на некотором будущем состоянии пути
A[U] на всех путях, в каждом состоянии до определенного состояния пути
E[U] на некотором пути, в каждом состоянии до определенного состояния пути

OBE операторы местонахождения лева-ассоциативные.

====== 4.2.3.3.2 OBE операторы импликации ======


Для любого варианта PSL, OBE операторы со следующим наивысшим приоритетом, это те которые используются для описания поведения, состоящего из Булевых выражений или свойства, которое выполняется, если Булево выражение или другое свойство выполняется. Это следующие операторы:

-> логическая IF импликация
<-> логическая IFF импликация

Операторы логической IF и логической IFF импликации право-ассоциативные.

==== 4.2.4 Макросы ====


PSL предоставляет возможность обработки макросов, которые помогают в определении свойств. SystemC, VHDL и
GDL варианты поддерживают cpp препроцессорные директивы (т.е. #define, #ifdef, #else, #include и #undef).
SystemVerilog и Verilog поддерживают директивы Verilog компилятора (т.е. `define, `ifdef, `else, `include и `undef). Все варианты, также поддерживают PSL макросы %for и %if, которые могут использоваться для условно или итеративно генерированного PSL утверждения. Компилированные директивы Verilog или cpp должны быть интерпретированы первыми, макросы PSL %if и %for должны быть интепретированы вторыми

===== 4.2.4.1 Конструкция %for =====

===== 4.2.4.2 Конструкция %if =====

==== 4.2.5 Комментарии ====

PSL обеспечивает возможность вставки комментариев в PSL спецификацию. Для каждого стиля, возможность комментариев совместима с тем, что обеспечивается соответсвующией средой PSL.

Для SystemC, SystemVerilog, и Verilog стиля, оба варианта блочных комментариев (/* .... */) и (// .... ''<eol>'') поддерживается. (''<eol>'' — конец строки)

Для стиля VHDL, поддерживается комментарии (-- .... ''<eol>'').

Для стиля GDL, оба блочных стилей комментариев поддерживаются: (/* .... */) и (-- .... ''<eol>'').

=== 4.3 Синтаксис ===

==== 4.3.1 Соответствия ====

{| class=standard align=center
! Операнд || SystemVerilog || Verilog || VHDL || SystemC || GDL
|-
| И || && || && || and || && || &
|-
| ИЛИ || <nowiki>||</nowiki> || <nowiki>||</nowiki> || or || <nowiki>||</nowiki> || <nowiki>|</nowiki>
|-
| НЕ || ! || ! || not || ! || !
|-
| ДИАПАЗОН || : || : || to || :|| ..
|-
| МИНИМАЛЬНОЕ ЗНАЧЕНИЕ || 0 || 0 || 0 || 0 || null
|-
| МАКСИМАЛЬНОЕ ЗНАЧЕНИЯ || $ || inf || inf || inf || null
|-
| ЛЕВАЯ ГРАНИЦА || [ || [ || ( || [ || (
|-
| ПРАВАЯ ГРАНИЦА || ] || ] || ) || ] || )
|-
| ПРИСВАИВАНИЕ || = || = || is || = || :=
|}

=== 4.4 Семантика ===


Следующие подпункты представляют различные общие концепции связанные со спецификацией временных свойств и пояснения того, как они применяются в PSL.

==== 4.4.1 Временная оценка против не временной оценки ====

== NEW ==

PSL/IEEE Standard 1850-2010 for Property Specification Language (PSL)

2013-10-23T16:18:23Z

Valentin: /* 4.3 Syntax */

{{PSL TOC}}

== 1. Обзор ==

=== 1.1 Возможность ===


Этот стандарт определяет язык свойств спецификации (PSL), который формально описывает поведение электронных систем. Этот стандарт специфицирует синтаксис и семантику для PSL, а также разъясняет, как PSL взаимодействует с различными стандартами языков описания электронных систем.

===1.2 Назначение===


Назначение этого стандарта заключается в том, чтобы предоставить четкий язык для формальной спецификации поведения электронных систем, который будет совместим с множеством языков описания электронных систем, включая IEEE Std 1076TM (VHDL®),1 IEEE Std 1364TM (Verilog®), IEEE Std 1800TM (SystemVerilog®), и IEEE Std 1666TM (SystemC®), способствуя общему потоку верификации и спецификации для проектов описанных на разных и смешанных языках.


Этот стандарт создает обновленный IEEE стандарт базирующийся на IEEE Std 1850-2005. Обновленный стандарт усовершенствует IEEE стандарт, адресные опечатки, незначительные технические вопросы и предполагаемого расширения непосредственно связанных свойств, для дальнейшего использования и облегчения моделирования.

==== 1.2.1 Происхождение ====


Сложность проектов с очень большой степенью интеграции (VLSI) выросла до такого уровня, что традиционные подходы начали достигать своего предела, а издержки верификации достигли 60%-70% от ресурсов разработки. Потребность в более продвинутой методологии верификации, с улучшенной наблюдаемостью поведения проекта и улучшенной контролируемостью (способностью контроля) процесса верификации, стала критической. За последние 10 лет, методология, базирующаяся на понятии "свойств", была определена, как мощная парадигма верификации, которая способна обеспечить повышение производительности (эффективности), повышенное качество проекта, и значительно ускорить время выхода на рынок (time to market), увеличить число производителей (higher value to engineers?) и пользователей электронных продуктов. Свойства, используемые в данном контексте, являются краткие, декларативные/описательные (declarative), выразительные/ясные/точные (expressive) и однозначные спецификации желаемого поведения системы, которые используются для проведения процесса верификации. IEEE 1850 PSL стандартный язык для описания (спецификации) поведения электронной системы, используя свойства. PSL облегчает верификацию основанную на свойствах (property-based verification) с использованием как моделирования так и формальной верификации, что позволяет повысить эффективность функциональной верификации.

====1.2.2 Мотивация====


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


IEEE PSL был создан, чтобы устранить эти недостатки. Это дает архитектуре проекта стандарт, означающий спецификацию свойств проекта
используемых краткий синтаксис с простой формальной семантикой. Аналогичным образом, позволяется RTL-исполнителю определить цели проекта в проверяемых формах, пока разрешается верификации подтвердить, что выполнение окончено и его спецификация определена через ''динамическую'' ( моделирование) и статическую (формальную) верификацию. Более того, он предоставляет средства для определения качества процесса верификации, через создание полной функциональной модели построения на формально специфицированных свойствах. В дополнение, он предоставляет стандартные средства для аппаратуры проекта и инженера верификации при создании строгой и исполняемой машиной спецификации проекта.

====1.2.3 Цели====


PSL был специально создан для исполнения следующих общих аппаратных функциональных требований:
* Легко обучать, чиать и писать
* Краткий синтаксис
* Строго определенная формальная семантика
* Выразительная мощность, позволяющая специфицировать большие классы реальных проектов
* Известные эффективные алгоритмы моделирования, такие же как формальная верификация

===1.3 Использование===


PSL язык для формальной спецификации аппаратуры. Он используется для описания свойств, которые требуют поддержки в проекте под верификацию. PSL предоставляет средства для написания спецификаций, которые легко читаются и математически точны. Это предназначение используется для функциональной спецификации, с одной стороны, и как вход в программы функциональной верификации, с другой. Таким образом, спецификация PSL - это исполняемая спецификация для аппаратного проекта.

====1.3.1 Функциональная спецификация====


PSL может использоваться для выделения требований относительно общего поведения проекта, также как допущения о среде, в которой ожидается обработка проекта. PSL также может выделять внутреннее поведение требований и допущений, которые возникают в процессе обработки проекта. Доступными являются более эффективная функциональная верификация и продолжения обработки самого проекта.


Один из важных аспектов использования PSL - это использование для документации, как вместо, так и совместно с английской спецификацией. Спецификация PSL может описать простые инварианты (например: сигналы <code>read_enable</code> и
<code>write_enable</code> никогда не используются в одно время), также как многотактовое поведение (например: правильное поведение интерфейса с поддержкой протокола шины или правильное поведение конвейерных операций).


Спецификация PSL состоит из ''утверждений'' относительно ''свойства'' проекта под набором ''допущений''. ''Свойство'' строится из трех видов элементов: ''Булевы выражения'', которые описывают поведение в одно цикле; ''последовательные выражения'', которые могут описывать многотактовое поведение; и ''временные операторы'', которые описывают временные взаимоотношения между Булевыми выражениями и последовательностями. Например, Булево выражение в Verilog:

ena || enb


Это выражение описывает цикл, в котором, по крайней мере, один из сигналов <code>ena</code> и <code>enb</code> активен. Последовательное выражение PSL

{req; ack; !cancel}


описывает последовательность циклов, такую, что если <code>req</code> активен в первом цикле, <code>ack</code> активен во втором цикле, а <code>cancel</code> неактивен в третьем цикле. Следующее свойство получается, применяя временные операторы <code>always</code> и <code>|=></code> к этим выражениям,

always {req;ack;!cancel} |=> (ena || enb)


это значит, что всегда (в каждом цикле), если встречается последовательность <code>{req;ack;!cancel}</code>, то либо <code>ena</code>, либо <code>enb</code> активен в течение цикла после окончания последовательности. Добавляя директиву <code>assert</code> следующей:

assert always {req;ack;!cancel} |=> (ena || enb);


завершается спецификация, указывая, что это свойство ожидается в проекте и что потребности это ожидания нужно верифицировать.

====1.3.2 Функциональная верификация====


PSL также может использоваться, как вход для программ верификации, как для верификации моделированием, так и для формальной верификации, используется проверка модели или теоретическое доказательство. Каждый вариант обсуждается в следующих пунктах.

=====1.3.2.1 Моделирование=====


Спецификация PSL также может использоваться для автоматического генерирования проверок поведения моделирования. Это может быть реализовано, например, прямой интеграцией проверок в программе моделирования; интерпретацией свойств PSL в тестовую автоматизированную программу, которая сопровождает симулятор; генерированием HDL контроллеров, которые моделируются рядом с проектом; или анализом путей пройденных во время моделирования.


Например, следующие PSL свойства:

Свойство 1: always (req -> next !req)


означает, что сигнал <code>req</code> пульсирующий сигнал, т.е. если он принимает высокие значения в одном цикле,то он примет низкие значения в следующем цикле. Такое свойство может быть легко проверенно, используя проверки моделирования, написанные на каком-нибудь HDL, который имеет функциональность конечного автомат (FSM), показанный на Рисунке 1.

{| align=center
! [[Файл:Std psl fig01.png|300px]]
|-
!Рисунок 1—Простой FSM, который проверяет свойство 1
|}


Для более сложных свойств, чем то что представлено на рисунке 1, писать вручную соответствующие проверки - это кропотливый труд, подверженный ошибкам, и содержание набора таких проверок для постоянно изменяющегося проекта - это очень трудоемкое задание. Вместо этого, спецификация PSL может использоваться, как вход для программы, которая автоматически генерирует проверки, поддающиеся моделированию.


Хотя в принципе, все свойства PSL могут быть проверены при окончание моделирования, исполнение проверок, часто, значительно проще для подмножеств, называемых ''простые подмножества'' PSL. Неформально, в этих подмножествах, состав временных свойств ограничен для обеспечения того, что бы время ''двигалось вперед'' слева направо через свойство, как это делается на временной диаграмме. (Смотрите 4.4.4 для формального понимания простых подмножеств.)

Например, свойство

Свойство 2: always (a -> next[3] b)


которое означает, что если <code>a</code> принимает значения, то <code>b</code> примет значение через три цикла, принадлежит простому подмножеству, потому что <code>a</code> появляется слева от <code>b</code> в свойстве и, также, появляется слева от <code>b</code> на временной диаграмме любой поведенческой модели, что не нарушает свойство. Рисунок 2 показывает пример такой временной диаграммы.

{| align=center
! [[Файл:Std psl fig02.png|400px]]
|-
! Рисунок 2—Вариант удовлетворяющий свойство 2
|}


Пример свойства не принадлежащего этому подмножеству

Свойство 3: always ((a && next[3] b) -> c)

которое значит, что если <code>a</code> принимает значение и <code>b</code> принимает значение через три цикла, то <code>c</code> принимает значение в том же цикле, что и <code>a</code>. Это свойство не принадлежит простому подмножеству, потому что хотя <code>c</code> появляется справа от <code>a</code> и <code>b</code> в свойстве, он появляется слева от <code>b</code> и <code>a</code> на временной диаграмме, и это не нарушает свойство. Рисунок 3 показывает пример такой временной диаграммы.

{| align=center
! [[Файл:Std psl fig03.png|400px]]
|-
! Рисунок 3 3—Вариант, удовлетворяющий свойство 3
|}

=====1.3.2.2 Формальная верификация=====


PSL это расширение стандарта временной логики Линейной временной логике (LTL) и Вычисляемого логического дерева (CTL). Спецификация в PSL фундаментального языка (соответственно, PSL дополнительного ветвления) может быть ''скомпилирована'' в виде чистого LTL (соответственно, CTL), возможно с некоторым вспомогательным HDL- кодом, известным, как ''спутник''.

== 3. Определения, сокращения и аббревиатуры ==

<--
For the purposes of this document, the following terms and definitions apply. The IEEE Standards Diction-
ary: Glossary of Terms & Definitions should be referenced for terms not defined in this clause.6
-->
Цели этого документа - текущие термины и определения. IEEE словарь стандартов: Cловарь терминов и определений должен ссылаться на условия неопределенные в этом пункте.6

===3.1 Определения (Definitions) ===


Этот подпункт определяет термины, используемые в этом стандарте.


'''утверждение (assertion)''': значит, что данное свойство требуется выполнить и указать программе функциональной верификации, чтобы убедиться, что оно выполняется.


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


'''асинхронное свойство (asynchronous property)''': Свойство, временной контекст которого эквивалентен значению Правда.


'''поведение (behavior)''': Путь.


'''Булевы (выражения) (Boolean (expression))''': Выражения, которые принимают на выходе логические значения.


'''проверка (checker)''': Вспомогательный процесс (обычно применяемый, как конечный автомат), который проверяет моделирование проекта и сообщения об ошибках, когда утвержденное свойство не выполняется. Проверка может быть представлена в том же HDL-коде, что и проект или в какой-либо другой форме, которая может ссылаться на моделирование проекта.


'''завершение (completes)''': Термин используемый для определения последнего цикла пути, который удовлетворяет последовательности выражений или свойств.


'''вычисленный путь (computation path)''': Правопреемство состояний проекта, такое что проект может актуально переходить из каждого состояния на пути к его преемнику.


'''ограничение (constraint)''': Состояние ( обычно для входного сигнала), которое ограничивает набор поведений, которые следует рассматривать. Ограничение может представлять реальные требования (т.е. временные требования) в среде, в которой используется проект, или может представлять искусственные ограничения (т.е. настройки режима) наложенные в порядке разделения задания функциональной верификации.


'''счетчик (count)''': Число или диапазон.


'''зона покрытия (coverage)''': Мера возникновения определенного поведения в течение (обычно динамическое) функциональной верификации и поэтому расчет сложности (динамического) процесса функциональной верификации.


'''цикл (cycle)''': Оценочный цикл.


'''описания (describes)''': Термин, используемый для определения набора поведений, для которого Булевы выражения, последовательные выражения или выполняемые свойства.


'''проект (design)''': Модель кусочка аппаратуры, описанная на некотором языке описания аппаратуры (HDL). Проект типично включает в себя набор входов, выходов, элементов состояния и комбинационных функций, которые рассчитывают следующие состояние и выходы из текущего состояния и входов.


'''поведение проекта (design behavior)''': Рассчитанный путь для данного проекта.


'''динамическая верификация (dynamic verification)''': Процесс верификации, такой как моделирование, в котором свойство проверяется
отдельно, конечные поведения проекта, которые обычно получаются динамическим проведением проекта через конечное число оценочных циклов. В общем, динамическая верификация не дает вывода о выполняющемся свойстве поведения, через которое свойство еще не было проверено.


'''оценка (evaluation)''': Процесс проведения проекта итеративным принятием значений на его входы, рассчитывая его следующие состояния и выходные значения, время опережения, и назначение переменных состояний и выходов своих следующих значений.


'''оценочный цикл (evaluation cycle)''': Одна итерация оценочного процесса. На одном оценочном цикле, состояние проекта пересчитывается ( и может быть изменено).


'''расширения (данного пути) (extension (of a given path))''': Путь, который начинается с точного правопреемства состояний в данном пути.



* '''False''' — Интерпритация определённых значений определённых типов в HDL языках. В SystemVerilog и Verilog стилях, битовые значения 1’b0, 1 ’bx, и 1’bz интерпретируются как логическое значение False. В VHDL стиле, значения STD.Standard.Boolean’(False) и STD.Standard.Bit’(‘0’), также как значения IEEE.std_logic_1164.std_logic’( ‘0’), IEEE.std_logic_1164.std_logic’(‘L’), IEEE.std_logic_1164.std_logic’(‘X’), и IEEE.std_logic_1164.std_logic’(‘Z’) все интерпретируются как логическое значение False. В SystemC стиле, значение 'false' типа bool и любой литерал типа integer с числовым значением 0 интерпретируется как значение False. В GDL стиле, значение типа Boolean 'false' и значение типа bit 0B оба интерпретируются как логическое значение False.


'''конечный диапазон (finite range)''': Диапазон с большой конечной границей.


'''формальная верификация (formal verification)''': Процесс функциональной верификации, в котором анализ дизайна и выхода свойства логически разъясняет о выполняемое свойство для все поведений проекта. Если свойство продекларировано значение "правда" программой формальной верификации, моделирование не может сделать его значение "ложным". Если свойство не выполняется для каждого поведения, то процесс формальной верификации должен предоставить специфический контрпример свойства, если это возможно.


'''функциональная верификация (functional verification)''': Процесс подтверждения того, что для данного проекта и данного набора ограничений, свойство, которое требует выполнение в этом проекте, действительно выполняется в соответствие с данными ограничениями.


'''исполнение (holds)''': Термин используемый для разъяснения значения Булевых выражений, последовательных выражений или свойств.


'''обязательное исполнение(holds tightly)''': Термин используемый для разъяснения значения последовательных выражений. Последовательные выражения оцениваются на конечной стадии (поведение).


'''живучие свойства (liveness property)''': Свойства, которые указывают на случайность, которая не ограничена во времени. Грубо говоря, живучие свойства утверждает, что что-то “хорошее” в конечном счете произошло. Более формально, живучие свойство - это свойство, для которого любая конечная стадия может быть продолжена до стадии удовлетворения свойства. Например, свойство “когда-либо сигнал req принимает значение, сигнал ack принимает значение через некоторое время” это живучие свойство.


'''логический тип (logic type)''': Тип данных HDL, который включает значения, которые интерпретируются, как логические значения. Логический тип, также, включает значения, которые не интерпретируются, как логические значения. Как логический тип, обычно, представляет многозначную логику.


'''логическое значение (logical value)''': Значение из набора {True, False}.


'''проверка на модели (model checking)''': Тип формальной верификации.


'''число (number)''': Неотрицательное целочисленное значение, и статично подсчитанное выражение полученное, как выражение.


''' (occurs)''': Термин используемый для индикации того, что Булево выражение выполняется в данном цикле.


'''occurrence (of a Boolean expression)''': Цикл, в котором выполняется Булево выражение.


'''стадия (путь) (path)''': Правопреемственность состояний проекта, ???


'''положительный счетчик (positive count)''': Положительное число или положительный диапазон.


'''положительное число (positive number)''': Число, которое больше нуля (0).


'''положительный диапазон (positive range)''': Диапазон с нижней границей большей нуля (0).


'''префикс (данной стадии) (prefix (of a given path))''': Стадия в которую расширяется данная стадия.


'''свойство (property)''': Набор логических и временных взаимоотношений между и среди подчиненных Булевых выражений, последовательных выражений и других свойств, которые в совокупности представляют набор поведений.


'''диапазон (range)''': Набор последовательных чисел, от нижней до верней границы, включительно, такой, что нижняя граница меньше или равна верхней. В частности, это предполагает случай, в котором нижняя граница эквивалентна верхней. Также, пара статически подсчитанных целочисленных выражений представляются, как наборы последовательных чисел, где левая выражения является нижней границей, а правое выражение верхней границей набора. Диапазон может описывать набор значении и переменное число циклов или повторяющихся событий.


'''ограничение (restriction)''': Утверждение, что проект ограничивается данным последовательным выражением, и директива программе функциональной верификации рассматривать только стадию, на которой выполняется данное последовательное выражение.


'''защищенное свойство (safety property)''': Свойство, которое указывает инвариантность по состояниям в проекте. Инвариантность - это необязательно ограниченность в один цикл, но ограниченность по времени. Грубо говоря, защищенное свойство показывает, что ничего “плохого” не произошло. Более формально, защищенное свойство - это свойство, для которого любая стадия имеющая навязывающееся свойство получает конечный префикс, такой ,что каждое расширение префикса навязывается свойству. Например, свойство “когда-либо сигнал req принимает значение, сигнал ack принимает значение через три цикла”, является защищенным свойством.


'''последовательность (sequence)''': Последовательное выражение, которое может напрямую использоваться в течение свойства или директивы.


'''последовательное выражение (sequential expression)''': Законченный набор терминов, который представляет набор поведений.

'''последовательные регулярно расширяемые выражения (sequential extended regular expression)''': Форма последовательных выражений и компонентов последовательностей.


'''начало (starts)''': Термин используемый для идентификации первого цикла пути, который удовлетворяет последовательное выражение.


'''строго перед (strictly before)''': Перед, и не в этом же цикле.


'''сильный оператор (strong operator)''': Временной оператор, неотрицательное использование которого, обычно, создает живучие свойства.


'''временное выражение (temporal expression)''': Выражение, которое включает один или более временных операторов.


'''временной оператор (temporal operator)''' Оператор, который представляет временные ( т.е. ориентированные во времени) взаимоотношения между операндами.


'''условие завершения (terminating condition)''': Булево выражение, появление которого, приводит к завершению свойства.


'''свойство завершения (terminating property)''': Свойство, выполнение которого, приводит к завершению другого свойства.


* '''True''': Интерпритация определённых значений определённых типов в HDL языках.
** В SystemVerilog и Verilog стилях, битовые значение 1'b1 интерпретируется как логическое значение True.
** В VHDL стиле, значения STD.Standard.Boolean'(True), STD.Standard.Bit'('1'), IEEE.std_logic_1164.std_logic'('1'), и IEEE.std_logic_1164.std_logic'('H') интерпретируются как логическое значение True.
** В SystemC стиле, значение 'true' типа bool и любой литерал типа integer с ненулевым числовым значением интерпретируется как логическое значение True.
** В GDL стиле, значение типа Boolean 'true' и значение типа bit 1B интерпретируются как логическое значение True.


'''неизвестное значение (unknown value)''': Значение (многозначного) логического типа, отличное от 0 и 1.


'''слабый оператор (weak operator)''': Временной оператор, неотрицательное использование которого не создает живучего свойства.

== 3.2 Сокращения и аббревиатуры ==

* ABV — утверждения, базирующиеся на верификации
* BNF — расширенная форма Бакуса-Наура
* cpp — C препроцессор
* CTL — вычисляемое логическое дерево
* EDA — авторматизация проектирования
* FL — фундаметальный язык
* FSM — конечный автомат
* GDL — общий язык описания
* HDL — язык описания аппаратуры
* iff — если, и только если
* LTL — линейная временная логика
* PSL — язык спецификации свойств
* OBE — дополнительное расширение ветвления
* RTL — уровень регистровых передач
* SERE — последовательное расширенное регулярное выражение
* VHDL — VHSIC язык описания аппаратуры
* VHSIC — высоко скоростная интегральная схема

==== 4.1.1 Слои (Layers) ====
PSL состоит из четырёх слоёв: булевый (Boolean), временной (temporal), верификационный (verification), и модельный (modeling).

===== 4.1.1.1 Булевый слой (Boolean layer) =====


Булевый слой используется для создания выражений, которые, в свою очередь, используются другими слоями. Хотя этот слой содержит выражения над многими типами, он называется как булевый слой, потому что он является поставщиком булевых (логических) выражений для основы (сердца) языка — временнОго слоя. Выражения булевого слоя выполняются в едином (одиночном) цикле выполнения.

===== 4.1.1.2 ВременнОй слой (Temporal layer) =====

Временной слой является основой языка; он используется для описания свойств проекта. Он называется временным, потому что, в дополнение к простым свойствам, таким как "сигналы a и b являются взаимноисключающими", он может также описывать свойства включающие сложные временные отношения между сигналами, например "если сигнал c устанавливается, тогда сигнал d должен установиться прежде, чем сигнал e установится, но не позже более восьми периодов синхросигнала". ВременнЫе выражения выполняются в течении серии циклов выполнения.

===== 4.1.1.3 Верификационный слой (Verification layer) =====


Верификационный слой используется для того чтобы сказать верификационному инструменту (САПР), что делать с свойствами описанными во временном слое. Например, верификационный слой включает директивы, которые говорят инструменту (САПР) чтобы верифицировал (verify) то, что свойство удерживает (hold) или проверил (check) то, что заданная последовательность покрыта некоторым тестирующим случаем.

===== 4.1.1.4 Моделирующий слой (Modeling layer) =====


Моделирующий слой (Modeling layer) используется для моделирования поведения входов проекта (для инструментов (САПР), таких как инструменты (САПР) для формальной верификации, которые не используют тестов) и для моделирования дополнительной аппаратуры, которая не является частью проекта, но необходима для верификации.

==== 4.1.2 Стили/Варианты (Flavors) ====


PSL идёт с пятью вариантами/стилями (flavors): один для каждого HDL языка SystemVerilog, Verilog, VHDL, SystemC, и GDL. Синтаксис каждого варианта (стиля) соответствует синтаксису соответствующего HDL языка в ряде конкретных областей — данный стиль PSL совместим с соответствующим синтаксисом HDL-языка в этой области.

{| class=standard align=center
|+ Влияние стиля на слои PSL
!rowspan=2| Слой ||colspan=5 | HDL
|-
! SystemVerilog || Verolog || VHDL || SystemC || GDL
|-
| Булевый || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}}
|-
| Модельный || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}}
|-
| Временной || i:j || i:j || i to j || i:j || i..j
|-

|}

=== 4.2 Лексическая структура ===


Этот подпункт определяет идентификаторы, ключевые слова, операторы, макросы и комментарии, используемые в PSL.

==== 4.2.1 Идентификаторы (Identifiers) ====


Идентификаторы в PSL состоят из символа латинского алфавита, за которым следует ноль или более символов латинского алфавита; каждый последующий символ алфавита может по желанию предшествовать одному символу подчеркивания. Например:

mutex
Read_Transaction
L_123


PSL идентификаторы являются чувстительными к регистру в SystemVerilog, Verilog, и SystemC вариантах/стилях и не чувствительными к регистру в VHDL и GDL вариантах.

==== 4.2.2 Ключевые слова ====

{|
|<poem> A
E
next!
rose
AF
EF
next_a
AG
EG
next_a!
</poem>
| <poem> sequence
AX
abort
EX
next_e
stable
always
ended
next_e!
string
</poem>
| <poem>anda
eventually!
next_event
strong
assert
next_event!
sync_abort
assume
F
next_event_a
</poem>
| <poem>async_abort
fairness
next_event_a!
toe
before
fell
next_event_e
before!
for
next_event_e!
</poem>
| <poem> U
before!_
forall
nondet
union
before_
nondet_vector
until
bitvector
bit
</poem>
| <poem> G
notc
until!
boolean
numeric
until!_
hdltype
until_
clock
onehot
</poem>
| <poem>const
in
onehot0
vmode
countones
inf
ord
vpkg
cover
inherit
</poem>
| <poem> vprop
isb
property
vunit
default
isunknown
prev
W
report
mutable
</poem>
| <poem> within
restrict
restrict!
never
X
next
X!</poem>
|}

*a and is a keyword only in the VHDL flavor; see the flavor macro AND_OP (4.3.2.6).
*b is is a keyword only in the VHDL flavor; see the flavor macro DEF_SYM (4.3.2.9).
*c not is a keyword only in the VHDL flavor; see the flavor macro NOT_OP (4.3.2.6).
*d or is a keyword only in the VHDL flavor; see the flavor macro OR_OP (4.3.2.6).
*e to is a keyword only in the VHDL flavor; see the flavor macro RANGE_SYM (4.3.2.7).

==== 4.2.3 Операторы ====

===== 4.2.3.1 Операторы HDL языка =====

Для заданного стиля PSL, операторы основного HDL языка имеют наивысший преоритет. В частности это включает логические, арифметические операторы и операторы отношения языка HDL. Логические операции HDL языка для отрицания, конъюнкции и дизъюнкции булевых (логических) значений могут использоваться в PSL для отрицания, конъюнкции и дизъюнкции свойств. В таких приложениях, эти операторы имеют их обычный приоритет и ассоциативность, как если бы PSL свойства,....

===== 4.2.3.2 Операторы фундаментального языка =====


Различные операторы доступны в PSL. Каждый оператор имеет приоритет по отношению к другим операторам. В общем операторы с большим приоритетом получают доступ к свои операндам, раньше, чем операнды с меньшим приоритетом. Если два оператора имеют одинаковый приоритет и появляются в последовательности, то они получают доступ к свои операндам в соответствие с ассоциативностью операторов. Лева-ассоциативные оператор получает доступ к своим операндам слева на право в порядке появления в тексте, право-ассоциативные операторы получают доступ к своим операндам справа на лева в порядке появления в тексте.

{| class=standard align=center
|+ Таблица приоритетов и ассоциативности двух операторов фундаментального языка
|-
! Оператор класс || Ассоциативность ||colspan=2| Операторы
|-
| ''(наивысший приоритет)''

HDL операторы
| || ||
|-
| Оператор объединения || left || union ||
|-
| Оператор времени || left || @ ||
|-
| SERE повторяющийся оператор || left || [* ] [+] [= ] [-> ] ||
|-
| Последовательный предельный оператор || left || within ||
|-
| Последовательный оператор И || left || & || &&
|-
| Последовательный оператор ИЛИ || left || <nowiki>|</nowiki> ||
|-
| Последовательный оператор слияния || left || : ||
|-
| Последовательный оператор конкатенации || left || ; ||
|-
| Операторы прерывания фундаментального языка || left || abort sync_abort || async_abort
|-
| Операторы фундаментального языка, указывающие местонахождение || right || next* || eventually!
|-
| || || X X! || F
|-
| Операторы фундаментального языка, показывающие границы || right || U || W
|-
| || || until* || before*
|-
| Последовательный оператор импликации || right || <nowiki>|-></nowiki> || <nowiki>|=></nowiki>
|-
| Булевы операторы импликации || right || -> || <->
|-
| Неизменные операторы фундаментального языка ''(низший приоритет)'' || right || always G || never
|-
|}


Примечание - Обозначение next* представляет семейство next-операторов, которое включает операторы: next, next!,
next_a, next_a!, next_e, next_e!, next_event, next_event!, next_event_a! и
next_event_e!. Обозначение until* представляет семейство until-операторов, которое включает операторы: until,
until!, until_ и until!_. Обозначение before* представляет семейство before-операторов, которое включает операторы: before, before!, before_, and before!_.7

====== 4.2.3.2.1 Объединительные операторы ======


Для любого стиля PSL, FL оператор со следующим наибольшим приоритетом после HDL операторов является тот, который используется для обозначения недетерминированного выражения:

union union оператор

Оператор union является лева-ассоциативным.

====== 4.2.3.2.2 Операторы времени ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это оператор времени, который используется для связи временного выражения со свойством или последовательностью:

@ clock event

Временной оператор лева-ассоциативный.

====== 4.2.3.2.3 SERE операторы повторов (repetition operators) ======


Для любого стиля PSL, FL операторы со следующим наибольшим приоритетом являются операторами повторов, которые используются для создания последовательных расширенных регулярных выражений (Sequential Extended Regular Expressions — SEREs). Эти операторы следующие:

[* ] последовательное повторение (consecutive repetition)
[+] последовательное повторение (consecutive repetition)
[= ] не последовательное повторение (non-consecutive repetition)
[-> ] goto repetition

SERE операторы повторения являются лева-ассоциативными.

====== 4.2.3.2.4 Последовательный предельный оператор ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это последовательный предельный оператор, который используется для описания поведения, в котором одна последовательность появляется в ходе другой, или в пределах интервала ограниченного временем.

within последовательность within оператор

Последовательный предельный оператор лева-ассоциативный.

====== 4.2.3.2.5 Последовательные операторы конъюнкции ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетов - это последовательные операторы конъюнкции, которые описывают поведение состоящие из параллельных стадий. Это следующие операторы:

& последовательная конъюнкция без сопоставления длинны
&& последовательная конъюнкция с сопоставлением длины

Последовательные операторы конъюнкции лева-ассоциативные.

====== 4.2.3.2.6 Последовательный оператор дизъюнкции ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это последовательный оператор дизъюнкции, который используются для описания поведения состоящего из альтернативных стадий:

| последовательная дизъюнкция

Последовательный оператор дизъюнкции лева-ассоциативный.

====== 4.2.3.2.7 Последовательный оператор слияния ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это последовательный оператор слияния, который используется для описания поведения, в котором более поздняя последовательность начинает выполняться в том же цикле, в котором заканчивает выполняться более ранняя.

: последовательное слияние

Последовательный оператор слияния лева-ассоциативный.

====== 4.2.3.2.8 Последовательный оператор конкатенации ======


Для любого варианта PSL, оператор фундаментального со следующим наивысшим приоритетом - это последовательный оператор конкатенации, который используется, чтобы описывать поведение, в котором одна последовательность следует за другой:

; последовательная конкатенация

Последовательный оператор конкатенации лева-ассоциативный.

====== 4.2.3.2.9 Операторы прерывания фундаментального языка ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом - это операторы прерывания фундаментального языка, которые используются для описания поведения, в котором условие вызывает текущие и будущие процессы, которые будут прерваны:

sync_abort немедленное завершение текущего и следующего процесса, синхронизовано по времени
async_abort немедленное прерывание текущего и следующего процесса, независт от времени
abort эквивалентно to async_abort

Операторы прерывания фундаментального языка лева-ассоциативные.

====== 4.2.3.2.10 Операторы местонахождения фундаментального языка ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, в котором операнды используются в будущем. Это следующие операторы:
eventually! правый операнд выполняется через некоторое время в неопределенном будущем
next* правый операнд выполняется в некотором специфицированном будущем времени или диапазоне будущего времени
операторы местонахождения фундаментального языка право-ассоциативные.

====== 4.2.3.2.11 Граничные операторы ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые описывают поведение, в котором одно свойство выполняется в некотором цикле или во всех циклах перед выполнением следующего слова. Это следующие операторы:

until* левый операнд выполняется в любое время до выполнения правого операнда
before* левый операнд выполняется через некоторое время после выполнения правого

Граничные операторы фундаментального языка право-ассоциативные.

====== 4.2.3.2.12 Суффиксные операторы импликации ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, состоящего из свойства, которое выполняется в конце данной последовательности. Это следующие операторы:

|-> суффиксная импликация с перекрытием
|=> суффиксная импликация без перекрытия


Операторы суффиксной импликации право-ассоциативные.


Примечание - Свойство фундаментального языка {r} (f) - это альтернативная форма (и имеет такую же семантику) для свойства фундаментального языка {r} |-> f.

====== 4.2.3.2.13 Операторы логической импликации ======


Для любого варианта PSL, операторый фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, состоящего из Булевых выражений, последовательности или свойства, которое выполняется, если выполняется другое Булево выражение, последовательность или свойство.

-> логическая IF импикация
<-> логическая IFF импликация


Операторы логической импликации право-ассоциативные.

====== 4.2.3.2.14 Операторы неизменности фундаментального языка ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, в котором выполняется или не выполняется глобально.

always правый операнд выполняется глобально
never правый операнд не выполняется глобально

Операторы неизменности фундаментального языка право-ассоциативные.

===== 4.2.3.3 Операторы дополнительного расширенного ветвления (OBE) =====

{| class=standard align=center
|+ Таблица 3—OBE оператор, приоритет и ассоциативность
|-
! Класс оператора || Ассоциативность ||colspan=2| Операторы
|-
| (наивысший приоритет) HDL операторы || || ||
|-
| OBE операторы местонахождения ||left || AX AG AF A [ U ] || EX EG EF E [ U ]
|-
| Операторы Булевой импликации (низший приоритет) || right || -> || <->
|}

====== 4.2.3.3.1 OBE операторы местонахождения ======


Для любого варианта PSL, OBE операторы являются следующими операторами с наивысшим приоритетом, после HDL операторов, они используются для указания, когда подчиненное свойство должно выполняться, если выполняется старшее свойство. Это следующие операторы:

AX на всех путях, на следующем состоянии каждого пути
AG на всех путях, на каждом состоянии любого пути
AF на всех путях, на некотором будущем состоянии каждого пути
EX на некотором пути, на следующем состоянии пути
EG на некотором пути, на всех состояния пути
EF на некотором пути , на некотором будущем состоянии пути
A[U] на всех путях, в каждом состоянии до определенного состояния пути
E[U] на некотором пути, в каждом состоянии до определенного состояния пути

OBE операторы местонахождения лева-ассоциативные.

====== 4.2.3.3.2 OBE операторы импликации ======


Для любого варианта PSL, OBE операторы со следующим наивысшим приоритетом, это те которые используются для описания поведения, состоящего из Булевых выражений или свойства, которое выполняется, если Булево выражение или другое свойство выполняется. Это следующие операторы:

-> логическая IF импликация
<-> логическая IFF импликация

Операторы логической IF и логической IFF импликации право-ассоциативные.

==== 4.2.4 Макросы ====


PSL предоставляет возможность обработки макросов, которые помогают в определении свойств. SystemC, VHDL и
GDL варианты поддерживают cpp препроцессорные директивы (т.е. #define, #ifdef, #else, #include и #undef).
SystemVerilog и Verilog поддерживают директивы Verilog компилятора (т.е. `define, `ifdef, `else, `include и `undef). Все варианты, также поддерживают PSL макросы %for и %if, которые могут использоваться для условно или итеративно генерированного PSL утверждения. Компилированные директивы Verilog или cpp должны быть интерпретированы первыми, макросы PSL %if и %for должны быть интепретированы вторыми

===== 4.2.4.1 Конструкция %for =====

===== 4.2.4.2 Конструкция %if =====

==== 4.2.5 Комментарии ====

PSL обеспечивает возможность вставки комментариев в PSL спецификацию. Для каждого стиля, возможность комментариев совместима с тем, что обеспечивается соответсвующией средой PSL.

Для SystemC, SystemVerilog, и Verilog стиля, оба варианта блочных комментариев (/* .... */) и (// .... ''<eol>'') поддерживается. (''<eol>'' — конец строки)

Для стиля VHDL, поддерживается комментарии (-- .... ''<eol>'').

Для стиля GDL, оба блочных стилей комментариев поддерживаются: (/* .... */) и (-- .... ''<eol>'').

=== 4.3 Синтаксис ===

==== 4.3.1 Соответствия ====

{| class=standard align=center
! Операнд || SystemVerilog || Verilog || VHDL || SystemC || GDL
|-
| И || && || && || and || && || &
|-
| ИЛИ || <nowiki>||</nowiki> || <nowiki>||</nowiki> || or || <nowiki>||</nowiki> || <nowiki>|</nowiki>
|-
| НЕ || ! || ! || not || ! || !
|-
| ДИАПАЗОН || : || : || to || :|| ..
|-
| МИНИМАЛЬНОЕ ЗНАЧЕНИЕ || 0 || 0 || 0 || 0 || null
|-
| МАКСИМАЛЬНОЕ ЗНАЧЕНИЯ || $ || inf || inf || inf || null
|-
| ЛЕВАЯ ГРАНИЦА || [ || [ || ( || [ || (
|-
| ПРАВАЯ ГРАНИЦА || ] || ] || ) || ] || )
|-
| ПРИСВАИВАНИЕ || = || = || is || = || :=
|}

=== 4.4 Semantics ===

The following subclauses introduce various general concepts related to temporal property specification and
explain how they apply to PSL.

==== 4.4.1 Clocked vs. unclocked evaluation ====

== NEW ==

PSL/IEEE Standard 1850-2010 for Property Specification Language (PSL)

2013-10-23T16:13:27Z

Valentin: /* 4.2.4 Макросы */

{{PSL TOC}}

== 1. Обзор ==

=== 1.1 Возможность ===


Этот стандарт определяет язык свойств спецификации (PSL), который формально описывает поведение электронных систем. Этот стандарт специфицирует синтаксис и семантику для PSL, а также разъясняет, как PSL взаимодействует с различными стандартами языков описания электронных систем.

===1.2 Назначение===


Назначение этого стандарта заключается в том, чтобы предоставить четкий язык для формальной спецификации поведения электронных систем, который будет совместим с множеством языков описания электронных систем, включая IEEE Std 1076TM (VHDL®),1 IEEE Std 1364TM (Verilog®), IEEE Std 1800TM (SystemVerilog®), и IEEE Std 1666TM (SystemC®), способствуя общему потоку верификации и спецификации для проектов описанных на разных и смешанных языках.


Этот стандарт создает обновленный IEEE стандарт базирующийся на IEEE Std 1850-2005. Обновленный стандарт усовершенствует IEEE стандарт, адресные опечатки, незначительные технические вопросы и предполагаемого расширения непосредственно связанных свойств, для дальнейшего использования и облегчения моделирования.

==== 1.2.1 Происхождение ====


Сложность проектов с очень большой степенью интеграции (VLSI) выросла до такого уровня, что традиционные подходы начали достигать своего предела, а издержки верификации достигли 60%-70% от ресурсов разработки. Потребность в более продвинутой методологии верификации, с улучшенной наблюдаемостью поведения проекта и улучшенной контролируемостью (способностью контроля) процесса верификации, стала критической. За последние 10 лет, методология, базирующаяся на понятии "свойств", была определена, как мощная парадигма верификации, которая способна обеспечить повышение производительности (эффективности), повышенное качество проекта, и значительно ускорить время выхода на рынок (time to market), увеличить число производителей (higher value to engineers?) и пользователей электронных продуктов. Свойства, используемые в данном контексте, являются краткие, декларативные/описательные (declarative), выразительные/ясные/точные (expressive) и однозначные спецификации желаемого поведения системы, которые используются для проведения процесса верификации. IEEE 1850 PSL стандартный язык для описания (спецификации) поведения электронной системы, используя свойства. PSL облегчает верификацию основанную на свойствах (property-based verification) с использованием как моделирования так и формальной верификации, что позволяет повысить эффективность функциональной верификации.

====1.2.2 Мотивация====


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


IEEE PSL был создан, чтобы устранить эти недостатки. Это дает архитектуре проекта стандарт, означающий спецификацию свойств проекта
используемых краткий синтаксис с простой формальной семантикой. Аналогичным образом, позволяется RTL-исполнителю определить цели проекта в проверяемых формах, пока разрешается верификации подтвердить, что выполнение окончено и его спецификация определена через ''динамическую'' ( моделирование) и статическую (формальную) верификацию. Более того, он предоставляет средства для определения качества процесса верификации, через создание полной функциональной модели построения на формально специфицированных свойствах. В дополнение, он предоставляет стандартные средства для аппаратуры проекта и инженера верификации при создании строгой и исполняемой машиной спецификации проекта.

====1.2.3 Цели====


PSL был специально создан для исполнения следующих общих аппаратных функциональных требований:
* Легко обучать, чиать и писать
* Краткий синтаксис
* Строго определенная формальная семантика
* Выразительная мощность, позволяющая специфицировать большие классы реальных проектов
* Известные эффективные алгоритмы моделирования, такие же как формальная верификация

===1.3 Использование===


PSL язык для формальной спецификации аппаратуры. Он используется для описания свойств, которые требуют поддержки в проекте под верификацию. PSL предоставляет средства для написания спецификаций, которые легко читаются и математически точны. Это предназначение используется для функциональной спецификации, с одной стороны, и как вход в программы функциональной верификации, с другой. Таким образом, спецификация PSL - это исполняемая спецификация для аппаратного проекта.

====1.3.1 Функциональная спецификация====


PSL может использоваться для выделения требований относительно общего поведения проекта, также как допущения о среде, в которой ожидается обработка проекта. PSL также может выделять внутреннее поведение требований и допущений, которые возникают в процессе обработки проекта. Доступными являются более эффективная функциональная верификация и продолжения обработки самого проекта.


Один из важных аспектов использования PSL - это использование для документации, как вместо, так и совместно с английской спецификацией. Спецификация PSL может описать простые инварианты (например: сигналы <code>read_enable</code> и
<code>write_enable</code> никогда не используются в одно время), также как многотактовое поведение (например: правильное поведение интерфейса с поддержкой протокола шины или правильное поведение конвейерных операций).


Спецификация PSL состоит из ''утверждений'' относительно ''свойства'' проекта под набором ''допущений''. ''Свойство'' строится из трех видов элементов: ''Булевы выражения'', которые описывают поведение в одно цикле; ''последовательные выражения'', которые могут описывать многотактовое поведение; и ''временные операторы'', которые описывают временные взаимоотношения между Булевыми выражениями и последовательностями. Например, Булево выражение в Verilog:

ena || enb


Это выражение описывает цикл, в котором, по крайней мере, один из сигналов <code>ena</code> и <code>enb</code> активен. Последовательное выражение PSL

{req; ack; !cancel}


описывает последовательность циклов, такую, что если <code>req</code> активен в первом цикле, <code>ack</code> активен во втором цикле, а <code>cancel</code> неактивен в третьем цикле. Следующее свойство получается, применяя временные операторы <code>always</code> и <code>|=></code> к этим выражениям,

always {req;ack;!cancel} |=> (ena || enb)


это значит, что всегда (в каждом цикле), если встречается последовательность <code>{req;ack;!cancel}</code>, то либо <code>ena</code>, либо <code>enb</code> активен в течение цикла после окончания последовательности. Добавляя директиву <code>assert</code> следующей:

assert always {req;ack;!cancel} |=> (ena || enb);


завершается спецификация, указывая, что это свойство ожидается в проекте и что потребности это ожидания нужно верифицировать.

====1.3.2 Функциональная верификация====


PSL также может использоваться, как вход для программ верификации, как для верификации моделированием, так и для формальной верификации, используется проверка модели или теоретическое доказательство. Каждый вариант обсуждается в следующих пунктах.

=====1.3.2.1 Моделирование=====


Спецификация PSL также может использоваться для автоматического генерирования проверок поведения моделирования. Это может быть реализовано, например, прямой интеграцией проверок в программе моделирования; интерпретацией свойств PSL в тестовую автоматизированную программу, которая сопровождает симулятор; генерированием HDL контроллеров, которые моделируются рядом с проектом; или анализом путей пройденных во время моделирования.


Например, следующие PSL свойства:

Свойство 1: always (req -> next !req)


означает, что сигнал <code>req</code> пульсирующий сигнал, т.е. если он принимает высокие значения в одном цикле,то он примет низкие значения в следующем цикле. Такое свойство может быть легко проверенно, используя проверки моделирования, написанные на каком-нибудь HDL, который имеет функциональность конечного автомат (FSM), показанный на Рисунке 1.

{| align=center
! [[Файл:Std psl fig01.png|300px]]
|-
!Рисунок 1—Простой FSM, который проверяет свойство 1
|}


Для более сложных свойств, чем то что представлено на рисунке 1, писать вручную соответствующие проверки - это кропотливый труд, подверженный ошибкам, и содержание набора таких проверок для постоянно изменяющегося проекта - это очень трудоемкое задание. Вместо этого, спецификация PSL может использоваться, как вход для программы, которая автоматически генерирует проверки, поддающиеся моделированию.


Хотя в принципе, все свойства PSL могут быть проверены при окончание моделирования, исполнение проверок, часто, значительно проще для подмножеств, называемых ''простые подмножества'' PSL. Неформально, в этих подмножествах, состав временных свойств ограничен для обеспечения того, что бы время ''двигалось вперед'' слева направо через свойство, как это делается на временной диаграмме. (Смотрите 4.4.4 для формального понимания простых подмножеств.)

Например, свойство

Свойство 2: always (a -> next[3] b)


которое означает, что если <code>a</code> принимает значения, то <code>b</code> примет значение через три цикла, принадлежит простому подмножеству, потому что <code>a</code> появляется слева от <code>b</code> в свойстве и, также, появляется слева от <code>b</code> на временной диаграмме любой поведенческой модели, что не нарушает свойство. Рисунок 2 показывает пример такой временной диаграммы.

{| align=center
! [[Файл:Std psl fig02.png|400px]]
|-
! Рисунок 2—Вариант удовлетворяющий свойство 2
|}


Пример свойства не принадлежащего этому подмножеству

Свойство 3: always ((a && next[3] b) -> c)

которое значит, что если <code>a</code> принимает значение и <code>b</code> принимает значение через три цикла, то <code>c</code> принимает значение в том же цикле, что и <code>a</code>. Это свойство не принадлежит простому подмножеству, потому что хотя <code>c</code> появляется справа от <code>a</code> и <code>b</code> в свойстве, он появляется слева от <code>b</code> и <code>a</code> на временной диаграмме, и это не нарушает свойство. Рисунок 3 показывает пример такой временной диаграммы.

{| align=center
! [[Файл:Std psl fig03.png|400px]]
|-
! Рисунок 3 3—Вариант, удовлетворяющий свойство 3
|}

=====1.3.2.2 Формальная верификация=====


PSL это расширение стандарта временной логики Линейной временной логике (LTL) и Вычисляемого логического дерева (CTL). Спецификация в PSL фундаментального языка (соответственно, PSL дополнительного ветвления) может быть ''скомпилирована'' в виде чистого LTL (соответственно, CTL), возможно с некоторым вспомогательным HDL- кодом, известным, как ''спутник''.

== 3. Определения, сокращения и аббревиатуры ==

<--
For the purposes of this document, the following terms and definitions apply. The IEEE Standards Diction-
ary: Glossary of Terms & Definitions should be referenced for terms not defined in this clause.6
-->
Цели этого документа - текущие термины и определения. IEEE словарь стандартов: Cловарь терминов и определений должен ссылаться на условия неопределенные в этом пункте.6

===3.1 Определения (Definitions) ===


Этот подпункт определяет термины, используемые в этом стандарте.


'''утверждение (assertion)''': значит, что данное свойство требуется выполнить и указать программе функциональной верификации, чтобы убедиться, что оно выполняется.


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


'''асинхронное свойство (asynchronous property)''': Свойство, временной контекст которого эквивалентен значению Правда.


'''поведение (behavior)''': Путь.


'''Булевы (выражения) (Boolean (expression))''': Выражения, которые принимают на выходе логические значения.


'''проверка (checker)''': Вспомогательный процесс (обычно применяемый, как конечный автомат), который проверяет моделирование проекта и сообщения об ошибках, когда утвержденное свойство не выполняется. Проверка может быть представлена в том же HDL-коде, что и проект или в какой-либо другой форме, которая может ссылаться на моделирование проекта.


'''завершение (completes)''': Термин используемый для определения последнего цикла пути, который удовлетворяет последовательности выражений или свойств.


'''вычисленный путь (computation path)''': Правопреемство состояний проекта, такое что проект может актуально переходить из каждого состояния на пути к его преемнику.


'''ограничение (constraint)''': Состояние ( обычно для входного сигнала), которое ограничивает набор поведений, которые следует рассматривать. Ограничение может представлять реальные требования (т.е. временные требования) в среде, в которой используется проект, или может представлять искусственные ограничения (т.е. настройки режима) наложенные в порядке разделения задания функциональной верификации.


'''счетчик (count)''': Число или диапазон.


'''зона покрытия (coverage)''': Мера возникновения определенного поведения в течение (обычно динамическое) функциональной верификации и поэтому расчет сложности (динамического) процесса функциональной верификации.


'''цикл (cycle)''': Оценочный цикл.


'''описания (describes)''': Термин, используемый для определения набора поведений, для которого Булевы выражения, последовательные выражения или выполняемые свойства.


'''проект (design)''': Модель кусочка аппаратуры, описанная на некотором языке описания аппаратуры (HDL). Проект типично включает в себя набор входов, выходов, элементов состояния и комбинационных функций, которые рассчитывают следующие состояние и выходы из текущего состояния и входов.


'''поведение проекта (design behavior)''': Рассчитанный путь для данного проекта.


'''динамическая верификация (dynamic verification)''': Процесс верификации, такой как моделирование, в котором свойство проверяется
отдельно, конечные поведения проекта, которые обычно получаются динамическим проведением проекта через конечное число оценочных циклов. В общем, динамическая верификация не дает вывода о выполняющемся свойстве поведения, через которое свойство еще не было проверено.


'''оценка (evaluation)''': Процесс проведения проекта итеративным принятием значений на его входы, рассчитывая его следующие состояния и выходные значения, время опережения, и назначение переменных состояний и выходов своих следующих значений.


'''оценочный цикл (evaluation cycle)''': Одна итерация оценочного процесса. На одном оценочном цикле, состояние проекта пересчитывается ( и может быть изменено).


'''расширения (данного пути) (extension (of a given path))''': Путь, который начинается с точного правопреемства состояний в данном пути.



* '''False''' — Интерпритация определённых значений определённых типов в HDL языках. В SystemVerilog и Verilog стилях, битовые значения 1’b0, 1 ’bx, и 1’bz интерпретируются как логическое значение False. В VHDL стиле, значения STD.Standard.Boolean’(False) и STD.Standard.Bit’(‘0’), также как значения IEEE.std_logic_1164.std_logic’( ‘0’), IEEE.std_logic_1164.std_logic’(‘L’), IEEE.std_logic_1164.std_logic’(‘X’), и IEEE.std_logic_1164.std_logic’(‘Z’) все интерпретируются как логическое значение False. В SystemC стиле, значение 'false' типа bool и любой литерал типа integer с числовым значением 0 интерпретируется как значение False. В GDL стиле, значение типа Boolean 'false' и значение типа bit 0B оба интерпретируются как логическое значение False.


'''конечный диапазон (finite range)''': Диапазон с большой конечной границей.


'''формальная верификация (formal verification)''': Процесс функциональной верификации, в котором анализ дизайна и выхода свойства логически разъясняет о выполняемое свойство для все поведений проекта. Если свойство продекларировано значение "правда" программой формальной верификации, моделирование не может сделать его значение "ложным". Если свойство не выполняется для каждого поведения, то процесс формальной верификации должен предоставить специфический контрпример свойства, если это возможно.


'''функциональная верификация (functional verification)''': Процесс подтверждения того, что для данного проекта и данного набора ограничений, свойство, которое требует выполнение в этом проекте, действительно выполняется в соответствие с данными ограничениями.


'''исполнение (holds)''': Термин используемый для разъяснения значения Булевых выражений, последовательных выражений или свойств.


'''обязательное исполнение(holds tightly)''': Термин используемый для разъяснения значения последовательных выражений. Последовательные выражения оцениваются на конечной стадии (поведение).


'''живучие свойства (liveness property)''': Свойства, которые указывают на случайность, которая не ограничена во времени. Грубо говоря, живучие свойства утверждает, что что-то “хорошее” в конечном счете произошло. Более формально, живучие свойство - это свойство, для которого любая конечная стадия может быть продолжена до стадии удовлетворения свойства. Например, свойство “когда-либо сигнал req принимает значение, сигнал ack принимает значение через некоторое время” это живучие свойство.


'''логический тип (logic type)''': Тип данных HDL, который включает значения, которые интерпретируются, как логические значения. Логический тип, также, включает значения, которые не интерпретируются, как логические значения. Как логический тип, обычно, представляет многозначную логику.


'''логическое значение (logical value)''': Значение из набора {True, False}.


'''проверка на модели (model checking)''': Тип формальной верификации.


'''число (number)''': Неотрицательное целочисленное значение, и статично подсчитанное выражение полученное, как выражение.


''' (occurs)''': Термин используемый для индикации того, что Булево выражение выполняется в данном цикле.


'''occurrence (of a Boolean expression)''': Цикл, в котором выполняется Булево выражение.


'''стадия (путь) (path)''': Правопреемственность состояний проекта, ???


'''положительный счетчик (positive count)''': Положительное число или положительный диапазон.


'''положительное число (positive number)''': Число, которое больше нуля (0).


'''положительный диапазон (positive range)''': Диапазон с нижней границей большей нуля (0).


'''префикс (данной стадии) (prefix (of a given path))''': Стадия в которую расширяется данная стадия.


'''свойство (property)''': Набор логических и временных взаимоотношений между и среди подчиненных Булевых выражений, последовательных выражений и других свойств, которые в совокупности представляют набор поведений.


'''диапазон (range)''': Набор последовательных чисел, от нижней до верней границы, включительно, такой, что нижняя граница меньше или равна верхней. В частности, это предполагает случай, в котором нижняя граница эквивалентна верхней. Также, пара статически подсчитанных целочисленных выражений представляются, как наборы последовательных чисел, где левая выражения является нижней границей, а правое выражение верхней границей набора. Диапазон может описывать набор значении и переменное число циклов или повторяющихся событий.


'''ограничение (restriction)''': Утверждение, что проект ограничивается данным последовательным выражением, и директива программе функциональной верификации рассматривать только стадию, на которой выполняется данное последовательное выражение.


'''защищенное свойство (safety property)''': Свойство, которое указывает инвариантность по состояниям в проекте. Инвариантность - это необязательно ограниченность в один цикл, но ограниченность по времени. Грубо говоря, защищенное свойство показывает, что ничего “плохого” не произошло. Более формально, защищенное свойство - это свойство, для которого любая стадия имеющая навязывающееся свойство получает конечный префикс, такой ,что каждое расширение префикса навязывается свойству. Например, свойство “когда-либо сигнал req принимает значение, сигнал ack принимает значение через три цикла”, является защищенным свойством.


'''последовательность (sequence)''': Последовательное выражение, которое может напрямую использоваться в течение свойства или директивы.


'''последовательное выражение (sequential expression)''': Законченный набор терминов, который представляет набор поведений.

'''последовательные регулярно расширяемые выражения (sequential extended regular expression)''': Форма последовательных выражений и компонентов последовательностей.


'''начало (starts)''': Термин используемый для идентификации первого цикла пути, который удовлетворяет последовательное выражение.


'''строго перед (strictly before)''': Перед, и не в этом же цикле.


'''сильный оператор (strong operator)''': Временной оператор, неотрицательное использование которого, обычно, создает живучие свойства.


'''временное выражение (temporal expression)''': Выражение, которое включает один или более временных операторов.


'''временной оператор (temporal operator)''' Оператор, который представляет временные ( т.е. ориентированные во времени) взаимоотношения между операндами.


'''условие завершения (terminating condition)''': Булево выражение, появление которого, приводит к завершению свойства.


'''свойство завершения (terminating property)''': Свойство, выполнение которого, приводит к завершению другого свойства.


* '''True''': Интерпритация определённых значений определённых типов в HDL языках.
** В SystemVerilog и Verilog стилях, битовые значение 1'b1 интерпретируется как логическое значение True.
** В VHDL стиле, значения STD.Standard.Boolean'(True), STD.Standard.Bit'('1'), IEEE.std_logic_1164.std_logic'('1'), и IEEE.std_logic_1164.std_logic'('H') интерпретируются как логическое значение True.
** В SystemC стиле, значение 'true' типа bool и любой литерал типа integer с ненулевым числовым значением интерпретируется как логическое значение True.
** В GDL стиле, значение типа Boolean 'true' и значение типа bit 1B интерпретируются как логическое значение True.


'''неизвестное значение (unknown value)''': Значение (многозначного) логического типа, отличное от 0 и 1.


'''слабый оператор (weak operator)''': Временной оператор, неотрицательное использование которого не создает живучего свойства.

== 3.2 Сокращения и аббревиатуры ==

* ABV — утверждения, базирующиеся на верификации
* BNF — расширенная форма Бакуса-Наура
* cpp — C препроцессор
* CTL — вычисляемое логическое дерево
* EDA — авторматизация проектирования
* FL — фундаметальный язык
* FSM — конечный автомат
* GDL — общий язык описания
* HDL — язык описания аппаратуры
* iff — если, и только если
* LTL — линейная временная логика
* PSL — язык спецификации свойств
* OBE — дополнительное расширение ветвления
* RTL — уровень регистровых передач
* SERE — последовательное расширенное регулярное выражение
* VHDL — VHSIC язык описания аппаратуры
* VHSIC — высоко скоростная интегральная схема

==== 4.1.1 Слои (Layers) ====
PSL состоит из четырёх слоёв: булевый (Boolean), временной (temporal), верификационный (verification), и модельный (modeling).

===== 4.1.1.1 Булевый слой (Boolean layer) =====


Булевый слой используется для создания выражений, которые, в свою очередь, используются другими слоями. Хотя этот слой содержит выражения над многими типами, он называется как булевый слой, потому что он является поставщиком булевых (логических) выражений для основы (сердца) языка — временнОго слоя. Выражения булевого слоя выполняются в едином (одиночном) цикле выполнения.

===== 4.1.1.2 ВременнОй слой (Temporal layer) =====

Временной слой является основой языка; он используется для описания свойств проекта. Он называется временным, потому что, в дополнение к простым свойствам, таким как "сигналы a и b являются взаимноисключающими", он может также описывать свойства включающие сложные временные отношения между сигналами, например "если сигнал c устанавливается, тогда сигнал d должен установиться прежде, чем сигнал e установится, но не позже более восьми периодов синхросигнала". ВременнЫе выражения выполняются в течении серии циклов выполнения.

===== 4.1.1.3 Верификационный слой (Verification layer) =====


Верификационный слой используется для того чтобы сказать верификационному инструменту (САПР), что делать с свойствами описанными во временном слое. Например, верификационный слой включает директивы, которые говорят инструменту (САПР) чтобы верифицировал (verify) то, что свойство удерживает (hold) или проверил (check) то, что заданная последовательность покрыта некоторым тестирующим случаем.

===== 4.1.1.4 Моделирующий слой (Modeling layer) =====


Моделирующий слой (Modeling layer) используется для моделирования поведения входов проекта (для инструментов (САПР), таких как инструменты (САПР) для формальной верификации, которые не используют тестов) и для моделирования дополнительной аппаратуры, которая не является частью проекта, но необходима для верификации.

==== 4.1.2 Стили/Варианты (Flavors) ====


PSL идёт с пятью вариантами/стилями (flavors): один для каждого HDL языка SystemVerilog, Verilog, VHDL, SystemC, и GDL. Синтаксис каждого варианта (стиля) соответствует синтаксису соответствующего HDL языка в ряде конкретных областей — данный стиль PSL совместим с соответствующим синтаксисом HDL-языка в этой области.

{| class=standard align=center
|+ Влияние стиля на слои PSL
!rowspan=2| Слой ||colspan=5 | HDL
|-
! SystemVerilog || Verolog || VHDL || SystemC || GDL
|-
| Булевый || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}}
|-
| Модельный || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}}
|-
| Временной || i:j || i:j || i to j || i:j || i..j
|-

|}

=== 4.2 Лексическая структура ===


Этот подпункт определяет идентификаторы, ключевые слова, операторы, макросы и комментарии, используемые в PSL.

==== 4.2.1 Идентификаторы (Identifiers) ====


Идентификаторы в PSL состоят из символа латинского алфавита, за которым следует ноль или более символов латинского алфавита; каждый последующий символ алфавита может по желанию предшествовать одному символу подчеркивания. Например:

mutex
Read_Transaction
L_123


PSL идентификаторы являются чувстительными к регистру в SystemVerilog, Verilog, и SystemC вариантах/стилях и не чувствительными к регистру в VHDL и GDL вариантах.

==== 4.2.2 Ключевые слова ====

{|
|<poem> A
E
next!
rose
AF
EF
next_a
AG
EG
next_a!
</poem>
| <poem> sequence
AX
abort
EX
next_e
stable
always
ended
next_e!
string
</poem>
| <poem>anda
eventually!
next_event
strong
assert
next_event!
sync_abort
assume
F
next_event_a
</poem>
| <poem>async_abort
fairness
next_event_a!
toe
before
fell
next_event_e
before!
for
next_event_e!
</poem>
| <poem> U
before!_
forall
nondet
union
before_
nondet_vector
until
bitvector
bit
</poem>
| <poem> G
notc
until!
boolean
numeric
until!_
hdltype
until_
clock
onehot
</poem>
| <poem>const
in
onehot0
vmode
countones
inf
ord
vpkg
cover
inherit
</poem>
| <poem> vprop
isb
property
vunit
default
isunknown
prev
W
report
mutable
</poem>
| <poem> within
restrict
restrict!
never
X
next
X!</poem>
|}

*a and is a keyword only in the VHDL flavor; see the flavor macro AND_OP (4.3.2.6).
*b is is a keyword only in the VHDL flavor; see the flavor macro DEF_SYM (4.3.2.9).
*c not is a keyword only in the VHDL flavor; see the flavor macro NOT_OP (4.3.2.6).
*d or is a keyword only in the VHDL flavor; see the flavor macro OR_OP (4.3.2.6).
*e to is a keyword only in the VHDL flavor; see the flavor macro RANGE_SYM (4.3.2.7).

==== 4.2.3 Операторы ====

===== 4.2.3.1 Операторы HDL языка =====

Для заданного стиля PSL, операторы основного HDL языка имеют наивысший преоритет. В частности это включает логические, арифметические операторы и операторы отношения языка HDL. Логические операции HDL языка для отрицания, конъюнкции и дизъюнкции булевых (логических) значений могут использоваться в PSL для отрицания, конъюнкции и дизъюнкции свойств. В таких приложениях, эти операторы имеют их обычный приоритет и ассоциативность, как если бы PSL свойства,....

===== 4.2.3.2 Операторы фундаментального языка =====


Различные операторы доступны в PSL. Каждый оператор имеет приоритет по отношению к другим операторам. В общем операторы с большим приоритетом получают доступ к свои операндам, раньше, чем операнды с меньшим приоритетом. Если два оператора имеют одинаковый приоритет и появляются в последовательности, то они получают доступ к свои операндам в соответствие с ассоциативностью операторов. Лева-ассоциативные оператор получает доступ к своим операндам слева на право в порядке появления в тексте, право-ассоциативные операторы получают доступ к своим операндам справа на лева в порядке появления в тексте.

{| class=standard align=center
|+ Таблица приоритетов и ассоциативности двух операторов фундаментального языка
|-
! Оператор класс || Ассоциативность ||colspan=2| Операторы
|-
| ''(наивысший приоритет)''

HDL операторы
| || ||
|-
| Оператор объединения || left || union ||
|-
| Оператор времени || left || @ ||
|-
| SERE повторяющийся оператор || left || [* ] [+] [= ] [-> ] ||
|-
| Последовательный предельный оператор || left || within ||
|-
| Последовательный оператор И || left || & || &&
|-
| Последовательный оператор ИЛИ || left || <nowiki>|</nowiki> ||
|-
| Последовательный оператор слияния || left || : ||
|-
| Последовательный оператор конкатенации || left || ; ||
|-
| Операторы прерывания фундаментального языка || left || abort sync_abort || async_abort
|-
| Операторы фундаментального языка, указывающие местонахождение || right || next* || eventually!
|-
| || || X X! || F
|-
| Операторы фундаментального языка, показывающие границы || right || U || W
|-
| || || until* || before*
|-
| Последовательный оператор импликации || right || <nowiki>|-></nowiki> || <nowiki>|=></nowiki>
|-
| Булевы операторы импликации || right || -> || <->
|-
| Неизменные операторы фундаментального языка ''(низший приоритет)'' || right || always G || never
|-
|}


Примечание - Обозначение next* представляет семейство next-операторов, которое включает операторы: next, next!,
next_a, next_a!, next_e, next_e!, next_event, next_event!, next_event_a! и
next_event_e!. Обозначение until* представляет семейство until-операторов, которое включает операторы: until,
until!, until_ и until!_. Обозначение before* представляет семейство before-операторов, которое включает операторы: before, before!, before_, and before!_.7

====== 4.2.3.2.1 Объединительные операторы ======


Для любого стиля PSL, FL оператор со следующим наибольшим приоритетом после HDL операторов является тот, который используется для обозначения недетерминированного выражения:

union union оператор

Оператор union является лева-ассоциативным.

====== 4.2.3.2.2 Операторы времени ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это оператор времени, который используется для связи временного выражения со свойством или последовательностью:

@ clock event

Временной оператор лева-ассоциативный.

====== 4.2.3.2.3 SERE операторы повторов (repetition operators) ======


Для любого стиля PSL, FL операторы со следующим наибольшим приоритетом являются операторами повторов, которые используются для создания последовательных расширенных регулярных выражений (Sequential Extended Regular Expressions — SEREs). Эти операторы следующие:

[* ] последовательное повторение (consecutive repetition)
[+] последовательное повторение (consecutive repetition)
[= ] не последовательное повторение (non-consecutive repetition)
[-> ] goto repetition

SERE операторы повторения являются лева-ассоциативными.

====== 4.2.3.2.4 Последовательный предельный оператор ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это последовательный предельный оператор, который используется для описания поведения, в котором одна последовательность появляется в ходе другой, или в пределах интервала ограниченного временем.

within последовательность within оператор

Последовательный предельный оператор лева-ассоциативный.

====== 4.2.3.2.5 Последовательные операторы конъюнкции ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетов - это последовательные операторы конъюнкции, которые описывают поведение состоящие из параллельных стадий. Это следующие операторы:

& последовательная конъюнкция без сопоставления длинны
&& последовательная конъюнкция с сопоставлением длины

Последовательные операторы конъюнкции лева-ассоциативные.

====== 4.2.3.2.6 Последовательный оператор дизъюнкции ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это последовательный оператор дизъюнкции, который используются для описания поведения состоящего из альтернативных стадий:

| последовательная дизъюнкция

Последовательный оператор дизъюнкции лева-ассоциативный.

====== 4.2.3.2.7 Последовательный оператор слияния ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это последовательный оператор слияния, который используется для описания поведения, в котором более поздняя последовательность начинает выполняться в том же цикле, в котором заканчивает выполняться более ранняя.

: последовательное слияние

Последовательный оператор слияния лева-ассоциативный.

====== 4.2.3.2.8 Последовательный оператор конкатенации ======


Для любого варианта PSL, оператор фундаментального со следующим наивысшим приоритетом - это последовательный оператор конкатенации, который используется, чтобы описывать поведение, в котором одна последовательность следует за другой:

; последовательная конкатенация

Последовательный оператор конкатенации лева-ассоциативный.

====== 4.2.3.2.9 Операторы прерывания фундаментального языка ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом - это операторы прерывания фундаментального языка, которые используются для описания поведения, в котором условие вызывает текущие и будущие процессы, которые будут прерваны:

sync_abort немедленное завершение текущего и следующего процесса, синхронизовано по времени
async_abort немедленное прерывание текущего и следующего процесса, независт от времени
abort эквивалентно to async_abort

Операторы прерывания фундаментального языка лева-ассоциативные.

====== 4.2.3.2.10 Операторы местонахождения фундаментального языка ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, в котором операнды используются в будущем. Это следующие операторы:
eventually! правый операнд выполняется через некоторое время в неопределенном будущем
next* правый операнд выполняется в некотором специфицированном будущем времени или диапазоне будущего времени
операторы местонахождения фундаментального языка право-ассоциативные.

====== 4.2.3.2.11 Граничные операторы ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые описывают поведение, в котором одно свойство выполняется в некотором цикле или во всех циклах перед выполнением следующего слова. Это следующие операторы:

until* левый операнд выполняется в любое время до выполнения правого операнда
before* левый операнд выполняется через некоторое время после выполнения правого

Граничные операторы фундаментального языка право-ассоциативные.

====== 4.2.3.2.12 Суффиксные операторы импликации ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, состоящего из свойства, которое выполняется в конце данной последовательности. Это следующие операторы:

|-> суффиксная импликация с перекрытием
|=> суффиксная импликация без перекрытия


Операторы суффиксной импликации право-ассоциативные.


Примечание - Свойство фундаментального языка {r} (f) - это альтернативная форма (и имеет такую же семантику) для свойства фундаментального языка {r} |-> f.

====== 4.2.3.2.13 Операторы логической импликации ======


Для любого варианта PSL, операторый фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, состоящего из Булевых выражений, последовательности или свойства, которое выполняется, если выполняется другое Булево выражение, последовательность или свойство.

-> логическая IF импикация
<-> логическая IFF импликация


Операторы логической импликации право-ассоциативные.

====== 4.2.3.2.14 Операторы неизменности фундаментального языка ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, в котором выполняется или не выполняется глобально.

always правый операнд выполняется глобально
never правый операнд не выполняется глобально

Операторы неизменности фундаментального языка право-ассоциативные.

===== 4.2.3.3 Операторы дополнительного расширенного ветвления (OBE) =====

{| class=standard align=center
|+ Таблица 3—OBE оператор, приоритет и ассоциативность
|-
! Класс оператора || Ассоциативность ||colspan=2| Операторы
|-
| (наивысший приоритет) HDL операторы || || ||
|-
| OBE операторы местонахождения ||left || AX AG AF A [ U ] || EX EG EF E [ U ]
|-
| Операторы Булевой импликации (низший приоритет) || right || -> || <->
|}

====== 4.2.3.3.1 OBE операторы местонахождения ======


Для любого варианта PSL, OBE операторы являются следующими операторами с наивысшим приоритетом, после HDL операторов, они используются для указания, когда подчиненное свойство должно выполняться, если выполняется старшее свойство. Это следующие операторы:

AX на всех путях, на следующем состоянии каждого пути
AG на всех путях, на каждом состоянии любого пути
AF на всех путях, на некотором будущем состоянии каждого пути
EX на некотором пути, на следующем состоянии пути
EG на некотором пути, на всех состояния пути
EF на некотором пути , на некотором будущем состоянии пути
A[U] на всех путях, в каждом состоянии до определенного состояния пути
E[U] на некотором пути, в каждом состоянии до определенного состояния пути

OBE операторы местонахождения лева-ассоциативные.

====== 4.2.3.3.2 OBE операторы импликации ======


Для любого варианта PSL, OBE операторы со следующим наивысшим приоритетом, это те которые используются для описания поведения, состоящего из Булевых выражений или свойства, которое выполняется, если Булево выражение или другое свойство выполняется. Это следующие операторы:

-> логическая IF импликация
<-> логическая IFF импликация

Операторы логической IF и логической IFF импликации право-ассоциативные.

==== 4.2.4 Макросы ====


PSL предоставляет возможность обработки макросов, которые помогают в определении свойств. SystemC, VHDL и
GDL варианты поддерживают cpp препроцессорные директивы (т.е. #define, #ifdef, #else, #include и #undef).
SystemVerilog и Verilog поддерживают директивы Verilog компилятора (т.е. `define, `ifdef, `else, `include и `undef). Все варианты, также поддерживают PSL макросы %for и %if, которые могут использоваться для условно или итеративно генерированного PSL утверждения. Компилированные директивы Verilog или cpp должны быть интерпретированы первыми, макросы PSL %if и %for должны быть интепретированы вторыми

===== 4.2.4.1 Конструкция %for =====

===== 4.2.4.2 Конструкция %if =====

==== 4.2.5 Комментарии ====

PSL обеспечивает возможность вставки комментариев в PSL спецификацию. Для каждого стиля, возможность комментариев совместима с тем, что обеспечивается соответсвующией средой PSL.

Для SystemC, SystemVerilog, и Verilog стиля, оба варианта блочных комментариев (/* .... */) и (// .... ''<eol>'') поддерживается. (''<eol>'' — конец строки)

Для стиля VHDL, поддерживается комментарии (-- .... ''<eol>'').

Для стиля GDL, оба блочных стилей комментариев поддерживаются: (/* .... */) и (-- .... ''<eol>'').

=== 4.3 Syntax ===

==== 4.3.1 Conventions ====

{| class=standard align=center
! Flavor Macro || SystemVerilog || Verilog || VHDL || SystemC || GDL
|-
| AND_OP || && || && || and || && || &
|-
| OR_OP || <nowiki>||</nowiki> || <nowiki>||</nowiki> || or || <nowiki>||</nowiki> || <nowiki>|</nowiki>
|-
| NOT_OP || ! || ! || not || ! || !
|-
| RANGE_SYM || : || : || to || :|| ..
|-
| MIN_VAL || 0 || 0 || 0 || 0 || null
|-
| MAX_VAL || $ || inf || inf || inf || null
|-
| LEFT_SYM || [ || [ || ( || [ || (
|-
| RIGHT_SYM || ] || ] || ) || ] || )
|-
| DEF_SYM || = || = || is || = || :=
|}

=== 4.4 Semantics ===

The following subclauses introduce various general concepts related to temporal property specification and
explain how they apply to PSL.

==== 4.4.1 Clocked vs. unclocked evaluation ====

== NEW ==

PSL/IEEE Standard 1850-2010 for Property Specification Language (PSL)

2013-10-17T10:10:06Z

Valentin: /* 4.2.4 Macros */

{{PSL TOC}}

== 1. Обзор ==

=== 1.1 Возможность ===


Этот стандарт определяет язык свойств спецификации (PSL), который формально описывает поведение электронных систем. Этот стандарт специфицирует синтаксис и семантику для PSL, а также разъясняет, как PSL взаимодействует с различными стандартами языков описания электронных систем.

===1.2 Назначение===


Назначение этого стандарта заключается в том, чтобы предоставить четкий язык для формальной спецификации поведения электронных систем, который будет совместим с множеством языков описания электронных систем, включая IEEE Std 1076TM (VHDL®),1 IEEE Std 1364TM (Verilog®), IEEE Std 1800TM (SystemVerilog®), и IEEE Std 1666TM (SystemC®), способствуя общему потоку верификации и спецификации для проектов описанных на разных и смешанных языках.


Этот стандарт создает обновленный IEEE стандарт базирующийся на IEEE Std 1850-2005. Обновленный стандарт усовершенствует IEEE стандарт, адресные опечатки, незначительные технические вопросы и предполагаемого расширения непосредственно связанных свойств, для дальнейшего использования и облегчения моделирования.

==== 1.2.1 Происхождение ====


Сложность проектов с очень большой степенью интеграции (VLSI) выросла до такого уровня, что традиционные подходы начали достигать своего предела, а издержки верификации достигли 60%-70% от ресурсов разработки. Потребность в более продвинутой методологии верификации, с улучшенной наблюдаемостью поведения проекта и улучшенной контролируемостью (способностью контроля) процесса верификации, стала критической. За последние 10 лет, методология, базирующаяся на понятии "свойств", была определена, как мощная парадигма верификации, которая способна обеспечить повышение производительности (эффективности), повышенное качество проекта, и значительно ускорить время выхода на рынок (time to market), увеличить число производителей (higher value to engineers?) и пользователей электронных продуктов. Свойства, используемые в данном контексте, являются краткие, декларативные/описательные (declarative), выразительные/ясные/точные (expressive) и однозначные спецификации желаемого поведения системы, которые используются для проведения процесса верификации. IEEE 1850 PSL стандартный язык для описания (спецификации) поведения электронной системы, используя свойства. PSL облегчает верификацию основанную на свойствах (property-based verification) с использованием как моделирования так и формальной верификации, что позволяет повысить эффективность функциональной верификации.

====1.2.2 Мотивация====


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


IEEE PSL был создан, чтобы устранить эти недостатки. Это дает архитектуре проекта стандарт, означающий спецификацию свойств проекта
используемых краткий синтаксис с простой формальной семантикой. Аналогичным образом, позволяется RTL-исполнителю определить цели проекта в проверяемых формах, пока разрешается верификации подтвердить, что выполнение окончено и его спецификация определена через ''динамическую'' ( моделирование) и статическую (формальную) верификацию. Более того, он предоставляет средства для определения качества процесса верификации, через создание полной функциональной модели построения на формально специфицированных свойствах. В дополнение, он предоставляет стандартные средства для аппаратуры проекта и инженера верификации при создании строгой и исполняемой машиной спецификации проекта.

====1.2.3 Цели====


PSL был специально создан для исполнения следующих общих аппаратных функциональных требований:
* Легко обучать, чиать и писать
* Краткий синтаксис
* Строго определенная формальная семантика
* Выразительная мощность, позволяющая специфицировать большие классы реальных проектов
* Известные эффективные алгоритмы моделирования, такие же как формальная верификация

===1.3 Использование===


PSL язык для формальной спецификации аппаратуры. Он используется для описания свойств, которые требуют поддержки в проекте под верификацию. PSL предоставляет средства для написания спецификаций, которые легко читаются и математически точны. Это предназначение используется для функциональной спецификации, с одной стороны, и как вход в программы функциональной верификации, с другой. Таким образом, спецификация PSL - это исполняемая спецификация для аппаратного проекта.

====1.3.1 Функциональная спецификация====


PSL может использоваться для выделения требований относительно общего поведения проекта, также как допущения о среде, в которой ожидается обработка проекта. PSL также может выделять внутреннее поведение требований и допущений, которые возникают в процессе обработки проекта. Доступными являются более эффективная функциональная верификация и продолжения обработки самого проекта.


Один из важных аспектов использования PSL - это использование для документации, как вместо, так и совместно с английской спецификацией. Спецификация PSL может описать простые инварианты (например: сигналы <code>read_enable</code> и
<code>write_enable</code> никогда не используются в одно время), также как многотактовое поведение (например: правильное поведение интерфейса с поддержкой протокола шины или правильное поведение конвейерных операций).


Спецификация PSL состоит из ''утверждений'' относительно ''свойства'' проекта под набором ''допущений''. ''Свойство'' строится из трех видов элементов: ''Булевы выражения'', которые описывают поведение в одно цикле; ''последовательные выражения'', которые могут описывать многотактовое поведение; и ''временные операторы'', которые описывают временные взаимоотношения между Булевыми выражениями и последовательностями. Например, Булево выражение в Verilog:

ena || enb


Это выражение описывает цикл, в котором, по крайней мере, один из сигналов <code>ena</code> и <code>enb</code> активен. Последовательное выражение PSL

{req; ack; !cancel}


описывает последовательность циклов, такую, что если <code>req</code> активен в первом цикле, <code>ack</code> активен во втором цикле, а <code>cancel</code> неактивен в третьем цикле. Следующее свойство получается, применяя временные операторы <code>always</code> и <code>|=></code> к этим выражениям,

always {req;ack;!cancel} |=> (ena || enb)


это значит, что всегда (в каждом цикле), если встречается последовательность <code>{req;ack;!cancel}</code>, то либо <code>ena</code>, либо <code>enb</code> активен в течение цикла после окончания последовательности. Добавляя директиву <code>assert</code> следующей:

assert always {req;ack;!cancel} |=> (ena || enb);


завершается спецификация, указывая, что это свойство ожидается в проекте и что потребности это ожидания нужно верифицировать.

====1.3.2 Функциональная верификация====


PSL также может использоваться, как вход для программ верификации, как для верификации моделированием, так и для формальной верификации, используется проверка модели или теоретическое доказательство. Каждый вариант обсуждается в следующих пунктах.

=====1.3.2.1 Моделирование=====


Спецификация PSL также может использоваться для автоматического генерирования проверок поведения моделирования. Это может быть реализовано, например, прямой интеграцией проверок в программе моделирования; интерпретацией свойств PSL в тестовую автоматизированную программу, которая сопровождает симулятор; генерированием HDL контроллеров, которые моделируются рядом с проектом; или анализом путей пройденных во время моделирования.


Например, следующие PSL свойства:

Свойство 1: always (req -> next !req)


означает, что сигнал <code>req</code> пульсирующий сигнал, т.е. если он принимает высокие значения в одном цикле,то он примет низкие значения в следующем цикле. Такое свойство может быть легко проверенно, используя проверки моделирования, написанные на каком-нибудь HDL, который имеет функциональность конечного автомат (FSM), показанный на Рисунке 1.

{| align=center
! [[Файл:Std psl fig01.png|300px]]
|-
!Рисунок 1—Простой FSM, который проверяет свойство 1
|}


Для более сложных свойств, чем то что представлено на рисунке 1, писать вручную соответствующие проверки - это кропотливый труд, подверженный ошибкам, и содержание набора таких проверок для постоянно изменяющегося проекта - это очень трудоемкое задание. Вместо этого, спецификация PSL может использоваться, как вход для программы, которая автоматически генерирует проверки, поддающиеся моделированию.


Хотя в принципе, все свойства PSL могут быть проверены при окончание моделирования, исполнение проверок, часто, значительно проще для подмножеств, называемых ''простые подмножества'' PSL. Неформально, в этих подмножествах, состав временных свойств ограничен для обеспечения того, что бы время ''двигалось вперед'' слева направо через свойство, как это делается на временной диаграмме. (Смотрите 4.4.4 для формального понимания простых подмножеств.)

Например, свойство

Свойство 2: always (a -> next[3] b)


которое означает, что если <code>a</code> принимает значения, то <code>b</code> примет значение через три цикла, принадлежит простому подмножеству, потому что <code>a</code> появляется слева от <code>b</code> в свойстве и, также, появляется слева от <code>b</code> на временной диаграмме любой поведенческой модели, что не нарушает свойство. Рисунок 2 показывает пример такой временной диаграммы.

{| align=center
! [[Файл:Std psl fig02.png|400px]]
|-
! Рисунок 2—Вариант удовлетворяющий свойство 2
|}


Пример свойства не принадлежащего этому подмножеству

Свойство 3: always ((a && next[3] b) -> c)

которое значит, что если <code>a</code> принимает значение и <code>b</code> принимает значение через три цикла, то <code>c</code> принимает значение в том же цикле, что и <code>a</code>. Это свойство не принадлежит простому подмножеству, потому что хотя <code>c</code> появляется справа от <code>a</code> и <code>b</code> в свойстве, он появляется слева от <code>b</code> и <code>a</code> на временной диаграмме, и это не нарушает свойство. Рисунок 3 показывает пример такой временной диаграммы.

{| align=center
! [[Файл:Std psl fig03.png|400px]]
|-
! Рисунок 3 3—Вариант, удовлетворяющий свойство 3
|}

=====1.3.2.2 Формальная верификация=====


PSL это расширение стандарта временной логики Линейной временной логике (LTL) и Вычисляемого логического дерева (CTL). Спецификация в PSL фундаментального языка (соответственно, PSL дополнительного ветвления) может быть ''скомпилирована'' в виде чистого LTL (соответственно, CTL), возможно с некоторым вспомогательным HDL- кодом, известным, как ''спутник''.

== 3. Определения, сокращения и аббревиатуры ==

<--
For the purposes of this document, the following terms and definitions apply. The IEEE Standards Diction-
ary: Glossary of Terms & Definitions should be referenced for terms not defined in this clause.6
-->
Цели этого документа - текущие термины и определения. IEEE словарь стандартов: Cловарь терминов и определений должен ссылаться на условия неопределенные в этом пункте.6

===3.1 Определения (Definitions) ===


Этот подпункт определяет термины, используемые в этом стандарте.


'''утверждение (assertion)''': значит, что данное свойство требуется выполнить и указать программе функциональной верификации, чтобы убедиться, что оно выполняется.


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


'''асинхронное свойство (asynchronous property)''': Свойство, временной контекст которого эквивалентен значению Правда.


'''поведение (behavior)''': Путь.


'''Булевы (выражения) (Boolean (expression))''': Выражения, которые принимают на выходе логические значения.


'''проверка (checker)''': Вспомогательный процесс (обычно применяемый, как конечный автомат), который проверяет моделирование проекта и сообщения об ошибках, когда утвержденное свойство не выполняется. Проверка может быть представлена в том же HDL-коде, что и проект или в какой-либо другой форме, которая может ссылаться на моделирование проекта.


'''завершение (completes)''': Термин используемый для определения последнего цикла пути, который удовлетворяет последовательности выражений или свойств.


'''вычисленный путь (computation path)''': Правопреемство состояний проекта, такое что проект может актуально переходить из каждого состояния на пути к его преемнику.


'''ограничение (constraint)''': Состояние ( обычно для входного сигнала), которое ограничивает набор поведений, которые следует рассматривать. Ограничение может представлять реальные требования (т.е. временные требования) в среде, в которой используется проект, или может представлять искусственные ограничения (т.е. настройки режима) наложенные в порядке разделения задания функциональной верификации.


'''счетчик (count)''': Число или диапазон.


'''зона покрытия (coverage)''': Мера возникновения определенного поведения в течение (обычно динамическое) функциональной верификации и поэтому расчет сложности (динамического) процесса функциональной верификации.


'''цикл (cycle)''': Оценочный цикл.


'''описания (describes)''': Термин, используемый для определения набора поведений, для которого Булевы выражения, последовательные выражения или выполняемые свойства.


'''проект (design)''': Модель кусочка аппаратуры, описанная на некотором языке описания аппаратуры (HDL). Проект типично включает в себя набор входов, выходов, элементов состояния и комбинационных функций, которые рассчитывают следующие состояние и выходы из текущего состояния и входов.


'''поведение проекта (design behavior)''': Рассчитанный путь для данного проекта.


'''динамическая верификация (dynamic verification)''': Процесс верификации, такой как моделирование, в котором свойство проверяется
отдельно, конечные поведения проекта, которые обычно получаются динамическим проведением проекта через конечное число оценочных циклов. В общем, динамическая верификация не дает вывода о выполняющемся свойстве поведения, через которое свойство еще не было проверено.


'''оценка (evaluation)''': Процесс проведения проекта итеративным принятием значений на его входы, рассчитывая его следующие состояния и выходные значения, время опережения, и назначение переменных состояний и выходов своих следующих значений.


'''оценочный цикл (evaluation cycle)''': Одна итерация оценочного процесса. На одном оценочном цикле, состояние проекта пересчитывается ( и может быть изменено).


'''расширения (данного пути) (extension (of a given path))''': Путь, который начинается с точного правопреемства состояний в данном пути.



* '''False''' — Интерпритация определённых значений определённых типов в HDL языках. В SystemVerilog и Verilog стилях, битовые значения 1’b0, 1 ’bx, и 1’bz интерпретируются как логическое значение False. В VHDL стиле, значения STD.Standard.Boolean’(False) и STD.Standard.Bit’(‘0’), также как значения IEEE.std_logic_1164.std_logic’( ‘0’), IEEE.std_logic_1164.std_logic’(‘L’), IEEE.std_logic_1164.std_logic’(‘X’), и IEEE.std_logic_1164.std_logic’(‘Z’) все интерпретируются как логическое значение False. В SystemC стиле, значение 'false' типа bool и любой литерал типа integer с числовым значением 0 интерпретируется как значение False. В GDL стиле, значение типа Boolean 'false' и значение типа bit 0B оба интерпретируются как логическое значение False.


'''конечный диапазон (finite range)''': Диапазон с большой конечной границей.


'''формальная верификация (formal verification)''': Процесс функциональной верификации, в котором анализ дизайна и выхода свойства логически разъясняет о выполняемое свойство для все поведений проекта. Если свойство продекларировано значение "правда" программой формальной верификации, моделирование не может сделать его значение "ложным". Если свойство не выполняется для каждого поведения, то процесс формальной верификации должен предоставить специфический контрпример свойства, если это возможно.


'''функциональная верификация (functional verification)''': Процесс подтверждения того, что для данного проекта и данного набора ограничений, свойство, которое требует выполнение в этом проекте, действительно выполняется в соответствие с данными ограничениями.


'''исполнение (holds)''': Термин используемый для разъяснения значения Булевых выражений, последовательных выражений или свойств.


'''обязательное исполнение(holds tightly)''': Термин используемый для разъяснения значения последовательных выражений. Последовательные выражения оцениваются на конечной стадии (поведение).


'''живучие свойства (liveness property)''': Свойства, которые указывают на случайность, которая не ограничена во времени. Грубо говоря, живучие свойства утверждает, что что-то “хорошее” в конечном счете произошло. Более формально, живучие свойство - это свойство, для которого любая конечная стадия может быть продолжена до стадии удовлетворения свойства. Например, свойство “когда-либо сигнал req принимает значение, сигнал ack принимает значение через некоторое время” это живучие свойство.


'''логический тип (logic type)''': Тип данных HDL, который включает значения, которые интерпретируются, как логические значения. Логический тип, также, включает значения, которые не интерпретируются, как логические значения. Как логический тип, обычно, представляет многозначную логику.


'''логическое значение (logical value)''': Значение из набора {True, False}.


'''проверка на модели (model checking)''': Тип формальной верификации.


'''число (number)''': Неотрицательное целочисленное значение, и статично подсчитанное выражение полученное, как выражение.


''' (occurs)''': Термин используемый для индикации того, что Булево выражение выполняется в данном цикле.


'''occurrence (of a Boolean expression)''': Цикл, в котором выполняется Булево выражение.


'''стадия (путь) (path)''': Правопреемственность состояний проекта, ???


'''положительный счетчик (positive count)''': Положительное число или положительный диапазон.


'''положительное число (positive number)''': Число, которое больше нуля (0).


'''положительный диапазон (positive range)''': Диапазон с нижней границей большей нуля (0).


'''префикс (данной стадии) (prefix (of a given path))''': Стадия в которую расширяется данная стадия.


'''свойство (property)''': Набор логических и временных взаимоотношений между и среди подчиненных Булевых выражений, последовательных выражений и других свойств, которые в совокупности представляют набор поведений.


'''диапазон (range)''': Набор последовательных чисел, от нижней до верней границы, включительно, такой, что нижняя граница меньше или равна верхней. В частности, это предполагает случай, в котором нижняя граница эквивалентна верхней. Также, пара статически подсчитанных целочисленных выражений представляются, как наборы последовательных чисел, где левая выражения является нижней границей, а правое выражение верхней границей набора. Диапазон может описывать набор значении и переменное число циклов или повторяющихся событий.


'''ограничение (restriction)''': Утверждение, что проект ограничивается данным последовательным выражением, и директива программе функциональной верификации рассматривать только стадию, на которой выполняется данное последовательное выражение.


'''защищенное свойство (safety property)''': Свойство, которое указывает инвариантность по состояниям в проекте. Инвариантность - это необязательно ограниченность в один цикл, но ограниченность по времени. Грубо говоря, защищенное свойство показывает, что ничего “плохого” не произошло. Более формально, защищенное свойство - это свойство, для которого любая стадия имеющая навязывающееся свойство получает конечный префикс, такой ,что каждое расширение префикса навязывается свойству. Например, свойство “когда-либо сигнал req принимает значение, сигнал ack принимает значение через три цикла”, является защищенным свойством.


'''последовательность (sequence)''': Последовательное выражение, которое может напрямую использоваться в течение свойства или директивы.


'''последовательное выражение (sequential expression)''': Законченный набор терминов, который представляет набор поведений.

'''последовательные регулярно расширяемые выражения (sequential extended regular expression)''': Форма последовательных выражений и компонентов последовательностей.


'''начало (starts)''': Термин используемый для идентификации первого цикла пути, который удовлетворяет последовательное выражение.


'''строго перед (strictly before)''': Перед, и не в этом же цикле.


'''сильный оператор (strong operator)''': Временной оператор, неотрицательное использование которого, обычно, создает живучие свойства.


'''временное выражение (temporal expression)''': Выражение, которое включает один или более временных операторов.


'''временной оператор (temporal operator)''' Оператор, который представляет временные ( т.е. ориентированные во времени) взаимоотношения между операндами.


'''условие завершения (terminating condition)''': Булево выражение, появление которого, приводит к завершению свойства.


'''свойство завершения (terminating property)''': Свойство, выполнение которого, приводит к завершению другого свойства.


* '''True''': Интерпритация определённых значений определённых типов в HDL языках.
** В SystemVerilog и Verilog стилях, битовые значение 1'b1 интерпретируется как логическое значение True.
** В VHDL стиле, значения STD.Standard.Boolean'(True), STD.Standard.Bit'('1'), IEEE.std_logic_1164.std_logic'('1'), и IEEE.std_logic_1164.std_logic'('H') интерпретируются как логическое значение True.
** В SystemC стиле, значение 'true' типа bool и любой литерал типа integer с ненулевым числовым значением интерпретируется как логическое значение True.
** В GDL стиле, значение типа Boolean 'true' и значение типа bit 1B интерпретируются как логическое значение True.


'''неизвестное значение (unknown value)''': Значение (многозначного) логического типа, отличное от 0 и 1.


'''слабый оператор (weak operator)''': Временной оператор, неотрицательное использование которого не создает живучего свойства.

== 3.2 Сокращения и аббревиатуры ==

* ABV — утверждения, базирующиеся на верификации
* BNF — расширенная форма Бакуса-Наура
* cpp — C препроцессор
* CTL — вычисляемое логическое дерево
* EDA — авторматизация проектирования
* FL — фундаметальный язык
* FSM — конечный автомат
* GDL — общий язык описания
* HDL — язык описания аппаратуры
* iff — если, и только если
* LTL — линейная временная логика
* PSL — язык спецификации свойств
* OBE — дополнительное расширение ветвления
* RTL — уровень регистровых передач
* SERE — последовательное расширенное регулярное выражение
* VHDL — VHSIC язык описания аппаратуры
* VHSIC — высоко скоростная интегральная схема

==== 4.1.1 Слои (Layers) ====
PSL состоит из четырёх слоёв: булевый (Boolean), временной (temporal), верификационный (verification), и модельный (modeling).

===== 4.1.1.1 Булевый слой (Boolean layer) =====


Булевый слой используется для создания выражений, которые, в свою очередь, используются другими слоями. Хотя этот слой содержит выражения над многими типами, он называется как булевый слой, потому что он является поставщиком булевых (логических) выражений для основы (сердца) языка — временнОго слоя. Выражения булевого слоя выполняются в едином (одиночном) цикле выполнения.

===== 4.1.1.2 ВременнОй слой (Temporal layer) =====

Временной слой является основой языка; он используется для описания свойств проекта. Он называется временным, потому что, в дополнение к простым свойствам, таким как "сигналы a и b являются взаимноисключающими", он может также описывать свойства включающие сложные временные отношения между сигналами, например "если сигнал c устанавливается, тогда сигнал d должен установиться прежде, чем сигнал e установится, но не позже более восьми периодов синхросигнала". ВременнЫе выражения выполняются в течении серии циклов выполнения.

===== 4.1.1.3 Верификационный слой (Verification layer) =====


Верификационный слой используется для того чтобы сказать верификационному инструменту (САПР), что делать с свойствами описанными во временном слое. Например, верификационный слой включает директивы, которые говорят инструменту (САПР) чтобы верифицировал (verify) то, что свойство удерживает (hold) или проверил (check) то, что заданная последовательность покрыта некоторым тестирующим случаем.

===== 4.1.1.4 Моделирующий слой (Modeling layer) =====


Моделирующий слой (Modeling layer) используется для моделирования поведения входов проекта (для инструментов (САПР), таких как инструменты (САПР) для формальной верификации, которые не используют тестов) и для моделирования дополнительной аппаратуры, которая не является частью проекта, но необходима для верификации.

==== 4.1.2 Стили/Варианты (Flavors) ====


PSL идёт с пятью вариантами/стилями (flavors): один для каждого HDL языка SystemVerilog, Verilog, VHDL, SystemC, и GDL. Синтаксис каждого варианта (стиля) соответствует синтаксису соответствующего HDL языка в ряде конкретных областей — данный стиль PSL совместим с соответствующим синтаксисом HDL-языка в этой области.

{| class=standard align=center
|+ Влияние стиля на слои PSL
!rowspan=2| Слой ||colspan=5 | HDL
|-
! SystemVerilog || Verolog || VHDL || SystemC || GDL
|-
| Булевый || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}}
|-
| Модельный || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}} || {{V|16px}}
|-
| Временной || i:j || i:j || i to j || i:j || i..j
|-

|}

=== 4.2 Лексическая структура ===


Этот подпункт определяет идентификаторы, ключевые слова, операторы, макросы и комментарии, используемые в PSL.

==== 4.2.1 Идентификаторы (Identifiers) ====


Идентификаторы в PSL состоят из символа латинского алфавита, за которым следует ноль или более символов латинского алфавита; каждый последующий символ алфавита может по желанию предшествовать одному символу подчеркивания. Например:

mutex
Read_Transaction
L_123


PSL идентификаторы являются чувстительными к регистру в SystemVerilog, Verilog, и SystemC вариантах/стилях и не чувствительными к регистру в VHDL и GDL вариантах.

==== 4.2.2 Ключевые слова ====

{|
|<poem> A
E
next!
rose
AF
EF
next_a
AG
EG
next_a!
</poem>
| <poem> sequence
AX
abort
EX
next_e
stable
always
ended
next_e!
string
</poem>
| <poem>anda
eventually!
next_event
strong
assert
next_event!
sync_abort
assume
F
next_event_a
</poem>
| <poem>async_abort
fairness
next_event_a!
toe
before
fell
next_event_e
before!
for
next_event_e!
</poem>
| <poem> U
before!_
forall
nondet
union
before_
nondet_vector
until
bitvector
bit
</poem>
| <poem> G
notc
until!
boolean
numeric
until!_
hdltype
until_
clock
onehot
</poem>
| <poem>const
in
onehot0
vmode
countones
inf
ord
vpkg
cover
inherit
</poem>
| <poem> vprop
isb
property
vunit
default
isunknown
prev
W
report
mutable
</poem>
| <poem> within
restrict
restrict!
never
X
next
X!</poem>
|}

*a and is a keyword only in the VHDL flavor; see the flavor macro AND_OP (4.3.2.6).
*b is is a keyword only in the VHDL flavor; see the flavor macro DEF_SYM (4.3.2.9).
*c not is a keyword only in the VHDL flavor; see the flavor macro NOT_OP (4.3.2.6).
*d or is a keyword only in the VHDL flavor; see the flavor macro OR_OP (4.3.2.6).
*e to is a keyword only in the VHDL flavor; see the flavor macro RANGE_SYM (4.3.2.7).

==== 4.2.3 Операторы ====

===== 4.2.3.1 Операторы HDL языка =====

Для заданного стиля PSL, операторы основного HDL языка имеют наивысший преоритет. В частности это включает логические, арифметические операторы и операторы отношения языка HDL. Логические операции HDL языка для отрицания, конъюнкции и дизъюнкции булевых (логических) значений могут использоваться в PSL для отрицания, конъюнкции и дизъюнкции свойств. В таких приложениях, эти операторы имеют их обычный приоритет и ассоциативность, как если бы PSL свойства,....

===== 4.2.3.2 Операторы фундаментального языка =====


Различные операторы доступны в PSL. Каждый оператор имеет приоритет по отношению к другим операторам. В общем операторы с большим приоритетом получают доступ к свои операндам, раньше, чем операнды с меньшим приоритетом. Если два оператора имеют одинаковый приоритет и появляются в последовательности, то они получают доступ к свои операндам в соответствие с ассоциативностью операторов. Лева-ассоциативные оператор получает доступ к своим операндам слева на право в порядке появления в тексте, право-ассоциативные операторы получают доступ к своим операндам справа на лева в порядке появления в тексте.

{| class=standard align=center
|+ Таблица приоритетов и ассоциативности двух операторов фундаментального языка
|-
! Оператор класс || Ассоциативность ||colspan=2| Операторы
|-
| ''(наивысший приоритет)''

HDL операторы
| || ||
|-
| Оператор объединения || left || union ||
|-
| Оператор времени || left || @ ||
|-
| SERE повторяющийся оператор || left || [* ] [+] [= ] [-> ] ||
|-
| Последовательный предельный оператор || left || within ||
|-
| Последовательный оператор И || left || & || &&
|-
| Последовательный оператор ИЛИ || left || <nowiki>|</nowiki> ||
|-
| Последовательный оператор слияния || left || : ||
|-
| Последовательный оператор конкатенации || left || ; ||
|-
| Операторы прерывания фундаментального языка || left || abort sync_abort || async_abort
|-
| Операторы фундаментального языка, указывающие местонахождение || right || next* || eventually!
|-
| || || X X! || F
|-
| Операторы фундаментального языка, показывающие границы || right || U || W
|-
| || || until* || before*
|-
| Последовательный оператор импликации || right || <nowiki>|-></nowiki> || <nowiki>|=></nowiki>
|-
| Булевы операторы импликации || right || -> || <->
|-
| Неизменные операторы фундаментального языка ''(низший приоритет)'' || right || always G || never
|-
|}


Примечание - Обозначение next* представляет семейство next-операторов, которое включает операторы: next, next!,
next_a, next_a!, next_e, next_e!, next_event, next_event!, next_event_a! и
next_event_e!. Обозначение until* представляет семейство until-операторов, которое включает операторы: until,
until!, until_ и until!_. Обозначение before* представляет семейство before-операторов, которое включает операторы: before, before!, before_, and before!_.7

====== 4.2.3.2.1 Объединительные операторы ======


Для любого стиля PSL, FL оператор со следующим наибольшим приоритетом после HDL операторов является тот, который используется для обозначения недетерминированного выражения:

union union оператор

Оператор union является лева-ассоциативным.

====== 4.2.3.2.2 Операторы времени ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это оператор времени, который используется для связи временного выражения со свойством или последовательностью:

@ clock event

Временной оператор лева-ассоциативный.

====== 4.2.3.2.3 SERE операторы повторов (repetition operators) ======


Для любого стиля PSL, FL операторы со следующим наибольшим приоритетом являются операторами повторов, которые используются для создания последовательных расширенных регулярных выражений (Sequential Extended Regular Expressions — SEREs). Эти операторы следующие:

[* ] последовательное повторение (consecutive repetition)
[+] последовательное повторение (consecutive repetition)
[= ] не последовательное повторение (non-consecutive repetition)
[-> ] goto repetition

SERE операторы повторения являются лева-ассоциативными.

====== 4.2.3.2.4 Последовательный предельный оператор ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это последовательный предельный оператор, который используется для описания поведения, в котором одна последовательность появляется в ходе другой, или в пределах интервала ограниченного временем.

within последовательность within оператор

Последовательный предельный оператор лева-ассоциативный.

====== 4.2.3.2.5 Последовательные операторы конъюнкции ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетов - это последовательные операторы конъюнкции, которые описывают поведение состоящие из параллельных стадий. Это следующие операторы:

& последовательная конъюнкция без сопоставления длинны
&& последовательная конъюнкция с сопоставлением длины

Последовательные операторы конъюнкции лева-ассоциативные.

====== 4.2.3.2.6 Последовательный оператор дизъюнкции ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это последовательный оператор дизъюнкции, который используются для описания поведения состоящего из альтернативных стадий:

| последовательная дизъюнкция

Последовательный оператор дизъюнкции лева-ассоциативный.

====== 4.2.3.2.7 Последовательный оператор слияния ======


Для любого варианта PSL, оператор фундаментального языка со следующим наивысшим приоритетом - это последовательный оператор слияния, который используется для описания поведения, в котором более поздняя последовательность начинает выполняться в том же цикле, в котором заканчивает выполняться более ранняя.

: последовательное слияние

Последовательный оператор слияния лева-ассоциативный.

====== 4.2.3.2.8 Последовательный оператор конкатенации ======


Для любого варианта PSL, оператор фундаментального со следующим наивысшим приоритетом - это последовательный оператор конкатенации, который используется, чтобы описывать поведение, в котором одна последовательность следует за другой:

; последовательная конкатенация

Последовательный оператор конкатенации лева-ассоциативный.

====== 4.2.3.2.9 Операторы прерывания фундаментального языка ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом - это операторы прерывания фундаментального языка, которые используются для описания поведения, в котором условие вызывает текущие и будущие процессы, которые будут прерваны:

sync_abort немедленное завершение текущего и следующего процесса, синхронизовано по времени
async_abort немедленное прерывание текущего и следующего процесса, независт от времени
abort эквивалентно to async_abort

Операторы прерывания фундаментального языка лева-ассоциативные.

====== 4.2.3.2.10 Операторы местонахождения фундаментального языка ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, в котором операнды используются в будущем. Это следующие операторы:
eventually! правый операнд выполняется через некоторое время в неопределенном будущем
next* правый операнд выполняется в некотором специфицированном будущем времени или диапазоне будущего времени
операторы местонахождения фундаментального языка право-ассоциативные.

====== 4.2.3.2.11 Граничные операторы ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые описывают поведение, в котором одно свойство выполняется в некотором цикле или во всех циклах перед выполнением следующего слова. Это следующие операторы:

until* левый операнд выполняется в любое время до выполнения правого операнда
before* левый операнд выполняется через некоторое время после выполнения правого

Граничные операторы фундаментального языка право-ассоциативные.

====== 4.2.3.2.12 Суффиксные операторы импликации ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, состоящего из свойства, которое выполняется в конце данной последовательности. Это следующие операторы:

|-> суффиксная импликация с перекрытием
|=> суффиксная импликация без перекрытия


Операторы суффиксной импликации право-ассоциативные.


Примечание - Свойство фундаментального языка {r} (f) - это альтернативная форма (и имеет такую же семантику) для свойства фундаментального языка {r} |-> f.

====== 4.2.3.2.13 Операторы логической импликации ======


Для любого варианта PSL, операторый фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, состоящего из Булевых выражений, последовательности или свойства, которое выполняется, если выполняется другое Булево выражение, последовательность или свойство.

-> логическая IF импикация
<-> логическая IFF импликация


Операторы логической импликации право-ассоциативные.

====== 4.2.3.2.14 Операторы неизменности фундаментального языка ======


Для любого варианта PSL, операторы фундаментального языка со следующим наивысшим приоритетом те, которые используются для описания поведения, в котором выполняется или не выполняется глобально.

always правый операнд выполняется глобально
never правый операнд не выполняется глобально

Операторы неизменности фундаментального языка право-ассоциативные.

===== 4.2.3.3 Операторы дополнительного расширенного ветвления (OBE) =====

{| class=standard align=center
|+ Таблица 3—OBE оператор, приоритет и ассоциативность
|-
! Класс оператора || Ассоциативность ||colspan=2| Операторы
|-
| (наивысший приоритет) HDL операторы || || ||
|-
| OBE операторы местонахождения ||left || AX AG AF A [ U ] || EX EG EF E [ U ]
|-
| Операторы Булевой импликации (низший приоритет) || right || -> || <->
|}

====== 4.2.3.3.1 OBE операторы местонахождения ======


Для любого варианта PSL, OBE операторы являются следующими операторами с наивысшим приоритетом, после HDL операторов, они используются для указания, когда подчиненное свойство должно выполняться, если выполняется старшее свойство. Это следующие операторы:

AX на всех путях, на следующем состоянии каждого пути
AG на всех путях, на каждом состоянии любого пути
AF на всех путях, на некотором будущем состоянии каждого пути
EX на некотором пути, на следующем состоянии пути
EG на некотором пути, на всех состояния пути
EF на некотором пути , на некотором будущем состоянии пути
A[U] на всех путях, в каждом состоянии до определенного состояния пути
E[U] на некотором пути, в каждом состоянии до определенного состояния пути

OBE операторы местонахождения лева-ассоциативные.

====== 4.2.3.3.2 OBE операторы импликации ======


Для любого варианта PSL, OBE операторы со следующим наивысшим приоритетом, это те которые используются для описания поведения, состоящего из Булевых выражений или свойства, которое выполняется, если Булево выражение или другое свойство выполняется. Это следующие операторы:

-> логическая IF импликация
<-> логическая IFF импликация

Операторы логической IF и логической IFF импликации право-ассоциативные.

==== 4.2.4 Макросы ====


PSL предоставляет возможность обработки макросов, которые помогают в определении свойств. SystemC, VHDL и
GDL варианты поддерживают cpp препроцессорные директивы (т.е. #define, #ifdef, #else, #include и #undef).
SystemVerilog и Verilog поддерживают директивы Verilog компилятора (т.е. `define, `ifdef, `else, `include и `undef). Все варианты, также поддерживают PSL макросы %for и %if, которые могут использоваться для условно или итеративно генерированного PSL утверждения.

===== 4.2.4.1 The %for construct =====

===== 4.2.4.2 The %if construct =====

==== 4.2.5 Комментарии ====

PSL обеспечивает возможность вставки комментариев в PSL спецификацию. Для каждого стиля, возможность комментариев совместима с тем, что обеспечивается соответсвующией средой PSL.

Для SystemC, SystemVerilog, и Verilog стиля, оба варианта блочных комментариев (/* .... */) и (// .... ''<eol>'') поддерживается. (''<eol>'' — конец строки)

Для стиля VHDL, поддерживается комментарии (-- .... ''<eol>'').

Для стиля GDL, оба блочных стилей комментариев поддерживаются: (/* .... */) и (-- .... ''<eol>'').

=== 4.3 Syntax ===

==== 4.3.1 Conventions ====

{| class=standard align=center
! Flavor Macro || SystemVerilog || Verilog || VHDL || SystemC || GDL
|-
| AND_OP || && || && || and || && || &
|-
| OR_OP || <nowiki>||</nowiki> || <nowiki>||</nowiki> || or || <nowiki>||</nowiki> || <nowiki>|</nowiki>
|-
| NOT_OP || ! || ! || not || ! || !
|-
| RANGE_SYM || : || : || to || :|| ..
|-
| MIN_VAL || 0 || 0 || 0 || 0 || null
|-
| MAX_VAL || $ || inf || inf || inf || null
|-
| LEFT_SYM || [ || [ || ( || [ || (
|-
| RIGHT_SYM || ] || ] || ) || ] || )
|-
| DEF_SYM || = || = || is || = || :=
|}

=== 4.4 Semantics ===

The following subclauses introduce various general concepts related to temporal property specification and
explain how they apply to PSL.

==== 4.4.1 Clocked vs. unclocked evaluation ====

== NEW ==