Просмотр исходного текста страницы Open Source VHDL Verification Methodology/Better Coverage in VHDL/ru

{{OS-VVM TOC}}
==Введение ==

Почему тесбенчей (testbenches) не достаточно

=== Testbench vs. Coverage===

* Для небольших проектов или небольших блоков больших проектов, можно создать тестбенч, который будет:
** давать правильные результаты моделирования
** осуществлять все режимы работы устройства

* В случае больших современных проектов со сложной функциональностью, даже самый знающий разработчик может пропустить некоторые режимы работы при создании тестбенча.

* Поэтому необходимо подтверждение того, что:
** в тестбенче проверяются все режимы работы устройства,
** поведение устройства является ожидаемым.

{{Кр|Необходимо проверка покрытия (Coverage)!}}

=== Что такое покрытие (Coverage)? ===

* Покрытие является крайне неоднозначным термином, когда используется сам по себе.

Можно сказать, что (в электронике):

{{Info |'''Покрытие''' ('''''Coverage''''') является одной из разновидностей метрик проекта, которая сообщает, если определённые аспекты проекта были правильно выполнены во время процедуры тестирования.}}

* Обычно уточняют термин покрытия, говоря какой аспект был протестирован:
** Тестирование качества кода — покрытие кода (code coverage)
** проверка свойств/утверждений — покрытие свойств/утверждений (property coverage)
** Сбор значений переменных проекта — функциональное покрытие (functional coverage).

===Structure vs. Functionality===
<!-- 
* When we simulate HDL code of our design with '''code coverage''' enabled, we can monitor if all elements of '''code structure''' were exercised. ''If they were, we assume that design quality is high.''
* Fully tested HDL code may still not meet design specification: lack of errors means that ''actual'', not ''intended functionality'' of the code was tested...
* Functionality testing (represented by {{Зел|property coverage}} and {{Зел|functional coverage}}) gives us better information than structure testing.

{{Кр|Are structure and functionality tests mutually exclusive or do they overlap?}}
-->

* при моделировании HDL-кода проекта с включенной опцией '''покрытие кода''' ('''code coverage'''), можно контролировать, все ли элементы структуры кода ('''code structure''') были выполнены. ''Если они все выполнены, то принято считать, что качество проекта высокое''.

* Полностью протестированный HDL-код может по прежнему не соответствовать спецификации проекта: отсутствие ошибок означает то, что '''фактическая''', а не '''требуемая функциональность''' кода была протестирована...

* Функциональное тестирование (представленное {{Зел|покрытием свойств/утверждений}} и {{Зел|функциональным покрытием}}) дает больше информации, чем тестирование структуры кода.

{{Кр|Являются ли структурные и функциональные тесты взаимоисключающими или же они перекрывают друг друга?}}

=== Качество кода vs. функциональность (функционирование)===

[[Файл:Code quality-vs-functionality.png|center|400px]]


=== В чем проблема? ===
<!-- 
* We agree that we have to have good design code. Bad code can sometimes surprise us with good functionality, but it is not manageable.
: {{Кр|'''We need code coverage!'''}}

* Мы знаем, что хороший код может представлять плохое функциональность
:We can simulate a lot to verify that it really represents desired design behaviors.
:Property and functional coverage can do it faster and better!

* Let’s see what are the advantages and disadvantages of all three kinds of coverage...
-->

* Можно согласиться, что необходимо иметь хороший код проекта. Плохой код может иногда удивлять правильным функционированием, но это не управляемый процесс.
: {{Кр |'''Необходима проверка покрытия кода!'''}}

* Известно, что хороший код может представлять плохую функциональность.
: Можно моделировать много, чтобы убедиться, что он действительно представляет собой желаемое поведение проекта.
: Проведение покрытия свойств/утверждений и функциональное покрытие может сделать это быстрее и лучше!

* Рассмотрим каковы преимущества и недостатки всех трех видов покрытия ...

== Разновидности покрытия кода (Code Coverage) ==

<!-- When and How to Use Them-->
Когда и как их использовать?


=== Основы покрытия кода ===
<!--
* '''''Code Coverage''''' was invented to improve quality of programs written in “''regular''” programming languages (like C).

* By nature, code coverage analyses '''''structural correctness''''' of the code, not functional correctness! Structurally incorrect code <u>''usually''</u> malfunctions, so correcting bad code <u>''usually''</u> corrects functional errors.

* Code coverage developed into wide variety of flavors to address obvious and well-hidden problems that can sneak into the code.
-->

