Как получить дизайн ПЛИС, который определенно будет работать на реальном оборудовании

9

Я только начал изучать дизайн цифровой логики с помощью ПЛИС и строил много проектов. В большинстве случаев (так как я отчасти нуб), у меня есть дизайн, который идеально имитирует (поведенческое моделирование), но не синтезирует должным образом.

Итак, мой вопрос: «Какие этапы проектирования я могу включить в свой рабочий процесс, чтобы гарантировать, что у меня будет рабочий дизайн, который будет работать прямо на моей ПЛИС?»

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

  • Какие все шаги (просмотр схемы RTL, симуляция после синтеза, ...) я должен предпринять, изучая лучшие практики.
  • Что нужно помнить при разработке логики (скажем, FSM или последовательных цепей), чтобы избежать неожиданных результатов.

Я использую Xilinx Spartan 6 FPGA и Xilinx ISE Design Suite для своей работы.

ironstein
источник
1
С какими проблемами вы сталкиваетесь при синтезе? Вы достигаете высокого уровня охвата в симуляции?
pjc50
@ pjc50 Я не понимаю вопроса. Что вы имеете в виду "высокий уровень охвата в симуляции"?
Айронштейн
1
У вас есть испытательный стенд или стимул, управляющий симуляцией. Инструменты покрытия сообщают вам, сколько процентов фактически выполняется тестом, в процентах. Если это число слишком мало, то ваш тестовый стенд неадекватен, и вы не тестируете некоторые случаи, которые могут возникнуть при реальном использовании.
pjc50
@ pjc50 это действительно очень хороший совет. Что эквивалентно этому в Xilinx ISE design suite?
Айронштейн
1
Стоит отметить: синтезирует и «определенно работает на реальном оборудовании» разные уровни строгости. Есть шаблоны, которым можно следовать, чтобы убедиться, что он синтезирует. Однако, когда дело доходит до того, чтобы заставить его работать на реальном оборудовании, с уверенностью следует помнить принцип симуляции: «Все модели ошибочны; некоторые полезны».
Cort Ammon

Ответы:

13

В месте, где я работал, было два лагеря дизайнеров ПЛИС. Один лагерь я назвал симуляцией, симуляцией, симуляцией или кубами. Другой лагерь был все о дизайне.

Ребята с кубами использовали симулятор, такой как modelsim, они могли придумать начальный дизайн с помощью методов кодирования и \ или блоков в наборе дизайна. Затем они имитируют это и находят вещи, которые не будут работать, а затем изменяют код. Этот процесс повторялся несколько раз, пока они не придумали дизайн, который работал.

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

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

В каком лагере вы бы предпочли быть? Я думаю, что должен быть строгий дизайн, делать то, что работает для вас, но я думаю, что чем более детальным и строгим вы будете заниматься проектированием, тем меньше проблем у вас будет в долгосрочной перспективе. Я привел несколько примеров того, что возможно, они могут не соответствовать организационной структуре вашего рабочего места. Причина, по которой детали дизайна и тщательное планирование так полезны, это заставляет вас задуматься о том, что вы делаете. Это облегчает отладку. Разработайте рабочий процесс проектирования, который позволит этому случиться. Кроме того, познакомьтесь с инструментами моделирования и напишите хорошие испытательные стенды, которые будут проверять все условия, с которыми может столкнуться симулируемое устройство. Это, конечно, должно быть сбалансировано со временем. Например, напишите код ADC HDL, который будет имитировать устройство в ваших симуляциях.

Самый ценный инструмент для проектирования ПЛИС (на мой взгляд) - это хорошая процедура тестирования, которая позволит вам полностью протестировать свой дизайн и выполнить его в нужном темпе. Нельзя ожидать, что дизайн FPGA «просто сработает», нужно приложить усилия, чтобы убедиться, что все части работают. Если вы обнаружите ошибки, вернитесь к моделированию и проектированию и изучите различия между имитируемой FPGA и RTL. Это в основном приходит с опытом, но если дизайн работает в симуляции, а не в аппаратном обеспечении, вам нужно выяснить, почему есть разница.

