«…Труд избавляет человека от трех великих зол: скуки, порока, нужды…»

Coverage Cookbook/Executable Testplan Format/ru — различия между версиями

Материал из Wiki
Перейти к: навигация, поиск
(Новая страница: «{{Требуется перевод}} {{OS-VVM (Диплом) TOC‎}} A testplan is a document which captures the important features of a design and how they wi…»)
 
(→‎Требуемая структура плана)
 
(не показаны 26 промежуточных версий 2 участников)
Строка 12: Строка 12:
 
By putting an executable plan in place that captures a prioritized list of our verification intent, we are able to do the following:
 
By putting an executable plan in place that captures a prioritized list of our verification intent, we are able to do the following:
  
−
* Organize ourselves better. It is not possible to completely verify all states of a design however we can identify all critical, important and nice to have features,
+
* Organize ourselves better. It is not possible to completely verify all states of a design however we can identify all critical, important and nice to have features, then put a plan in place where we ensure that all critical and some important features are fully verified within schedule. If schedule permits, other features can be verified as well
−
then put a plan in place where we ensure that all critical and some important features are fully verified within schedule. If schedule permits, other features can be verified as well
+
* During Day to Day execution of the Verification project, an executable plan can help give you insight into current status. Progress can now be tracked instantly because you can see exactly where you are relative to what you intended to verify. You can visualize this progress against Milestones, priority of feature, or even resource
−
* During Day to Day execution of the Verification project, an executable plan can help give you insight into current status. Progress can now be tracked
+
* Helps manage function coverage closure as the project is being executed. Verification Engineers can focus their coverage closure efforts on the critical features that have been identified as holes, followed by important features and then by the nice to have features.
−
instantly because you can see exactly where you are relative to what you intended to verify. You can visualize this progress against Milestones, priority of feature, or even resource
+
−
* Helps manage function coverage closure as the project is being executed. Verification Engineers can focus their coverage closure efforts on the critical features
+
−
that have been identified as holes, followed by important features and then by the nice to have features.
+
  
 +
== Создание тестового плана ==
  
