Опыт разработки на основе тестирования (TDD) для проектирования логики (микросхем) в Verilog или VHDL

StackOverflow https://stackoverflow.com/questions/1633559

Вопрос

Я посмотрел в Интернете, и обсуждения / примеры, похоже, относятся к традиционной разработке программного обеспечения.Начиная с Verilog и VHDL (используемых для проектирования микросхем, напримерFPGA и ASIC) аналогичны разработке программного обеспечения на C и C ++, казалось бы, это имеет смысл.Однако у них есть некоторые отличия, поскольку они принципиально параллельны и требуют полного тестирования аппаратного обеспечения.

Какой опыт, хороший и плохой, у вас был?Какие-либо ссылки, которые вы можете предложить по этому конкретному приложению?

Изменения / уточнения:10/28/09:Я особенно спрашиваю о TDD.Я знаком с проведением тестовых стендов, в том числе с самоконтролем.Я также знаю, что SystemVerilog имеет некоторые особые функции для тестовых стендов.

10/28/09:Подразумеваемые вопросы включают 1) написание теста для любой функциональности, никогда не используя формы сигналов для моделирования и 2) сначала написание теста / тестовых стендов.

11/29/09:В Эмпирические исследования показывают, что разработка, основанная на тестировании, Повышает качество они сообщают о (программном обеспечении) TDD: "Плотность дефектов перед выпуском четырех продуктов, измеряемая как дефекты на тысячу строк кода, снизилась между 40% и 90% по сравнению с проектами, которые не использовали TDD.Руководство команд субъективно сообщило об увеличении времени начальной разработки на 15-35% для команд, использующих TDD, хотя команды согласились, что это было компенсировано снижением затрат на обслуживание ". Уменьшение количества ошибок снижает риск прерывания работы за счет умеренного влияния на расписание. Это также есть некоторые данные.

11/29/09:Я в основном занимаюсь кодом управления и пути к данным, а не DSP-кодом.Для DSP типичное решение включает в себя моделирование Matlab с точностью до битов.

03/02/10:Преимущество TDD в том, что вы сначала убедитесь, что тест не пройден.Я полагаю, это можно было бы сделать и с помощью утверждений.

Это было полезно?

Решение

Я пишу код для ПЛИС, а не для ASIC...но TDD по-прежнему остается моим предпочтительным подходом.Мне нравится иметь полный набор тестов для всего функционального кода, который я пишу, и я стараюсь (не всегда успешно) сначала написать тестовый код.Просмотр сигналов всегда происходит в какой-то момент при отладке, но это не очень хороший способ проверки вашего кода (ИМХО).

Учитывая сложность выполнения надлежащих тестов на реальном оборудовании (стимулирование угловых случаев особенно сложно) и тот факт, что VHDL-компиляция занимает секунды (по сравнению с компиляцией "на аппаратное обеспечение", которая занимает много минут (или даже часов)), я не вижу, как кто-либо может работать каким-либо другим способом!

Я также встраиваю утверждения в RTL по мере его написания, чтобы уловить то, что, как я знаю, никогда не должно произойти.Очевидно, что это воспринимается как немного "странное", поскольку существует мнение, что инженеры по верификации пишут утверждения, а разработчики RTL - нет.Но в основном я сам себе инженер по верификации, так что, может быть, именно поэтому!

Другие советы

Я использую ВУнит для разработки на основе тестирования с использованием VHDL.

VUnit - это библиотека Python, которая вызывает компилятор и симулятор VHDL и считывает результаты моделирования.Он также предоставляет несколько хороших библиотек VHDL, которые намного упрощают написание улучшенных тестовых стендов, таких как коммуникационная библиотека, библиотека ведения журнала и a проверка библиотеки.

Существует много возможностей, поскольку он вызывается из Python.Можно как генерировать тестовые данные, так и проверять выходные данные из теста на Python.На днях я видел этот пример, где они использовали Octave - копия Matlab - для отображения результатов тестирования.

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

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