* '''''Покрытие кода''''' было изобретено, чтобы улучшить качество программ, написанных на «''обычных''» языках программирования (например, C).

* По своей природе, покрытие кода анализирует '''''структурную корректность''''' кода, а не функциональную корректность! Структурно неправильный код <u>''обычно''</u> работает неправильно, поэтому исправление плохого кода <u>''обычно''</u> корректирует функциональные ошибки.

* Покрытие кода превратилось в широкое разнообразие разновидностей для решения очевидных и хорошо скрытых проблем, которые могут проникнуть в код.

=== Основные разновидности кодового покрытия===

* Основными разновидностями покрытия кода являются:
** '''''Покрытие операторов (Statement Coverage)''''' – проверка все ли операторы в коде были выполнены хотя бы один раз,
** '''''Покрытие ветвей (переходов) (Branch Coverage)''''' – проверка все ли ветви условных операторов ('''if''', '''case''' и др.) были пройдены.

* '''''Покрытие операторов''''' очень схоже с '''''покрытием строк (Line Coverage)''''', результаты которых будут отличаться, если только программист записывает больше одного оператора в одной строке (что является плохой практикой). <!-- results of both differ only if the coder squeezes more than one statement in one line (not a good practice).-->

<!-- 
* The results of '''''Branch Coverage''''' could be extracted from the statement coverage results, but in large designs it would be very tedious task...
-->
* Результаты '''''покрытия ветвей''''' могут быть извлечены из результатов покрытия состояний (утверждений), но в больших проектах это очень трудоёмкая задача...

=== Дополнительные разновидности покрытия кода ===
<!-- 
* Statement and branch coverage can yield false positive results when they deal with non-trivial expressions:
-->
* Покрытие операторов и ветвей может давать ложные положительные результаты, когда имеют места необычные выражения:
** <source lang="vhdl">Trig := SensA or SensB;</source>

<!--
:: There are 4 different combinations of values of SensA and SensB, but statement coverage will be OK after just one execution of the assignment.
-->
:: Есть 4 различных комбинации значений SensA и SensB, но покрытие операторов будет полным уже после всего одного выполнения данного оператора.

{| align=center
! {{Кр|В таких случаях необходимо выполнять ''<u>покрытие выражений</u> (Expression Coverage)''.}}
|}

:* <source lang="vhdl">if Load='1' and Enable='1' then ...</source>

<!--
:: Branch coverage will just tell that the branch was not executed without specifying if Load, Enable or both are to blame.
-->
:: Покрытие ветвей только сообщит о том, что ветвь не была пройдена, без указания из-за какого сигнала (Load или Enable, или обоих) ветка не выполнилась.

{| align=center
! {{Кр|В таких случаях требуется проводить ''<u>покрытие состояний</u> (Condition Coverage)''.}}
|}

=== Специальные разновидности покрытия <!-- Special Coverage Flavor--> ===

{| align=center width=70% 
| 
{| 
|<source lang="vhdl">if pol='1' then </source> 
! 1|| 2|| 3 || 4
|-
| <source lang="vhdl">  a := buf1;</source> 
! 1|| || 3 ||
|-
| <source lang="vhdl">else</source>  || || || ||
|-
| <source lang="vhdl">  a := not buf1;</source>  
! || 2 || || 4
|-
| <source lang="vhdl">end if;</source> || || || ||
|-
| <source lang="vhdl">if act='1' then</source>  
! 1 || 2 || 3 || 4
|-
|<source lang="vhdl">  res := a or b;</source>  
! 1 || || || 4
|-
| <source lang="vhdl">else</source>  || || || ||
|-
| <source lang="vhdl">  res := a and b;</source>  
! ||  2 ||3  ||
|-
|<source lang="vhdl">end if;</source> 
! || || ||
|}
| width=70% |
<!--
* If we run simulation of the code presented to the left, then two executions are needed to achieve statement and branch coverage (they are marked with '''1''' and '''2''').
-->
* При выполнении моделирования приведённого кода, тогда два запуска (прохода) необходимы для достижения покрытия операторов и ветвей (они помечены '''1''' и '''2''').
<!-- 
* But there are two additional execution paths that were not exercised yet – marked with '''3''' and '''4'''.
-->
* Но есть два дополнительных пути исполнения, которые не были еще пройдены — они отмечены '''3''' и '''4'''.
<!-- 
* We need two more executions and '''Path Coverage''' enabled to fully test this code...
-->
* Необходимо включить ещё два прохода и '''<u>покрытие путей</u> (Path Coverage)''', чтобы полностью протестировать данный код...
|}

