С графическими контроллероми понятно, а как 2D акселераторы делают?
Типа того

А что такого? Алгоритмы рисования линий, полигонов просто на ПЛИС делают и все. К примеру полупрозрачность - прочитали строку из SDRAM, одновременнос прибавлением к примеру 10, и записали обратно. Получилась горизонтальная линия полупрозрачная.

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

Например, смотрел код 2-х программ для NIOS II (application selector и picture viewer) так там и прямоугольники, и круги , и линии - все исключительно программно рисуется, по одной точке, у каждой координаты высчитываются в программе.

Помню где-то в середине 90-х были соревнования программеров для PC, размер кода был ограничен то ли 4-мя, то ли 10-ю килобайтами. Так люди в эти килобайты такое вталкивали, говорили, что в одной программе код программы одновременно являлся массивом констант. Так вот все это работало на 386SX и без всяких ускорителей и эффекты там были намного интересней, например очень реалистично было нарисовано пламя в динамике.

Они и сейчас есть. 


http://www.demoscene.ru/demo/demo1a.php3?2010

Что естественно, так как писалось на асме.

UPD: Только сейчас понял глубину вашей фразы. Если одновременно код являлся константами — то это круто конечно. Подобное помню только в bat-вирусах.

Прошу прощения за оффтоп.

Да,это не слишком удачно.
Но может , есть где примеры кода на ПЛИС?

Спрошу по другому:
Как аппаратно нарисовать дугу или прямую , не параллельную сторонам экрана? Теоретически , хотябы.

Вы уж решите что вам. Брезенхейм гуглите.

Да, мне по барабану, что вам проще.

Чего его гуглить , меня не он интересует, а его реализация на ПЛИСном языке.

Кстати, я давно не гуглю, а нигмлю.
Не нравится мне этот ваш гугиль-мугиль.

ПЛИСного языка не существует. Есть языки описания аппаратуры - это VHDL, Verilog, System Verilog
Для того чтобы получить корректные ответы, нужно самому, что-то на форум выложить. Мой совет начните например с функциональной схемы.
Попробуйте поискать описания на микросхемы - посмотрите там архитектуру.
Например это
Моожет еще/или это Здесь же приведена архитектура
Пример разработки на ПЛИС
Здесь можете найти алгоритмы...

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

НЕТ это именно демка ускорителя (контора TES, девайс D/AVE 2D)
http://www.tesbv.com/index.php?option=com_...9&Itemid=91
хрена такое видео на ниосе сделаешь - совершенно не те возможности

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

начтите с С/С++ - алгоритмы машинной графики или тому подобное (хоть в яндексе, хоть в книжных магазинах) - а на ПЛИС это можно перенести несколькими способами - то есть
в природе есть ПО которое может С скомпилить для ПЛИС, также есть SystemC (С++ библиотека)

ну и вообще, после токо, как на С сможете нарисовать (в "замедленном" режиме), перенести на "язык" ПЛИС это не проблема

Вот-вот! Я и говорю :"ПЛИСного", а подрузамеваю : "VHDL, Verilog, System Verilog"

А вы знаете нормальный синтезатор для SystemC ?

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

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


Ну, чуть попроще.

Книжка есть про это - "Основы интерактивной машинной графики" Дж.Фоли, А. вэн Дэм
аж 1985 года издания. Читать главу 11.

нет, практического опыта не имею, прикрыли эту тему синопсисы (баловался с systemC в DC 2005-го года).
википедия врет - инноватор и систем студио чисто верификационные тулзы

но тем не менее можно посмотреть
http://www.forteds.com/products/cynthesizer.asp
http://www.cadence.com/products/sd/silicon...es/default.aspx
http://www.mentor.com/products/esl/high_le...pult_synthesis/

есть у меня американские товарищи, которые ForteDS вполне успешно использовали

Ага, сразу вспоминается ветка про "устройство печати таблицы умножения" (3 строчки на Си).

Тему следует переименовать: «Напишите алгоритм Брезенхэма и кусочно-гладкой аппроксимации на hdl».
В чем конкретно затык, не понятно.

Вроде понятно - со стороны непонятно, неужели ПЛИСоводы до сих пор вручную расписывают все переходы в КА.

За всех не могу говорить, я все КА расписываю. Приведите «си-шную» аналогию, пожалуйста. У меня недостаточно опыта, чтобы ответить вам квалифицированно.
Думаю, ПЛИСоводы склонны экономить на ресурсах, поэтому вряд ли кто-то будет увлекаться поведенческим стилем там, где нужно делать 2d-акселерацию.

http://www.google.ru/search?hl=ru&neww...m+hdl+algorithm

Да. Расписывают. 


Мне вообще не понятно, почему этого делать не следует?
Экономия времени? Так этап "набора" кода занимает не более 5% общего количество времени, затраченного на разработку проекта.
Ну на сколько можно ускорить кодирование, перейдя на "Си"? На 20%, на 40%?


В итоге, сэкономите 1% или 2% от общего времени. И стоит оно того?
Лучше потратить время на совершенствование тех 20% действий,  которые отнимают 80% времени.  