Расширения SystemVerilog к стандарту IEEE Verilog включают различные конструкции, которые облегчают создание полных наборов тестов для проверки сложных цифровых логических схем.SystemVerilog является одним из языков проверки аппаратного обеспечения (HVL), который используется для проверки микросхем ASIC проекты с помощью моделирования (в отличие от эмуляции или использования FPGA).

Существенными преимуществами по сравнению с традиционным языком проектирования аппаратного обеспечения (Verilog) являются:

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

Ключ в том, чтобы иметь доступ к программному обеспечению для моделирования, которое поддерживает этот недавний (2005) стандарт.Не все симуляторы полностью поддерживают более продвинутые функции.

В дополнение к стандарту IEEE существует библиотека SystemVerilog с открытым исходным кодом компоненты проверки доступны в VMM Central (http://www.vmmcentral.com).Это обеспечивает разумную основу для создания тестовой среды.

Вы также можете провести дополнительные исследования по этой теме, выполнив поиск по Форуму Гильдии верфикации.

SystemVerilog - не единственный HVL, и VMM - не единственная библиотека.Но я бы рекомендовал и то, и другое, если у вас есть доступ к соответствующим инструментам.Я обнаружил, что это эффективная методология поиска дизайна ошибки до того , как становление кремнием.

Я не очень разбираюсь в дизайне оборудования / чипов, но я глубоко разбираюсь в TDD, так что могу, по крайней мере, обсудить с вами пригодность этого процесса.

Вопрос, который я бы назвал наиболее уместным, заключается в следующем:Как быстро ваши тесты могут дать вам обратную связь по дизайну?Связанный с этим:Как быстро вы можете добавлять новые тесты?И насколько хорошо ваши инструменты поддерживают рефакторинг (изменение структуры без изменения поведения) вашего дизайна?

Процесс TDD во многом зависит от "мягкости" программного обеспечения - хорошие автоматизированные модульные тесты выполняются за считанные секунды (максимум минуты) и управляют короткими этапами целенаправленного конструирования и рефакторинга.Поддерживают ли ваши инструменты такой тип рабочего процесса - быстрое переключение между написанием и запуском тестов и построение тестируемой системы за короткие итерации?

Что касается инструментов рефакторинга для аппаратных языков, я хотел бы указать вам на наш инструмент Сигаси HDT.Sigasi предоставляет IDE со встроенным анализатором VHDL и рефакторингом VHDL.

Филипп Фаес, Сигаси

НАКОВАЛЬНЯ– Другой уровень взаимодействия Verilog немного рассказывает об этом.Я еще не пробовал этого.

Я никогда активно не пробовал TDD в RTL-дизайне, но у меня были свои мысли по этому поводу.

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

Однако я бы не стал полностью полагаться на утверждения, это может стать очень сложным.

Может быть, вы также можете высказать свои мысли по этому поводу, поскольку вы просите об этом, я предполагаю, что вы носите какие-то идеи в своей голове?

Что такое TDD для вас?Вы имеете в виду, что весь ваш код постоянно выполняется автоматическими тестами, или вы идете дальше, подразумевая, что тесты пишутся до кода и новый код не пишется, если тесты не завершаются неудачей?

Какой бы подход вы ни предпочитали, тестирование кода HDL не сильно отличается от тестирования программного обеспечения.У этого есть свои плюсы (гораздо лучший охват и глубина тестирования) и минусы (сложность в настройке и громоздкость относительно программного обеспечения).

У меня был очень хороший опыт использования Python и универсальных HDL-транзакторов для реализации комплексных и автоматических тестов для синтезируемых модулей HDL.Идея в чем - то похожа на то, что Дженик Бержерон представлен в его книгах, но вместо SystemVerilog Python используется для (1) генерации кода VHDL из тестовых сценариев, написанных на Python, и (2) проверки результатов, написанных отслеживающими транзакторами, которые принимают формы сигналов из проекта во время моделирования.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top