===HDL аспекты покрытия кода ??? <!-- Aspects of Code Coverage-->===

<!-- 
* Original code coverage was created for sequential code and ignores concurrency and modularity of VHDL.

*Modularity issue can be addressed by '''''per instance''''' data collection in addition to '''''per unit''''' data collection:
** If you have D-flipflop component instantiated 4 times and '''''per unit''''' data collection is enabled, execution of '''''one instance''''' signals complete coverage.
** If you enable '''''per instance''''' data collection in the same design, '''''all 4 instances''''' must be executed to signal complete coverage.

* There are no ways of verifying (with code coverage) concurrent execution of two processes residing in one unit...
-->
* Исходное покрытие кода было создано для последовательного кода и игнорирует параллелизм и модульность языка VHDL.

* Проблема модульности может быть решена путем сбора данных по '''''каждому экземпляру/элементу (per instance)''''' в дополнение к сбору данных '''''на компонент (per unit)''''':
** Если у вас есть компоненты D-триггеров используемые 4 раза и включен сбор данных '''''по компоненту''''', то выполнение '''''одного экземпляра/элемента''''' означает полное покрытие.
** Если вы включите сбор данных '''''по каждому экземпляру/элементу''''' в том же проекте, то '''''все 4 элемента''''' должны быть выполнены, чтобы выполнить полное покрытие.

* Нет никаких способов проверки (с покрытием кода) одновременного выполнение двух процессов, размещённых в одном компоненте (блоке) ...

===Покрытие кода в программах САПР <!-- Code Coverage in the Tools-->===

<!-- 
* Code coverage is not a language feature – it is a '''''tool feature'''''...
* As such, it usually requires more advanced version of the simulator or additional license features.
* Always check which flavors of code coverage are supported in the tool.
* All tools should generate textual '''''coverage reports''''';
: look for additional '''''coverage viewers''''' that make analysis of code coverage results easier.
* Do not enable all coverage flavors at the same time; 
: it will slow down your simulation and usually will not yield significantly better results...
-->

* Покрытие кода не является особенностью (функцией) языка — это '''''функция программы САПР'''''...

* Как таковая, она обычно требует более продвинутой версии симулятора или дополнительной лицензии.

* Всегда проверяйте какие разновидности покрытия кода поддерживаются программами моделирования.

* Все программы САПР должны генерировать текстовые '''''отчеты о покрытии (coverage reports)''''';
: Ищите дополнительные '''''просмоторщики покрытия (coverage viewers)''''', которые делают анализ результатов покрытия кода проще.

* Не включайте все разновидности покрытия одновременно;
: Это будет замедлять работу моделирования и обычно не даёт значительно лучших результатов ...

===Выводы===

[[Image:Summary.png|right|150px]]
<!-- 
* Code coverage checks structural integrity of the code directly and only indirectly suggests functional correctness.

* Code coverage lets you improve quality of your verification procedures.

* 100% code coverage never gives guarantee that design functionality is correct.

* Less than 100% code coverage gives strong indication that there are also functional problems in the design.

* Code coverage will not check concurrency and timing!
-->
* Покрытие кода проверяет структурную целостность кода непосредственно и только косвенно свидетельствует о функциональной корректности.

* Покрытие кода позволяет улучшить качество процесса верификации.

* 100% покрытие кода никогда не дает гарантии, что проект функционирует правильно.

* Покрытие кода менее 100% является сильным признаком, что есть также проблемы функционирования в проекте.

* Покрытие кода не будет проверять параллелизм и временные ограничения!

== Покрытие свойств/утверждений (Property Coverage) ==

Close Relative of Assertions


===Основные термины===

<!-- * '''''Boolean logic''''' tests general statements about the design.-->
* '''''Булева логика (Boolean logic)''''' тестирует основные утверждения (statements) о проекте.

<!-- * '''''Temporal logic''''' adds time dimension to Boolean logic and tests absence, presence, persistence, sequence, etc. of certain events.-->
* '''''Временная логика (Temporal logic)''''' добавляет временнОе измерение (dimension) в булеву логику (Boolean logic) и тестирует отсутствие (absence), наличие (presence), неизменность/повторяемость (persistence), последовательность (sequence), и прочее определённых событий.