Несколько ключевых вещей, которые я изучил:
1) Санитарная обработка ваших входов, схемы синхронизации и сброса должны быть чистыми, иначе вы можете получить метастабильность, распространяющуюся через вашу систему. Знайте, что такое синхронизатор двойного ранга. Существует множество различных топологий для схем сброса, знайте, как их использовать (в сети есть отличная статья, хотя у меня ее нет под рукой).
2) Получить требования дизайна заранее, а затем дизайн вокруг них. Если окружающие вас люди не будут предъявлять вам определенные требования, придумайте их сами.
3) Набор инструментов с фиксированной точкой Matlab отлично подходит для имитации систем управления и приложений DSP, но у вас может не быть к этому доступа. Это отличный способ доказать дизайн, прежде чем писать код.
4) Сначала дизайн, потом кодирование, потом симуляция.
5) Строго набирается, также сохраняйте согласованность имен сигналов на схемах pcb и hdl. (это также, почему я предпочитаю VHDL над Verilog.

Скачок напряжения
источник
2
+1 за "кубик" или sямULaTяоN3
Пеббельс
Неплохо: к «строгому дизайну» я бы добавил «использование системы типов». Пример: индекс массива соответствующего типа, такого как диапазон массива, не нужно проверять состояние вне границ. Я бы только не согласился с «формой волны по сравнению с спроектированной формой волны на бумаге» ... на этой стадии спроектированная форма волны должна быть в VHDL (или, возможно, считываться из текстового файла), и симулятор должен выполнить сравнение.
Брайан Драммонд
Это также может быть сделано таким образом, я нашел полезным разработать форму волны на бумаге, потому что она дает что-то для сравнения. Как и в случае сигнала АЦП, время было спроектировано и затем сопоставлено с выходным сигналом Modlesim, а затем проверено физически. Если вывод modelsim правильный, сравните его с этим. Код был строго напечатан (я забыл упомянуть об этом), но это действительно важно. Вот почему я предпочитаю VHDL, а не Verilog, есть меньше ярлыков, которые вы можете использовать. И это делает код намного более читабельным.
Напряжение Спайк
да. На самом деле, как и в других областях, таких как программное обеспечение или обычное оборудование, отправная точка состоит в том, чтобы разбить проблему на блоки, а затем спросить себя, «как я узнаю, когда этот блок будет работать». Затем сделать его. Создайте свой дизайн блок за блоком, затем соедините блоки и снова проверьте, что вы получаете то, что ожидается. Иногда вы можете понять, что с лучшим дизайном на уровне блоков это будет чище или проще, поэтому вы возвращаетесь.
danmcb
6

Основные вещи:

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

У меня было несколько довольно сложных конструкций, работающих корректно (или, по крайней мере, в основном правильно) в первом тесте на реальной ПЛИС, следуя приведенному выше. Нет необходимости проверять схему RTL, это просто чрезвычайно громоздко и является полной тратой времени на крупные проекты. Моделирование после синтеза было бы гораздо более полезным.

alex.forencich
источник
1
Спасибо за ваш быстрый ответ. Не могли бы вы уточнить второй пункт (минимизировать логические уровни).
Айронштейн
5

Весь ваш синтезируемый код должен быть выражен как:

  • ТМП
  • Шлепки
  • Специфичные для поставщика примитивы

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

В VHDL, например, вы не можете использовать wait forв синтезируемом коде. Чтобы понять почему, попробуйте детерминистически выразить, wait for 100 nsиспользуя LUT или триггеры. Ты не можешь

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

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

apalopohapa
источник
wait until rising_edge(clk);конечно, можно синтезировать, хотя некоторые инструменты накладывают ограничения на его использование.
Брайан Драммонд
2

Самый очевидный первый шаг - проверить предупреждения.

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

Затем вам нужно установить временные ограничения. Как быстро после нарастающего фронта на тактовом сигнале A необходимо установить линию данных B? Или как долго нужно удерживать линию данных B до падения фронта на часах A? Временные ограничения позволят вам указать все это. Если у вас нет временных ограничений, компилятор может предположить, что вас это не особенно волнует, и может направить ваши сигналы куда угодно. Если у вас есть временные ограничения, компилятор будет работать, чтобы ваши сигналы соответствовали этим ограничениям, перемещая размещение вокруг. И если он не может соответствовать временным ограничениям, он выдаст предупреждение.

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

Грэхем
источник