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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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