<!-- * '''''Property''''' is the formalized description of design behavior taken from the design specification and expressed in temporal logic terms.-->
* '''''Свойства/утверждения (Property)''''' это формальное описание поведения проекта, взятое из спецификации проекта и выраженное в терминах временной логики (temporal logic).
<!-- 
** '''''Properties''''' can be expressed in '''''PSL''''' (Property Specification Language – now native to VHDL) or in '''''SVA''''' (SystemVerilog Assertions subset – works with VHDL via checker modules).
-->
** '''''Свойства/утверждения (Properties)''''' могут быть выражены с помощью '''''PSL''''' (Property Specification Language – теперь включен в VHDL) или с помощью '''''SVA''''' (подмножество SystemVerilog Assertions – работает с VHDL через модули проверок (checker modules)).

<!-- * '''''Sequences''''' are the simplest form of properties, representing sequences of events/conditions.-->
* '''''Последовательности (Sequences)''''' являются простейшей формой свойств/утверждений, представляющие последовательность событий/состояний.

=== Clocking Properties===
<!-- 
* Both PSL and SVA use discrete time version of temporal logic, i.e. they '''''sample''''' values of design signals at certain '''''clocking events'''''.
-->
* И PSL и SVA используют дискретное время для временной логики (temporal logic), например, они '''''фиксируют/собирают (sample)''''' значения сигналов в проекте по определённым '''''синхронным событиям (clocking events)'''''

<!-- * PSL lets you set default clock using:--> 
* PSL позволяет установить синхросигнал по умолчанию, используя: 

:: <source lang="vhdl">default clock is rising_edge(CLK1);</source>

<!-- :or clock for a given property (or sequence) using:-->
:или задать синхросигнал для заданного свойства/утверждения (или последовательности), используя:

:: <source lang="vhdl">my_prop_or_seq @falling_edge(CLK2);</source>

<!-- * You can also use {{Зел|rose()}} and {{Зел|fell()}} functions to detect signal edges for the purpose of “internal clocking”.-->
* Можно использовать функции {{Зел|rose()}} и {{Зел|fell()}} для обнаружения изменения сигналов в целях «внутреннего тактирования» (“internal clocking”)

===Примеры простых последовательностей===

<!-- ''Concatenation:'' A is '''''true''''' in the current clock cycle and B is true in the {{Кр|'''''next'''''}} cycle:-->
''Последовательность событий/объединение/конкатенация (Concatenation):'' A является '''''true''''' в текущем периоде синхросигнала, а B является '''''true''''' в  {{Кр|'''''следующем'''''}} периоде:

: '''{A {{Кр|;}} B}''' [[Файл:Simple Sequence Examples-1.1.png|100px]]

<!-- 
''Concatenation with Consecutive Repetition:'' A is '''''true''''' for {{Кр|2}} clock cycles and B is true for {{Кр|2}} clock cycles (starting {{Кр|'''''at the next sample'''''}} after A sequence ended):
-->
''Объединение/конкатенация с последовательным повторением (Concatenation with Consecutive Repetition):'' A является '''''true''''' для {{Кр|2}} периодов синхросигнала, а B является '''''true''''' для {{Кр|2}} периодов  синхросигнала  (начиная {{Кр|'''''со следующей выборки'''''}} после окончания последовательности A):

: '''<tt><big>{A[{{Кр|*2}}] {{Кр|;}} B[{{Кр|*2}}]}</big></tt>''' [[Файл:Simple Sequence Examples-1.2.png|160px]]

<!-- 
''Consecutive Repetition With Range:'' A is '''''true''''' for 2 clock cycles and B is '''''true''''' for {{Кр|2 to 3}} clock cycles (starting {{Сн|'''''at the next sample'''''}} after A sequence ended):
-->
''Последовательное повторение с диапазоном (Consecutive Repetition With Range):'' A является '''''true''''' для 2-х периодов синхросигнала, а B является '''''true'''''  {{Кр|от 2 до 3}} периодов синхросигнала (начиная {{Сн|'''''со следующего отсчета'''''}} после окончания последовательности A):

: '''<tt><big>{A[*2] ; B[{{Кр|*2 to 3}}]}</big></tt>''' [[Файл:Simple Sequence Examples-1.3.png|200px]]

<!-- 
''Fusion with Repetition'': A is '''''true''''' for 2 clock cycles and B is '''''true''''' for 2 to 3 clock cycles (starting {{Кр|'''''at the same sample'''''}} where A sequence ended):
-->
''Соединение с повторением (Fusion with Repetition)'': A является '''''true''''' для 2-х периодов синхросигнала, а B является '''''true''''' от 2 до 3 периодов синхросигнала (начиная {{Кр|'''''с того же отсчёта'''''}}, где оканчивается последовательность A):

: '''<tt><big>{A[*2] {{Кр|:}} B[*2 to 3]}</big></tt>''' [[Файл:Simple Sequence Examples-1.4.png|160px]]

