OVM/OVM методология/Основы верификации — различия между версиями
Vidokq (обсуждение | вклад) (→1.1) |
|||
| Строка 1: | Строка 1: | ||
| − | + | Функционально проверить устройство означает, сравнить цель разработчика с полученным поведением на их эквивалентность. Мы считаем устройство проверенным, когда, к всеобщему удовлетворению, оно работает в соответствии с целью разработчика. Этот основной принцип часто теряется при использовании testbenches, среды контроля, отладки, моделирования , и все другие средства, применяемые в современных технологических проверках. Чтобы узнать, работает ли верно устройство, вы должны сравнить его с некоторыми известными эталоном, который представляет цель разработчика. Каждый testbench имеет своего рода эталонную модель и средство для сравнения функциональность устройство с эталоном. | |
| − | + | ||
| − | + | Когда мы говорим "устройство", мы имеем в виду проверяемое устройство, часто называемое тестируемое устройство или DUT. Чтобы проверить, DUT, как правило, представлен форме подходящей для производства, которое может быть перенесено на кремний с помощью автоматизированных и ручных средств. Мы различаем DUT от эскиза на обратной стороне салфетки или окончательного нанесенный на кристалл, ни один из которых не может быть проверен. Эталонная модель отражает цели разработчика, то есть то, что устройство должно делать.Эталон может принимать различные формы, такие как документ, описывающий работу DUT, golden модель, которая содержит уникальный алгоритм, или assertions, которые представляют протокол. | |
| − | |||
| − | |||
| − | |||
[[Файл:1.png]] | [[Файл:1.png]] | ||
| + | |||
Для автоматизации сравнения поведения и эталона, оба должны быть представлены в форме, которую можно выполнить на компьютере с помощью некоторых программ, что делает сравнение. | Для автоматизации сравнения поведения и эталона, оба должны быть представлены в форме, которую можно выполнить на компьютере с помощью некоторых программ, что делает сравнение. | ||
| − | + | 1.1.1 Два вопроса | |
| − | Проверка устройства включает в себя два вопроса:Does it work? (Работает ли это устройство?) и Are we done? (Сделали ли мы?). Это основные, и некоторые сказали бы, очевидные вопросы. Тем не менее они мотивируют всю механику каждой проверочного потока. Первый вопрос - это Does it work? Этот вопрос исходит от основной идеи верификации. Он спрашивает, Соответствует ли устройство эталону? Второй вопрос - Are we done? Он спрашивает, довольны ли мы сравнительным анализом полученной схемы и эталона для определения работает ли устройство согласно цели, если нет, то почему. Мы используем эти ценные вопросы создания основы для разработки эффективных testbenches. | + | Проверка устройства включает в себя два вопроса:Does it work? (Работает ли это устройство?) и Are we done? (Сделали ли мы?). Это основные, и некоторые сказали бы, очевидные вопросы. Тем не менее они |
| + | мотивируют всю механику каждой проверочного потока. Первый вопрос - это Does it work? Этот вопрос исходит от основной идеи верификации. Он спрашивает, Соответствует ли устройство эталону? Второй вопрос - Are we done? Он спрашивает, довольны ли мы сравнительным анализом полученной схемы и эталона для определения работает ли устройство согласно цели, если нет, то почему. Мы используем эти ценные вопросы создания основы для разработки эффективных testbenches. | ||
| − | + | 1.1.2 Does it work? | |
| − | + | ||
| − | + | ||
| − | + | Does it work? Это не единственный вопрос, а категория вопросов, которые представляют природу DUT. Каждый проект будет иметь свой собственный набор Does-It-Work вопросов, чья роль заключается в определении правильного функционирования устройства. Функциональные вопросы определяют, ведет ли себя устройство должным образом в конкретных ситуациях. Мы получаем эти вопросы непосредственно из цели разработки устройства, и мы используем их, чтобы отразить цель проекта в testbench. | |
| − | + | ||
| − | + | ||
| − | Это простой пример полного набора вопросов. Для устройства даже такого простого как этот гипотетическое маршрутизатор, набор Does-It-Work вопросов может быть длинным. Чтобы построить план проверки и testbench, который поддерживает план, вы должны сначала перечислить все вопросы или показать как получит полный набор вопросов, а затем выберите те, которые являются интересными. | + | Рассмотрим простой маршрутизатор пакетов в качестве примера. Это устройство маршрутизации пакетов от входа к одному из четырех портов вывода. Пакеты содержат адреса портов назначения и имеют различные длины полезной нагрузки. Каждый пакет имеет заголовок, трейлер, и два байта для циклического избыточного кода (CRC). Does-It-Work вопросы в этом случае должны быть следующие: |
| + | |||
| + | *пакет, поступающий на вход порта, адресованный на имя выходного порта 3, прибыл на порт 3? | ||
| + | *пакет длиной 16 пришел без изменений? | ||
| + | *CRC байты правильны, если полезная нагрузка [0f 73 a8 c2 3e 57 11 0a 88 FF 00 00 33 2b 4c 89]? | ||
| + | |||
| + | |||
| + | Это простой пример полного набора вопросов. Для устройства даже такого простого как этот гипотетическое маршрутизатор, набор Does-It-Work вопросов может быть длинным. Чтобы построить план проверки и testbench, который поддерживает план, вы должны сначала перечислить все вопросы или показать как получит полный набор вопросов, а затем выберите те, которые являются интересными. | ||
| + | |||
| + | Продолжая пример маршрутизатора пакетов,для того чтобы перечислить все Does-It-Work вопросы, вы можете создать таблицу: | ||
| − | |||
[[Файл:2.png]] | [[Файл:2.png]] | ||
| Строка 34: | Строка 36: | ||
[[Файл:3.png]] | [[Файл:3.png]] | ||
[[Файл:4.png]] | [[Файл:4.png]] | ||
| − | |||
Обратите внимание, что мы формулируем все вопросы, так что на них можно ответить да или нет. В конце концов, схема работает либо нет – она либо готова для синтеза, размещения и трассировке, либо нет. Если вы можете ответить на все вопросы утвердительно, тогда проект готов для следующего производственного шага. | Обратите внимание, что мы формулируем все вопросы, так что на них можно ответить да или нет. В конце концов, схема работает либо нет – она либо готова для синтеза, размещения и трассировке, либо нет. Если вы можете ответить на все вопросы утвердительно, тогда проект готов для следующего производственного шага. | ||
| − | |||
При разработке набора does-it-work вопросов, не забудьте сформулировать их таким образом, чтобы на них можно было ответить да или нет. Ответ да положителен, то есть, ответить да означает, что устройство работает правильно. Это будет сделать легче, чем пытаться отслеживать на какие вопросы нужно ответить да, и на какие следует ответить нет. Такой вопрос как Передает ли маршрутизатор ошибочные пакеты? требует ответа нет, чтобы считаться успешным. Лучшей формулировкой вопроса будет: Отклоняет ли маршрутизатор ошибочные пакеты? Вы должны сделать вопросы наиболее конкретными, даже если лучшее звучание будет: Когда ошибочный пакет попадает на входной порт, маршрутизатор обнаруживает его, подает сигнал ошибки и отклоняет этот пакет? Имейте в виду, что более конкретные вопросы более подробно описывают устройство. Ваш testbench должен дать ответ да или нет. | При разработке набора does-it-work вопросов, не забудьте сформулировать их таким образом, чтобы на них можно было ответить да или нет. Ответ да положителен, то есть, ответить да означает, что устройство работает правильно. Это будет сделать легче, чем пытаться отслеживать на какие вопросы нужно ответить да, и на какие следует ответить нет. Такой вопрос как Передает ли маршрутизатор ошибочные пакеты? требует ответа нет, чтобы считаться успешным. Лучшей формулировкой вопроса будет: Отклоняет ли маршрутизатор ошибочные пакеты? Вы должны сделать вопросы наиболее конкретными, даже если лучшее звучание будет: Когда ошибочный пакет попадает на входной порт, маршрутизатор обнаруживает его, подает сигнал ошибки и отклоняет этот пакет? Имейте в виду, что более конкретные вопросы более подробно описывают устройство. Ваш testbench должен дать ответ да или нет. | ||
| − | |||
Тщательно сформулированный да или нет вопрос содержит свои собственные критерии успеха. Он сообщает, что получает ответа да. Такой вопрос как, Средняя задержка менее 27 тактов? содержит метрику, 27 тактов, и форму сравнения, меньше. Если вопрос (неправильно) сформулирован, например, Какова средняя задержка прохождения пакетов через маршрутизатор? мы не будем знать, что считается приемлемым. Чтобы ответить на ваш вопрос, вы в первую очередь должны быть в состоянии определить среднее время задержки. Только при правильной постановке вопроса мы знаем, как сделать сравнение, чтобы определить, является ли результат правильным. Метрика сама по себе не говорит нам о том, функционирует ли схема как задумано. Когда мы сравниваем измеренное значение со значением в спецификации, 27 тактов в этом примере, мы можем определить, работает ли схема. | Тщательно сформулированный да или нет вопрос содержит свои собственные критерии успеха. Он сообщает, что получает ответа да. Такой вопрос как, Средняя задержка менее 27 тактов? содержит метрику, 27 тактов, и форму сравнения, меньше. Если вопрос (неправильно) сформулирован, например, Какова средняя задержка прохождения пакетов через маршрутизатор? мы не будем знать, что считается приемлемым. Чтобы ответить на ваш вопрос, вы в первую очередь должны быть в состоянии определить среднее время задержки. Только при правильной постановке вопроса мы знаем, как сделать сравнение, чтобы определить, является ли результат правильным. Метрика сама по себе не говорит нам о том, функционирует ли схема как задумано. Когда мы сравниваем измеренное значение со значением в спецификации, 27 тактов в этом примере, мы можем определить, работает ли схема. | ||
| − | |||
Как это часто бывает, это не практично перечислять каждый does-it-work вопрос. Чтобы убедиться, что каждое слово в памяти 1 Мб можно записать и читать, непрактично и не необходимо записать один миллион вопросов. Вместо этого, вопрос-генератор, вопрос, который генерирует многие другие, занимает место миллиона отдельных вопросов. Может каждый миллион слов в памяти быть успешно записан и считан? -является вопросом-генератором. | Как это часто бывает, это не практично перечислять каждый does-it-work вопрос. Чтобы убедиться, что каждое слово в памяти 1 Мб можно записать и читать, непрактично и не необходимо записать один миллион вопросов. Вместо этого, вопрос-генератор, вопрос, который генерирует многие другие, занимает место миллиона отдельных вопросов. Может каждый миллион слов в памяти быть успешно записан и считан? -является вопросом-генератором. | ||
| + | Другие вопросы могут сами по себе представлять классы вопросов. Вопрос 3, Является ли вычисление CRC корректным для каждого пакета? является примером такого вопроса. Тестирование CRC вычисления требует ряда тщательно продуманных тестов, для определения является ли вычисления CRC корректным во всех случаях. | ||
| + | |||
| + | 1.1.3 Are We Done? | ||
| + | |||
| + | Для определения ответа на вопрос Are we done?, мы должны знать, что мы ответили на достаточное количество does-it-work вопросов, чтобы утверждать, что у нас есть проверенная схема. Мы начинаем эту задачу путем разделения на приоритеты всех does-it-work вопросов по двум направлениям: | ||
| + | |||
| + | [[Файл:5.png]] | ||
| + | |||
| + | Искусство создания testbench требует, чтобы на начальном этапе, мы определили множество вопросов и отсортировали их в соответствии с ценностью возвращаемой информации с точки зрения проверки схемы. Следующий шаг заключается в создании механизма, который будет отвечать на вопросы и определять на какие из них были даны ответы (и на какие нет). | ||
| + | |||
| + | Are-we-done вопросы также называется вопросами функционального покрытия, вопросы, которые устанавливают все ли состояния охватывают тесты с точки зрения функций схемы. Как и does-it-work вопросы, мы можем также разбить вопросы функционального охвата на более подробные вопросы. И как вопросы функциональной корректности, вопросы функционального охвата должны также иметь ответы да или нет. Приведенный ниже список включает в себя примеры вопросы функционального охвата: | ||
| + | |||
| + | • Выполняется ли каждая команда процессора, по крайней мере, один раз? | ||
| + | |||
| + | • Проходит, по крайней мере, один пакет от каждого входного порта до каждого выходного порта? | ||
| + | |||
| + | • Можно ли обратиться к памяти с набором адресов, которые содержат каждый бит адреса как 1 и затем каждый бит адреса 0, не включая 0xffffffff и 0x00000000?(?????????) | ||
| + | |||
| + | Другим мнением об этих вопросах является то, о чем они спрашивают, Получен ли утвердительный ответ на необходимый does-it-work вопрос? Когда мы думаем о функциональном охвате с этой точки зрения, то имеем виду покрытие множества does-it-work вопросов. Кроме того, вопросы охвата распознают метрику и порог для сравнения. Покрытие будет (то есть, охват вопрос можно ответить, да), когда метрика достигает порога. | ||
| + | |||
| + | Таким образом, искусство построения testbench начинается с плана тестирования. План тестирования начинается с тщательно продуманным набором does-it-work и Are-we-done вопросов. | ||
| + | |||
| + | |||
| + | 1.1.4 Двухпетлевый поток (???????????????) | ||
| + | |||
| + | |||
| + | Процесс ответа на does-it-work и Are-we-done вопросы может быть описан простой схемой, как показано на рисунке 1-2. Все обусловлено функциональной спецификации на проектирование. Из функциональной спецификации, вы можете получить саму схему и план проверки. План проверки запускает testbench. | ||
| + | |||
| + | Поток состоит из двух циклов, does-it-work цикла и Are-we-done цикл. Оба цикла начинаются с моделирования. Моделирование тестирует схему при помощи testbench и генерирует информацию, которую мы используем для ответа на вопросы. Сначала мы спрашиваем, Это работает? Если ответа нет, то необходимо отладить проект. Процесс отладки схемы может привести к изменениям в реализации схемы. | ||
| + | Как только схема работает, то пора ответить на вопрос, Are-we-done? Мы ответим на этот вопрос, собирая информацию охвата и сравнения его с порогом, указанным в тестовом плане. Если мы не достигнем порогов, то ответ нет, и мы должны изменить testbench для увеличения охвата. Тогда мы моделируем снова. | ||
| + | |||
| + | Изменение testbench или воздействия может вызвать другие скрытые ошибки в схеме. Последующие итерации по циклу могут заставить нас вернуться к does-it-work циклу снова, чтобы исправить новые ошибки, которые появятся. Как вы можете видеть, полный процесс проверки колеблется вперед и назад между does-it-work и Are-we-done циклами, пока мы не можем утвердительно ответить на все вопросы обоих категорий. | ||
| + | [[Файл:6.png]] | ||
| − | + | В идеальном мире, схема не имеет ошибок и с покрытием всегда полное, так что вам только надо пройти по каждому циклу один раз, чтобы получить ответы да на оба вопроса. В реальном мире, это может занять много итераций для достижения двух ответов да. Одна из целей хорошего потока проверки свести к минимуму количество итераций для выполнения верификации проекта в кратчайшие сроки с использованием наименьшего количества ресурсов. | |
Версия 13:05, 21 февраля 2013
Функционально проверить устройство означает, сравнить цель разработчика с полученным поведением на их эквивалентность. Мы считаем устройство проверенным, когда, к всеобщему удовлетворению, оно работает в соответствии с целью разработчика. Этот основной принцип часто теряется при использовании testbenches, среды контроля, отладки, моделирования , и все другие средства, применяемые в современных технологических проверках. Чтобы узнать, работает ли верно устройство, вы должны сравнить его с некоторыми известными эталоном, который представляет цель разработчика. Каждый testbench имеет своего рода эталонную модель и средство для сравнения функциональность устройство с эталоном.
Когда мы говорим "устройство", мы имеем в виду проверяемое устройство, часто называемое тестируемое устройство или DUT. Чтобы проверить, DUT, как правило, представлен форме подходящей для производства, которое может быть перенесено на кремний с помощью автоматизированных и ручных средств. Мы различаем DUT от эскиза на обратной стороне салфетки или окончательного нанесенный на кристалл, ни один из которых не может быть проверен. Эталонная модель отражает цели разработчика, то есть то, что устройство должно делать.Эталон может принимать различные формы, такие как документ, описывающий работу DUT, golden модель, которая содержит уникальный алгоритм, или assertions, которые представляют протокол.
Для автоматизации сравнения поведения и эталона, оба должны быть представлены в форме, которую можно выполнить на компьютере с помощью некоторых программ, что делает сравнение.
1.1.1 Два вопроса
Проверка устройства включает в себя два вопроса:Does it work? (Работает ли это устройство?) и Are we done? (Сделали ли мы?). Это основные, и некоторые сказали бы, очевидные вопросы. Тем не менее они мотивируют всю механику каждой проверочного потока. Первый вопрос - это Does it work? Этот вопрос исходит от основной идеи верификации. Он спрашивает, Соответствует ли устройство эталону? Второй вопрос - Are we done? Он спрашивает, довольны ли мы сравнительным анализом полученной схемы и эталона для определения работает ли устройство согласно цели, если нет, то почему. Мы используем эти ценные вопросы создания основы для разработки эффективных testbenches.
1.1.2 Does it work?
Does it work? Это не единственный вопрос, а категория вопросов, которые представляют природу DUT. Каждый проект будет иметь свой собственный набор Does-It-Work вопросов, чья роль заключается в определении правильного функционирования устройства. Функциональные вопросы определяют, ведет ли себя устройство должным образом в конкретных ситуациях. Мы получаем эти вопросы непосредственно из цели разработки устройства, и мы используем их, чтобы отразить цель проекта в testbench.
Рассмотрим простой маршрутизатор пакетов в качестве примера. Это устройство маршрутизации пакетов от входа к одному из четырех портов вывода. Пакеты содержат адреса портов назначения и имеют различные длины полезной нагрузки. Каждый пакет имеет заголовок, трейлер, и два байта для циклического избыточного кода (CRC). Does-It-Work вопросы в этом случае должны быть следующие:
- пакет, поступающий на вход порта, адресованный на имя выходного порта 3, прибыл на порт 3?
- пакет длиной 16 пришел без изменений?
- CRC байты правильны, если полезная нагрузка [0f 73 a8 c2 3e 57 11 0a 88 FF 00 00 33 2b 4c 89]?
Это простой пример полного набора вопросов. Для устройства даже такого простого как этот гипотетическое маршрутизатор, набор Does-It-Work вопросов может быть длинным. Чтобы построить план проверки и testbench, который поддерживает план, вы должны сначала перечислить все вопросы или показать как получит полный набор вопросов, а затем выберите те, которые являются интересными.
Продолжая пример маршрутизатора пакетов,для того чтобы перечислить все Does-It-Work вопросы, вы можете создать таблицу:
Приведенная выше таблица содержит два вида вопросов, те, на которые мы можем ответить сразу и те, которые мы можно разбить на более мелкие вопросы. Вопрос 1 из ряда вопросов, которые можно представить в виде:
Обратите внимание, что мы формулируем все вопросы, так что на них можно ответить да или нет. В конце концов, схема работает либо нет – она либо готова для синтеза, размещения и трассировке, либо нет. Если вы можете ответить на все вопросы утвердительно, тогда проект готов для следующего производственного шага. При разработке набора does-it-work вопросов, не забудьте сформулировать их таким образом, чтобы на них можно было ответить да или нет. Ответ да положителен, то есть, ответить да означает, что устройство работает правильно. Это будет сделать легче, чем пытаться отслеживать на какие вопросы нужно ответить да, и на какие следует ответить нет. Такой вопрос как Передает ли маршрутизатор ошибочные пакеты? требует ответа нет, чтобы считаться успешным. Лучшей формулировкой вопроса будет: Отклоняет ли маршрутизатор ошибочные пакеты? Вы должны сделать вопросы наиболее конкретными, даже если лучшее звучание будет: Когда ошибочный пакет попадает на входной порт, маршрутизатор обнаруживает его, подает сигнал ошибки и отклоняет этот пакет? Имейте в виду, что более конкретные вопросы более подробно описывают устройство. Ваш testbench должен дать ответ да или нет. Тщательно сформулированный да или нет вопрос содержит свои собственные критерии успеха. Он сообщает, что получает ответа да. Такой вопрос как, Средняя задержка менее 27 тактов? содержит метрику, 27 тактов, и форму сравнения, меньше. Если вопрос (неправильно) сформулирован, например, Какова средняя задержка прохождения пакетов через маршрутизатор? мы не будем знать, что считается приемлемым. Чтобы ответить на ваш вопрос, вы в первую очередь должны быть в состоянии определить среднее время задержки. Только при правильной постановке вопроса мы знаем, как сделать сравнение, чтобы определить, является ли результат правильным. Метрика сама по себе не говорит нам о том, функционирует ли схема как задумано. Когда мы сравниваем измеренное значение со значением в спецификации, 27 тактов в этом примере, мы можем определить, работает ли схема. Как это часто бывает, это не практично перечислять каждый does-it-work вопрос. Чтобы убедиться, что каждое слово в памяти 1 Мб можно записать и читать, непрактично и не необходимо записать один миллион вопросов. Вместо этого, вопрос-генератор, вопрос, который генерирует многие другие, занимает место миллиона отдельных вопросов. Может каждый миллион слов в памяти быть успешно записан и считан? -является вопросом-генератором. Другие вопросы могут сами по себе представлять классы вопросов. Вопрос 3, Является ли вычисление CRC корректным для каждого пакета? является примером такого вопроса. Тестирование CRC вычисления требует ряда тщательно продуманных тестов, для определения является ли вычисления CRC корректным во всех случаях.
1.1.3 Are We Done?
Для определения ответа на вопрос Are we done?, мы должны знать, что мы ответили на достаточное количество does-it-work вопросов, чтобы утверждать, что у нас есть проверенная схема. Мы начинаем эту задачу путем разделения на приоритеты всех does-it-work вопросов по двум направлениям:
Искусство создания testbench требует, чтобы на начальном этапе, мы определили множество вопросов и отсортировали их в соответствии с ценностью возвращаемой информации с точки зрения проверки схемы. Следующий шаг заключается в создании механизма, который будет отвечать на вопросы и определять на какие из них были даны ответы (и на какие нет).
Are-we-done вопросы также называется вопросами функционального покрытия, вопросы, которые устанавливают все ли состояния охватывают тесты с точки зрения функций схемы. Как и does-it-work вопросы, мы можем также разбить вопросы функционального охвата на более подробные вопросы. И как вопросы функциональной корректности, вопросы функционального охвата должны также иметь ответы да или нет. Приведенный ниже список включает в себя примеры вопросы функционального охвата:
• Выполняется ли каждая команда процессора, по крайней мере, один раз?
• Проходит, по крайней мере, один пакет от каждого входного порта до каждого выходного порта?
• Можно ли обратиться к памяти с набором адресов, которые содержат каждый бит адреса как 1 и затем каждый бит адреса 0, не включая 0xffffffff и 0x00000000?(?????????)
Другим мнением об этих вопросах является то, о чем они спрашивают, Получен ли утвердительный ответ на необходимый does-it-work вопрос? Когда мы думаем о функциональном охвате с этой точки зрения, то имеем виду покрытие множества does-it-work вопросов. Кроме того, вопросы охвата распознают метрику и порог для сравнения. Покрытие будет (то есть, охват вопрос можно ответить, да), когда метрика достигает порога.
Таким образом, искусство построения testbench начинается с плана тестирования. План тестирования начинается с тщательно продуманным набором does-it-work и Are-we-done вопросов.
1.1.4 Двухпетлевый поток (???????????????)
Процесс ответа на does-it-work и Are-we-done вопросы может быть описан простой схемой, как показано на рисунке 1-2. Все обусловлено функциональной спецификации на проектирование. Из функциональной спецификации, вы можете получить саму схему и план проверки. План проверки запускает testbench.
Поток состоит из двух циклов, does-it-work цикла и Are-we-done цикл. Оба цикла начинаются с моделирования. Моделирование тестирует схему при помощи testbench и генерирует информацию, которую мы используем для ответа на вопросы. Сначала мы спрашиваем, Это работает? Если ответа нет, то необходимо отладить проект. Процесс отладки схемы может привести к изменениям в реализации схемы. Как только схема работает, то пора ответить на вопрос, Are-we-done? Мы ответим на этот вопрос, собирая информацию охвата и сравнения его с порогом, указанным в тестовом плане. Если мы не достигнем порогов, то ответ нет, и мы должны изменить testbench для увеличения охвата. Тогда мы моделируем снова.
Изменение testbench или воздействия может вызвать другие скрытые ошибки в схеме. Последующие итерации по циклу могут заставить нас вернуться к does-it-work циклу снова, чтобы исправить новые ошибки, которые появятся. Как вы можете видеть, полный процесс проверки колеблется вперед и назад между does-it-work и Are-we-done циклами, пока мы не можем утвердительно ответить на все вопросы обоих категорий.
В идеальном мире, схема не имеет ошибок и с покрытием всегда полное, так что вам только надо пройти по каждому циклу один раз, чтобы получить ответы да на оба вопроса. В реальном мире, это может занять много итераций для достижения двух ответов да. Одна из целей хорошего потока проверки свести к минимуму количество итераций для выполнения верификации проекта в кратчайшие сроки с использованием наименьшего количества ресурсов.
