[SM 0]

Как по мне, так программирование принципиально проигрывает описанию устройств. Разумеется функциональное исключаем, его суть очень похожа на описание устройств, я имею в виду классическое программирование. Другое дело, что большинство народа привыкли к программированию, и хотят им же пользоваться для описания устройств, для чего оно собственно не предназначено изначально. А вот наоборот - разложение описания устройства на мультипроцессорную систему и синтез программ для этих процессоров по описанию - в принципе вроде должен быть более продвинутый подход именно к программированию. Т.е. я даже не уверен, что то дальнее будущее в ПЛИС/ИМС за синтезом устройств с программ, а не наоборот - будущее программирования не за синтезом программ с описаний устройств (этот путь как раз развивается в функциональных ЯП). А огромное кол-во С-кодеров с их голыми амбициями совершенно не показатель. Они разве что кормят всяких там Форте и Менторов с их цынтезаторами.

[SergeyF 0]

И еще один вопрос.

Та же Synfora помимо PICO делает продукт под названием Esterel Studio на основе языка Esterel (еще один язык, больше известный в computer science, произошедший из группы языков описания потоков данных). И оттуда зачем-то заявлен синтез в C/System C или в VHDL/Verilog.

 

Вот эта фраза особо интересна в контексте текущей дискуссии, если вдуматься:

"Esterel Studio is complementary to the PICO algorithmic synthesis platform and is part of our long-term vision of providing integrated design environment for both application accelerators and more control IP."

 

Выделено мной. И что они сами на самом деле думают?

[SM 0]

И что они сами на самом деле думают?

А вот этого мы никогда не узнаем :)

[CaPpuCcino 0]

Как по мне, так программирование принципиально проигрывает описанию устройств.

вот и по моим ощущениям императивные языки - это, фигурально выражаясь, проекция трёхмерного объекта на плоскость, т.е. проектировались они не исходя из универсальности описания вычислений (кстати это было лозунгом функциональных языков), а исходя из удобства представления алгоритма в фон-Неймановской архитектуре (это в общем-то заложено даже в самом определение императивных языков - их концепция, это принципы фон-Ниймана другими словами). беда в том что за 50 лет мы настолько вжились в стереотип последовательного исполнения, что нам трудно выйти за рамки линейной модели даже в фантазиях. а теперь под влиянием этого стереотипа мы пытаемся произвести реконструкцию обратно в пространство, т.к. этого требуют новые вычислительные архитектуры со всевозможными уровнями параллелизма, будь то суперскалр, VLIW, или многоядерность (неговоря уже о поточных вычислителях/data driven/).

в концепции императивных языков просто не хватает понятия топологии

ЗЫ: для примера "плоскости" императивных языков возмите хотябы способы описания многопоточности в каком-нибудь традиционном програмистском языке и конструкцию fork...join в Verilog(можно даже не вспоминать про синхронизацию по событиям) и прослезитесь ;) ну и кто там быстрее вымрет?..

[SM 0]

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

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

 

А вот займут ли функциональные ЯП место HDL... Или HDL расширятся в этом направлении... Вопрос интересный. Вообще, даже складывание кубиков в симулинке это в общем функциональный ЯП, и одновременно HDL-описание, так как точности (читай размеры шин между блоками) четко определены.

[CaPpuCcino 0]

по поводу ФЯП для синтеза, вопрос для меня лично очень сложный. мне кажется, что в чистой концепции функциональных языков, описание на ФЯП будет через чур абстрактным/высокоуровневым для САПР (хотя чистых-то и не осталось). мне сложно представить что за умная машина должна быть, чтобы ссинтезировать подобное описание(правда я вопросом техники компиляции с ФЯП как-то не удосужился поинтересоваться/как-нить надо будет почитать/, поэтому некомпетентен). опять же остаются вопросы к реализации cycle-accurate моделей (а от них в случае описания протоколов никуда не деться, хотя возможно здесь смогут использовать linear temporal logic/та что в основе языков описания свойств аппаратуры лежит, но вопрос открытый - есть ли в использовании в этих целях LTL большой смысл по сравнению с RTL/)

[SM 0]

описание на ФЯП будет через чур абстрактным/высокоуровневым для САПР