===Ещё примеры последовательностей ===

<!-- 
''Inclosure'': A is '''''true''''' for 2 clock cycles {{Кр|'''''within'''''}} 5 clock period time when B is '''''true''''' :
-->
''Inclosure'': A является '''''true''''' для 2 периодов синхросигнала {{Кр|'''''в приделах (within)'''''}} времени 5 периодов синхросигнала, пока B равно '''''true''''':

: '''<tt><big>{A[*2] {{Кр|within}} B[*5]}</big></tt>'''  [[Файл:Better Coverage in VHDL-2.1.png|200px]]

<!--
''Non-consecutive Repetition:'' A is '''''true''''' for 2 clock cycles (not necessarily consecutive) '''''within''''' 5 clock period time when B is '''''true''''' :
-->
''Не последовательное повторение (Non-consecutive Repetition):'' A является '''''true''''' для 2 периодов синхросигнала (не обязательно последовательных) '''''в приделах (within)''''' времени 5-ти периодов синхросигнала, пока B равно '''''true''''' :

: '''<tt><big>{A[{{Кр|<nowiki>=</nowiki>2}}] within B[*5]}</big></tt>'''  [[Файл:Better Coverage in VHDL-2.2.png|200px]]

<!-- 
''Go-to Repetition:'' A is '''''true''''' for 2 clock cycles (not-consecutive, but including last
sample in sequence) '''''within''''' 5 clock period time when B is '''''true''''' :
-->
''Go-to Repetition:'' A равно '''''true''''' для 2 периодов синхросигналов (не последовательных, но включая последнюю выборку в последовательности) '''''в течении (within)''''' 5 периодов синхросигнала, когда B равно '''''true''''':

: '''<tt><big>{A[{{Кр|->2}}] within B[*5]}</big></tt>'''  [[Файл:Better Coverage in VHDL-2.3.png|200px]]

===Примеры свойств/утверждений (Property)===

<!-- ''Operator '''always''''': Signal POWER must always be high:-->
''Оператор '''always''''': Сигнал POWER должен быть всегда (always) равен '1':

: <big>'''<tt>always (POWER='1')</tt>'''</big>

<!-- ''Operator '''never''''': Signal Z should never be '''''true''''' right after Y:-->
''Оператор '''never''''': Сигнал Z никогда не должен быть '''''true''''' сразу после Y:

: <big>'''<tt>never {Y ; Z}</tt>'''</big>

<!-- ''Operator '''eventually!''':'' Signal DONE should be '''''true''''' before end of simulation:-->
''Оператор '''eventually!''':'' Сигнал DONE должен быть '''''true''''' до окончания моделирования:

: <big>'''<tt>eventually! DONE</tt>'''</big>

''Non-overlapping implication:'' If X is true for 2 cycles, then Y is true for 3
cycles starting '''''at the last''''' sample of X:

: <big>'''<tt>X[*2] {{Кр|<nowiki>|-></nowiki>}} Y[*3]</tt>'''</big>   [[Файл:Better Coverage in VHDL (Property Examples)-3.1.png|200px]]

''Overlapping implication:'' If X is true for 2 cycles, then Y is true for next 3
cycles '''''after the last''''' sample of X:

: <big>'''<tt>X[*2] {{Кр|<nowiki>|=</nowiki>>}} Y[*3]</tt>'''</big> [[Файл:Better Coverage in VHDL (Property Examples)-3.2.png|160px]]

=== Property Coverage vs. Assertions ===

<!-- * Properties checked with '''''assert''''' directive alarm us only when something went wrong (not good for coverage).-->
* Свойсвта/Утвержения, проверяемые директивой '''''assert''''', предупреждают нас только если что-либо пошло не так (что не хорошо для покрытия).

<!-- * We must use the property with '''''cover''''' directive to get confirmation that the behavior it represents was tested.-->
* Нужно использовать Свойство/Утверждение с директивой  '''''cover''''' для подтверждения того, что поведение, которое оно (утверждение) представляет, было протестировано.

<!-- 
* Properties used in '''''cover''''' directive enable '''''property coverage'''''; 
: we get messages when property evaluation succeeded and report listing all properties that were not covered.
-->
* Свойства/Утверждения используемые с директивой  '''''cover'''''  включают  '''''property coverage'''''; 
: приходит сообщение, когда Свойство/Утверждение выполняется успешьно и отчет показывает все свойства/утверждения, которые не были покрыты.

