[SergeyF 0]

Вы с SystemC знакомы?

IMHO, это как раз пример относительно удачной реализации библиотеки. SV как таковой, включая SVA, мне больше нравится, я понимаю, это дело вкуса.

 

Но тогда давайте говорить о SystemC, а не о том, что мы будем писать на C/C++, не задумываясь о регистрах, синхронизации и т.д..

 

А я все-таки к исходной тематике пытаюсь вернуться, которая заявлена в заголовке. А то уже непонятно о чем говорим. Обычному C/C++ программисту, если придется переходить на SystemC, придется понять концепции, которые заложены и в HDL, и в языках типа Esterel. Если нравится SystemC - замечательно, но это не совсем высокоуровневый синтез с C/C++, о котором говорилось, IMHO.

 

Производительность. Жаба и шарп будут едва ли быстрее имеющихся решений на HDL. Эффективный компилируемый код дает тут качественный скачок.

Для программы на ПК. А для синтеза?

[CaPpuCcino 0]

Уже не первый случай неверной интерпретации моих слов.

извините - не со зла.

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

 

всё, больше не встреваю.

:laughing:

сообщение было отредактировано пользователем

[dxp 53]

Но тогда давайте говорить о SystemC

Так SC - это и есть C++ в чистом виде. Это не новый язык, не какие-то специальные расширения. Все в рамках одного языка.

 

мы будем писать на C/C++, не задумываясь о регистрах, синхронизации и т.д..

Об этом и речи нет. При работе с любым языком (ЯП или HDL) в любой области всегда надо думать о предметной области и четко представлять, что там происходит. И никто тут не утверждает, что если взять голимого РС программера, дать ему SC, то получится HDL дизайнер. Не получится. До тех пор, пока этот программер не начнет понимать предметную область, в которой он работает. Ровно та же проблема возникает, если такого программера посадить разрабатывать программы для мелких embedded приложений - пока он не вникнет в целевую платформу, ее возможности, ограничения и т.п., ничего у него путного не получится.

 

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

 

 

А я все-таки к исходной тематике пытаюсь вернуться, которая заявлена в заголовке. А то уже непонятно о чем говорим. Обычному C/C++ программисту, если придется переходить на SystemC, придется понять концепции, которые заложены и в HDL, и в языках типа Esterel.

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

 

Если нравится SystemC - замечательно, но это не совсем высокоуровневый синтез с C/C++, о котором говорилось, IMHO.

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

 

Для программы на ПК. А для синтеза?

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

[CaPpuCcino 0]

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

а он в принципе возможен?

:) сейчас понесётся всё по второму кругу :) :)

я на всякий случай здесь ссылку на первый пост поставлю, чтобы не делать un-loop бесконечного цикла :)

http://electronix.ru/forum/index.php?showt...st&p=718619

[SM 0]

Весь вопрос в средствах синтеза - они пока до этого не доросли.

Я бы сказал, что не недоросли, а приостановились в развитии. Видимо как тупиковый путь. А то ведь был и behavioral compiler у синопсиса, да сплыл вместо того, чтобы продвигаться и расширяться. Преобразование программ в устройства это не то, за чем будущее.

 

А так - продвижение в правильном направлении есть - например синтез верилог-описаний с описаний в симулинке. И синтез программ с тех же описаний. Это яркий пример синтеза с высокоуровневого функционального описания, который реально развивается.

[SergeyF 0]

Об этом и речи нет. При работе с любым языком (ЯП или HDL) в любой области всегда надо думать о предметной области и четко представлять, что там происходит. И никто тут не утверждает, что если взять голимого РС программера, дать ему SC, то получится HDL дизайнер. Не получится.

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

 

А со всем написанным Вами далее по сути согласен. :)

 

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

Но тут всплывают вопросы об эквивалентности модели результатам синтеза и, в частности корректности "нативного" исполнения. А по поводу быстродействия - для еще большего быстродействия толстые клиенты толстых фирм не парятся и покупают, например, Incisive Palladium у Cadence. :)

[dxp 53]

Я бы сказал, что не недоросли, а приостановились в развитии. Видимо как тупиковый путь. А то ведь был и behavioral compiler у синопсиса, да сплыл вместо того, чтобы продвигаться и расширяться.

Это мы не знаем. Вот бы же CoCentric, и вы сами им даже успешно пользовались. А потом - бац, и новая доктрина: SC - фтопку, SV - форева. Почему? Вряд ли тут технические причины. Политика и бизнес в чистом виде.

 

Преобразование программ в устройства это не то, за чем будущее.