Ну, вообще-то отладка программы написанной на Си выгодно отличается от отладки ассемблерной программы, как и само их написание. Это в качестве примера преимущества ЯВУ над ЯНУ.
Ускорение кодирования является следствием упрощения кодирования. Отсюда и отладка упрощается.
Попробуйте оспорить.

Эту аналогию и имел в виду.

Попробую 

Во-первых, для существенной разницы в отладки должна быть существенная разница в уровнях абстракций, которые предоставляют сравниваемые языки. Между V/SV и Си не такой разницы, как между Си и Asm.

Во-вторых, важно, как происходит отладка. При переходе от Asm к Си минимальный шаг отладки изменяется от инструкции ассемблера до инструкции языка Си. При переходе от HDL к Си минимальный шаг отладки все равно остается равен одному такту.

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



Из вышесказанного следует, что аналогия неуместна.

Из выше_сказанного вовсе не следует, что аналогия неуместна.

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


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


Мне не понятно, что такое минимальный шаг отладки. Тем более «минимальный шаг отладки все равно остается равен одному такту».
Отладка ведь не шагами измеряется, и далеко не всегда делается по шагам.

А вообще это уже оффтоп, не имеющий прямого отношения к теме.

http://forum.ixbt.com/topic.cgi?id=48:1629:4790#4790
Попробуйте на "чистом" HDL написать такое устройство - большая часть времени уйдет на подробные объяснения синтезатору, что такое "последовательные" действия.
C 2D акселератором будет та-же проблема.

Для решения любой задачи есть свои наиболее подходящие средства. В конце концов никто не запрещает использовать в качестве 2d-акселератора множество АЛУ или GPU, как в рядовой графической карте, «прорисовку» делать на Си или Ассемблере. А вот попробуйте на Си описать наиоптимальный GPU под архитектуру конкретной ПЛИС (не описывая КА, сохраняя «высокий стиль»). ИМХО, не стоит сравнивать топор и молоток.

Знаете, я для таких задач буду использовать sed. Зачем мне это писать на HDL? Может мне еще GUI на Verilog начать писать?

Пишут же, и вполне успешно. Достаточно пробежаться по youtube.

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


Я имел в виду, что с текущими синтезаторами с высокоуровневых языков, я пока не могу забыть о том, что устройство функционирует по тактам. Нельзя написать алгоритм и указать, чтобы выходные данные появлялись, например, через 12 нс. Нужно думать о частоте и латентности схемы. И, если что-то идет не так, то при отладке иногда приходится "смотреть" выполнение алгоритма по тактам.


Вы правы. 



Честно, не видел, но верю. 
Главный вопрос - зачем?  
Разные задачи - разные инструменты.

Видимо, for fun, как говорится.
http://www.fpga4fun.com/PongGame.html
http://www.youtube.com/results?search_quer...a+game&aq=f

Это, конечно, не GUI, но тоже весьма забавно. 

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

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

GUI самый настоящий.

http://www.youtube.com/watch?v=wkVf81ZwTk8 вот может быть это подпадет под ваше особое определение графического интерфейса.

Maverick, никто не сравнивал несравнимое.
Спасибо, что объяснили что такое Си и HDL и чем они отличаются.
В общем зачетная лекция, только к нашему обсуждению прямого отношения не имеет. Я ведь с вами согласен и писал несколько о другом.

Добавлю. IP ядра и библиотечные функции сродни классам, функциям в языке Си. Думаю, это неизбежный процесс.
Так ранее синтезатор не понимал знаки операций +,-,*
Это как раз говорит о движении в сторону Си (или языка подобного уровня абстракции, как его не назови).
И согласитесь (это как раз тот момент из-за которого возникла дискуссия), отладка одного и того же функционального множества, реализованного языками разного уровня будет тем проще, чем проще описание данной реализации. Сравните работу по отладке абстрактного блока с сумматором на гейт-уровне и на уровне описания сумматора "+". Когда-то такие споры и по поводу Си и Асма возникали.


Кстати, эта тема по-моему 1000 раз обсуждалась на форуме.

Уже можно Посмотрите на Bluespec SystemVerilog

теперь понял о чем речь ...


можно вопрос: САПР какого производителя его поддерживает или когда будет реализована поддержка?

напишите им что вы вуз и хотите их синтезатор, вроде как дают %)

Собственно их сапр и поддерживает (www.bluespec.com). Работает как препроцессор в SV
Стоимость этого тулза совершенно не гуманная ($1M в год за лицензию)

1М=1000000
если это так, то действительно ОЧЕНЬ МНОГО!!!

Я читал. 

С такими ценами, для меня - что они есть, что их нет - одинаково. 




Это - попало. 

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

сам не пользовался

а для совсем высокого - всяческие генераторы с Симулинка/Матлаба и тому подобное - кстати, как мне кажется, вполне подходящий флоу для ускорителя

опять же не забываем С2Н от Альтеры....

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

----------------

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

Я немного ошибся в порядке цены - оно стоит $100К
Много, даже для $100К