Ну как сказать. Во первых можно при помощи констрейнов объяснять синтезатору, сколько тактов что должно делаться если последовательно, и сколько уровней конвейера, есть конвейеризировано. А во вторых, все таки, для полноценного описания устройства конечно нужны и интерфейсы, и модули... Поэтому явно должен быть гибрид - или введение в ФЯП железячных прибамбасов, или введение в HDL элементов ФЯП (хотя, по сути, глубоко параметризованные модули это оно и есть, ну конечно не в полном объеме). Но это уже все частности и нюансы...

 

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

[CaPpuCcino 0]

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

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

[Methane 0]

Как по мне, так программирование принципиально проигрывает описанию устройств.

Мне чего-то кажется, что сейчас все делается не для производительности или там предельного удешевления, а для облегчения жизни программисту. Отсюда уже и стеки нормальные, и DSP для которых на С можно спокойно программировать, и отсутствие векторных (нормальных, как в DSP) для x86. Сейчас JTAG в каждом дохлом процессоре за бакс. ИМХО то что сложно, отмирает. А то что просто, идет в перед. HDL, принципиально сложнее чем С, и проще не станет. Так что ХЕЗ.

[SM 0]

А то что просто, идет в перед. HDL, принципиально сложнее чем С, и проще не станет. Так что ХЕЗ.

HDL не сложнее, чем С, ни грамма, ни принципиально, ни как. Он проще, чем С. Попробуйте на С написать программу из 20 тредов и плотной связью меж них, и устройство из 20-ти процессов на HDL - на HDL окажется все проще и прозрачнее. Он просто непривычен для большинства, которое не умеет мыслить параллельными структурами. А те, кто одинаково хорошо знают обе системы разработки (это не два языка программирования, это один язык программирования и один язык описания устройств - две совершенно различных методологии с разными принципами), это видят, и, кстати, по моему наблюдению, многие меняют и подходы к программированию в сторону большего распараллеливание. В общем сложность и привычку путать не надо. Чтобы понять красоту и простоту HDL надо на время обучения ему ВЫКИНУТЬ слово программирование из головы напрочь.

 

Что же касается ФЯП и синтеза с них - так это любой математик сможет тогда свой алгоритм на нем описать, и в таком случае надобность в программисте или разработчике описаний устройств вообще отпадет. Добавь в ФЯП модули и клоки - вот и супермощная и удобная среда описания устройств. Математики делают описание их хитрых алгоритмов, сами, без программерско-HDL-ных прослоек, а железячнику остается обрамить их клоками и интерфейсами, программисту - так вообще ничего не делать, а просто синтезировать с этого описания программу.

[CaPpuCcino 0]

HDL не сложнее, чем С, ни грамма, ни принципиально, ни как. Он проще, чем С.

даже не касаясь параллельности, если например взять программу на Си и программу на СистемВерилог, СВ на порядок проще Си по семантике (возмите хобя бы работу с массивами/особенно многомерными/ в одном и в другом).

 

так вообще ничего не делать, а просто синтезировать с этого описания программу.

так что, господа программисты, закупайте белые простыни - скоро вымрете как класс :) :)

[Leka 0]

Напишите компилятор ЯВУ на синтезируемром HDL.

[SM 0]

закупайте белые простыни - скоро вымрете как класс :) :)

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

 

Напишите компилятор ЯВУ на синтезируемром HDL.

Речь не о состоянии синтезируемого подмножества на сегодняшний день, а о уровне ФЯП. Хотя и не вижу никаких проблем в написании компилятора на синтезируемом HDL. Просто надо мыслить не так, как при работе с классикой программирования, и все. Переломите свое мышление - тогда поймете, что HDL не сложнее. Только вот вряд-ли кому придет в голову сделать интегральный компилятор чисто из маркетинговых соображений.

 

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

[dxp 34]

Ну, понаписа-али. :) Не хотел ввязываться, но не удержался, т.к. многое из сказанного в этом топике - явно попутанное "теплое" с "мягким". На мой взгляд, тут высказано много субъективно однобокого, исходя из профессиональной специализации (hardware design), совершенно не принимая во внимание глубину проработки методологии, парадигм, приемов, да и просто контекста противопоставляемой технологии (software design).

 

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