<!-- * Properties with implication ('''|=>''', '''|->''') are very convenient in '''''assert'''''ions, but not so much in '''''covers'''''.-->
: ('''''Vacuous pass''' — situation when implication antecedent is false — avoids false alarms in assertions, but triggers '''false positives in covers''''')

* Свойства/Утверждения с импликацией ('''|=>''', '''|->''') являются очень удобными в  '''''assert'''''ions (утверждениях), но не очень подходящими для '''''covers''''' (покрытия).
: '''''Vacuous pass''' — ситуация, когда мипликация предыдущего шага является ложным — ............

=== Design Example===

* Quote from the design specification:

: '''''Signal DVALID should be activated 3 to 5 clock cycles after activation of ACK and 2 to 4 clock cycles before deactivation of ACK.'''''
: '''''DVALID should remain active at least 2 clock cycles after deactivation of ACK.'''''

* First phase of the property:
:: '''<tt><big>{ rose(ACK) : (ACK='1')[*3 to 5] }</big></tt>'''

* Second phase:
:: '''<tt><big>{ rose(DVALID) : ((ACK and DVALID)='1')[*2 to 4] }</big></tt>'''
: or even
:: '''<tt><big>{ rose(DVALID) : (DVALID='1')[*2 to 4] }</big></tt>'''

* Third, final phase:
:: '''<tt><big>{ fell(ACK) : (DVALID='1')[*2 to inf] }</big></tt>'''

=== Пример проекта – продолжение ===

<!-- * We can inject PSL code into '''''special comments''''' in VHDL; 
: this way it will not interfere with synthesis and similar applications.-->
* Можно вставлять PSL код в '''''специальные комментарии''''' в VHDL;
: таким образом, этот код не будет оказывать влияния на синтез и похожие программы.
<!-- 
*We can define 3 '''''sequences''''' to represent 3 phases of our property.
*Final '''''property''''' definition concatenates those 3 sequences.
*Labeled '''''cover''''' directive tells simulator how to check property.

-->* Можно задать 3 '''''последовательности (sequences)'''''  для предстваления трёх фаз задаваемого свойства.
* Конечное описания  '''''свойства (property)''''' объединяет эти 3 последовательности.
* Помеченная меткой директива  '''''cover''''' показывает симулятору как проверять это свойство.

::{|
|<source lang="verilog">
--@clk  rising_edge(CLK);
--@psl  sequence ack35_s is { rose(ACK) : (ACK='1')[*3 to 5] } ;
--@psl  sequence dvalid24_s is { rose(DVALID) : (DVALID='1')[*2 to 4] } ;
--@psl  sequence dvalid2inf_s is { fell(ACK) : (DVALID='1')[*2 to inf] } ;
--@psl  property ackdvalid_p is { ack35_s ; dvalid24_s ; dvalid2inf_s } ;
--@psl  ackdvalid_c: cover(ackdvalid_p) report "Sequence ACK/DVALID covered!";
</source>
|}

[[Файл:Better Coverage in VHDL ( Design Example - cont.).png|800px|center]]

=== Советы по покрытию свойств (Property Coverage Hints) ===

<!-- * Additional simulation resources are needed to check properties, so '''''do not exaggerate''''' with adding them.
-->
* Дополнительные ресурсы при моделировании необходимы для проверки свойств, поэтому, чтобы следует '''''не злоупотреблять''''' с их добавлением.

<!-- * Do not add properties describing obvious behaviors, e.g. counter counting. Malfunctions in such areas will be easy to notice in simulation.-->
* не следует добавлять свойства, описывающие очевидное поведение, например, счёт счётчика. Неисправности в таких случаях будет легко определить при моделировании.

<!-- * Add properties checking '''''critical behaviors''''', especially if they do not demonstrate immediately as the top level signal changes.-->
* {{ЖЛампа|18px}} Следует добавить свойства, проверяющие  '''''критическое поведение (critical behaviors)''''', особенно если они не демонстрируют сразу же как изменится сигнал на верхнем уровне.

<!-- * Add properties testing interaction of data coming from different blocks of the design (especially when dealing
with IP blocks).-->
* Добавить свойства, тестирующие взаимодействие данных данных, поступающих из различных блоков проекта (особенно при работе с IP-блоками).

=== Выводы ===

[[Image:Summary.png|right|150px]]

<!-- * Property coverage checks functional correctness of the design by comparing its behavior against design properties.-->
* Покрытие свойств проверяет функциональную корректность проекта с помощью сравнения его поведения по отношению к свойствам проекта.

