Каковы лучшие практики для языков описания оборудования (Verilog, VHDL и т. д.) [закрыто]
https://stackoverflow.com/questions/326880
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Какие рекомендации следует соблюдать при реализации кода HDL?
Каковы общие черты и различия по сравнению с более распространенными областями разработки программного обеспечения?
Решение
Лучшая книга на эту тему Руководство по методологии повторного использования.Он охватывает как VHDL, так и Verilog.
И, в частности, некоторые проблемы, которые не имеют точного соответствия в программном обеспечении:
- Нет защелок
- Будьте осторожны с сбросами
- Проверьте свое внутреннее и внешнее время
- Используйте только синтезируемый код
- Зарегистрируйте выходные данные всех модулей
- Будьте осторожны с блокировкой vs.неблокирующие назначения
- Будьте осторожны с конфиденциальными списками для комбинаторной логики (или используйте @(*) в Verilog).
Некоторые из них одинаковы, включают
- Используйте CM
- Проведите обзоры кода
- Протестируйте (моделируйте) свой код
- Повторно используйте код, когда это необходимо.
- Иметь актуальное расписание
- Иметь спецификацию или варианты использования или Agile-клиента.
Другие советы
Вроде старая тема, но хотел вложить свои 0,02 доллара.Это не является специфичным для Verilog/VHDL..подробнее об аппаратном обеспечении в целом...специально синтезируемый дизайн для пользовательских ASIC.
Это мое мнение основанный на многолетнем промышленном (а не академическом) опыте проектирования.Они расположены в произвольном порядке
Мое общее заявление — проектировать для выполнения валидации.При проектировании аппаратного обеспечения проверка имеет первостепенное значение.Ошибки обходятся намного дороже, если их обнаружить в настоящем кремнии.Вы не можете просто перекомпилировать.Поэтому прекремнию уделяется гораздо больше внимания.
Знайте разницу между путями управления и путями данных.Это позволяет создавать гораздо более элегантный и удобный в сопровождении код.Также позволяет сохранять гейты и минимизировать распространение X.Например, пути данных никогда не должны нуждаться в сбрасываемых флопах, они всегда нужны путям управления.
Докажите функциональность перед проверкой.Либо с помощью формального подхода, либо с помощью сигналов.У этого есть много преимуществ, я объясню 2.Во-первых, это сэкономит вам время, потраченное на очистку лука.В отличие от большого количества проектов на уровне приложений (особенно во время обучения) и большей части курсовой работы, время внесения изменений в код очень велико (от 10 минут до дней, в зависимости от сложности).Каждый раз, когда вы меняете код, вам необходимо пройти этапы разработки, проверки, компиляции, вывода формы сигнала и, наконец, фактического моделирования.что само по себе может занять несколько часов.Во-вторых, у вас гораздо меньше шансов столкнуться с трудными для решения угловыми случаями.Обратите внимание, что это относится к предварительной проверке кремния.Они наверняка нанесут удар по пост-кремниевому блоку, который будет стоить вам много долларов.Поверьте мне, первоначальные затраты на проверку функциональности значительно сводят к минимуму риск и стоят затраченных усилий.В этом иногда трудно убедить недавних выпускников колледжей.
Возьмите «куриные кусочки».Куриные биты — это биты в MMIO, установленные через драйвер для отключения функции кремния.Он предназначен для отмены изменений, внесенных с невысокой степенью достоверности (достоверность прямо пропорциональна усилиям по проверке).Практически невозможно достичь всех возможных состояний в предварительном кремнии.Уверенность в вашей конструкции не может быть истинной, пока она не будет проверена в пост-кремниевом исполнении.Даже если есть только одно состояние, которое поражается в 0,000005% случаев, что обнажает ошибку, она БУДЕТ ПОПАДАТЬ в пост-кремниевом, но не обязательно в пре-кремниевом состоянии.
Любой ценой избегайте исключений в пути управления.Каждое новое исключение удваивает ваши усилия по проверке.Это трудно объяснить.Допустим, есть блок DMA, который сохраняет данные в памяти, которую будет использовать другой блок.Допустим, сохраненная структура данных зависит от выполнения какой-либо функции.Если вы решили спроектировать так, чтобы сохраняемая структура данных различалась в разных функциях, вы просто умножили усилия по проверке на количество функций DMA.Если следовать этому правилу, сохраненная структура данных будет представлять собой супернабор всех данных, доступных для каждой функции, в которой расположение содержимого жестко запрограммировано.Как только логика сохранения DMA проверена для 1 функции, она проверяется для всех функций.
Минимизируйте интерфейсы (читайте минимизируйте пути управления).Это связано с минимизацией исключений.Во-первых, каждый новый интерфейс требует проверки.Сюда входят новые средства проверки/трекера, утверждения, точки покрытия и функциональные модели шины в вашем тестовом стенде.Во-вторых, это может значительно увеличить ваши усилия по проверке!Допустим, у вас есть 1 интерфейс для чтения данных в кешах.Теперь предположим (по какой-то странной причине) вы решили, что вам нужен другой интерфейс для чтения основной памяти.Вы только что увеличили усилия по проверке в четыре раза.Теперь вам необходимо проверять эти комбинации в любой момент времени. н:
- нет чтения кэша, нет чтения памяти
- нет чтения кэша, чтение памяти
- чтение кэша, чтение памяти отсутствует
- чтение кэша, чтение памяти
Понимать и сообщать предположения.Отсутствие этого является основной причиной возникновения проблем со связью.У вас может быть полностью проверенный идеальный блок.однако без понимания всех предположений ваш блок выйдет из строя при подключении.
Минимизируйте потенциальные состояния.Чем меньше состояний (преднамеренных или непреднамеренных) имеет проект, тем меньше усилий требуется для его проверки.Хорошей практикой является группирование одинаковых функций в одну функцию верхнего уровня (например, секвенсоры и арбитры).Очень сложно идентифицировать и определить эту функцию высокого уровня так, чтобы она охватывала как можно больше более мелких функций, но при этом вы значительно устраняете состояние и, в свою очередь, потенциальную возможность ошибок.
Всегда подавайте сильный сигнал, покидая свой блок.В большинстве случаев провал — это решение.Вы понятия не имеете, что с ним будут делать блоки конечной точки.Вы можете столкнуться с проблемами времени, которые могут оказать прямое влияние на идеальную реализацию.
Избегайте автоматов мучнистого типа, если это не отрицательно влияет на производительность.Автоматы Мили чаще вызывают проблемы с синхронизацией, чем Мур
..и, наконец, то, что мне больше всего не нравится:«Если что-то не сломано, не чините это». Из-за связанного с этим риска и высокой стоимости ошибок взлом во многих случаях является более практичным решением проблем.Другие уклонились от этого, упомянув об использовании существующих компонентов.
Что касается сравнения с более традиционный дизайн программного обеспечения:
Программирование, управляемое дискретными событиями, — это совершенно другая парадигма.Люди видят синтаксис verilog и думают: «О, это как C»…однако это не может быть дальше от истины.Хотя синтаксис схож, нужно думать по-другому.Например, традиционный отладчик практически бесполезен для синтезируемых RTL (дизайн Testbench другой).Формы сигналов на бумаге — лучший доступный инструмент.Однако при этом дизайн FSM иногда может имитировать процедурное программирование.Люди, имеющие опыт разработки программного обеспечения, обычно сходят с ума от автоматов (сначала я это знал).
Система Verilog имеет множество специфических функций испытательного стенда.Он полностью объектно-ориентирован.Что касается проектирования тестовых стендов, то оно очень похоже на традиционное проектирование программного обеспечения.Однако с ним связано еще одно измерение — время.необходимо учитывать условия гонки и задержки протокола
Что касается валидации, то она тоже разная (и та же самая).Есть 3 основных подхода;
- Формальная распространяющая верификация (FPV):Вы доказываете с помощью логики, что это всегда будет работать
- Направленное выборочное тестирование.Случайно устанавливайте задержки, входные значения и включение функций в соответствии с начальным значением. направленный означает, что семя придает вес путям, которые имеют меньшую уверенность.Этот подход использует точки покрытия для определения состояния здоровья.
- Фокусное тестирование.Это похоже на традиционное тестирование программного обеспечения.
...для полноты мне нужно также обсудить лучшие практики проектирования испытательных стендов...но это на другой день
Извините за длину..Я был в "Зоне" :)
HDL, такие как Verilog и VHDL, действительно поощряют спагетти-код. Большинство модулей состоят из нескольких блоков Always (Verilog) или Process (VHDL), которые могут быть в любом порядке. Общий алгоритм или функция модуля часто полностью скрыты. Выяснить, как работает код (если вы его не написали), - болезненный процесс.
Несколько лет назад я наткнулся на этот документ , в котором описан более структурированный метод для VHDL дизайн. Основная идея состоит в том, что каждый модуль имеет только 2 блока процесса. Один для комбинаторного кода, другой для синхронного (регистры). Он отлично подходит для создания удобочитаемого и поддерживаемого кода.
в HDL некоторые части кода могут работать одновременно, например, две строки кода «могут работать» одновременно, это преимущество, которое нужно использовать с умом.это то, что программисту, привыкшему к построчному языку, поначалу может быть трудно понять:
- Могут быть созданы длинные и специфичные для ваших нужд конвейеры.
- Вы можете заставить ваши большие модули работать одновременно.
- вместо одного модуля для выполнения повторяющегося действия над разными данными можно создать несколько блоков и выполнять работу параллельно.
Особое внимание следует уделить процессу загрузки: как только ваш чип заработает, вы проделали огромный путь.
Отладка оборудования обычно намного сложнее, чем отладка программного обеспечения, поэтому:
Простой код предпочтится, иногда существуют другие способы ускорения вашего кода, после того как он уже работает, например, с использованием чипа с более высокой скоростью и т. Д. ».
Избегайте «умных» протоколов между компонентами.
Рабочий код в HDL более ценен, чем в другом программном обеспечении, поскольку аппаратное обеспечение очень сложно отлаживать, поэтому его можно использовать повторно, а также рассмотрите возможность использования «библиотек» модулей, некоторые из которых бесплатны, а другие продаются.
При проектировании следует учитывать не только ошибки в HDL-коде, но и сбои в программируемом вами чипе, а также в других аппаратных устройствах, которые взаимодействуют с чипом, поэтому действительно следует подумать о проекте, который легко проверить.
Несколько советов по отладке:
Если конструкция включает в себя несколько строительных блоков, вероятно, потребуется создать линии от интерфейсов между этими блоками к точкам тестирования за пределами чипа.
Вы захотите сохранить в своем проекте достаточно строк, чтобы отвлечь интересные данные для проверки с помощью внешних устройств.Кроме того , и т. д'
Если ваш чип можно реконфигурировать, это станет еще более удобным, поскольку вы сможете адаптировать конкретные тесты и перепрограммировать выходы для каждого теста по ходу дела (это очень хорошо смотрится со светодиодами :).)
Редактировать:
Под интеллектуальными протоколами я имел в виду, что если два ваших физических устройства соединятся, они должны взаимодействовать с помощью самого простого доступного протокола связи.то есть не используйте между ними никаких сложных самодельных протоколов.
Причина в том, что это - ошибки в скрипке «внутри» FPGA/ASIC очень легко, поскольку у вас есть симуляторы.Поэтому, если вы уверены, что данные поступают так, как вы хотите, и выходите на улицу, когда ваша программа отправляет ее, вы достигли аппаратной утопии - имея возможность работать на уровне программного обеспечения :) (с симулятором).Но если ваши данные не доходят до вас так, как вы хотите, и вам нужно выяснить, почему...вам придется подключиться к линиям, а это не так-то просто.
Обнаружить ошибку на линиях сложно, так как к линиям приходится подключаться с помощью специального оборудования, которое фиксирует состояние линий в разное время, и следить за тем, чтобы ваши линии работали в соответствии с протоколом.
Если вам нужно подключить два из ваших физических единиц, сделайте «протокол» настолько простым, насколько это возможно, вплоть до того, что он не будет называться протоколом :) и заставьте одну единицу написать те, а другое устройство прочитали, таким образом, передавая одно «слово», которое имеет x биты между ними, например, на каждом падении часов.Если у вас есть FPGA, если исходная тактовая частота будет слишком высокой для параллельных данных - вы можете контролировать скорость этого в соответствии с вашими экспериментами, например, заставляя данные оставаться на строках, по крайней мере, «t» тактовых циклов и т. д.Я предполагаю, что параллельная передача данных проще, так как вы можете работать с более низкими тактовыми частотами и получать ту же производительность, без необходимости разбивать слова на один блок и собирать его на другой.(надеюсь, между «часами», которые получает каждое устройство, нет задержки).Даже это, наверное, слишком сложно :)
Что касается SPI, I2C и т. Д. 'Я не реализовал ни один из них, я могу сказать, что я подключил ноги двух FPGA, бегущих с одного и того же часа (не помните точное образование резисторов в середине), много Более высокие ставки, поэтому я действительно не могу придумать вескую причину использовать их, как основной способ передачи данных между вашими собственными FPGA, если только FPGA не расположены очень далеко от другого, что является одной из причин для использования сериала, а скорее чем параллельный автобус.
JTAG используется некоторыми компаниями FPGA для тестирования/программирования своих продуктов, но не уверен, что он используется как способ передачи данных на высоких скоростях, и это протокол...(все еще тот, который может иметь встроенную поддержку чипа).
Если вам все же необходимо реализовать какой-либо известный протокол, рассмотрите возможность использования для этого готового кода HDL, который можно найти или купить.
Это вопрос, который требует 10 заповедей JBDAVID для проектирования аппаратного обеспечения.
<Ол>Для ПЛИС у Xilinx есть эта страница . Почти все будут применяться к другим поставщикам ПЛИС или будут иметь эквивалентные правила. Многое применимо к конструкции ASIC.
Intel рекомендовала стили HDL и рекомендации по дизайну (PDF) на этой странице .