Это как вопрос ставить. Верилог-описание, пока оно на симуляторе гоняется - это программа в чистом виде. А как только синтезируемую ее часть скормили синтезатору, так получили другую модель - нетлист для загрузки в устройство (либо изготовление устройства по нетлисту).

 

Ровно то же самое и с другими языками. Пока SC описание гоняется на компе - это программа. Как только прогнали через синтезатор - тоже получили нетлист. Никакой принципиальной разницы между V/SV и SC тут нет. А то, что разработчик должен эти моменты четко представлять, так это +100!

 

 

А так - продвижение в правильном направлении есть - например синтез верилог-описаний с описаний в симулинке. И синтез программ с тех же описаний. Это яркий пример синтеза с высокоуровневого функционального описания, который реально развивается.

И чем описание в m-файлах Матлаба принципиально отличается от описания на каком-нибудь ЯП?

 

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

Хм, ну так эта же история возникает и в случае, если, скажем, посадить РС программера, который окошки кодил в борландовском билдере, писать код такого кодека для какого-нить TMS или ADSP - если чел не разберется с аппаратной частью целевого процессора, не поймет его сильные стороны и ограничения, а будет бездумно метать операторы new/delete к месту и не к месту, то проект будет иметь полный провал. Нету здесь принципиальной разницы между программным и аппаратным дизайном - для достижения эффективности работы неизбежно надо вникать в целевое оборудование. С этой точки зрения сабжевая профессия никуда не денется. Даже при описании на высоком уровне абстракции все равно надо представлять, как это реализуется в железе.

 

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

А в чем тут вопросы? Чем исполнение компилированного промежуточного кода на виртуальной машине корректнее с точки зрения функциональности, чем исполнение нативного кода?

 

А по поводу быстродействия - для еще большего быстродействия толстые клиенты толстых фирм не парятся и покупают, например, Incisive Palladium у Cadence. :)

Ну, не у всех есть возможность покупать такие дивайсы. А писюк есть у всех. :)

[SM 0]

Это как вопрос ставить. Верилог-описание, пока оно на симуляторе гоняется - это программа в чистом виде. А как только синтезируемую ее часть скормили синтезатору, так получили другую модель - нетлист для загрузки в устройство (либо изготовление устройства по нетлисту).

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

 

И чем описание в m-файлах Матлаба принципиально отличается от описания на каком-нибудь ЯП?

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

[dxp 53]

Как ни ставь - описание на HDL, каким бы этот HDL не был, это описание, а не программа. Так как программа по определению это последовательность действий, выполняемых исполнительным устройством,

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

 

Но из этого описания можно получить как схему устройства, синтезировав нетлист, так и программу,

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

 

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

Как это нету? А это что?

 

А описание в виде соединения блоков в симулинке - это типичное функциональное описание.

Описание в виде блоков в симулинке - это типичное графическое описание - block diagram - структурно-функциональная схема. Это и в квартусе том же можно так же вводить описания, только все знают, что это не круто, а круто на языке. :)

 

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

Вот тут еще один момент, который я давно не понимаю в ваших постах: вы часто упоминаете функциональное программирование в контексте данной темы, ставите чуть ли не знак равенства между функциональным программированием и HDL, в последнем посте опять упомянули функциональное программирование, проведя аналогию уже с графической схемой симулинка. Я, конечно, совсем не специалист в функциональном программировании, даже можно сказать почти не знаком с ним - только на уровне принципов да и то поверхностно. Но даже эти поверхностные познания не дают мне возможности понять связь между ФП и HDL и схемой симулинка. Где в HDL и симулинке лямбда-исчисление? На какой из ФЯП (Haskell, OCaml, Lisp, Erlang и т.д.) похож Verilog/VHDL и Simulink? И чем похож?

[Sefo 0]

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

 

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

 

Так что SM прав - "программа по определению это последовательность действий, выполняемых исполнительным устройством"

[dxp 53]

И всетаки, программа - это не алгоритм. Программа - это реализация алгоритма.

Вы зачем усекли мою фразу? У меня было не "программа - это алгоритм", а "программа - это алгоритм, записанный на каком-либо языке". Алгоритм как таковой - это вообще чисто информационная сущность. Записанный алгоритм - это уже несколько иной объект, т.к. отображен на том или ином материальном носителе. И программа (записанный алгоритм) - это не реализация алгоритма, это его отображение на материальном носителе. А реализация алгоритма (если угодно углублять философию в этом вопросе) - это тоже алгоритм, но более детально проработанный, конкретизированный и наполненный деталями реализации. Это легко показать на примере:

 

