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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изменить:

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

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

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

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

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

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

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

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

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

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

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

namespace detail
{
  template <class Comparator>
  class CounterComparator: Comparator
  {
  public:
    CounterComparator(size_t& counter):
        Comparator(), mCounter(&counter) {}
    CounterComparator(Comparator comp, size_t& counter):
        Comparator(comp), mCounter(&counter) {}

    template <class T, class U>
    bool operator()(T& lhs, U& rhs) const
    { 
      ++(*mCounter);
      return this->Comparator::operator()(lhs,rhs);
    }
  private:
    size_t* mCounter;
  };
} // namespace detail

template <
  class Key, 
  class Value, 
  class Cmp = std::less<Key>, 
  class Allocator = std::allocator< std::pair<const Key,Value> >
>
class SuperMap
{
  typedef detail::CounterComparator<Cmp> Comparator;
public:
  SuperMap(): mCounter(0), mData(Comparator(mCounter)) {}

  Value& operator[](const Key& key) { return mData[key]; }

  size_t rank(const Key& key) const
  { 
    mCounter = 0; mData.find(key); return mCounter;
  }

private:
  typedef std::map<Key,Value, Comparator, Allocator> data_type;

  mutable size_t mCounter;
  data_type mData;
}; // class SuperMap

int main(int argc, char* argv[])
{
  SuperMap<int,int> superMap;
  superMap[1] = 42;
  std::cout << superMap.rank(1) << std::endl;
}

// outputs
// 2

Подсчитывается количество тестов, но поскольку std:: map прекращает тестирование, как только получает правильный ключ... Это должно быть хорошо:) Хотя, вероятно, есть некоторое смещение, чтобы вывести там (1 или 2), чтобы получить ранг вместо.

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

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

Если вам не нужно повторно загружать ресурсы каждый раз, просто запустите Maven в «автономном» режиме с коммутатором -o.

Также, просто наконечник, вы можете создать и установить POM, даже для сторонних JAR, а затем получить их в вашем местном репо. Таким образом Maven не придется выходить к трубкам, чтобы каждый раз получать ресурсы (это проверит, но они будут разрешены локально).

Для сторонних или сторонних JAR можно установить с помощью установочного подключаемого модуля .

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

Корпорация Intel рекомендовала стили кодирования HDL и рекомендации по проектированию (PDF) на этой странице .