Каковы наилучшие методы для языков описания оборудования (Verilog, VHDL и т.д.)

Ответ 1

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

И, в частности, некоторые проблемы, которые не имеют точного соответствия в программном обеспечении:

• Без защелок
• Будьте осторожны при сбрасывании
• Проверьте свое внутреннее и внешнее время
• Использовать только синтезируемый код
• Зарегистрируйте выходные данные всех модулей.
• Будьте осторожны с блокировкой и неблокирующими назначениями
• Будьте осторожны с чувствительными списками для комбинаторной логики (или используйте @(*) в Verilog)

Некоторые из них являются такими же, как

• Использовать CM
• Прочитайте обзоры кода
• Проверьте (имитируйте) свой код
• Повторно использовать код
• У вас есть современное расписание
• Имеют спецификацию или варианты использования или клиент Agile

Ответ 2

Сортировка старого потока, но мне хотелось поставить $0,02. Это не совсем специфично для Verilog/VHDL.. подробнее об аппаратном дизайне в целом... специально синтезируемый дизайн для пользовательских ASIC.

Это мое мнение, основанное на многолетнем опыте промышленности (в отличие от академического) по дизайну. Они не имеют особого порядка.

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

• Знайте разницу между путями управления и путями данных. Это позволяет создавать гораздо более элегантный и удобный код. Также позволяет сохранять ворота и минимизировать распространение X. Например, пути данных никогда не должны иметь сбрасываемых флопов, пути управления должны всегда нуждаться в этом.

• Докажите функциональность перед проверкой. Либо через формальный подход, либо через осциллограммы. У этого есть много преимуществ, я объясню 2. Во-первых, это спасет вас впустую время лука пилинг через проблемы. В отличие от множества проектов уровня приложения (esp во время обучения) и большей части курса, время изменения кода очень велико (от 10 минут до дней, в зависимости от сложности). Каждый раз, когда вы меняете код, вам нужно пройти разработку, проверку, компиляцию, формирование формы волны и, наконец, фактическую симуляцию. Это может занять несколько часов. Во-вторых, у вас гораздо меньше шансов попасть в угловые случаи. Обратите внимание, что это касается проверки перед кремнием. Они, несомненно, попадут в пост-силиконовый калькулятор, который вы потратите на $$$. Поверьте мне, первоначальная стоимость проверки функциональности значительно минимизирует риск и стоит усилий. Иногда бывает трудно убедить недавних выпускников колледжей.

• Имейте "куриные биты". Куриные биты - это бит в MMIO, установленный с помощью драйвера, чтобы отключить функцию в кремнии. Он предназначен для возврата изменений, в которых уверенность невелика (доверие прямо пропорционально усилиям по валидации). Невозможно поразить все возможные состояния в пред-кремнии. Уверенность в вашем дизайне не может быть достигнута до тех пор, пока это не подтвердится в пост-кремнии. Даже если есть только 1 состояние, которое попадает на 0.000005% времени, которое подвергает ошибку, оно БУДЕТ ХИТ в пост-кремнии, но не обязательно в предварительном кремнии.

• Избегайте исключений в пути управления любой ценой. Каждое новое исключение удваивает ваши действия по валидации. Это трудно объяснить. Допустим, есть блок DMA, который будет сохранять данные в памяти, которые будет использовать другой блок. Допустим, что сохраненная структура данных зависит от выполняемой функции. Если вы решили сконструировать таким образом, чтобы сохраненная структура данных отличалась между различными функциями, вы просто умножали свои усилия по проверке на количество функций DMA. Если это правило соблюдается, структура данных, сохраненная в результате, будет супер-множеством всех данных, доступных для каждой функции, где объекты содержимого жестко запрограммированы. После того, как логика сохранения DMA будет проверена для 1 функции, она будет проверена для всех функций.

