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

вроде старой нити, но хотел положить в мой $ 0.02. Это не совсем специфично для Verilog / VHDL.. подробнее о дизайне оборудования в целом... специфически synthesizable конструкция для изготовленного на заказ ASICs.

Это мой мнение основанный на летах опыта индустрии (в отличие от академического) на дизайне. Они, в частности, нет порядка!--1-->

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Edit:

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

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

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

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

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

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

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

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

1. используйте ревизию / контроль версий, как и в программном обеспечении. SVN и Hg свободны.
2. требовать, чтобы код прошел проверку синтаксиса перед регистрацией. Инструмент корпии лучше.
3. использовать полную силу аппаратных средств верификации языка для проверки дизайна. System-Verilog-почти безопасный выбор.
4. Отслеживания Ошибок. Bugzilla и комары являются бесплатными инструментами. Они требуется немного $.
5. используйте утверждения, чтобы обнаружить проблемы с неправильным использованием.
6. Триада охвата делает для стабилизированной конструкции: охват кода измерения, функциональный охват и охват утверждения как в симуляции, так и в официальных инструментах.
7. Power is King: используйте CPF или UPF для захвата, обеспечения и проверки вашего намерения власти.
8. реальный дизайн часто смешанный сигнал, использует язык смешивать-сигнала для проверки аналога с цифровым. Verilog-AMS является одним из таких решение. Но не перегибай палку. Моделирование Realnumber может выполнить большинство функциональных аспектов поведения смешанного сигнала.
9. используйте аппаратное ускорение для проверки программного обеспечения, которое должно работать с кремнием!
10. синтаксические текстовые редакторы для вашего HDL / HVL являются минимальным требованием для IDE разработчика.

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

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