Можно ли для FPGA писать программы на Си

можно
http://www.mentor.com/products/c-based_design/index.cfm
http://www.celoxica.com/products/dk/default.asp

и еще
http://www.impulsec.com/

а на сколько это распространено?

а на сколько это распространено? Обсалютное большинство пишет на VHDL или Verilog?

чуть было не забыл про www.altera.com/c2h )))

Пока да
http://en.wikipedia.org/wiki/SystemC

Это в общем-то напоминает ситуацию с процессорами лет на 15 раньше. Тогда, в эпоху 286 машин все, что надо было делать быстро писали на Ассемблере, потом появился МакроАссемблер - некая переходная грань между языком совсем низкого уровня и начальным уровнем абстракции, потом появились сравнительно "умные" компиляторы с языков высокого уровня. Так и в FPGA.

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

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

Дальше будет SystemC - практически полностью абстрактный язык описания схем. На сегодняшний день получаемое быстродействие весьма посредственное, количество ресурсов - значительное, но скорость разработки значительно выше.

Я думаю, что по мере роста ресурсов в FPGA все большая и большая часть проектов будет разрабатываться на SystemC и лишь высокоскоростные блоки будут все также писаться на поведенческом VHDL или Verilog. Такая практика повсеместно используется в разработке програмного обеспечения и дает наилучшее сочетание цена/производительность получаемых решений.

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

Мне лично хотелось бы, чтобыэто направление развивалось, но почему спад я так и не понял.
Сорри, если не по теме, конечно...

Это как запустить Linux на софтовом процессоре на Microblaze на Xilinx - очень круто и навороченно, но пока не нужно. Нет, я понимаю, что можно найти задачу, под которую это будет оптимально и необходимо, но по большому счету Linux там - излишество. Так и с SystemC - пока что потеря 20-30% быстродействия и 10-15% емкости кристалла не оправдывает то увеличение скорости разработки, которое способен обеспечить SystemC. Но ведь и винды не сразу стали стандартом де-факто на персоналках. Выросла мощность компьютеров, увеличились объемы памяти, снизилась стоимость винтов и все получилось. Так и с SystemC - его начнут использовать тогда, когда емкость и скорострельность FPGA чипов будет позволять компенсировать недостатки, связанные с этой технологией. Думаю, что это произойдет в районе удвоения существующих показателей по емкости и скорострельности для FPGA при сохранении существующей на сегодняшний день цены.

На западе как я смотрю вовсю больше пользуют VHDL чем Verilog к примеру, хотя иногда поподаются требования знать его. По моему все дело в том что написано куча готовых проектов, в которые вложены деньги и переходить на новые языки с работающих кодов никто не хочет. Вот это все и отмирает по тихоньку....

А чем лучше SystemC по сравнению с раздельными Microblaze © + быстрые блоки на HDL?
И еще, я не писал на SystemC , но из его описания у меня сложилось впечатление, что все
увеличение скорости разработки будет растеряно на этапе отладки в железе.

В принципе тем же, чем JAVA лучше Си...

Он же SYSTEM Си. На нем в первую очередь хорошо описывать системы, большие комплексы моделировать. А синтез в FPGA проходит (сейчас, по крайней мере) через промежуточное описание на HDL. Реально получается аналог Java, только для железячников. Если будете использовать SystemC в основном для моделирования больших систем, то реально получите выигрыш в скорости разработки. А синтез и отладка высокоуровневой модели в FPGA - один из маленьких этапов процесса, поэтому его вклад в потерю времени небольшой.



Похоже, что так и есть. Ситуация мне очень напоминает начало развития Java...

Кстати, по сабжу, есть еще такие Handel-C и Spec-C... Интересно, что же станет стандартом де-факто?

Вообще-то SystemC умер толком не родившись. Его основной поддерживальщик, Synopsys, купивший CoCentric, его перестал поддерживать в пользу SystemVerilog

Это слишком громко. Он не умер, он жив! Но основная область его применения - это TLM, ESL и прочие гадости. Библиотека постепенно развивается в этом направлении.
Последнее обновление датировано 4 декабря прошлого(2006) года!

Он почти умер в части синтеза с него. В последних версиях Design Compiler команда compile_systemc просто напросто закончила свое существование. Симуляция - да, пожалуйста, сколько угодно. А для синтезабильных описаний жестко и с напором продвигают SystemVerilog.

Наткнулся на эту тему. Прочитал. Нифига не понял.

Я сам абсолютный новичок во всех этих делах, но поставлена передо мной задача, описанная тут http://electronix.ru/forum/index.php?showtopic=30180

Объясните, пожалуйста, используется ли сейчас написание на C для FPGA? Если нет, то почему? Стоит ли мне на данный момент вообще заморачиваться с изучением этой области? Тут в теме был ряд ссылок на различные версии компиляторов C->FPGA. Как я понял, они все транслируют написанный код в HDL, а уже этот HDL потом вставляется в квартус и так далее. Так? Как они вообще работают и как с ними взаимодействовать? Какие лучше? Как вообще выглядит процесс разработки? Вообщем, очень хотелось бы получить небольшой ликбез на эту тему.

