Від C до Silicon: Як реалізувати програмне / програмне рішення як апаратне забезпечення?

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

Я усвідомлюю, що я міг би дивитися на цей сценарій з неправильної точки зору. Історично з мого власного досвіду, як правило, у вас є обладнання, яке хтось реалізував як програмне рішення (думаю, апаратна емуляція). Чи існує ця концепція навпаки? Як ці великі компанії роблять це, такі як маршрутизація програмного забезпечення проти апаратного забезпечення IP?

Ні, немає стандартного рішення для перетворення програмного забезпечення на апаратне забезпечення. Взагалі кажучи, беручи до уваги програмне забезпечення, яке не було написано з технічною реалізацією, не можна легко перетворити на апаратне забезпечення без великих витрат і неефективності. Зазвичай, найкраще зробити це лише зробити чіп із процесором та ПЗУ - і поставити програмне забезпечення в ПЗУ.

Протягом багатьох років існували компілятори, які брали б "C-Like" код і компілювали його в апаратне забезпечення - майже так само, як VHDL або Verilog можна компілювати в апаратне забезпечення. Але головне, що це "C-Like", а не C. Ви все одно не можете взяти, наприклад, програму C / C ++, яка обчислює PI і магічно перетворює її в апаратне забезпечення, яке обчислює PI. Більшість цих мов C-Line відійшли або не використовуються в жодній кількості. Однією з найпопулярніших версій цього є SystemC , але важливо зазначити, що це не C / C ++ і не є корисним для загального "давайте запишемо програмне забезпечення, а потім компілюємо його в апаратне забезпечення". Вам все одно потрібно "написати деяке обладнання, яке також може бути складено в програмне забезпечення".

Перемикачі та маршрутизатори, як правило, мають апаратне забезпечення, яке виконує більшість часто використовуваних і критичних функцій маршрутизатора (швидкість пошуку матеріалів у таблицях маршрутизації, керування чергами тощо) в апаратному забезпеченні, а потім використовуйте процесор, щоб виконувати всі не дуже поширені функції (обробка винятків, помилок, оновлення таблиці маршрутів тощо). Багато в чому це схоже на те, як працюють сучасні процесори, де найбільш поширені опкоди виконуються апаратно, а іноді деякі опкоди реально реалізовані в програмному забезпеченні (наприклад, інструкції з плаваючою комою, коли ФПУ відсутня).

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

Зазвичай ви реалізуєте програмний процесор NIOS II в Altera FPGA. Потім ви напишете для нього якийсь код ANSI C, як і будь-який інший процесор. Тоді скажіть, що одна з функцій C, яку ви написали, передбачає важку математику, яка б виграла від продуктивності від паралельного виконання. Ви викликаєте компілятор C2H, говорите "Реалізація в апаратному забезпеченні", і це по суті перетворює цю функцію на периферійну мережу процесора NIOS II.

Ось приклад кодування обчислення Мандельброта в ANSI C та подальшої його реалізації в апаратному забезпеченні:

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

Повернувшись до вашого прикладу, процесор NIOS II може запускати Linux. А певні функції, необхідні для виконання завдань маршрутизації, можуть отримати користь від апаратного прискорення. Це, швидше за все, краще, ніж чистий програмний роутер. Але він ніколи не наблизиться до роботи спеціально розроблених спеціально виділених ASIC.

Ви згадуєте "C to Silicon" у своєму заголовку і згадуєте продукти на рівні дошки в корпусі. Я просто зосередиться на частині того рівняння, яке існує -> "C - до кремнію" тече дизайн. C сам по собі не є природним придатним для опису апаратних засобів, оскільки йому бракує певної фундаментальної підтримки притаманного паралелізму апаратних засобів, необхідності запобігання гоночним умовам та інших питань, і це не особливо виражає можливість представити ці поняття. Або майже не стільки, скільки Verilog і VHDL.

Код C, який синтезується (тобто може бути наданий до апаратного опису) і тут апаратне забезпечення = цифрова логіка, не виграє жодних конкурсів кодування, оцінених розробниками програмного забезпечення.

Ось список деяких помітних постачальників, що постачають C -> Силіконові інструменти для натовпу потоків ASIC.

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

• Вихователь Катапульт

• BlueSpec C

• Synopsys Synphony (колишня Synfora)

• Каденція C-до-кремнію

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