<!-- * Property coverage requires some coding in PSL (or SVA) and proper simulator license.-->
* Покрытие свойств требует некоторого кодирования на языке PSL (или SVA) и соответствующей лицензии для моделирования.

<!-- * 100% property coverage says that all properties you have specified were exercised, so choose them wisely.-->
* 100% покрытие свойств говорит о том, что все свойства, которые вы задали, были выполнены, так что выбирайте их разумно.

<!-- * Less than 100% property coverage means that your design behavior does not meet design specification requirements!-->
* Менее чем 100% покрытия свойств означает то, что поведение проекта не соответствует требованиям спецификации проекта! 

<!-- * Properties work in formal verification, too.-->
* Свойства работают также при формальной верификации.

== Smart Functional Coverage==
How OS-VVM Does It Better in VHDL


=== Почему функциональное покрытие ===
<!-- 
* Sometimes coverage goal is hard to express in terms of behavior;
: it may be easier to specify using values of design variables.

* Let’s consider the following example of climate controller reading data from 8-bit humidity sensor:
**  0 to 100 readouts can trigger 5 different actions,
** Readouts above 100 are illegal.
* If we define all possible values of sensor variable as below, how can we verify that all ranges were tested, but not over-tested?
-->
* Иногда цель покрытия трудно выразить в терминах поведения;
: Это может быть проще задать, используя значения переменных проекта.

* Давайте рассмотрим следующий пример климат-контроллера, читающего данные с 8-битного датчика влажности:
** показания от 0 до 100  могут вызвать 5 различных действий,
** Показания выше 100 являются ошибочными (запрещёнными).
* Если определить все возможные значения переменной датчика, как показано ниже. Как мы можем убедиться в том, что все диапазоны были протестированы, и не было избыточного тестирования?

{| class=standard align=center
! Значение <br /> диапазонов || от 0 до 9 || от 10 до 29 || от 30 до 70 || от 71 до 90 || от 91 до 100 || от 101 до 255 
|-
! Статус
| Too_Low || Low || Normal || High || Too_High || Illegal 
|}


<center>{{Кр|'''''Необходимо функционально покрытие (Functional Coverage)!'''''}}</center>

=== Покрытие корзин (Bins) ===


{| class=standard align=center
! Value Range || 0 to 9 ||  10 to 29 || 30 to 70 || 71 to 90 || 91 to 100 || 101 to 255 
|-
! Status
| Too_Low || Low || Normal || High || Too_High || Illegal
|}

<!-- * '''''Functional coverage''''' counts values of design variable according to previously defined '''''bins''''' – groups of values that have special meaning in the design.-->
* '''''Функциональное покрытие (Functional coverage)''''' подсчитывает значения переменных проекта по заранее определённым  '''''корзинам (bins)''''' — группам значений, которые имеют специальное значение в проекте.

<!-- * Bins using just one variable create data structure we can call '''''coverage item''''' or '''''coverage point''''', e.g. 6 bins for our humidity sensor variable.-->
* Корзины, используя только одну переменную создают структуру данных, которая называют '''''элементом покрытия (coverage item)''''' или '''''точкой покрытия (coverage point)''''', например, 6 корзин для заданной переменной сенсора влажности.

<!-- * We can create '''''cross coverage bins''''' combining values of multiple variables to get '''''cross coverage item'''''.-->
* Можно создать '''''корзины перекрёстного покрытия (cross coverage bins)''''' совмещающие значения нескольких переменных, чтобы получить '''''элемент перекрёстного покрытия (cross coverage item)'''''.

* If we have '''''action''''' variable in our climate control design with values {{Зел|Idle}}, {{Зел|Humidify}}, {{Зел|Dehumidify}}, {{Зел|Alarm}} we can create bins like this: ({{Кр|Low}}, {{Зел|Humidify}}), ({{Кр|Normal}}, {{Зел|Idle}}), ({{Кр|High}}, {{Зел|Dehumidify}}), ({{Кр|Illegal}}, {{Зел|Alarm}}), etc.

* Если есть  '''''действующая/активная (action)''''' переменная в приведённом проекте климат-контроля со значениями  {{Зел|Idle}}, {{Зел|Humidify}}, {{Зел|Dehumidify}}, {{Зел|Alarm}} мы можем создать корзины как следующие: ({{Кр|Low}}, {{Зел|Humidify}}), ({{Кр|Normal}}, {{Зел|Idle}}), ({{Кр|High}}, {{Зел|Dehumidify}}), ({{Кр|Illegal}}, {{Зел|Alarm}}), и т.д.

