Прототипирование программируемых вентильных матриц ( прототипирование ПЛИС ), также называемое прототипированием на основе ПЛИС, прототипированием ASIC или прототипированием систем на кристалле (SoC), представляет собой метод прототипирования систем на кристалле и специализированных интегральных схем на ПЛИС для проверки оборудования и ранней разработки программного обеспечения .
Методы проверки для проектирования оборудования , а также раннее совместное проектирование программного обеспечения и прошивки стали мейнстримом. Прототипирование проектов SoC и ASIC с одним или несколькими FPGA и программным обеспечением для автоматизации электронного проектирования (EDA) стало хорошим методом для этого. [1]
Проектирование для прототипирования [5] ( DFP ) относится к проектированию систем, которые поддаются прототипированию . Многие из препятствий, с которыми сталкиваются команды разработчиков, которые принимают прототипы FPGA, можно свести к трем «законам»:
Помещение проекта SoC в прототип FPGA требует тщательного планирования для достижения целей прототипирования с минимальными усилиями. Для облегчения разработки прототипа передовые практики, называемые Design-for-Prototyping, влияют как на стиль проектирования SoC , так и на процедуры проекта, применяемые проектными группами. Процедурные рекомендации включают добавление соглашений DFP к стандартам кодирования RTL, использование среды моделирования, совместимой с прототипом, и внедрение стратегии отладки системы совместно с командой программного обеспечения.
Из-за возросшей сложности схемы и сокращения времени выхода на рынок растет потребность в проверке проектов специализированных интегральных схем (ASIC) и систем на кристалле (SoC). Аппаратные платформы становятся все более популярными среди инженеров-верификаторов из-за возможности тестировать проекты систем на скорости с тактовыми генераторами шины на кристалле по сравнению с тактовыми генераторами моделирования, которые могут не обеспечивать точного считывания поведения системы. [6] Эти проекты с несколькими миллионами вентилей обычно размещаются на платформе прототипирования с несколькими FPGA с шестью или более FPGA, поскольку они не могут полностью поместиться на одной FPGA. Чем меньше FPGA, тем больше проект должен быть разделен, чтобы уменьшить усилия инженера-конструктора. [7] Справа представлена фотография платформы прототипирования на основе FPGA, использующей конфигурацию с двумя FPGA.
Системные RTL-проекты или списки соединений должны быть разделены на каждой ПЛИС, чтобы иметь возможность разместить проект на платформе прототипирования. [8] Это создает новые проблемы для инженера, поскольку ручное разделение требует огромных усилий и часто приводит к низкой скорости (тестируемого проекта). [7] Если количество разделов может быть уменьшено или весь проект может быть помещен на одну ПЛИС, реализация проекта на платформе прототипирования становится проще.
При создании разделов схемы инженеры должны сначала изучить доступные ресурсы, которые предлагает FPGA, поскольку проект будет размещен на структуре FPGA. [7] Архитектура каждой FPGA зависит от производителя, но главная цель при разделении проекта — обеспечить равномерный баланс использования ресурсов FPGA. Различные ресурсы FPGA включают таблицы поиска (LUT), D-триггеры , блочные ОЗУ , цифровые сигнальные процессоры (DSP), тактовые буферы и т. д. Перед балансировкой разделов проекта пользователю также полезно выполнить глобальную оптимизацию логики , чтобы удалить любую избыточную или неиспользуемую логику. Типичная проблема, которая возникает при создании сбалансированных разделов, заключается в том, что это может привести к конфликту времени или ресурсов, если разрез происходит на многих сигнальных линиях. Чтобы иметь полностью оптимизированную стратегию разделения, инженер должен учитывать такие вопросы, как ограничения времени/мощности, а также размещение и маршрутизация, при этом сохраняя сбалансированное разделение между FPGA. Строгое сосредоточение на одной проблеме во время разделения может создать несколько проблем в другом.
Чтобы достичь оптимального расположения и маршрутизации для секционированных проектов, инженер должен сосредоточиться на количестве выводов FPGA и сигналах между FPGA. После разделения проекта на отдельные FPGA количество сигналов между FPGA не должно превышать количество выводов на FPGA. [9] Этого очень трудно избежать, когда схемы имеют огромные размеры, поэтому сигналы должны использовать такие стратегии, как мультиплексирование с временным разделением (TDM), при котором несколько сигналов могут передаваться по одной линии. [10] Эти несколько сигналов, называемые подканалами, по очереди передаются по линии в течение временного интервала. Когда отношение TDM высокое, тактовую частоту шины необходимо уменьшить, чтобы разместить временные интервалы для каждого подканала. Уменьшение тактовой частоты затрудняет пропускную способность системы. [7]
Проекты систем обычно охватывают несколько доменов синхронизации с сигналами, проходящими через отдельные домены. [7] Встроенные генераторы синхронизации и глобальные линии синхронизации обычно смягчают эти проблемы, но иногда эти ресурсы могут быть ограничены или не соответствовать всем требованиям дизайна. Внутренние часы должны быть реализованы в устройствах FPGA, поскольку соединения линии синхронизации и буферов синхронизации ограничены между FPGA. Внутренние синхронизированные проекты, которые разделены на несколько FPGA, должны копировать генератор синхронизации в FPGA, обеспечивая низкий перекос синхронизации между сигналами между FPGA. Кроме того, любая логика стробируемых часов должна быть преобразована в тактовые, позволяющие уменьшить перекос при работе на высоких тактовых частотах.
Пересечения доменов синхронизации не должны быть разделены на отдельные FPGA. Сигналы, проходящие через пересечение, должны оставаться внутренними для одного FPGA, поскольку добавленное время задержки между FPGA может вызвать проблемы в другом домене. Также рекомендуется, чтобы сигналы, проходящие между FPGA, тактировались в регистрах.
Одной из самых сложных и трудоемких задач в прототипировании FPGA является отладка системных проектов. Для этого придуман термин «FPGA hell». [11] [12] Отладка стала более сложной и трудоемкой с появлением больших, сложных проектов ASIC и SoC. Для отладки прототипа FPGA зонды добавляются непосредственно в проект RTL, чтобы сделать определенные сигналы доступными для наблюдения, синтезируются и загружаются на платформу прототипа FPGA.
Поставщики FPGA, включая ChipScope и SignalTAP, предлагают ряд стандартных инструментов отладки. Эти инструменты могут исследовать максимум 1024 сигнала и требуют обширных ресурсов LUT и памяти. Для SoC и других конструкций эффективная отладка часто требует одновременного доступа к 10 000 или более сигналов. Если ошибка не может быть обнаружена исходным набором датчиков, получение доступа к дополнительным сигналам приводит к ситуации «иди домой на день». Это связано с длительными и сложными потоками САПР для синтеза, размещения и маршрутизации, которые могут потребовать от 8 до 18 часов для завершения.
Улучшенные подходы включают такие инструменты, как Certus от Tektronix [13] или EXOSTIV от Exostiv Labs. [14]
Certus обеспечивает улучшенную видимость уровня RTL для отладки на основе FPGA. Он использует высокоэффективный многоступенчатый концентратор в качестве основы для своей сети наблюдения, чтобы уменьшить количество LUT, требуемых для каждого сигнала, чтобы увеличить количество сигналов, которые могут быть исследованы в заданном пространстве. Возможность просмотра любой комбинации сигналов является уникальной для Certus и устраняет одно из самых критических узких мест прототипирования. [15]
EXOSTIV использует большой внешний накопитель и гигабитные трансиверы для извлечения глубоких трасс из FPGA, работающей на скорости. Улучшение заключается в его способности видеть большие трассы во времени как непрерывный поток или в пакетах. Это позволяет исследовать расширенные сценарии отладки, которые не могут быть достигнуты традиционными методами встроенного инструментария . Решение утверждает, что экономит как ресурсы ввода-вывода FPGA, так и память FPGA за счет гигабитных трансиверов, для улучшения видимости в 100 000 раз и более. [16] [17]