Далеко не всякую программу можно хоть сколько-нибудь эффективно хотя бы описать (не говоря уже о синтезе) на современных HDL. А если действовать по принципу "мы за ценой не постоим", то и описание алгоритма на ЯП вполне поддается реализации аппаратно. Пример тому - синтез алгоритов из m-файлов Матлаба. Качество реализации уступает рукописному HDL? Да. Зато время разработки сильно выигрывает. И еще вопрос, что важнее - все определяется конкретным случаем применения.

 

А попробуйте, например, реализовать аппаратно простой GUI (окошки, менюшки, диалоги и т.п.), который спокойно описывается на С++ (и любом ЯП, нативно поддерживающим ООП), имеет прозрачную структуру, отличную управляемость, расширяемость, и все это доступно любому программисту, знакомому с основами упомянутого языка и концепцией ООП (при этом замечательно работает даже на достаточно мелком микроконтроллере). Даже SystemVerilog, даже на уровне несинтезируемой части языка даст куда менее красивое и эффективное описание - не дорос еще. А уж про реализацию этого только лишь с использованием синтезируемого подмножества лучше и не говорить.

 

А программистам (а их много и они наглые и с амбициями)

Что-то в этом топике я не замечаю указанных амбиций. Зато обозначаются оные с противоположной стороны.

 

просто очень хочется вот так сразу, не изучая схемотехники, не изучая внутреннего устройства исполнительных/вычислительных устройств, не вникая в предмет, отсинтезировать по их программе чип.

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

 

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

 

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

 

Просто это совершенно разные подходы - программирование и описание устройств. Соответственно, все таки, на мой взгляд обозримое будущее за HDL, и SystemC один из них, а не за синтезом с С,

Подходы разные, а цель одна. А SystemC, как вы прекрасно знаете, - это не новый HDL, а не что иное, как язык программирования С++ + библиотека (поддержка параллельности + дополнительные типы и макросы) + методология использования. Т.е. как яркий пример того, как обычный императивный ЯП общего назначения использован для описания алгоритмов с акцентом на параллельность и прицелом на аппаратную реализацию.

 

Ментор это понял, что все таки SystemC для дела-то важнее и нужнее, и вернул его.

К сожалению, Синопсис, идя на два корпуса впереди, свернул это перспективное направление.

 

А реального толку от синтеза с С не будет (ну кроме разве что возможности позагибать пальцы прогаммерам, какие они типа крутые),

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

 

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

Такое заявление требует уточнения. Какой программы? Точнее, какой по сложности программы? Если в рамках того, что эффективно реализуется на основе синтезируемого подмножества современных HDL,то тут нет ничего сложного для того же SystemC (который есть С++). А если речь идет о программах, например, вроде квартуса, то тут одинаково далеко как xHDL, так и ЯП в качестве HDL (и, кстати, ЯП тут даже и поближе к истине). Не доросли они еще до этого. И боюсь, что тут далеко не 10 лет.

 

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

Ничем оно не уступает! Оно просто другое. У него свои плюсы и минусы. Вы пытаетесь сравнивать несравнимые вещи. На данном этапе развития xHDL по уровню достижимой функциональной сложности - это просто дети по сравнению с ЯП. Посмотрите на флагман HDL - SystemVerilog. В нем только-только появились средства, которые в древнючем С были изначально (псевдонимы типов, структуры, перечисления). Попытки внести в него поддержку объектной и объектно-ориентированной парадигмы находятся пока в зачаточном состоянии и касаются только несинтезируемой части.

 

В области последовательсного (классического) программирования пропахано очень и очень глубоко - несколько парадигм, всякие статические и динамические полиморфизмы, паттерны проектирования и т.д. и т.п. Я сам железячник, и программирование меня касается с боку, но то, что видно даже с этой точки, не позволяет ставить методы аппаратного дизайна выше методов программного. А уж квалифицированный программист вам еще назовет возможностей ЯП, которые HDL и не снились.

 

И не понятно, где вы усмотрели похожесть ФП и описания аппаратуры? Что там общего? В ФП есть средства для cycle-accurate описания алгоритмов? Или в HDL поддерживается концепция lazy вычислений? HDL - низкоуровневая по уровню абстрации вещь - нативная привязка к особенностям железа. Императивные ЯП - уровень абстракции уже выше. ФП - еще выше.

 

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

 

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

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

 

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

 

