От C до Silicon: Как реализовать программно-аппаратное решение как аппаратное обеспечение?

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

Я понимаю, что мог бы смотреть на этот сценарий с неправильной точки зрения. Исходя из моего собственного опыта, обычно у вас есть какое-то оборудование, которое кто-то реализовал как программное решение (подумайте, аппаратная эмуляция). Существует ли эта концепция в обратном направлении? Как эти крупные компании делают это, например, программное обеспечение или аппаратная IP-маршрутизация?

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

За прошедшие годы появились компиляторы, которые брали код типа «C-Like» и компилировали его в аппаратные средства - во многом так же, как VHDL или Verilog можно компилировать в аппаратные средства. Но главное в том, что это "C-Like", а не C. Вы все равно не можете взять, например, программу на C / C ++, которая вычисляет PI и магически конвертирует ее в аппаратное обеспечение, которое вычисляет PI. Большинство из этих языков C-Line исчезли или не используются ни в каком количестве. Одна из наиболее популярных версий этого - SystemC , но важно отметить, что это не C / C ++ и не полезен для универсального «давайте напишем программное обеспечение, а затем скомпилируем его в аппаратное обеспечение». Вам все еще нужно «написать какое-то оборудование, которое также может быть скомпилировано в программное обеспечение».

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

Наиболее близким был бы C-to-Hardware (C2H) компилятор Altera . Это может сделать то, что вы предлагаете. Но есть вызывающе предостережения. Вы не можете превратить какой-либо код на C в аппаратное обеспечение, и не захотите. Но определенные функции работают довольно хорошо, и вы можете увидеть резкое увеличение производительности.

Как правило, вы бы внедрили программный процессор NIOS II в Altera FPGA. Затем вы должны написать для него код ANSI C, как любой другой процессор. Затем, скажем, одна из написанных вами функций C включает в себя некоторую сложную математику, которая выиграла бы от производительности при параллельном выполнении. Вы вызываете компилятор C2H, скажем, «Внедрение в аппаратное обеспечение», и он по существу превращает эту функцию в периферийное устройство программного процессора NIOS II.

Вот пример кодирования вычисления Мандельброта в ANSI C и последующей реализации его на аппаратном уровне:

Алгоритм Мандельброта, ускоряемый компилятором C2H, приводит к повышению скорости как минимум в 60 раз по сравнению с тем же алгоритмом, работающим на самом быстром процессоре Nios II с использованием уровня оптимизации компилятора 2 (-O2). Это увеличение скорости происходит из-за параллельности и высокой скорости итерации, которую может обеспечить аппаратное обеспечение, что невозможно из универсального процессора.

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

Вы упоминаете "C to Silicon" в своем названии и упоминаете продукты уровня платы в теле. Я просто сосредоточусь на той части уравнения, которая существует -> "C to Silicon". Сам по себе C не является естественным образом подходящим для описания аппаратного обеспечения, поскольку ему не хватает фундаментальной поддержки присущего аппаратному параллелизму, необходимости предотвращения состязаний и других проблем, и он не особенно выразителен в способности представлять эти концепции. Или не так сильно, как Verilog и VHDL.

С-код, который является синтезируемым (то есть может быть преобразован в описание аппаратного обеспечения) и здесь аппаратное обеспечение = цифровая логика, не выиграл бы ни одного конкурса кодирования, оцененного разработчиками программного обеспечения.

Вот список некоторых известных поставщиков, поставляющих инструменты C -> Silicon для потока ASIC.

• Форте синтезатор

• Наставник катапульты

• BlueSpec C

• Synopsys Synphony (бывшая Synfora)

• Cadence C-to-Silicon

Превращение программного обеспечения в аппаратное обеспечение не является тривиальной задачей, если вы ожидаете разумного оборудования. Аппаратному обеспечению обычно требуется больше архитектуры для тщательного управления использованием ресурсов, которое связано с площадью / стоимостью. Сказав это, есть ряд инструментов, которые принимают C в той или иной форме, позволяют добавлять специфичную для оборудования информацию (например, что такое аппаратный интерфейс?) И генерируют оптимизированное оборудование. Опытные пользователи могут легко получить лучшие результаты за меньшее время, чем RTL с ручным кодированием.