Coverage Cookbook/Executable Testplan Format/ru - История изменений

Vasiliy Torubarov: /* Требуемая структура плана */

2013-05-20T17:55:40Z

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

Vasiliy Torubarov: /* Требуемая структура плана */

2013-05-20T17:52:07Z

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

Vasiliy Torubarov: /* Повторное использование существующих тестовых планов */

2013-04-23T15:56:52Z

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

Vasiliy Torubarov: /* Содержание тестового плана */

2013-04-14T19:09:51Z

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

Vasiliy Torubarov: /* Запись тестового плана */

2013-04-14T19:08:50Z

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

Vasiliy Torubarov: /* Требуемая структура плана */

2013-04-14T19:06:25Z

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

Vasiliy Torubarov: /* Столбцы определенные пользователем */

2013-04-12T14:59:18Z

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

Vasiliy Torubarov: /* Столбцы определенные пользователем */

2013-04-12T14:58:58Z

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

Vasiliy Torubarov: /* User Defined Columns */

2013-04-12T14:58:06Z

‎User Defined Columns

Vasiliy Torubarov: /* Other Columns Understood By Questa */

2013-04-12T14:24:08Z

‎Other Columns Understood By Questa

@@ Строка 41: / Строка 41: @@
 ===   Требуемая структура плана  ===
-Для решения задачи верификации в Questa необходимо заполнить четыре различных параметра для записи каждого требования.. Это Раздел, Название, Ссылка и Тип. Кроме того, другая информация понимается из {{Жел|box}}. Дополнительная информация по каждому требованию включает в себя Описание, Вес и Цель. Хотя эти дополнительные поля не являются обязательными, они используются в большинстве случаев. Questa's Verification Management solution также достаточно гибкая, что позволяет использовать [https://verificationacademy.com/cookbook/Coverage/Executable_Testplan_Format#User_Defined_Columns поля, определенные пользователем].
+Для решения задачи верификации в Questa необходимо заполнить четыре различных параметра для записи каждого требования. Это Раздел, Название, Ссылка и Тип. Кроме того, другая информация понимается из {{Жел|box}}. Дополнительная информация по каждому требованию включает в себя Описание, Вес и Цель. Хотя эти дополнительные поля не являются обязательными, они используются в большинстве случаев. Questa's Verification Management solution также достаточно гибкая, что позволяет использовать [https://verificationacademy.com/cookbook/Coverage/Executable_Testplan_Format#User_Defined_Columns поля, определенные пользователем].
 Если мы посмотрим на обычно используемый формат полей в таблице, то можно заметить, что каждое поле представляет собой столбец в таблице.

@@ Строка 41: / Строка 41: @@
 ===   Требуемая структура плана  ===
-Questa's Verification Management solution требует четырех различных фрагментов информации для записи каждого требования. Это Раздел, Название, Ссылка и Тип. Кроме того, другая информация понимается из {{Жел|box}}. Дополнительная информация по каждому требованию включает в себя Описание, Вес и Цель. Хотя эти дополнительные поля не являются обязательными, они используются в большинстве случаев. Questa's Verification Management solution также достаточно гибкая, что позволяет использовать [https://verificationacademy.com/cookbook/Coverage/Executable_Testplan_Format#User_Defined_Columns поля, определенные пользователем].
+Для решения задачи верификации в Questa необходимо заполнить четыре различных параметра для записи каждого требования.. Это Раздел, Название, Ссылка и Тип. Кроме того, другая информация понимается из {{Жел|box}}. Дополнительная информация по каждому требованию включает в себя Описание, Вес и Цель. Хотя эти дополнительные поля не являются обязательными, они используются в большинстве случаев. Questa's Verification Management solution также достаточно гибкая, что позволяет использовать [https://verificationacademy.com/cookbook/Coverage/Executable_Testplan_Format#User_Defined_Columns поля, определенные пользователем].
 Если мы посмотрим на обычно используемый формат полей в таблице, то можно заметить, что каждое поле представляет собой столбец в таблице.

@@ Строка 177: / Строка 177: @@
 ==   Повторное использование существующих тестовых планов  ==
-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.
+* Тестовые планы были разработаны на уровне блоков и должны быть включены в чип или тестовый план системного уровня.
 * 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
-* 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.

@@ Строка 34: / Строка 34: @@
 ==  Содержание тестового плана ==
-Запись требований к тестированию в плане процесс. Этот процесс определен в статье [https://verificationacademy.com/cookbook/Coverage/Specification_to_testplan Спецификация для тестового плана]. Процесс включает в себя тщательный анализ спецификаций, сотрудничество между архитектурными, проектными и верификационными командами и обзоры, помогающие убедиться, что ничего не упущено. Все требования, которые выходят из этого процесса должны быть записаны в тестовый план с некоторой необходимой структурой. Требуемая структура позволяет стать тестовому плану исполняемым и стать частью цикла верификации.
+Запись требований к тестированию в план это процесс. Этот процесс определен в статье [https://verificationacademy.com/cookbook/Coverage/Specification_to_testplan Спецификация для тестового плана]. Процесс включает в себя тщательный анализ спецификаций, сотрудничество между архитектурными, проектными и верификационными командами и обзоры, помогающие убедиться, что ничего не упущено. Все требования, которые выходят из этого процесса должны быть записаны в тестовый план с некоторой необходимой структурой. Требуемая структура позволяет стать тестовому плану исполняемым и стать частью цикла верификации.
 <!-- ==   Contents of the Testplan==

@@ Строка 26: / Строка 26: @@
 <!-- ==   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 Повторное использование существующих тестовых планов].
+Гибкость является ключевым фактором, когда речь идет о подключении тестового плана к симулятору. В случае 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. -->

@@ Строка 50: / Строка 50: @@
 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>
 Каждая строка в таблице соответствует требованию записанному в процессе создания тестового плана. Каждая колонка имеет особое значение в Questa's Verification Management solution.

@@ Строка 166: / Строка 166: @@
 * Что я делаю в рамках моих ресурсов?
-Таблица используемая в [https://verificationacademy.com/cookbook/Coverage/System_Level_Functional_Coverage_Example#Functional_Coverage_Model_Creation:_Spreadsheets Пример функционального покрытия системного уровня] добавляет '''Владелец''' и '''Приоритет''' как столбцы определенные пользователем.
+Таблица используемая в [https://verificationacademy.com/cookbook/Coverage/System_Level_Functional_Coverage_Example#Functional_Coverage_Model_Creation:_Spreadsheets Примере функционального покрытия системного уровня] добавляет '''Владелец''' и '''Приоритет''' как столбцы определенные пользователем.
 <!-- These added columns help to answer questions such as:

@@ Строка 153: / Строка 153: @@
 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. -->
-===   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.
+Для обеспечения пользователям возможности записывать другую важную информацию, связанную с требованием, Questa's Verification Management solution позволяет использовать столбцы определенные пользователем. Это позволяет спецификации отслеживать все, что нужно. Он также может дать вам лучшую видимость в процессе верификации. Некоторые столбцы, которые обычно добавляют, включают требования, за которые инженер отвечает при тестировании и то, что является приоритетом требований или особенностью проекта.
-These added columns help to answer questions such as:
+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. -->
 * How am I doing on my high priority testplan items?
@@ Строка 163: / Строка 173: @@
 * 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. -->
 ==   Повторное использование существующих тестовых планов  ==

@@ Строка 132: / Строка 132: @@
 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. -->
-===   Other Columns Understood By Questa===
+===   Другие столбцы, используемые в Questa ===
-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'''
+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. -->
-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.
+'''Путь'''
-'''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.
+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. -->
 ===   User Defined Columns  ===