Я плотненько полазал по сайту ImpulseC, там все так красиво описано, что аж слюнки текут. А как оно в реальности обстоит?

На западе в принципе и то и то в ходу. Есть тенденция писать ASICи на Verilogе, особенно в Штатах и им подобных моделях хай-тека (например Израиль и Дальний Восток), ну а если учесть что часто (но не всегда) FPGA это идет как переходный процесс к ASIC (т.е. делается принципиальная имплементация на FPGAе, отрабатываются проблемные логические вещи, алгоритмы и т.д. и потом делается ASIC), но удобства ради предпочитают Verilog и для FPGAев. Т.е. если вы напереваетесь например войты в рынок труда в данной области в Штатах, Израиле, Дальнем Востоке (Тайвань, Япония и т.д.) - знание и опыт Verilogа вам помогут больше чем VHDLя (хотя и последний далеко не помеха...)

Европа-же по моему больше стоит на VHDLе.

полностью согласен. а теперь сравните объёмы разработок США и Европы. Европа это вообще задворки в плане введения в строй передовой технологии (за небольшим исключением)
по поводу СистемЦ: при синтезе это всё тот же структурный подход - ничего из ряда научной фантастики в данной области (синтез поведения) нет - просто ещё один синтаксис (у Ц++ он достаточно гибкий для расширения поэтому его и выбрали за основу новой технологии SC - а в принципе можно написать синтезатор хоть с Паскаля или с Бейсика /так же как вы в принципе можете компилировать Верилог и ВХДЛ в исполняемый код для процессоров регулярной архотектуры - если это кому-нибудь когда-нибудь будет нужно/ - главное то что координатьно ничего не меняется : синтез - структурный, а не поведеньческий! /хотя есть свои наработки у продвинутых фирм и поведеньческого синтеза - но это больше их ноу-хау в технологии синтеза чем характеристика какого-либо языка/)

Да, так и есть. И учитывая это - трудно понять академии - в универах на последнем году обучения предлагаются предметы програмируемой логики - но везде в основном учат азы VHDL (универы Израиля и те американские о которых я в курсе). Может из-за того что VHDL более строг и систематичен...

А на мои вопросы кто-нибудь ответит?

наверное просто все светилы Катапульт Си отдыхают - советую дождаться их, но если не втерпёж - могу и я на уровне сплетен поделиться