Задание: есть МК AVR, к его выводу подключен светодиод, надо мигнуть светодиодом длительностью 1 секунда.

 

Алгоритм:

 

1. Инициализация (если светодиод был включен, выключить его).

2. Включить светодиод.

3. Подождать 1 сек.

4. Выключить светодиод.

 

Реализация алгоритма (на С):

 

if( PORTA & 0x01) PORTA &= ~0x01;

 

PORTA |= 0x01;

__delay_cycles(...);

PORTA &= ~0x01;

 

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

 

Если пропустим этот код через компилятор, то получим еще более детальную реализацию алгоритма (уже в командах целевого процессора). Это тоже будет алгоритм.

 

Поэтому противопоставлять термины "алгоритм" и "реализация алгоритма" не совсем корректно - второе является первым (но добавляет информации о нюансах).

 

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

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

 

1. Возьми деньги.

2. Оденься.

3. Обуйся.

4. Иди в магазин, который за углом.

5. Купи хлеба и водки.

6. Отнеси водку отцу в гараж.

7. Принеси домой хлеб.

8. Возьми с полки конфетку.

 

Алгоритм? Алгоритм. Записанное в виде вышепредставленных строк - программа (действий)? Программа. Исполнительное "устройство" - чадо мамаши.

 

Конечно, алгоритм, записанный на обычном языке, чреват ошибками и неоднозначностями как, например, в анекдоте:

 

Жена программиста посылает его в магазин и инструктирует:

 

- Купи палку колбасы, и если будут яйца, купи десяток.

 

Приходит программист из магазина, притаскивает 10 палок колбасы. Жена:

 

- Зачем столько купил?!!

- Но ведь яйца же были.

 

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

 

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

 

Ввиду всего вышесказанного не могу в целом согласиться с утверждением: "программа по определению это последовательность действий, выполняемых исполнительным устройством". Оно (утверждение) описывает лишь частный случай - какую-то реализацию алгоритма, но не описывает ситуацию в общем виде. В частности, обратите внимание, что даже в таком простом алгоритме про поход в магазин очевидно, что и строго определенной последовательности действий исходный алгоритм не навязывает - можно сначала обуться, потом одеться, потом взять деньги. Можно сперва одеться, потом взять деньги, потом обуться - количество вариантов из трех: 2^3 = 8. А можно даже делать и параллельно - одновременно обуваться (совать ноги в тапки), одеваться (натягивать куртку) и брать деньги (с тумбочки свободной рукой). Алгоритм (программа) не навязывает тут жесткой реализации - эту реализацию можно сделать более конкретной на следующем этапе. Но не все действия можно менять меж собой - пойти в магазин и взять деньги местами не поменяешь без нарушения целостности алгоритма как последовательности действий, приводящих к требуемому результату.

 

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

[SM 0]

а "программа - это алгоритм, записанный на каком-либо языке". Алгоритм как таковой - это вообще чисто информационная сущность. Записанный алгоритм - это уже несколько иной объект, т.к. отображен на том или ином материальном носителе. И программа (записанный алгоритм) - это не реализация алгоритма, это его отображение на материальном носителе.

 

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

 

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

[Leka 0]

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

Программа — ...

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

 

Предлагаю обсудить последовательные описания в синтезируемом HDL.

Например, приоритетный энкодер на Верилоге -

типично последовательное ("программное") описание параллельного устройства:

module prienc(
  input [14:0] d, 
  output reg [3:0] q
);
integer i;
always@* begin
  q <= 0; 
  for( i = 0; i < 15; i = i+1 )
    if( d[i] ) q <= i+1;
end 
endmodule

А вот описание "последовательных" устройств (КА и тп) на HDL - "закат солнца вручную".

Опишите, например, "устройство печати таблицы умножения":

writeln('Таблица умножения');
for i:=1 to 10 do for j:=1 to 10 do writeln( i, ' * ', j, ' = ', (i*j) );
writeln('При перепечатке ссылка обязательна').

Что надо добавить/изменить в HDL, чтобы подобные устройства описывались так-же наглядно,

как и в "последовательных" ЯП ?

[SM 0]

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

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

 

А что добавить в HDL, чтобы это также было удобно? Да то же, что и в том же С для этого используется - библиотечную функцию (или модуль).

[Leka 0]

Речь о синтезируемом HDL, под "writeln" понимается последовательный вывод в какое-либо _одно_ устройство (UART, например). На Верилоге "библиотечной функцией" не обойтись, придется описывать некоторый КА с коммутатором данных для устройства вывода - хуже программирования на ассемблере.