<!-- * Bins can count hits, trigger errors or be ignored during simulation.-->
* Корзины могу считать отсчеты, защёлкивать ошибки или могут игнорироваться во время моделирования.

=== Функционально покрытие (ФП) и Рандомизация(Randomization) ===

<!-- * '''''Functional coverage''''' can work alone, but it really shines when combined with '''''constrained random stimulus'''''.-->
* '''''Функциональное покрытие (Functional coverage)''''' может работать самостоятельно, но это наиболее удобно при совмещении с '''''constrained random stimulus'''''.

* In our humidity sensor example, we can randomly generate readouts and stop simulation when each bin was hit at least once; this way we complete tests much faster than in the case of scanning through all possible sensor readouts.

* Some languages have elaborate constraint system for random variables that requires dedicated constraint solver and works independently from functional coverage.

* What if we could have live feedback coming from the FC engine that controls randomization?


<!-- Функциональное покрытие может работать в одиночку, но это действительно сияет, когда в сочетании с ограниченным случайных стимулов.

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

     Некоторые языки имеют сложную систему ограничений для случайных величин, что требует выделенного Решатель ограничений и работает независимо от функционального освещения.

     Что, если мы могли бы иметь живую обратную связь приходя от двигателя FC, который управляет рандомизации?-->

=== Smart Functional Coverage ===

* '''''Open Source VHDL Verification Methodology''''' (OS-VVM*) introduced to VHDL the concept of '''''smart functional coverage'''''.

* '''''OS-VVM''''' contains both randomization and functional coverage packages that can work independently, but also create '''''coverage → randomization feedback''''' that enables '''''smarter''''', more efficient verification.

* Smart coverage controls randomization process to ensure that values belonging to already covered bins are no longer randomly generated.

* <small>* To learn more about OS-VVM, please watch recording of our previous webinar or visit osvvm.org.</small>

=== Smart Coverage Benefits ===

* When random number generator produces uniformly distributed values from the range '''''1..n''''', it takes approximately '''''n log(n)''''' trials to cover all values in the range. This number is even higher for non-uniform distributions.

* Smart coverage reduces the number of trials to precisely n.

* In plain language, smart coverage gives you guarantee that each value in the randomized range will show up only once.

* You can fine tune smart coverage by using different '''''randomization weights''''' for different coverage bins.


=== Smart Coverage Example ===

* Let’s say that we 100x100 display matrix that we want to test randomly so that each pixel is tested at least once.


<source lang="vhdl">
variable XYCov : CovPType;       -- coverage item object declared using
                                 -- CovPType from the OS-VVM package
variable X,Y : integer;          -- index data buffers
  . . .
XYCov.AddCross(GenBin(0,99), GenBin(0,99));  -- 100x100 bin matrix
XYCov.InitSeed(XYCov'instance_name);         -- seed for smart coverage
  . . .
while not XYCov.IsCovered loop   -- loop runs until indices covered
  wait until rising_edge(CLK);   -- sampling event detection
  (X, Y) := XYCov.RandCovPoint;  -- randomize uncovered indices
  XYCov.ICover((X, Y));          -- collect cross data
end loop;
</source>

<center>{{Кр|'''''while loop will have 10000 iterations – several thousands less than in case of ‘dumb’ randomization...'''''}}</center>

=== Summary ===

[[Image:Summary.png|right|150px]]

* Functional coverage checks correctness of the design by collecting values (or sets of values) of design variables during simulation.

* Bin definition requires sound knowledge of the design structure and functionality.

* Functional coverage requires some coding in VHDL — minimal if you use OS-VVM.

* 100% property coverage says that all bins you have specified were hit during simulation.

* Smart coverage speeds up simulation by controlling randomization dynamically.


== Conclusion==

Summary, Contact Data, Q&A


=== Which Coverage? ===

{| class=standard align=center
! Coverage Kind || Coding Required? || Tool Setup  Required? || Special  License? || Checks Code  Structure || Checks Design Behavior
|-
! Code Coverage ||  No || Yes || Yes || {{V|18px}} ||
|-
! Property Coverage || Yes || No || Yes || 
! {{V|18px}} 
|-
! Functional Coverage || Yes || No || No || 
! {{V|18px}}
|}


* As we see in the comparison table, there is no single kind of coverage that has advantages only.

* Code coverage checks code structure, but may be expensive. 

* Property coverage is excellent for checking behavior, but may be expensive, too.

* Functional coverage with OS-VVM has only one drawback – it requires some coding...

* Balanced use of those three coverage kinds should dramatically increase design quality and reduce verification time.