был на конференции на одной - там был доклад по какому-то из подобных инструментов - они действительно производили трансляцию с Си на ВХДЛ - зачем верхний уровень на Си? - чтобы можно было моделировать взаимодействие программной и аппаратной части (это в принципе решается и средствами СистемСи и Верилога - и в какой-то степени и ВХДЛ для двух последних методами импорта Сишных функций в общую модель симулятора - в первом случае - естественно напрямую /Си++ всё-таки/)
в принципе задачи синтеза поведеньческих конструкций до некоторой степени решаемы (можно например синтезировать do-while или цикл for так чтобы он был действительно циклом во времени а не в пространстве) поэтому поведение Си синтезировать до некоторой степени можно
однако програмистским языкам как правило не хватает синтаксических средств для представления структуры устройства (ведь функционирование устройства - это множество параллельных процессов - а следовательно и представления о взаимодействие процессов во времени, но самая большая сложность для поведеньческого синтеза -это неоднозначность абстрактных операций над данными и множества их возможных реализаций - простой пример - умножение вам как выполнять? конвейером за n тактов или мартичным умножителем за 1 такт(но более длинный в рамках той же технологии) - и так далее - а система вещь детерминированная - там хотя бы одна неоднозначность и формальные методы уже не работают. (можно на эту тему долго рассуждать - здесь не буду - далеко зайти можно )

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

Мой уневер (UMCP в 2003-2004 гг.) офицально только преподавал Verilog как HDL которым следует пользоватся. Тем не мение, отдельные препод. могли включать VHDL в программу по желанию, но это не было детальное образование, а так, на скорую руку, только что бы что-то постигнуть... Но зато все фирмы выполняющаи госзаказы работают с VHDL, правительство США не признает Verilog не для гражданских, и не на военных заказов. Собственно, VHDL был создан для пользовоня DoD контракторов.

Это интересно, не знал. У нас почти везде где проэктируются ASICи - идет Verilog. Наши конторы очень часто и много пересекаются с американскими (много так-же R&D центров американских контор), и везде там Verilog где сталкивались. Хотя не знаком со Штатовксой военкой лично, вполен вероятно они действительно обязаны работать на VHDLe. В плане ASICом я сталкивался только с областью consumer (чипы на рынок мультимедии - digital cameras, DVDs, DVD recorders, и т.д.)
В израильских техн. вузах я пока не встречал курсов HDLя на Verilogе, все что видел - VHDL, но тоже уровень самый базисный. Тоже самое слышал об нескольких Штатовских, думал что это тенденция.
Хотя странно, ежели официальная линиая правительства (в Штатах) на военку/гос-заказы - VHDL, почему-же в универах тогда дают Verilog ? Или одно другого не касается ?

Потому что гос-заказы в США - это очень мало, основной объем разработок - коммерческий. Официальным языком программирования для военки США долго была Ada - ну и что, практически никто его не знает.

Понял, спасибо, было интерсно узнать.

я бы не стал проводить подобных аналогий между десктоп-направлением и встраиваемыми применениями (а уж в проекции на FPGA - высокопроизводительными встраиваемыми системами)

в процессорах плата за пользовани ЯВУ - увеличенное время выполнения алгоритма
в ПЛИС - повышенное потребление (докучи к необходимости применения более емкого и дорогого кристалла)

в ASIC-проектировании ситуция еще более интересная (в случае рассмотрения возможного использования SC): надо найти компромисс между площадью (т.е. стоимостью) конечного кристалла и временем разработки + опять же существуют свои сферы устройств с критичным энергопотреблением.

Я знаю . Первая работа послала на курс Ada-95, у нас все софт что выше network и link layer (в т.ч. все чего косается пользователь) должно было быть на Ada. И не какая нибудь супер-секретноя работа, а заурядня гражданская контора... Просто кому-то хотелось иметь Mil-Spec, и почему-то не нравилось C/C++. Я от туда смотался после 2 лет, но слышал от знакомых что теперь все переписывают на Java .

Угу, так потому я и сказал о дальнейшем развитии технологий FPGA до той степени, когда 10-20 тысяч макроячеек - типа современных альтеровский ALUT'ов будут раздаваться в качестве бонуса к основному объему самой FPGA Согласен, это время наступит очень не скоро, но оно обязательно придет. Все ведь дело в соотношении стоимости чипа ко времени программиста его проектирующего

C точки зрения временного или пространственного разворота цикла - так это тоже не проблема. Компилятор будущего сам примет решение как его развернуть и сгенерит код, который будет давать абсолютно четкий детерминированный результат согласно спецификации языка. Для примера, Intel C++ компилятор версии 6.0 при компиляции исходников для P4 Northwood заменял некоторые операции умножения несколькими операциями сложения - чем не пример пространственного vs временного разворота цикла?


Еще. По роду занятий пришлось немного пооптимизировать на Ассемблере для старших x86 - презанимательнейшее занятие. Как оказалось, каждая команда имеет свое время обновления результатов, их можно спаривать - тогда они выполняются одновременно, если попытаться использовать результат выполнения команды слишком рано, то процессор останавливается и ждет готовности операндов команды, а может запустить другие независимые команды из очереди. Короче, компилятор постоянно решает задачи планирования, подобные временной vs пространственный разворот. И весьма успешно.

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

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

ага - и на марсе скоро будут яблони цвести. конечно когда-нибудь всё у всех будет. да и в принципе языки программирования отомрут - компиляторы будут непосредственно читать гениальные мысли разработчика прям из мозга - по электромагнитным показаниям его активность

+1
Вот помечтали о следующем веке...

Думаю, ресурсами одной компании сделать нормальный синтезатор с языка С задача как минимум 5-10 лет.

Ну чо, давайте пи...ми меряться Я начинал програмить еще на ЕС1045, первым моим компилятором был компилятор с языка PL/1, до сих пор где-то валяются записи по синтаксису языка PL/1 и описание некоторых его библиотек. В то время каждый этап сборки программы выполнялся отдельной программой и надо было помнить командную строку запуска транслятора, компилятора, линкера и еще нескольких программ, непосредственно участвовавших в процессе. Отладка даже простой программы могла растянуться на день, а иногда и на больше.

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

Эволюция от ЕС1045 с PL/1 до компиляторов сегодняшнего уровня была пройдена менее чем за 15 лет. По моим субъективным оценкам уровень развития компиляторов будущего для FPGA находится где-то во второй половине пути - т.е., лет через пять уже можно будет начинать забывать о идеологии написания аппаратуры на RTL уровне - просто работа на RTL уровне будет уже не эффективной.

нее давайте не будем - всё-таки это уже вне рамок данного топика
да и потом уже говорилось о разнице встраиваимых систем и операционных систем для домохозяек - первое всё-таки всегда будет на острие атаки и встраиваемые системы до сих пор (вроде) не разрабатываются с помощью Visual Basic, хотя вторые конечно уже давно радуют глаз кухарок весёлой собачкой-подсказкой в окне текстового процессора Микрософт Ворд

к разговору о PL/1 и эволюции языков:

ведь сотрудники многих ЗАТО до сих пор сидят на PL/1. И что главное - руководство не располагает планами (/желанием?) чтобы с него куда-то переходить, развиваться.

и это притом, что данная область всегда была (увы) на острие технологий..