Объясните проверку DUT на собеседовании

Завтра я иду на собеседование, и мне задавали этот вопрос почти на каждом собеседовании, на котором я присутствовал.

Учитывая спецификацию DUT +, как вы проверяете?

Может ли кто-нибудь кратко объяснить мне, как я должен начать отвечать на этот вопрос? Что я должен учитывать (сначала план тестирования с приоритетами, среда Testbench, охват и т. д.)?

ПРИМЕЧАНИЕ. Ответ не обязательно должен относиться конкретно к этому тестируемому устройству. Мне нужна общая картина того, как это объяснить.

заранее спасибо


verification system-verilog uvm
person user1978273    schedule 10.07.2016    source источник
comment
На какую работу вы проходите собеседование? Если это кандидат на должность дизайнера, расскажите что-нибудь о модульном тестировании с помощью самопроверяющегося испытательного стенда и изучите TDD. Если речь идет о должности технического руководителя, скажите что-нибудь о независимой проверке на основе плана проверки, который описывает, как будут проверяться требования в спецификации, например. статический анализ, случайная выборка с ограничениями или формальная верификация. Если это для позиции проверки, и вы не знаете ответа, подумайте о том, чтобы начать с другой позиции и изучить проверку на работе.   -  person teadotjay    schedule 11.07.2016

Ответы (1)


arrow_upward
2
arrow_downward

Очевидно, что существует много способов (и много мнений) о том, как проверить DUT.

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

  1. Спецификация исследования (очевидно)
  2. Соберите требования к тестированию. а. Высокий уровень — размер блока, возможные пользователи ТБ, необходимые выходные данные, типы входных данных для ТБ
    b. Низкий уровень/Подробности — особые требования к отладке,
  3. Разработайте документ по архитектуре ТБ верхнего уровня.
  4. Разработайте план тестирования верхнего уровня.
  5. План тестирования верхнего уровня можно преобразовать или разработать подробный план тестирования.
  6. Разработайте или выведите таблицу Excel с функциональным покрытием. [большинство симуляторов поддерживают отслеживание такого листа]
  7. Получите список случайных управляющих переменных и диапазон/ограничение для переменных. [ необязательный ]
  8. Документ низкого уровня TB — описывает конкретные драйверы, агенты, интерфейсы.
  9. Разработайте график на основе вышеуказанных исходных данных - сложности дизайна и т.д. [сам этот шаг может выполняться частями]
  10. Начать разработку скрипта - для прогона и регрессии и т.д.
  11. Разработка и развертывание тестовых случаев в соответствии с планом тестирования.
  12. Сообщать/файлировать ошибки - следить за количеством ошибок.
  13. Мониторинг и измерение охвата — кода и функционала.
  14. Достигнуть 100% охвата (в идеале), но реально некоторые договорились о цели и нулевом количестве ошибок (несбыточная мечта)
  15. Завершить проверку и объявить об успехе

На что обратить внимание

1) 1) Это среда проверки уровня системы, полного чипа, уровня блока или это ASIC или FPGA?

2) В зависимости от сложности, сколько уровней ТБ требуется.

например многоуровневый уровень -> несколько подсистем-> единая полночиповая среда…

3) В зависимости от продолжительности проекта и времени до закрытия — нужна ли вам поддержка FPGA и/или эмуляции.

4) Формальная проверка — что блокирует.

5) Есть ли потребность в совместном моделировании – от команды разработчиков программного обеспечения. Вам нужно использовать API от команды разработчиков ПО/архитектуры?

6) Есть ли необходимость генерировать векторы — тестовые векторы, воспитывать векторы.

7) Как вы хотите проверить критерии прохождения теста?

а. Модель/табло –

я. Архитектурные модели

II. Модели уровня транзакций (более подробная информация приведена выше)

III. Цикл точных моделей. (например, арбитры)

б. Утверждения – время выполнения + формальное

8) Возможность повторного использования

а. Последовательности

я. В этом

II. Данные/управление

б. Табло

в. Агенты

9) Требования к отладке

а. Форматирование вывода.

б. Инструменты для мониторинга и извлечения информации.

10) Какой язык, симулятор и инструменты лучше всего соответствуют требованиям?

person Rahul Menon    schedule 11.07.2016