Подтвердить что ты не робот

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

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

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

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

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

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

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

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

4b9b3361

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

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