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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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