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

Question

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

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

Редактирует / уточнения: 28.10.09: Я особенно спрашиваю о TDD. Я знаком с выполнением испытательных стендов, в том числе самоконтроля. Мне также известно, что SystemVerilog имеет некоторые особенности для испытательных стендов.

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

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

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

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

Answer 1

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

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

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

Answer 2

Я использую VUnit для тестовой разработки с VHDL.

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

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

Answer 5

ANVIL - Еще об этом говорит другой слой взаимодействия Verilog. Я не пробовал это.

Answer 6

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

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

Answer 7

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

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

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

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

Answer 8

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

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

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

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