−
== Creating a Testplan ==
+
Во многих случаях характеристики будут проверены в моделировании и записаны как проверенные, используя [https://verificationacademy.com/cookbook/Coverage/Code_Coverage_Metrics покрытие кода] и [https://verificationacademy.com/cookbook/Coverage/Functional_Coverage_Metrics функциональное покрытие]. Тестовый план может также включать информацию о лаборатории и программное/аппаратное интеграционное тестирование. Для тестовых планов, которые включают в себя покрытие кода и функциональное покрытие, связь между тестовым планом и моделированием может быть автоматизирована. Чтобы выполнить тестовый план должен быть соблюден определенный формат документа. Формат, который Questa's Verification Management solution использует, описан ниже.
 +
<!-- == Creating a Testplan ==
  
−
In many cases, the features will be verified in simulation and recorded as verified using either [https://verificationacademy.com/cookbook/Coverage/Code_Coverage_Metrics code coverage] or [https://verificationacademy.com/cookbook/Coverage/Functional_Coverage_Metrics functional coverage].  The testplan can also include information about lab validation and firmware/hardware integration testing.  For testplans which include code coverage and functional coverage, the connection between the testplan and simulations can be automated.  To make the testplan executable a certain document format must be followed.  The format which Questa's Verification Management solution uses is described below.
+
In many cases, the features will be verified in simulation and recorded as verified using either [https://verificationacademy.com/cookbook/Coverage/Code_Coverage_Metrics code coverage] or [https://verificationacademy.com/cookbook/Coverage/Functional_Coverage_Metrics functional coverage].  The testplan can also include information about lab validation and firmware/hardware integration testing.  For testplans which include code coverage and functional coverage, the connection between the testplan and simulations can be automated.  To make the testplan executable a certain document format must be followed.  The format which Questa's Verification Management solution uses is described below. -->
  
 +
==  Запись тестового плана ==
 +
<!-- ==  Capturing the Testplan == -->
  
−
==  Capturing the Testplan ==
+
Гибкость является ключевым фактором, когда речь идет о подключении тестового плана к симулятору. В случае Questa Verification Management существуют несколько различных форматов исходных документов. Единственным требованием является то, чтобы исходный документ можно было экспортировать в документ XML. Например, Microsoft Word, Microsoft Excel, OpenOffice Writer, OpenOffice Calc и Adobe FrameMaker могут легко вывести XML документ, который может быть обработан и сделан исполняемым. На самом деле, вполне приемлемо  записать одну часть вашего тестового плана в Word, а другую в Excel. Эти различные секции могут быть затем объединены вместе, как описано ниже в разделе [https://verificationacademy.com/cookbook/Coverage/Executable_Testplan_Format#Re-Using_Existing_Testplans Повторное использование существующих тестовых планов].
 +
<!-- Flexibility is key when it comes to connecting a testplan to a simulator.  In Questa Verification Management's case, several different source document formats are valid.  The only requirement is that the source document must be able to be exported to an XML document.  For example, Microsoft Word, Microsoft Excel, OpenOffice Writer, OpenOffice Calc and Adobe FrameMaker can all easily output an XML document which can be processed and made executable.  In fact, it is perfectly acceptable to capture one section of your testplan in Word and another in Excel.  These different sections can then be combined together as described below in the [https://verificationacademy.com/cookbook/Coverage/Executable_Testplan_Format#Re-Using_Existing_Testplans Re-Using Existing Testplans] section. -->
  
−
Flexibility is key when it comes to connecting a testplan to a simulator. In Questa Verification Management's case, several different source document formats are valid.  The only requirement is that the source document must be able to be exported to an XML document.  For example, Microsoft Word, Microsoft Excel, OpenOffice Writer, OpenOffice Calc and Adobe FrameMaker can all easily output an XML document which can be processed and made executable.  In fact, it is perfectly acceptable to capture one section of your testplan in Word and another in Excel.  These different sections can then be combined together as described below in the [https://verificationacademy.com/cookbook/Coverage/Executable_Testplan_Format#Re-Using_Existing_Testplans Re-Using Existing Testplans] section.
+
Из различных вариантов входа таблицы являются наиболее распространенным и хорошо подходят типу данных, используемом в тестовом плане. Формат таблицы обеспечивает понятные и сжатые средства визуализации целей верификации. В остальной части этой статье будут описана необходимая информация для таблиц и как гибко добавлять дополнительную информацию для использования протяжении всего жизненного цикла тестового плана.
 +
<!-- Of the different input options, spreadsheets are the most commonly used and lend themselves very nicely to the type of data which is captured in a testplan.  The spreadsheet format provides a clean and concise means of visualizing verification intent.  The rest of this article will describe both required information needed in a spreadsheet and how to flexibly add additional information for usage throughout the testplan's life cycle. -->
  
−
Of the different input options, spreadsheets are the most commonly used and lend themselves very nicely to the type of data which is captured in a testplan. The spreadsheet format provides a clean and concise means of visualizing verification intent.  The rest of this article will describe both required information needed in a spreadsheet and how to flexibly add additional information for usage throughout the testplan's life cycle.
+
== Содержание тестового плана ==
  
 +
Запись требований к тестированию в план это процесс. Этот процесс определен в статье [https://verificationacademy.com/cookbook/Coverage/Specification_to_testplan Спецификация для тестового плана]. Процесс включает в себя тщательный анализ спецификаций, сотрудничество между архитектурными, проектными и верификационными командами и обзоры, помогающие убедиться, что ничего не упущено. Все требования, которые выходят из этого процесса должны быть записаны в тестовый план с некоторой необходимой структурой. Требуемая структура позволяет стать тестовому плану исполняемым и стать частью цикла верификации.
 +
<!-- ==  Contents of the Testplan==
  
−
==  Contents of the Testplan==
+
Capturing the requirements for testing into the plan is a process.  That process is defined in the [https://verificationacademy.com/cookbook/Coverage/Specification_to_testplan Specification to Testplan] article.  The process involves rigorous analysis of specifications, collaboration between architecture, design and verification teams and reviews to ensure nothing is missed.  All of the requirements which come out of this process need to be captured in the testplan with some required structure. The required structure allows the testplan to become executable and to become part of the verification cycle. -->
  
−
Capturing the requirements for testing into the plan is a process. That process is defined in the [https://verificationacademy.com/cookbook/Coverage/Specification_to_testplan Specification to Testplan] article.  The process involves rigorous analysis of specifications, collaboration between architecture, design and verification teams and reviews to ensure nothing is missed.  All of the requirements which come out of this process need to be captured in the testplan with some required structure.  The required structure allows the testplan to become executable and to become part of the verification cycle.
+
===  Требуемая структура плана ===
  
−
===  Required Plan Structure  ===
+
Для решения задачи верификации в Questa необходимо заполнить четыре различных параметра для записи каждого требования. Это Раздел, Название, Ссылка и Тип. Кроме того, другая информация понимается из {{Жел|box}}. Дополнительная информация по каждому требованию включает в себя Описание, Вес и Цель. Хотя эти дополнительные поля не являются обязательными, они используются в большинстве случаев. Questa's Verification Management solution также достаточно гибкая, что позволяет использовать [https://verificationacademy.com/cookbook/Coverage/Executable_Testplan_Format#User_Defined_Columns поля, определенные пользователем].
 +
 
 +
Если мы посмотрим на обычно используемый формат полей в таблице, то можно заметить, что каждое поле представляет собой столбец в таблице.
 +
<!-- ===  Required Plan Structure  ===
  
 
Questa's Verification Management solution requires four distinct pieces of information for each requirement captured.  They are Section, Title, Link and Type.  Additionally, other information is understood out of the box.  The additional information for each requirement includes a Description, a Weight and a Goal.  While these additional fields are not required, they are used the majority of the time.  Questa's Verification Management solution also has the flexibilty to allow [https://verificationacademy.com/cookbook/Coverage/Executable_Testplan_Format#User_Defined_Columns user defined fields].
 
Questa's Verification Management solution requires four distinct pieces of information for each requirement captured.  They are Section, Title, Link and Type.  Additionally, other information is understood out of the box.  The additional information for each requirement includes a Description, a Weight and a Goal.  While these additional fields are not required, they are used the majority of the time.  Questa's Verification Management solution also has the flexibilty to allow [https://verificationacademy.com/cookbook/Coverage/Executable_Testplan_Format#User_Defined_Columns user defined fields].
  
−
If we look at the typically used fields in a spreadsheet format, each field is represented by a column in the spreadsheet.
+
If we look at the typically used fields in a spreadsheet format, each field is represented by a column in the spreadsheet. -->
  
−
<div><div> [[Файл:300px-Tplan_basic.png|frame|center|Plan Structure]]</div></div>
+
<div><div> [[Файл:300px-Tplan_basic.png|frame|center|Структура плана]]</div></div>
  
−
Each row in the spreadsheet corresponds to a requirement captured during the testplan creation process.  Each column has specific meaning in Questa's Verification Management solution.
+
Каждая строка в таблице соответствует требованию записанному в процессе создания тестового плана. Каждая колонка имеет особое значение в Questa's Verification Management solution.
 +
<!-- Each row in the spreadsheet corresponds to a requirement captured during the testplan creation process.  Each column has specific meaning in Questa's Verification Management solution. -->
  
−
====  Section and Title  ====
+
==== Раздел и название ====
 +
 
 +
Столбцы '''Раздел ''' и '''Название''' используются совместно для создания имен и иерархии в тестовом плане.
 +
 
 +
'''Раздел ''' 
 +
 
 +
Столбец раздел это, как правило, число, используемое для создания иерархии в рамках тестового плана и группы связанных с ним элементов тестового плана вместе в отношениями родитель/ребенок. В таблицах, пользователь отвечает за ввод этой информации. Обычно вы начнете нумерацию разделов с номера '1 'и продолжает последовательно. Подраздел этой секции будут обозначаться как "1,1" и так далее, где каждый дополнительный уровень иерархии будет представлен добавлением "." между номерами разделов.
 +
 
 +
'''Название'''
 +
 
 +
Столбец название используется для названий требований или особенностей проекта, которые должны быть верифицированы. Это название раздела тестового плана, которое появятся в Questa. Выбранное здесь имя должно иметь такое значение, чтобы оно было видимым во всем  потоке.
 +
 
 +
Когда тестовый план экстрагируется Questa, он использует информацию из столбцов '''Раздел''' и '''Название''' для создания иерархического имени и уникальную метку для каждой строки тестового плана. Например, '''Раздел 1.1''' будет иметь иерархическое имя '''/testplan/Parent_1/Child_1'''.
 +
<!-- ====  Section and Title  ====
  
 
The '''Section''' and '''Title''' columns work in conjunction to create the naming and hierarchy within the testplan.
 
The '''Section''' and '''Title''' columns work in conjunction to create the naming and hierarchy within the testplan.
  
−
'''Section   '''   
+
'''Section'''   
  
 
The Section column, usually a number, is used to create hierarchy within the testplan and group related testplan items together in a parent / child relationship. In spreadsheets, the user is responsible for entering this information. Typically you will start numbering sections with the number '1' and continuing sequentially. A sub-section beneath that section would then be numbered "1.1" and so on, where each additional level of hierarchy would be represented by the addition of a "." between section numbers.
 
The Section column, usually a number, is used to create hierarchy within the testplan and group related testplan items together in a parent / child relationship. In spreadsheets, the user is responsible for entering this information. Typically you will start numbering sections with the number '1' and continuing sequentially. A sub-section beneath that section would then be numbered "1.1" and so on, where each additional level of hierarchy would be represented by the addition of a "." between section numbers.
Строка 58: Строка 80:
 
The title column captures the name of the requirement or design feature to be verified. This is the name of the testplan section that will appear within Questa.  The name chosen here should have meaning as it will be visible through the tool flow.
 
The title column captures the name of the requirement or design feature to be verified. This is the name of the testplan section that will appear within Questa.  The name chosen here should have meaning as it will be visible through the tool flow.
  
−
When the testplan is extracted by Questa, it uses the information in the '''Section''' and '''Title''' columns to create a hierarchical name and unique tag for each row of the testplan. For example, given the simple testplan example above, '''Section 1.1''' would have a hierarchical name '''/testplan/Parent_1/Child_1'''.
+
When the testplan is extracted by Questa, it uses the information in the '''Section''' and '''Title''' columns to create a hierarchical name and unique tag for each row of the testplan. For example, given the simple testplan example above, '''Section 1.1''' would have a hierarchical name '''/testplan/Parent_1/Child_1'''. -->
  
−
====  Description  ====
+
====  Описание ====
  
−
The description column allows for more detail to be added to the spreadsheet. This could include references to other documentation to allow engineers to gather more information or it could be a simple explanation as to why the requirement exists. Any text can be captured in this column. It is technically optional, but in practice a requirement captured in a testplan should have an entry in the description column.
+
Столбец описание позволяет добавлять в таблицу более подробную информацию. Это могут быть ссылки на другие документы, чтобы позволить инженерам собирать больше информации или это может быть простое объяснение, почему эти требование нужны. Любой текст может быть записан в эту колонку. Технически это опционально, но на практике требование в тестовый план должны быть записаны в столбце Описание.
 +
<!-- ====  Description  ====
  
−
====  Link and Type ====
+
The description column allows for more detail to be added to the spreadsheet. This could include references to other documentation to allow engineers to gather more information or it could be a simple explanation as to why the requirement exists. Any text can be captured in this column. It is technically optional, but in practice a requirement captured in a testplan should have an entry in the description column. -->
  
−
The '''Link''' and '''Type''' columns are used to specify the code or functional coverage items that will be linked to the requirement. A requirement can be linked to multiple different coverage metrics, including metrics of different types. Questa supports linking to Covergroups, Coverpoints, Crosses, Assertions, Cover Directives, Directed tests and code coverage metric types. These columns also allow other testplans to be imported as described in the [https://verificationacademy.com/cookbook/Coverage/Executable_Testplan_Format#Re-Using_Existing_Testplans Re-Using Existing Testplans] section.
+
====  Ссылка и тип ====
  
−
'''Link'''   
+
Столбцы Ссылка и тип используются для указания покрытия кода или функционального покрытия элементов, которые будут связаны с требованиями. Требование может быть связано с несколькими различными метриками покрытия, включая метрики различных типов. Questa поддерживает ссылки на группы покрытия, точки покрытия, пересечения, утверждения, директивы покрытия, направленные тесты и типы  метрик  покрытия кода. Эти столбцы также позволяют импортировать другие тестовые планы, как описано в разделе [[#Повторное использование существующих тестовых планов|Повторное использование существующих тестовых планов]].
 +
<!-- ====  Link and Type  ====
  
−
This column is where you specify the name of the actual coverage object(s) in the coverage database that is linked to this respective testplan item. This could include a specific covergroup instance, an assertion, etc.
+
The '''Link''' and '''Type''' columns are used to specify the code or functional coverage items that will be linked to the requirement. A requirement can be linked to multiple different coverage metrics, including metrics of different types. Questa supports linking to Covergroups, Coverpoints, Crosses, Assertions, Cover Directives, Directed tests and code coverage metric types.  These columns also allow other testplans to be imported as described in the [https://verificationacademy.com/cookbook/Coverage/Executable_Testplan_Format#Re-Using_Existing_Testplans Re-Using Existing Testplans] section. -->
  
−
'''Type'''
+
'''Ссылка'''   
 +
 
 +
Это столбец, в котором вы указываете имя текущего объекта покрытия в базе данных покрытия, которая связана с соответствующий элементом тестового плана. Это может включать определенную группу покрытия, утверждение и т.д.
 +
<!-- '''Link'''   
 +
 
 +
This column is where you specify the name of the actual coverage object(s) in the coverage database that is linked to this respective testplan item.  This could include a specific covergroup instance, an assertion, etc. -->
 +
 
 +
'''Тип'''
 +
 
 +
Это столбец, в котором вы указываете тип объекта покрытия, указанного в столбце '''Ссылка'''.
 +
 
 +
Вместе информация столбцов '''Ссылка''' и '''Тип''' используется для эффективного поиска соответствующих объектов покрытия в базе данных покрытия и создания связи между тестовым планом и определенными объектами покрытия. Эти столбцы дают возможность тестовому плану стать исполняемым.
 +
<!-- '''Type'''
  
 
This column is where you specify the type of the coverage object you specified in the '''Link''' column.
 
This column is where you specify the type of the coverage object you specified in the '''Link''' column.
  
−
Together, the '''Link''' and '''Type''' column information is used to find the corresponding coverage objects in the coverage database efficiently and create the links between the testplan and the specified coverage objects.  These columns enable the testplan to become executable.
+
Together, the '''Link''' and '''Type''' column information is used to find the corresponding coverage objects in the coverage database efficiently and create the links between the testplan and the specified coverage objects.  These columns enable the testplan to become executable. -->
 +
 
 +
====  Вес ====
 +
 
 +
В столбец Вес записывается целое число, которое отражает относительную важность текущего элемента тестового плана среди аналогичных элементов, в его родительский раздел тестового плана. Если не указано, то по умолчанию он равен 1. Когда покрытие для тестового плана вычисляется в Questa, которая использует "средневзвешенной" алгоритм расчета, эти веса учитывается. Для получения дополнительной информации о том, как Questa рассчитывает покрытие тестового плана смотрите документации на Questa Verification Management.
  
−
====  Weight  ====
+
Кроме того, столбец Вес может быть использован для исключения частей тестового плана указанием его значения 0 для раздела/строки тестового плана, которые должны быть исключены.
 +
<!-- ====  Weight  ====
  
 
The weight column captures an integer number that reflects the relative importance of the current testplan item amongst its siblings, to its parent testplan section. The default is 1 if not specified. When coverage for the testplan is being calculated by Questa, which uses a "weighted-average" calculation algorithm, these weights are taken into account. For more information about how Questa calculates tesplan coverage please see Questa documentation on Verification Management.
 
The weight column captures an integer number that reflects the relative importance of the current testplan item amongst its siblings, to its parent testplan section. The default is 1 if not specified. When coverage for the testplan is being calculated by Questa, which uses a "weighted-average" calculation algorithm, these weights are taken into account. For more information about how Questa calculates tesplan coverage please see Questa documentation on Verification Management.
  
−
Additionally, the weight column can be used to exclude portions of a testplan by specifying a value of 0 for the testplan section / item row that need to be excluded.
+
Additionally, the weight column can be used to exclude portions of a testplan by specifying a value of 0 for the testplan section / item row that need to be excluded. -->
  
−
====  Goal  ====
+
====  Цель ====
  
−
This column specifies the verification objective for a particular testplan section. Legal values range from 1 to 100, with the default being 100 if not specified. Questa uses this information to determine the point at which a testplan section / item is deemed to be covered. It does not alter how coverage is calculated.
+
В этом столбце указывается цель верификации для конкретного раздела тестового плана. Допустимые значения от 1 до 100, если не задано, то по умолчанию составляет 100. Questa использует эту информацию, чтобы определить точку, в которой раздел/элемент  тестового плана считается покрытым. Это не зависит от того, каким образом рассчитывается покрытие.
 +
<!-- ====  Goal  ====
  
−
===  Other Columns Understood By Questa===
+
This column specifies the verification objective for a particular testplan section. Legal values range from 1 to 100, with the default being 100 if not specified. Questa uses this information to determine the point at which a testplan section / item is deemed to be covered. It does not alter how coverage is calculated. -->
  
−
There are other special purpose columns which can be used in a coverage testplan. These columns are all optional however when they are present Questa leverages their content.
+
===  Другие столбцы, используемые в Questa ===
  
−
'''Path'''
+
Есть и другие специальные столбцы, которые могут быть использованы в покрытия тестового плана. Эти столбцы не являются обязательными, но если они присутствуют, то Questa использует их содержание.
 +
<!-- ===  Other Columns Understood By Questa ===
  
−
When linking to a specific instance of a covergroup, two options exist.  Optionally, the full hierarchical path to the covergroup could be added into the '''Link''' column.  This works very well if only one coverge item is being accessed at that level of design hierarchy.  If however, multiple coverage items are being linked to in the same level of design hierarchy, the '''Path''' column allows for the specification of the design path which will be prepended to the entry in the link column to create a fully qualified reference.
+
There are other special purpose columns which can be used in a coverage testplan. These columns are all optional however when they are present Questa leverages their content. -->
  
−
'''Unimplemented'''
+
'''Путь'''
  
−
As testplans are being defined, it is common for requirements to be captured where corresponding coverage items don't yet exist in a testbench or design. To handle this situation, a requirement can be maked as unimplemented by either adding a value of 'yes' or a number greater than zero to the '''Unimplmented''' column. This will cause testplan coverage calculations to accurately reflect that a requirement exists which is not yet covered by showing zero coverage for that requirement. By default, it is assumed that coverage for a requirement is implemented unless this column is specified.
+
При ссылке на конкретную группу покрытия, существует два варианта. Опционально полный иерархический путь к группе покрытия может быть добавлен в столбец '''Ссылка'''. Это работает очень хорошо, если только один элемент покрытия осуществляет доступ на этом уровне иерархии проекта. Однако, если несколько элементов покрытия в настоящее время связаны с таким же уровнем иерархии проекта, столбец '''Путь''' позволяет создать полностью квалифицированные ссылки для пути спецификации проекта, который будет добавлен в запись в столбце ссылка.
 +
<!-- '''Path'''
  
−
===  User Defined Columns ===
+
When linking to a specific instance of a covergroup, two options exist. Optionally, the full hierarchical path to the covergroup could be added into the '''Link''' column.  This works very well if only one coverge item is being accessed at that level of design hierarchy.  If however, multiple coverage items are being linked to in the same level of design hierarchy, the '''Path''' column allows for the specification of the design path which will be prepended to the entry in the link column to create a fully qualified reference. -->
  
−
To ensure users have the flexibility to record other vital information related to a requirement, Questa's Verification Management solution allows user defined columns to be created as well.  This allows for the specification of anything that needs to be tracked.  It can also give you better visibility into the verification process.  Some columns which are routinely added include which engineer is responsible for testing a requirement and what the priority of the requirement or design feature is. 
+
'''Нереализованные'''
  
−
These added columns help to answer questions such as:
+
Когда определяются тестовые планы, для требований является распространенным записываться туда, где соответствующие элементы покрытия еще не существует в тестовой программе или проекте. Чтобы справиться с этой ситуацией, требование может быть отмечено как нереализованное, добавив значение 'да' или число больше нуля в колонке '''Нереализованные'''. Это приведет к тому, что расчеты покрытия тестового плана точно отражают, что существует требование, которое еще не покрыто, показывая нулевое покрытие этого требования. По умолчанию предполагается, что покрытие требования реализовано, если этот столбец указан.
 +
<!-- '''Unimplemented'''
 +
 
 +
As testplans are being defined, it is common for requirements to be captured where corresponding coverage items don't yet exist in a testbench or design.  To handle this situation, a requirement can be maked as unimplemented by either adding a value of 'yes' or a number greater than zero to the '''Unimplmented''' column.  This will cause testplan coverage calculations to accurately reflect that a requirement exists which is not yet covered by showing zero coverage for that requirement.  By default, it is assumed that coverage for a requirement is implemented unless this column is specified. -->
 +
 
 +
===  Столбцы определенные пользователем  ===
 +
 
 +
Для обеспечения пользователям возможности записывать другую важную информацию, связанную с требованием, Questa's Verification Management solution позволяет использовать столбцы определенные пользователем. Это позволяет спецификации отслеживать все, что нужно. Он также может дать вам лучшую видимость в процессе верификации. Некоторые столбцы, которые обычно добавляют, включают требования, за которые инженер отвечает при тестировании и то, что является приоритетом требований или особенностью проекта.
 +
<!-- ===  User Defined Columns  ===
 +
 
 +
To ensure users have the flexibility to record other vital information related to a requirement, Questa's Verification Management solution allows user defined columns to be created as well.  This allows for the specification of anything that needs to be tracked.  It can also give you better visibility into the verification process.  Some columns which are routinely added include which engineer is responsible for testing a requirement and what the priority of the requirement or design feature is. --> 
 +
 
 +
Эти дополнительные столбцы помогают ответить на такие вопросы, как:
 +
 
 +
* Что я делаю с элементами высокого приоритета моего тестового плана?
 +
* Где я относительно достижения этапов моего текущего проекта?
 +
* Что я делаю в рамках моих ресурсов?
 +
 
 +
Таблица используемая в [https://verificationacademy.com/cookbook/Coverage/System_Level_Functional_Coverage_Example#Functional_Coverage_Model_Creation:_Spreadsheets Примере функционального покрытия системного уровня] добавляет '''Владелец''' и '''Приоритет''' как столбцы определенные пользователем.
 +
<!-- These added columns help to answer questions such as:
  
 
* How am I doing on my high priority testplan items?
 
* How am I doing on my high priority testplan items?
Строка 110: Строка 173:
 
* How are my doing in terms of my resources?
 
* How are my doing in terms of my resources?
  
−
The spreadsheet used in the [https://verificationacademy.com/cookbook/Coverage/System_Level_Functional_Coverage_Example#Functional_Coverage_Model_Creation:_Spreadsheets System Level Functional Coverage Example] adds '''Owner''' and '''Priority''' user defined columns.
+
The spreadsheet used in the [https://verificationacademy.com/cookbook/Coverage/System_Level_Functional_Coverage_Example#Functional_Coverage_Model_Creation:_Spreadsheets System Level Functional Coverage Example] adds '''Owner''' and '''Priority''' user defined columns. -->
−
 
+
  
−
==  Re-Using Existing Testplans ==
+
==  Повторное использование существующих тестовых планов ==
  
−
Often it is useful to be able to make use of existing testplan's in other contexts. A few common situations where this becomes useful are:
+
Часто бывает полезно иметь возможность использовать существующие тестовые планы в другом контексте. Несколько общих ситуациях, когда это бывает полезным:
 +
<!-- Often it is useful to be able to make use of existing testplan's in other contexts. A few common situations where this becomes useful are: -->
  
−
* Testplans were developed at the block level and need to be incorporated into the chip or system level testplan.
+
* Тестовые планы были разработаны на уровне блоков и должны быть включены в чип или тестовый план системного уровня.
 +
* Тестовый план поставляется с частью IP или с верификацией IP. Например, протокол определенной верификации IP должен содержать полный тестовый план протокола, для обеспечения полной верификации протокола.
 +
* Включение автоматически сгенерированных тестовых планов в наши подсистемы или в план SoC уровня. Например, для контроля над мощностью симуляций, симуляторы должны быть в состоянии создать тестовый план, чтобы быть полностью готовым к любому сценарию.
 +
* Объединение тестовых планов записанных различным инструментарием  редактирования в один главный тестовый план.
 +
<!-- * Testplans were developed at the block level and need to be incorporated into the chip or system level testplan.
 
* A testplan is delivered with a piece of IP or verification IP.  For example, protocol specific Verification IP should contain a complete protocol testplan to ensure a protocol is completely verified.
 
* A testplan is delivered with a piece of IP or verification IP.  For example, protocol specific Verification IP should contain a complete protocol testplan to ensure a protocol is completely verified.
 
* Incorporate auto generated testplans into our sub-system or SoC level plan.  For example, for power aware simulations simulators should be able to create a testplan to ensure the power scenarios are completely
 
* Incorporate auto generated testplans into our sub-system or SoC level plan.  For example, for power aware simulations simulators should be able to create a testplan to ensure the power scenarios are completely
−
* Combine testplans captured by different editing tools into one master testplan.
+
* Combine testplans captured by different editing tools into one master testplan. -->
  
 
In these situations, existing testplans can be hierarchically imported into the top-level testplan being created, allowing for visualization of the full depth of the verification effort.
 
In these situations, existing testplans can be hierarchically imported into the top-level testplan being created, allowing for visualization of the full depth of the verification effort.

Текущая версия на 21:55, 20 мая 2013

Aqua pencil.png Эта статья требует перевода на русский язык
Проект Диплом
Литература
Coverage Cookbook (en)
OVM методология
* OS-VVM *

A testplan is a document which captures the important features of a design and how they will be verified.

Содержание

Motivation for Creating a Testplan

Functional Verification has been described as a major challenge in SoC Designs with many citing inadequate visibility into the verification process as a major factor contributing to this challenge. This lack of visibility impacts design quality, schedule predictability and cost (resource/tools/infrastructure). Typical questions that verification managers need answers to are: When are we done with verification? Are all critical requirements of the system verified? Are we using all verification resources adequately to meet project schedules?

By putting an executable plan in place that captures a prioritized list of our verification intent, we are able to do the following:

  • Organize ourselves better. It is not possible to completely verify all states of a design however we can identify all critical, important and nice to have features, then put a plan in place where we ensure that all critical and some important features are fully verified within schedule. If schedule permits, other features can be verified as well
  • During Day to Day execution of the Verification project, an executable plan can help give you insight into current status. Progress can now be tracked instantly because you can see exactly where you are relative to what you intended to verify. You can visualize this progress against Milestones, priority of feature, or even resource
  • Helps manage function coverage closure as the project is being executed. Verification Engineers can focus their coverage closure efforts on the critical features that have been identified as holes, followed by important features and then by the nice to have features.

Создание тестового плана

Во многих случаях характеристики будут проверены в моделировании и записаны как проверенные, используя покрытие кода и функциональное покрытие. Тестовый план может также включать информацию о лаборатории и программное/аппаратное интеграционное тестирование. Для тестовых планов, которые включают в себя покрытие кода и функциональное покрытие, связь между тестовым планом и моделированием может быть автоматизирована. Чтобы выполнить тестовый план должен быть соблюден определенный формат документа. Формат, который Questa's Verification Management solution использует, описан ниже.

Запись тестового плана

Гибкость является ключевым фактором, когда речь идет о подключении тестового плана к симулятору. В случае Questa Verification Management существуют несколько различных форматов исходных документов. Единственным требованием является то, чтобы исходный документ можно было экспортировать в документ XML. Например, Microsoft Word, Microsoft Excel, OpenOffice Writer, OpenOffice Calc и Adobe FrameMaker могут легко вывести XML документ, который может быть обработан и сделан исполняемым. На самом деле, вполне приемлемо записать одну часть вашего тестового плана в Word, а другую в Excel. Эти различные секции могут быть затем объединены вместе, как описано ниже в разделе Повторное использование существующих тестовых планов.

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

Содержание тестового плана

Запись требований к тестированию в план это процесс. Этот процесс определен в статье Спецификация для тестового плана. Процесс включает в себя тщательный анализ спецификаций, сотрудничество между архитектурными, проектными и верификационными командами и обзоры, помогающие убедиться, что ничего не упущено. Все требования, которые выходят из этого процесса должны быть записаны в тестовый план с некоторой необходимой структурой. Требуемая структура позволяет стать тестовому плану исполняемым и стать частью цикла верификации.

Требуемая структура плана

Для решения задачи верификации в Questa необходимо заполнить четыре различных параметра для записи каждого требования. Это Раздел, Название, Ссылка и Тип. Кроме того, другая информация понимается из box. Дополнительная информация по каждому требованию включает в себя Описание, Вес и Цель. Хотя эти дополнительные поля не являются обязательными, они используются в большинстве случаев. Questa's Verification Management solution также достаточно гибкая, что позволяет использовать поля, определенные пользователем.

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

Структура плана

Каждая строка в таблице соответствует требованию записанному в процессе создания тестового плана. Каждая колонка имеет особое значение в Questa's Verification Management solution.

Раздел и название

Столбцы Раздел и Название используются совместно для создания имен и иерархии в тестовом плане.

Раздел

Столбец раздел это, как правило, число, используемое для создания иерархии в рамках тестового плана и группы связанных с ним элементов тестового плана вместе в отношениями родитель/ребенок. В таблицах, пользователь отвечает за ввод этой информации. Обычно вы начнете нумерацию разделов с номера '1 'и продолжает последовательно. Подраздел этой секции будут обозначаться как "1,1" и так далее, где каждый дополнительный уровень иерархии будет представлен добавлением "." между номерами разделов.

Название

Столбец название используется для названий требований или особенностей проекта, которые должны быть верифицированы. Это название раздела тестового плана, которое появятся в Questa. Выбранное здесь имя должно иметь такое значение, чтобы оно было видимым во всем потоке.

Когда тестовый план экстрагируется Questa, он использует информацию из столбцов Раздел и Название для создания иерархического имени и уникальную метку для каждой строки тестового плана. Например, Раздел 1.1 будет иметь иерархическое имя /testplan/Parent_1/Child_1.

Описание

Столбец описание позволяет добавлять в таблицу более подробную информацию. Это могут быть ссылки на другие документы, чтобы позволить инженерам собирать больше информации или это может быть простое объяснение, почему эти требование нужны. Любой текст может быть записан в эту колонку. Технически это опционально, но на практике требование в тестовый план должны быть записаны в столбце Описание.

Ссылка и тип

Столбцы Ссылка и тип используются для указания покрытия кода или функционального покрытия элементов, которые будут связаны с требованиями. Требование может быть связано с несколькими различными метриками покрытия, включая метрики различных типов. Questa поддерживает ссылки на группы покрытия, точки покрытия, пересечения, утверждения, директивы покрытия, направленные тесты и типы метрик покрытия кода. Эти столбцы также позволяют импортировать другие тестовые планы, как описано в разделе Повторное использование существующих тестовых планов.

Ссылка

Это столбец, в котором вы указываете имя текущего объекта покрытия в базе данных покрытия, которая связана с соответствующий элементом тестового плана. Это может включать определенную группу покрытия, утверждение и т.д.

Тип

Это столбец, в котором вы указываете тип объекта покрытия, указанного в столбце Ссылка.

Вместе информация столбцов Ссылка и Тип используется для эффективного поиска соответствующих объектов покрытия в базе данных покрытия и создания связи между тестовым планом и определенными объектами покрытия. Эти столбцы дают возможность тестовому плану стать исполняемым.

Вес

В столбец Вес записывается целое число, которое отражает относительную важность текущего элемента тестового плана среди аналогичных элементов, в его родительский раздел тестового плана. Если не указано, то по умолчанию он равен 1. Когда покрытие для тестового плана вычисляется в Questa, которая использует "средневзвешенной" алгоритм расчета, эти веса учитывается. Для получения дополнительной информации о том, как Questa рассчитывает покрытие тестового плана смотрите документации на Questa Verification Management.

Кроме того, столбец Вес может быть использован для исключения частей тестового плана указанием его значения 0 для раздела/строки тестового плана, которые должны быть исключены.

Цель

В этом столбце указывается цель верификации для конкретного раздела тестового плана. Допустимые значения от 1 до 100, если не задано, то по умолчанию составляет 100. Questa использует эту информацию, чтобы определить точку, в которой раздел/элемент тестового плана считается покрытым. Это не зависит от того, каким образом рассчитывается покрытие.

Другие столбцы, используемые в Questa

Есть и другие специальные столбцы, которые могут быть использованы в покрытия тестового плана. Эти столбцы не являются обязательными, но если они присутствуют, то Questa использует их содержание.

Путь

При ссылке на конкретную группу покрытия, существует два варианта. Опционально полный иерархический путь к группе покрытия может быть добавлен в столбец Ссылка. Это работает очень хорошо, если только один элемент покрытия осуществляет доступ на этом уровне иерархии проекта. Однако, если несколько элементов покрытия в настоящее время связаны с таким же уровнем иерархии проекта, столбец Путь позволяет создать полностью квалифицированные ссылки для пути спецификации проекта, который будет добавлен в запись в столбце ссылка.

Нереализованные

Когда определяются тестовые планы, для требований является распространенным записываться туда, где соответствующие элементы покрытия еще не существует в тестовой программе или проекте. Чтобы справиться с этой ситуацией, требование может быть отмечено как нереализованное, добавив значение 'да' или число больше нуля в колонке Нереализованные. Это приведет к тому, что расчеты покрытия тестового плана точно отражают, что существует требование, которое еще не покрыто, показывая нулевое покрытие этого требования. По умолчанию предполагается, что покрытие требования реализовано, если этот столбец указан.

Столбцы определенные пользователем

Для обеспечения пользователям возможности записывать другую важную информацию, связанную с требованием, Questa's Verification Management solution позволяет использовать столбцы определенные пользователем. Это позволяет спецификации отслеживать все, что нужно. Он также может дать вам лучшую видимость в процессе верификации. Некоторые столбцы, которые обычно добавляют, включают требования, за которые инженер отвечает при тестировании и то, что является приоритетом требований или особенностью проекта.

Эти дополнительные столбцы помогают ответить на такие вопросы, как:

  • Что я делаю с элементами высокого приоритета моего тестового плана?
  • Где я относительно достижения этапов моего текущего проекта?
  • Что я делаю в рамках моих ресурсов?

Таблица используемая в Примере функционального покрытия системного уровня добавляет Владелец и Приоритет как столбцы определенные пользователем.

Повторное использование существующих тестовых планов

Часто бывает полезно иметь возможность использовать существующие тестовые планы в другом контексте. Несколько общих ситуациях, когда это бывает полезным:

  • Тестовые планы были разработаны на уровне блоков и должны быть включены в чип или тестовый план системного уровня.
  • Тестовый план поставляется с частью IP или с верификацией IP. Например, протокол определенной верификации IP должен содержать полный тестовый план протокола, для обеспечения полной верификации протокола.
  • Включение автоматически сгенерированных тестовых планов в наши подсистемы или в план SoC уровня. Например, для контроля над мощностью симуляций, симуляторы должны быть в состоянии создать тестовый план, чтобы быть полностью готовым к любому сценарию.
  • Объединение тестовых планов записанных различным инструментарием редактирования в один главный тестовый план.

In these situations, existing testplans can be hierarchically imported into the top-level testplan being created, allowing for visualization of the full depth of the verification effort.

When creating such a testplan, the Type column will be given a value of "XML" to inform Questa that this section does not reference a coverage object, but rather it refers to another testplan document. The Link column will be used to specify the actual testplan file that contains the testplan being imported (via either a relative or full-path to the file).

Источник — «http://simhard.com/wiki/index.php?title=Coverage_Cookbook/Executable_Testplan_Format/ru&oldid=2553»