И аналог HDL тут - это параллельный ассемблер. Сами знаете, насколько это более сложное, кропотливое и ответственное занятие - разложить руками алгоритм на параллельный асм.

 

И если мы доживем до удачных и эффективных реализаций распространенных типовых задач на основе параллельно работающих аппаратных блоков (реконфиге), то это будет скорее что-то похожее на ЯП высокого уровня абстракции (выше, чем тот же С++ - скорее что-то похожее на Python или Ruby), нежели на HDL, как он есть на сегодня.

 

Разный уровень абстракции HDL и ЯП порождает и разные пути их развития. ЯП движутся по пути увеличения функциональной сложности, что влечет за собой повышение уровня абстракции, появление соответствующих парадигм программирования и т.д. А в развитии HDL основные усилия идут на развитие средств, обеспечивающих контроль целостности HDL-описания, таких как assertion-based verification, язык описания свойств аппаратуры, различные методики и библиотеки верификации (TLM, OVM, VMM и т.п.) - т.е. очень остро стоит вопрос обеспечения функциональной целостности введенного дизайна. И это при том, что функциональная сложность этого дизайна с точки зрения обычного ЯП во многих случаях вполне тривиальна.

 

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

 

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

 

вот и по моим ощущениям императивные языки - это, фигурально выражаясь, проекция трёхмерного объекта на плоскость, т.е. проектировались они не исходя из универсальности описания вычислений (кстати это было лозунгом функциональных языков), а исходя из удобства представления алгоритма в фон-Неймановской архитектуре (это в общем-то заложено даже в самом определение императивных языков - их концепция, это принципы фон-Ниймана другими словами). беда в том что за 50 лет мы настолько вжились в стереотип последовательного исполнения, что нам трудно выйти за рамки линейной модели даже в фантазиях.

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

 

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

 

ЗЫ: для примера "плоскости" императивных языков возмите хотябы способы описания многопоточности в каком-нибудь традиционном програмистском языке и конструкцию fork...join в Verilog(можно даже не вспоминать про синхронизацию по событиям) и прослезитесь ;) ну и кто там быстрее вымрет?..

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

 

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

Вот это вряд ли. :) Вся эволюция идет по пути усложнении внутри и упрощения снаружи. Поэтому внутри (реализации, платформы) будет усложняться, а снаружи (средства ввода) упрощаться. И это будут никак не HDL. Это будут языки высокого уровня абстракции (императивно-функциональные), позволяющие коротко и однозначно описать алгоритм, который компилятор при необходимости разложит на сколько угодно параллельно выполняемых (если это необходимо) кусков, реализумых программно или аппаратно - в зависимости от платформы и требований. Первые шаги уже сделаны (синтез из m-файлов Матлаба). И хотя это пока неэффективное с точки зрения реализации решение и касается больше вычислительных приложений, тенденция обозначилась.

 

P.S. К сожалению, сильно загружен текущей работой, поэтому вряд ли смогу принимать участите в данной интересной дискуссии, а длинный пост удалось написать по причине свободного вечера выходного дня.

[cms 0]

2 dxp: ну вы просто накрыли всех скептиков ракетным залпом. Пройдусь топориком: программисты не более наглые, они более активные. Легко и непринужденно вторгаются в различные области, в том числе и дзайн железа. Во многих областях достигают успеха, бо теория у них, dxp абсолютно прав, на три поколения опережает текущие мысли в других областях и прикладывают они её творчески и с задором.

Наблюдая за развитием SV не оставляет мысль, что Куммингс, Сюзерленд и компания просто осваивают то что занимало умы передовых программеров лет 30 назад - объектное программирование, стандартизация методологии через библиотеку классов VMM по неуклюжести очень напоминает майкрософтовкую MFC двадцатилетней давности. Так что толковым программистам точно что есть сказать по поводу RTL. И они скажут, я в этом не сомневаюсь.

 

С другой стороны сами программисты не стремятся писать все и вся на C - веб пишут на PHP/Java, c базами данных работают на SQL, окошки под винду - на C#, GPU - на OpenCL.

 

По поводу компиляции HDL в програму для CPU - так synopsys VCS тем и занимается, генерит испольняемый бинарник. Компилированный из С алгоритм работает на процессоре быстрее.