Современные средства генерирования VHDL описаний аппаратуры при проектировании программируемых схем FPGA

Заметка редактора

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

Введение

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

Например, в области программного обеспечения машинный код (двоичная последовательность) когда-то был единственным языком, который можно было использовать для программирования компьютера. В 1950-х годах была введена концепция ассемблера (и ассемблера). Наконец, языки высокого уровня (HLL) и связанные с ними методы компиляции были разработан для повышения производительности программного обеспечения. HLL, которые не зависят от платформы, следуют правилам человеческого языка с грамматикой, синтаксисом и семантикой. Таким образом, они обеспечивают гибкость и портативность, скрывая детали компьютерной архитектуры. Язык ассемблера сегодня используется только в ограниченных сценариях, прежде всего, для оптимизации критических частей программы, когда существует абсолютная потребность в скорости и компактности кода, или в обоих. Однако с ростом сложности как современных системных архитектур, так и программных приложений использование HLL и компиляторов явно дает лучшие общие результаты. Никто сегодня даже не подумает о программировании сложного программного приложения исключительно на языке ассемблера.

В области аппаратного обеспечения спецификация языки и методологии проектирования развивались аналогично. 1 , 2 По этой причине, до конца 1960-х годов, IC были разработаны, оптимизирован и выложен вручную. Моделирование на уровне ворот появилось в начале 1970-х годов, и моделирование на основе циклов стало доступно к 1979 году. Методы, введенные в 1980-х годах, включали в себя определение местоположения и схемы, захват схемы, формальную проверку, и статический анализ времени. Языки описания оборудования (HDL), такие как Verilog (1986) и VHDL (1987), позволили широкое внедрение моделирования инструменты. Эти ЛПВП также служили входами в логику инструменты синтеза, ведущие к определению их синтезируемых подмножеств. В течение 1990-х годов первое поколение коммерческие инструменты синтеза высокого уровня (HLS) были коммерчески доступны. 3,4 Примерно в то же время, исследования интерес к программно-аппаратным кодам оценка, исследование, разделение, взаимодействие, коммуникация, синтез и косимуляция получили импульс. 5 Концепция IP ядра и платформы на основе дизайн начал появляться. 6-8 В 2000-х годах произошел переход к парадигме электронного уровня системы (ESL), которая облегчает исследование, синтез и проверку сложных SoC. 9 Это включает в себя введение языков с системными абстракциями, такими как SystemC (http://www.systemc.org), SpecC (http: // www.cecs.uci.edu/~specc) или SystemVerilog (IEEE 1800-2005; http://standards.ieee.org) и внедрение моделирования на уровне транзакций (TLM). Сдвиг парадигмы ESL, вызванный ростом сложности системы, множеством компонентов в продукте (сотни процессоров в машине, например), множество версий чипа (для лучшей дифференциации продукта) и взаимозависимость компонентов поставщики заставили рынок сосредоточиться на оборудовании производительность программного обеспечения, надежность, функциональная совместимость и возможность повторного использования. В этом контексте настройка процессора и HLS стали необходимыми путями к эффективный дизайн ESL. 10 Новая СВА потоков, в дополнении чтобы сократить время на создание оборудования, а также помочь сократить время, чтобы проверить это, а также облегчить другие потоки, такие как анализ мощности.

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

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

Инструменты HLS преобразуют несвязанный (или частично синхронизированный) высокоуровневая спецификация в полностью синхронизированную реализацию. 10-13 Они автоматически или полуавтоматически генерируют собственную архитектуру для эффективной реализации спецификация. В дополнение к банкам памяти и интерфейсы связи, сгенерированная архитектура описана в RTL и содержит тракт данных (регистры, мультиплексоры, функциональные блоки, и автобусы) и контроллер, как того требует спецификация и конструктивные ограничения.

Ключевые идеи

Начиная с высокоуровневого описания приложения, библиотеки компонентов RTL и конкретного дизайна ограничения, инструмент HLS выполняет следующие задачи (см. рисунок 1):

1. составляет спецификацию,
2. выделяет аппаратные ресурсы (функциональные блоки, компоненты для хранения, автобусы и т. д.),
3. планирует операции по тактам,
4. привязывает операции к функциональным единицам,
5. привязывает переменные к элементам хранения,
6. связывает переводы на автобусы, и
7. генерирует архитектуру RTL

Задачи со 2 по 6 являются взаимозависимыми, и для достижения оптимального решения проектировщик в идеале должен быть оптимизирован совместно. Чтобы справиться с реальным миром проекты, однако, задачи обычно выполняются в последовательность для управления вычислительной сложностью синтез. Особый порядок некоторых синтеза задачи, а также мера того, насколько хорошо взаимозависимости оцениваются и учитываются, значительно влияет на качество созданного дизайна. Подробнее доступны в другом месте. 10-13

Компиляция и моделирование

HLS всегда начинается с составления функциональной спецификации. Этот первый шаг преобразует входное описание в формальное представление.

Этот первый шаг традиционно включает в себя несколько оптимизаций кода, таких как устранение мертвого кода, устранение ложных зависимостей данных и постоянное свертывание и преобразования цикла. Формальная модель, созданная компиляцией, классически показывает данные и управляющие зависимости между операциями. Зависимости данных могут быть легко представлены с помощью графика потока данных (DFG), в котором каждый узел представляет операцию, а дуги между узлами представляют входные, выходные и временные переменные. Только 12 чистых DFG зависимостей модели данных. В некоторых случаях эту модель можно получить, удалив управляющие зависимости начальной спецификации из модели во время компиляции. Для этого циклы полностью развертываются путем преобразования в неитеративные кодовые блоки, а условные присвоения разрешаются путем создания мультиплексированных значений. Результирующий DFG явно демонстрирует весь внутренний параллелизм спецификации. Однако необходимые преобразования могут привести к большому формальному представлению, которое требует значительного объема памяти для хранения во время синтеза. Более того, это представление не поддерживает циклы с неограниченным количеством итераций и нестатические операторы управления, такие как goto . Это ограничивает использование чистых представлений DFG несколькими приложениями. Модель DFG была расширена за счет добавления зависимостей управления: графика управления и потока данных (CDFG). 12-15 CDFG - это ориентированный граф, в котором ребра представляют поток управления. Узлы в CDFG обычно называют базовыми блоками и определяются как прямолинейная последовательность операторов, которые не содержат ветвей или внутренних точек входа или выхода. Края могут быть условными для представления конструкций if и switch . CDFG демонстрирует зависимости данных внутри базовых блоков и фиксирует поток управления между этими базовыми блоками. CDFG более выразительны, чем DFG, потому что они могут представлять циклы с неограниченными итерациями. Однако параллелизм является явным только внутри базовых блоков, и требуется дополнительный анализ или преобразования для выявления параллелизма, который может существовать между базовыми блоками. Такие преобразования включают в себя, например, развертывание цикла, конвейерную обработку цикла, объединение цикла и разбиение цикла. Эти методы, выявляя параллельность между циклами и между итерациями цикла, используются для оптимизации задержки или пропускной способности, а также размера и количества обращений к памяти. Эти преобразования могут быть реализованы автоматически , 14 или они могут быть управляемыми пользователем. 10 В дополнение к управляющим зависимостям, зависимости данных между базовыми блоками могут быть добавлены в модель CDFG как показано в иерархическом представлении графа задачи, используемом в инструменте SPARK. 14,16 Распределение Распределение определяет тип и количество аппаратных ресурсов (например, функциональных блоков, компонентов хранения или компонентов связи), необходимых для удовлетворения проектных ограничений. В зависимости от инструмента HLS некоторые компоненты могут быть добавлены во время задач планирования и связывания. Например, компоненты подключения (такие как шины или двухточечные соединения между компонентами) могут быть добавлены до или после задач связывания и планирования. Компоненты выбираются из библиотеки компонентов RTL. Важно выбрать хотя бы один компонент для каждой операции в модели спецификации. Библиотека также должна включать характеристики компонентов (таких как площадь, задержка и мощность) и ее метрики, которые будут использоваться другими задачами синтеза. Планирование Все операции, требуемые в модели спецификации, должны быть запланированы в циклы. Другими словами, для каждой операции , такие как ? б ор c, переменные b и c должны быть считаны из их источников (либо компонентов хранения, либо компонентов функциональных блоков) и выведены на вход функционального блока, который может выполнять операцию op, а результат a должен быть доставлен по назначению (хранилище или функциональные единицы).

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

Связывание

Каждая переменная, которая переносит значения между циклами, должна быть связана с единицей хранения. Кроме того, несколько переменных с неперекрывающимися или взаимоисключающими временами жизни могут быть связаны с одними и теми же блоками хранения. Каждая операция в модели спецификации должна быть связана с одним из функциональных блоков, способных выполнить операцию. Если есть несколькоблоков с такой возможностью алгоритм привязки должен оптимизировать этот выбор. Связывание хранилища и функционального блока также зависит от привязки подключения, которая требует, чтобы каждый перенос от компонента к компоненту был связан с блоком подключения, таким как шина или мультиплексор (см., Например, http: //www-labsticc.univ-ubs. FR / WWW-Гаут /). В идеале, высокоуровневый синтез оценивает задержку подключения и площадь как можно раньше, чтобы последующие этапы HLS могли лучше оптимизировать проект. Альтернативный подход заключается в указании полной архитектуры во время выделения, чтобы можно было использовать первоначальные результаты планирования этажей во время привязки и планирования (см. Http://www.cecs.uci.edu/~nisc ). Генерация После принятия решений в предыдущих задачах выделения, планирования и связывания цель этапа генерации архитектуры RTL состоит в том, чтобы применить все принятые проектные решения и сгенерировать модель RTL синтезированного проекта. Архитектура. Архитектура RTL реализована с помощью набора компонентов передачи регистров. Обычно он включает в себя контроллер и путь к данным (см. Рисунок 2). Путь данных состоит из набора элементов хранения (таких как регистры, файлы регистров и запоминающие устройства), набора функциональных блоков (таких как ALU, множители, сдвиги и другие пользовательские функции) и элементов взаимосвязи (таких как драйверы Tristate). , мультиплексоры и автобусы). Все эти компоненты передачи регистра могут быть распределены в разных количествах и типах и произвольно подключены через шины. Каждый компонент может выполнять один или несколько тактовых циклов, может быть конвейерным и может иметь входные или выходные регистры. Кроме того, весь путь данных и контроллер могут быть конвейеризованы в несколько этапов. Первичные входные и выходные порты проектируемого интерфейса взаимодействуют с внешним миром для передачи как данных, так и управления (используются для согласования протокола синхронизации и синхронизации). Входы и выходы данных подключены к тракту данных, а входы и выходы управления подключены к контроллеру. Также имеются управляющие сигналы от контроллера к тракту данных и сигналы состояния от тракта данных к контроллеру. Тем не менее, некоторые архитектуры не могут иметь все соединения только что описанные, и в общем случае некоторые из функций контроллера может быть реализованы как часть данных pathfor например, счетчик плюс другой логики в тракте передачи данных , который генерирует управляющие сигналами. Контроллер представляет собой конечный автомат, который управляет потоком данных в тракте данных путем установки значений управляющих сигналов (также называемых управляющим словом), таких как входы выбора функциональных блоков, регистров и мультиплексоров. Входы в контроллер могут поступать от первичных входов (входы управления) или от компонентов тракта передачи данных, таких как компараторы и т. Д. (Сигналы состояния). Контроллер состоит из регистра состояния (SR), логики следующего состояния и логики вывода. SR хранит текущее состояние процессора, которое равно текущему состоянию модели конечного автомата (FSM), описывающей работу контроллера. Логика следующего состояния вычисляет следующее состояние, которое будет загружено в SR, тогда как логика выхода генерирует управляющие сигналы и управляющие выходы. Контроллер простого выделенного сопроцессора классически реализован с помощью проводных логических вентилей. С другой стороны, контроллер может быть программируемым с программным запоминающим устройством только для чтения или только для чтения для конкретного пользовательского процессора. В этом случае в памяти программы могут храниться инструкции или просто управляющие слова, которые длиннее, но не требуют декодирования. В таких обстоятельствах SR называется счетчиком программ, логика следующего состояния - это генератор адресов, а логика вывода - RAM или ROM. Выходная модель. В соответствии с решениями, принятыми в задачах связывания, описание архитектуры может быть написано на RTL с различными уровнями детализации (то есть без привязки или с частичной или полной привязкой). Например, a ? b ? c, выполняющийся в состоянии ( n ), можно записать так, как показано на рисунке 3:

Когда описание RTL включает в себя только частичное связывание ресурсов, этап логического синтеза, который следует за HLS, должен выполнить задачу связывания и связанную оптимизацию. Оставление компонентов несвязанными в сгенерированном RTL обеспечивает RTL и физическому синтезу гибкость для оптимизации привязок на основе обновленных временных оценок, которые учитывают нагрузку на проводную связь из-за физических ( планирование этажей и место и маршрут) соображений. Несколько потоков проектирования Распределение, планирование и привязка могут выполняться одновременно или в определенной последовательности в зависимости от используемой стратегии и алгоритмов. Однако все они взаимосвязаны. Если они выполняются вместе, процесс синтеза становится слишком сложным, чтобы применять его к реалистичным примерам. Порядок, в котором они реализуются, зависит от проектных ограничений и целей инструмента. Например, распределение будет выполнено первым, когда планирование попытается минимизировать задержку или максимизировать пропускную способность при ограничении ресурсов. Распределение будет определено во время планирования, когда планирование пытается минимизировать область при временных ограничениях. 17 Подходы с ограниченными ресурсами используются, когда разработчик хочет определить архитектуру тракта данных 18 , 19 или хочет ускорить приложение, используя устройство FPGA с ограниченным количеством доступных ресурсов. 20 ограниченных во время подходов СЭДА , когда цель состоит в том, чтобы уменьшить площадь цепи , в то время удовлетворения требований пропускной способности приложений ', как и в мультимедийных или телекоммуникационных приложениях. 21 На практике проблему с ограниченными ресурсами можно решить, используя ограниченный во времени подход или инструмент (и наоборот). В этом случае разработчик ослабляет временные ограничения до тех пор, пока предоставленная область схемы не станет приемлемой. Задержка, пропускная способность, количество ресурсов и область теперь являются хорошо известными ограничениями и целями. Однако в недавней работе были рассмотрены такие особенности, как тактовый интервал, пропускная способность памяти, отображение памяти , энергопотребление и т. Д., Которые еще более затрудняют решение проблемы синтеза. 10 , 22 -24 Другой пример того, как можно упорядочить задачи синтеза, касается этапов выделения и связывания. Типы и номера ресурсов, определенные в задаче выделения, принимаются в качестве входных данных для задачи привязки. Однако в практических инструментах HLS ресурсы часто распределяются только частично. Дополнительные ресурсы выделяются на этапе привязки в соответствии с ограничениями и целями проекта. Эти дополнительные ресурсы могут быть любого типа: функциональные блоки, мультиплексоры или регистры. Следовательно, функциональные блоки могут быть сначала выделены для планирования и связывания операций. И регистры, и мультиплексоры могут быть выделены (созданы) на этапе привязки переменной к регистру . Задачи синтеза могут быть выполнены вручную или автоматически. Очевидно, что возможны многие стратегии, что подтверждается доступными инструментами EDA: эти инструменты могут выполнять каждую из вышеупомянутых задач только частично в автоматическом режиме, а остальное оставляется на усмотрение дизайнера. 10

Промышленные инструменты

Здесь мы кратко рассмотрим сначала коммерчески доступные инструменты HLS для задания описания входа, а затем мы более внимательно рассмотрят два stateof -The-арт промышленных HLS инструментов. Языки ввода и инструменты Спецификация вход должен захватить предполагаемый функциональность дизайна на высоком уровне абстракции. Скорее чем кодирование деталей реализации низкого уровня, разработчик использует автоматизацию, предоставляемую инструментом HLS руководить проектными решениями, которые сильно зависят о целях производительности и целевой технологии. За Например, если в спецификации HLS есть параллелизм, он извлекается с использованием анализа потока данных в соответствии с возможностями целевой технологии и Цели производительности (при медленной технологии для достижения цели производительности требуется больше параллелизма). Последнее поколение инструментов HLS, в большинстве случаев, использует ANSI C, C ++ или такие языки, как SystemC которые основаны на C или C ++, которые добавляют аппаратное обеспечение с onstructs , такие как выбор времени, аппаратной иерархии, интерфейсных портов, сигналов, явной спецификации параллелизма, и другие. Некоторые инструменты HLS, которые поддерживают C или C ++ или производными являются катапульта Ментора C (C, C ++), Синтезатор Forte ( SystemC ), CyberWorkbench от NEC (C с аппаратными расширениями), PICO (C) Synfora и C-to-Silicon ( SystemC ). Другие языки используется для моделирования высокого уровня MathWork's Matlab и симулинк. Инструменты, которые поддерживают Matlab или Simulink Xilinx ' AccelDSP ( Matlab ) и Synopsys' SimplifyDSP (Simulink); оба используют IP-подход для генерации аппаратной реализации. Альтернатива подход для генерации реализации заключается в использовании конфигурируемый процессорный подход, который является подход как процессора процессоров CoWare и Tensilica - х Xtensa . Другие языки, не основанные на C или C ++, но которые адаптированы к конкретным доменам, также были предложены. Esterel - синхронный язык для разработки реактивных систем. Студия Эстерель может генерировать программное или аппаратное обеспечение. Bluespec - х BSV - язык, предназначенный для определения параллелизма с основанными на правилах атомарными транзакциями. Спецификация ввода для инструментов HLS должна быть написана с учетом некоторой аппаратной реализации, чтобы получить лучшие результаты. Например, буферизация видео строки должен быть закодирован как часть алгоритма для генерации высокопроизводительные конструкции. 25 В идеале такая реструктуризация кода все еще сохраняет большую часть уровня абстракции. Это выходит за рамки данной статьи, чтобы предоставить обзор конкретных стилей письма, требуемых в спецификации для различных инструментов. По мере развития возможностей инструментов кроме того, потребуется меньше модификаций для преобразования алгоритма, написанного для программного обеспечения, в алгоритм, подходящий для ввода в HLS. Аналог эволюция произошла с синтезом RTL, например, с оптимизацией арифметических выражений.

Синтез Catapult С

Catapult использует алгоритм, написанный на ANSI C ++ и набор пользовательских директив в качестве входных данных и генерирует RTL, оптимизированный для указанной целевой технологии. Ввод может быть скомпилирован по любому стандарту компилятор, совместимый с C ++; Прагмы и директивы не меняйте функциональное поведение входа Спецификация.

Входная спецификация является последовательной и не включает в себя никакого понятия времени или явного параллелизм: он не жестко кодирует интерфейс или Архитектура дизайна. Сохранение входного реферата необходимо, потому что любое жесткое кодирование интерфейса и архитектурных деталей значительно ограничивает диапазон проекты, которые HLS может генерировать. Обязательные директивы указать целевую технологию (библиотека компонентов) и период времени. Необязательные директивы управления интерфейсом синтеза, отображения массивов в память, количество обнаружение параллелизма путем развертывания цикла, конвейерной передачи цикла, аппаратной иерархии и блочной связи, планирование (задержка или цикл) ограничения, распределение директивы, чтобы ограничить количество или тип оборудования ресурсы и тд. Собственные целочисленные типы C ++, а также C ++ с точностью до бита Поддерживаются целочисленные и фиксированные типы данных.

Сгенерированный RTL точно отражает поведение с битовой точностью, указанное в источнике. Общедоступные целочисленные и фиксированные типы данных, предоставляемые Mentor Graphics '( http://www.mentor.com/esl ), библиотека алгоритмических типов данных C (заголовочные файлы ANSI C ++), а также синтезируемое подмножество целочисленных и фиксированных целочисленных значений SystemC. точечные типы данных поддерживаются для синтеза. Поддержка языковых конструкций C ++ соответствует и превосходит требования, изложенные в самом последнем проекте стандарта Synthesis Subset OSCI ( http://www.systemc.org ). Генерация оборудования из ANSI C или C ++. Одно из преимуществ сохранения источника в том, что он может генерировать очень широкий спектр интерфейсов и архитектур без изменения спецификации входного источника. Еще одним преимуществом несвязанного источника является то, что он позволяет избежать ошибок, возникающих в результате ручного кодирования архитектурных деталей. Интерфейс и архитектура созданного оборудования находятся под контролем разработчика с помощью директив синтеза. Графический интерфейс Catapult предоставляет интерактивную среду с инструментами управления и анализа, позволяющими эффективно исследовать пространство проектирования. Синтез интерфейса позволяет отобразить передачу данных, которая подразумевается путем передачи аргументов функции C ++ в различные аппаратные интерфейсы, такие как провода, регистры, память, шины или более сложные пользовательские интерфейсы. Все необходимые сигналы и временные ограничения генерируются во время процесса синтеза, так что сгенерированный RTL соответствует и оптимизируется под требуемые интерфейсы. Например, массив в источнике C может привести к аппаратному интерфейсу, который передает данные или передает данные через память, банк регистров и т. Д. Выбор интерфейса потоковой передачи подразумевает, что среда предоставляет данные в порядке последовательного индекса, тогда как выбор интерфейса памяти подразумевает, что среда предоставляет данные путем записи массива в память. Зернистость передачи sizefor Например, количество элементов массива , предоставленные в качестве транспортирующего потока или в качестве памяти wordis также задаваема как директива пользователя. Иерархия (параллелизм на уровне блоков) может быть указана пользовательскими директивами. Например, функция C может быть синтезирована как отдельный аппаратный блок, а не встроена . Иерархия также может быть указана в стиле, соответствующем модели вычисления сети процесса Кана (по-прежнему в последовательном ANSI C ++). Блоки связаны с соответствующими каналами связи, и необходимые интерфейсы установления связи генерируются, чтобы гарантировать правильное выполнение указанного поведения. Блоки могут быть синтезированы для управления разными часами. Логика пересечения часового домена генерируется Catapult. Связь оптимизируется в соответствии с пользовательскими директивами, чтобы обеспечить максимальный параллелизм выполнения блоков на уровне блоков с использованием буферов FIFO (для потоковых данных) и памяти ping-pong, чтобы включить конвейерную обработку на уровне блоков и, таким образом, повысить пропускную способность всего проекта. На всех этапах HLS учитываются точные значения площади компонентов и времени для целевой технологии ASIC или FPGA для выбранного синтезатором RTL-инструмента. Точная синхронизация и номера областей для компонентов важны для генерации RTL, которая соответствует синхронизации и оптимизирована для области. Во время синтеза Catapult запрашивает библиотеку компонентов, чтобы она могла выделить различные комбинационные или конвейерные компоненты с разной компромиссной производительностью и областями. Библиотека запрашиваемых компонентов предварительно охарактеризована для целевой технологии и целевого инструмента синтеза RTL. Библиотеки компонентов также могут быть сконструированы разработчиком для включения определенных характеристик памяти, шин, интерфейсов ввода / вывода или других функциональных блоков, таких как конвейерные компоненты. Проверка и оценка мощности потоков. В процессе синтеза создается необходимая инфраструктура верификации в SystemC, чтобы входные стимулы из исходного тестового стенда C ++ можно было применить к сгенерированному RTL для проверки его функциональных возможностей в соответствии с (золотой) спецификацией исходного кода C ++ с использованием моделирования. Процесс синтеза также генерирует необходимую инфраструктуру проверки (оболочки и сценарии), чтобы обеспечить возможность последовательной проверки эквивалентности между исходной спецификацией C ++ и сгенерированным RTL. Автоматическое создание инфраструктуры проверки имеет важное значение, поскольку интерфейс сгенерированного оборудования сильно зависит от синтеза интерфейса. Потоки оценки мощности сторонними инструментами позволяют разработчику собирать данные о коммутации для проекта и получать оценки мощности RTL и уровня затвора. Изучая различные архитектуры, разработчик может быстро перейти к дизайну с низким энергопотреблением, который соответствует требуемым показателям производительности и задачам. Catapult успешно использовался в более чем 200 ASIC-выходах и нескольких сотнях FPGA. Типичные приложения включают в себя вычислительные алгоритмы для связи, обработки видео и изображений.

Cynthesizer SystemC синтез

Cynthesizer использует модуль SystemC, содержащий иерархию, несколько процессов, интерфейсные протоколы и алгоритмы, и создает RTL Verilog, оптимизированный для конкретной целевой технологии и тактовой частоты. Целевая технология определяется предоставленным пользователем файлом .lib или, для реализации FPGA, пользователем, определяющим целевую часть Xilinx или Altera. Синтез ввода. Входной поток HLS, используемый с синтезатором, представляет собой модель SystemC с точным выводом и протоколом . Поскольку SystemC является библиотекой классов C ++, для повторного использования алгоритмов, написанных на C ++, языковой перевод не требуется. Синтезируемое подмножество довольно обширно, включая классы и структуры, перегрузку операторов и специализацию шаблонов C ++. Конструкции, которые не поддерживаются для синтеза, включают динамическое размещение ( malloc , free, new и delete), арифметику указателей и виртуальные функции. Разработчик помещает несвязанный высокоуровневый C ++ в аппаратный контекст, используя SystemC для представления аппаратных элементов, таких как порты, границы синхронизации, структурная иерархия, типы данных с битовой точностью и параллельные процессы. Как показано на рисунке 4, синтезируемый SC_MODULE может содержать несколько экземпляров SC_CTHREAD и несколько экземпляров SC_METHOD, а также экземпляры субмодуля и сигналы для внутренних соединений. Порты ввода / вывода имеют уровень сигнала SystemC sc_in и sc_out порты. Экземпляры SC_MODULE являются классами C ++, поэтому они также могут содержать функции-члены C ++ и члены-данные (переменные), которые представляют поведение модуля и локальное хранилище соответственно. Процессы с синхронизированными потоками, реализованные как SystemC Экземпляры SC_CTHREAD используются для большей части функциональности модуля. Они содержат бесконечный цикл, который реализует основную часть функциональности, а также код сброса, который инициализирует порты ввода-вывода и переменные. Конструкция синхронизированного потока SystemC обеспечивает необходимую семантику сброса. В потоке разработчик может объединить несвязанный код вычислений с кодом протокола с точностью до цикла. Разработчик определяет протокол, написав код SystemC, содержащий операторы ввода-вывода портов и операторы wait ( ) . Синтезатор использует гибридный подход к планированию, при котором код протокола распределяется с точностью до цикла, соблюдая границы тактового сигнала, указанные разработчиком как SystemC операторы wait ( )

Вычислительный код написан без каких-либо операторов wait ( ) и запланирован инструментом для удовлетворения задержки, конвейерной обработки и других ограничений, заданных разработчиком. Триггерные методы, реализованные как SystemC Экземпляры SC_METHOD также можно использовать для реализации поведения, которое запускается активностью сигналов в списке чувствительности, аналогично блоку Verilog всегда . Это позволяет при необходимости использовать сочетание стилей кодирования высокого и низкого уровня. Сложные подсистемы создаются и проверяются путем объединения модулей с использованием структурной иерархии, как в Verilog или VHDL. Модели высокого уровня, используемые в качестве входных данных для синтеза, могут быть смоделированы непосредственно для проверки как алгоритмов, так и способа взаимодействия кода алгоритма с кодом протокола интерфейса. Несколько модулей моделируются вместе для проверки правильности их взаимодействия для реализации функциональных возможностей иерархической подсистемы. Ориентация на конкретный технологический процесс. Чтобы гарантировать, что синтезированный RTL соответствует требованиям к синхронизации при заданной тактовой частоте с использованием определенной технологии литейного производства и процесса, инструмент HLS требует точных оценок временных характеристик каждой операции. Cynthesizer использует внутренний механизм оптимизации пути данных для создания библиотеки сумматоров, множителей и т. Д. Это занимает несколько часов для конкретной технологии процесса и тактовой частоты и может быть выполнено разработчиком с учетом любого файла библиотеки. Синтезатор использует временные характеристики и характеристики области этих компонентов, чтобы найти компромисс и оптимизировать RTL. Разработчики имеют возможность использовать шлюзы для реализации или использовать RTL-представления компонентов тракта данных для логического синтеза. Синтез вывода. Cynthesizer производит RTL Verilog для использования с инструментами синтеза логики, предоставленными поставщиками EDA для технологий ASIC и FPGA. RTL состоит из FSM и набора явно созданных компонентов пути к данным, таких как множители, сумматоры и мультиплексоры. Более сложные пользовательские компоненты пути к данным, которые реализуют арифметические выражения, используемые в проекте, создаются автоматически, и разработчик может указать разделы кода C ++, которые будут реализованы в качестве компонентов пути к данным. Мультиплексоры, управляющие потоком данных через компоненты и регистры тракта данных, управляются обычным автоматическим автоматическим модулем, состоящим из двоичного кода или регистра с одним горячим состоянием и логики следующего состояния, реализованной в блоках Verilog, всегда . Сильные стороны SystemC потока. SystemC хорошо подходит для HLS, потому что он поддерживает высокий уровень абстракции и может напрямую описывать аппаратное обеспечение. Он сочетает в себе высокоуровневые и объектно-ориентированные функции C ++ с аппаратными конструкциями, которые позволяют конструктору напрямую представлять структурную иерархию, сигналы, порты, границы часов и т. Д. Эта комбинация характеристик обеспечивает очень эффективный процесс проектирования и проверки, в котором поведенческие модели нескольких модулей могут одновременно моделироваться для проверки их объединенного алгоритма и поведения интерфейса. Большинство функциональных ошибок могут быть найдены и устранены на этой высокой скорости поведенческий уровень, который устраняет необходимость трудоемкого моделирования RTL для проверки интерфейсов и работы на уровне системы и существенно сокращает общее количество требуемых медленных моделирования RTL. Когда поведение является функционально корректным, моделируемые модели используются непосредственно для синтеза, исключая возможность ошибок или недоразумений.

HLS пришел с первых дней в конце 1970 - х годов является преобладание различных инструментов ЗОЖ, которые доступны, как академически , так и на коммерческой основе . Тем не менее, многие функции еще должны быть добавлены, прежде чем эти инструменты станут столь же широко распространенными, как инструменты компоновки и логического синтеза. Более того, многие конкретные приложения для встраиваемых систем требуют особого внимания. По мере того, как HLS переходит от уровня блока к подсистеме к полному проектированию системы, взаимодействие аппаратного и программного обеспечения становится одновременно проблемой и возможностью для дальнейшей автоматизации. Дополнительные исследования жизненно важны, потому что мы все еще далеки от HLS, который автоматически ищет пространство проектирования без руководства дизайнера и обеспечивает оптимальные результаты для различных ограничений дизайна и технологий.

Ссылки

1. A. Sangiovanni-Vincentelli, ‘‘The Tides of EDA,’’ IEEE Design & Test, vol. 20, no. 6, 2003, pp. 59-75.
2. D. MacMillen et al., ‘‘An Industrial View of Electronic Design Automation,’’ IEEE Trans. Computer-Aided Design of Integrated Circuits and Systems, vol. 19, no. 12, 2000, pp. 1428-1448.
3. D.W. Knapp, Behavioral Synthesis: Digital System Design Using the Synopsys Behavioral Compiler, Prentice Hall, 1996.
4. J.P. Elliot, Understanding Behavioral Synthesis: A Practical Guide to High-Level Design, Kluwer Academic Publishers, 1999.
5. W. Wolf, ‘‘A Decade of Hardware/Software Co-design,’’ Computer, vol. 36, no. 4, 2003, pp. 38-43.
6. H. Chang et al., Surviving the SoC Revolution: A Guide to Platform-Based Design, Kluwer Academic Publishers, 1999.
7. M. Keating and P. Bricaud, Reuse Methodology Manual for System-on-a-Chip Designs, Kluwer Academic Publishers, 1998.
8. D. Gajski et al., SpecC: Specification Language and Methodology, Kluwer Academic Publishers, 2000.
9. B. Bailey, G. Martin, and A. Piziali, ESL Design and Verification: A Prescription for Electronic System Level Methodology, Morgan Kaufman Publishers, 2007.
10. P. Coussy and A. Morawiec, eds., High-Level Synthesis: From Algorithm to Digital Circuit, Springer, 2008.
11. D. Ku and G. De Micheli, High Level Synthesis of ASICs under Timing and Synchronization Constraints, Kluwer Academic Publishers, 1992.
12. D. Gajski et al., High-Level Synthesis: Introduction to Chip and System Design, Kluwer Academic Publishers, 1992.
13. R.A. Walker and R. Camposano, eds., A Survey of HighLevel Synthesis Systems, Springer, 1991
14. S. Gupta et al., SPARK: A Parallelizing Approach to the High-Level Synthesis of Digital Circuits, Kluwer Academic Publishers, 2004.
15. A. Orailoglu and D.D. Gajski, ‘‘Flow Graph Representation,’’ Proc. 23rd Design Automation Conf. (DAC 86), IEEE Press, pp. 503-509.
16. M. Girkar and C.D. Polychronopoulos, ‘‘Automatic Extraction of Functional Parallelism from Ordinary Programs,’’ IEEE Trans. Parallel and Distributed Systems, vol. 3, no. 2, 1992, pp.166-178.
17. P. Paulin and J.P. Knight, ‘‘Algorithms for High-Level Synthesis,’’ IEEE Design and Test, vol. 6, no. 6, 1989, pp. 18-31.
18. M. Reshadi and D. Gajski, ‘‘A Cycle-Accurate Compilation Algorithm for Custom Pipelined Datapaths,’’ Proc. Int’l Symp. Hardware/Software Codesign and System Synthesis (CODES+ISSS 05), ACM Press, 2005, pp. 21-26.
19. I. Auge and F. Petrot, ‘‘User Guided High Level Synthesis,’’ High-Level Synthesis: From Algorithm to Digital Circuit, P. Coussy and A. Morawiec, eds., Springer, 2008, pp. 171-196.
20. D. Chen, J. Cong, and P. Pan, FPGA Design Automation: A Survey, Now Publishers, 2006.
21. W. Geurts et al., Accelerator Data-Path Synthesis for High-Throughput Signal Processing Applications, Kluwer Academic Publishers, 1996.
22. L. Zhong and N.K. Jha, ‘‘Interconnect-Aware Low-Power High-Level Synthesis,’’ IEEE Trans. Computer-Aided Design of Integrated Circuits and Systems, vol. 24, no. 3, 2005, pp. 336-351.
23. M. Kudlur, K. Fan, and S. Mahlke, ‘‘Streamroller: Automatic Synthesis of Prescribed Throughput Accelerator Pipelines,’’ Proc. Int’l Conf. Hardware/Software Codesign and System Synthesis (CODES+ISSS 06), ACM Press, pp. 270-275.
24. M.C. Molina et al., ‘‘Area Optimization of Multi-cycle Operators in High-Level Synthesis,’’ Proc. Design, Automation and Test in Europe Conf. (DATE 07), IEEE CS Press, 2007, pp. 1-6.
25. G. Stitt, F. Vahid, and W. Najjar, ‘‘A Code Refinement Methodology for Performance-Improved Synthesis from C,’’ Proc. IEEE/ACM Int’l Conf. Computer-Aided Design (ICCAD 06), ACM Press, 2006, pp. 716-723.