• Минимизировать интерфейсы (прочитать сведения о путях управления). Это связано с минимизацией исключений. Во-первых, каждый новый интерфейс требует проверки. Это включает в себя новые шашки/трекеры, утверждения, точки покрытия и функциональные модели шины в вашем тестовом стенде. Во-вторых, это может увеличить ваши усилия по оценке экспоненциально! Допустим, у вас есть 1 интерфейс для чтения данных в кешках. Теперь давайте скажем (по какой-то нечетной причине) вы решили, что хотите использовать другой интерфейс для чтения основной памяти. Вы только в четыре раза увеличили ваши усилия по валидации. Теперь вам нужно проверить эти комбинации в любой момент времени n:

  • нет чтения кеша, чтение без памяти
  • чтение кэша, чтение в память
  • чтение кеша, чтение без памяти
  • чтение кэша, чтение в память

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

• Минимизировать потенциальные состояния. Чем меньше состояний (предполагаемых или непреднамеренных) имеет дизайн, тем меньше усилий требуется для проверки. Хорошая практика группировать подобные функции в 1 функцию верхнего уровня (например, секвенсоры и арбитры). Очень сложно определить и определить эту функцию высокого уровня, чтобы она охватывала как можно больше меньших функций, но при этом вы значительно устраняете состояние и, в свою очередь, потенциал для ошибок.

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

• Избегайте FSM мучнистого типа, если производительность не оказывает негативного влияния. Meily FSM с большей вероятностью создадут проблемы с синхронизацией по сравнению с Moore.

• .. и, наконец, тот, который мне больше всего не нравится: "если он не сломался, не исправляйте его" Из-за риска и высокой стоимости ошибок много раз взломать более практичный решение проблем. Другие избегали этого, упоминая об использовании существующих компонентов.

Что касается сравнения с более традиционным дизайном программного обеспечения:

• программирование с дискретным событием - совершенно другая парадигма. Люди видят синтаксис verilog и думают "о, это точно так же, как C"... однако это не может быть дальше от истины. Хотя синтаксис подобен, нужно думать по-другому. Например, традиционный отладчик практически не имеет смысла в синтезируемом RTL (дизайн Testbench отличается). Наилучшим инструментом являются формы сигналов на бумаге. Тем не менее, при этом, дизайн FSM может иногда имитировать процедурное программирование. Люди с программным фоном, как правило, сходят с ума от FSM (я знаю, что сначала).

• В системе Verilog есть много и много (и много) специальных возможностей testbench. Он полностью объектно ориентирован. Что касается дизайна testbench, то он очень похож на традиционный дизайн программного обеспечения. Однако у него есть еще одно измерение, связанное с ним, времени. условия гонки и задержки протокола должны учитываться

• Что касается проверки, он также отличается (и тем же). Существует три основных подхода;

  • Формальная пропагандистская проверка (FPV): вы доказываете логикой, что она всегда будет работать.
  • Направленное случайное тестирование. Произвольно устанавливайте задержки, входные значения и возможность включения, определяемые семенем. направленное означает, что семя кладет вес на пути, которые имеют меньшую уверенность. Этот подход использует точки покрытия для обозначения состояния здоровья
  • Фокусное тестирование. Это похоже на традиционное тестирование программного обеспечения.

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

Извините за длину.. Я был в "Зоне":)

Ответ 3

HDL, как Verilog и VHDL, действительно, похоже, поощряют кодекс спагетти. Большинство модулей состоят из нескольких блоков "всегда" (Verilog) или "process" (VHDL), которые могут быть в любом порядке. Общий алгоритм или функция модуля часто полностью закрываются. Выяснить, как работает код (если вы его не пишете), является болезненным процессом.

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

Ответ 4

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

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

• Особое внимание следует уделять процессу загрузки - как только ваш чип функционирует, вы сделали огромный путь.

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

• Простой код предпочтительнее, иногда есть и другие способы ускорить ваш код, после он уже запущен, например, с использованием микросхемы с более высокой скоростью и т.д. ".

• Избегайте "умных" протоколов между компонентами.

• Рабочий код в HDL более ценен, чем на другом программном обеспечении, поскольку аппаратное обеспечение настолько сложно отлаживать, чтобы повторное использование, а также рассмотреть возможность использования "библиотек" модулей, некоторые из которых являются бесплатными, а другие проданы.

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

Некоторые советы по отладке:

• Если проект включает в себя несколько строительных блоков, можно было бы, вероятно, создать линии от интерфейсов между этими блоками до точек тестирования вне чипа.

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

  Если ваш чип будет реконфигурироваться, это станет еще более удобным, так как вы сможете адаптировать конкретные тесты и перепрограммировать выходы для каждого теста, как вы идете (это выглядит очень хорошо со светодиодами:). )

Edit:

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

Причина, это - Исправленные ошибки "внутри" FPGA/ASIC достаточно просты, так как у вас есть симуляторы. Поэтому, если вы уверены, что данные поступают так, как вы хотите, и гаснут, когда ваша программа отправляет их, вы достигли Hardware utopia - возможность работать на уровне программного обеспечения:) (с помощью симулятора). Но если ваши данные не доходят до вас, как вы этого хотите, и вам нужно выяснить, почему... вам придется подключаться к линиям, и это не так просто.

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

Если вам нужно подключить два ваших физических устройства, сделайте "протокол" таким простым, насколько это возможно, до такой степени, что он не будет называться протоколом:) Например, если единицы разделяют часы, добавьте х строк данных между ними и сделайте один блок, чтобы записать их, а другой блок прочитал, таким образом, передав, например, одно "слово", которое имеет х бит между ними при каждом падении часов. Если у вас есть FPGA, если исходная тактовая частота будет слишком быстрой для параллельных данных - вы можете контролировать скорость этого, согласно вашим экспериментам, например, чтобы данные оставались на линиях не менее 't' тактовых циклов и т.д. '. Я предполагаю, что параллельная передача данных проще, так как вы можете работать с более низкими тактовыми частотами и получать те же самые характеристики, без необходимости разделить свои слова на одном устройстве и повторно собрать на другом. (надеюсь, что между "часами" нет никакой задержки между каждым часом). Даже это, вероятно, слишком сложно:)

Относительно SPI, I2C и т.д. Я не реализовал ни одного из них, Я могу сказать, что я связал ноги двух FPGA, идущих от одних и тех же часов (не помню точное формирование резисторов посередине), на гораздо более высоких скоростях, поэтому я действительно не могу придумать веских оснований для используйте их как основной способ передачи данных между вашими FPGA, если FPGA не расположены очень далеко друг от друга, что является одной из причин использования последовательной, а не параллельной шины.

JTAG используется некоторыми компаниями FPGA, чтобы тестировать/программировать свои продукты, но не уверен, что он использовался как способ транспортировки данных на высоких скорости, и это протокол... (еще один, который может иметь встроенную поддержку чипа).

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

Ответ 5

Это вопрос, который требует JBDAVID 10 команд для проектирования оборудования.

• Используйте Revision/Version Control, как в Software. SVN и Hg являются бесплатными.
• Требовать, чтобы код прошел проверку синтаксиса перед регистрацией. Инструмент LINT лучше.
• Используйте полнофункциональный язык проверки аппаратных средств для проверки дизайна. System-Verilog - это почти безопасный выбор.
• Отслеживание ошибок. Bugzilla и GNATS - бесплатные инструменты. Для FogBugz требуется немного $.
• Используйте Assertions для устранения проблем с неправильным использованием.
• The Coverage Triad обеспечивает стабильный дизайн: охват кода измерения, функциональный охват и охват утверждений как в симуляции, так и в формальных инструментах.
• Power is King: используйте CPF или UPF для захвата, обеспечения и проверки вашего Power-Intent.
• реальный дизайн часто представляет собой смешанный сигнал. Используйте язык смешанного сигнала, чтобы проверить аналоговый с цифровым. Verilog-AMS - одно из таких решений. Но не заходите за борт. Моделирование Realnumber может выполнять большинство функциональных аспектов поведения смешанного сигнала.
• Используйте аппаратное ускорение для проверки программного обеспечения, которое должно работать с кремнием!
• Синтаксис. Текстовые редакторы Aware для вашего HDL/HVL являются минимальным требованием для IDE разработчика.

Ответ 6

Для FPGA Xilinx имеет эту отличную страницу (отсутствует, новое местоположение TBD). Почти все будут применяться к другим поставщикам FPGA или будут иметь эквивалентные правила. Для проектирования ASIC очень много.

Altera имеет Рекомендуемые стили кодирования HDL (PDF) и Дизайн Рекомендации для Altera Устройства и помощник по проектированию Quartus II. Altera имеет этот курс оплаты. Однако речь идет о производительности. У меня нет другой информации, насколько она хороша.