[blackfin 22]

Чтобы не быть голословным в заявлениях крутизны dsp - возьмем типичную DSP задачу - воть хоть мой примерчик 2006 года с

...

В Вашем случае обчая архитектура системы подкачала..

Тогда, для полноты картины, не могли бы Вы сообщить потребляемую мощность для решения на FPGA из Вашего "примерчика"?

Для сравнения - BF537-600 MHz потребляет 0.2A*1.2V=0.24W.

[fontp 0]

Чтобы не быть голословным в заявлениях крутизны dsp - возьмем типичную DSP задачу - воть хоть мой примерчик 2006 года с http://electronix.ru/forum/index.php?showtopic=15866 - это тупая fpga реализация ITU compliant адикма 16кбит - время кодирования сэмпла 243 нс, тактовая кажись 70 Mhz - и сотворите нам чудо, а мы посмотрим сколько будет стоить этот dsp и на какой частоте оно будет працювать.

 

Это не есть типичная dsp задача. Это детская радиолюбительская задачка.

 

G723.1 хочу

[Harbour 0]

Это не есть типичная dsp задача. Это детская радиолюбительская задачка.

 

G723.1 хочу

 

от простого к сложному - пока не видать результатов и на простых примерах

[MIkler 0]

Это не есть типичная dsp задача. Это детская радиолюбительская задачка.

 

G723.1 хочу

А ещё G.729A, G.729B, G.729AB, G.726, GSM, ILBC;

В общемто стандартные задачи для VoIP;

[Harbour 0]

...

Тогда, для полноты картины, не могли бы Вы сообщить потребляемую мощность для решения на FPGA из Вашего "примерчика"?

Для сравнения - BF537-600 MHz потребляет 0.2A*1.2V=0.24W.

 

Увы, камень довольно староват и по этому показателю конечно же проигрывает, но не валом :

 

; Power Models ; Final

; Total Thermal Power Dissipation ; 328.83 mW

; Core Dynamic Thermal Power Dissipation ; 208.17 mW

; Core Static Thermal Power Dissipation ; 82.50 mW

; I/O Thermal Power Dissipation ; 38.17 mW

 

P.S. Но интересно за сколько времени и на какой частоте DSP решит свою задачу

[MIkler 0]

насчет видео все обстоит также как и в остальных dsp задачах - применение fpga выйдет дешевле и быстрее. В Вашем случае обчая архитектура системы подкачала

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

[Harbour 0]

пасиб, учтем в проектных планах ;)

[anton 0]

А GPU и универсальные камни не стоит со счетов збрасывать, поскольку вложения в эти сферы значительны и соответственно они развиваются более высокими темпами. (и надо учитывать что это молодые игроки, CPU лет пять GPU чуть более года)

[jojo 0]

Мне не совсем понятно теперь.

Если задача едва может уложиться в средний Cyclone 3 и младший DSP TigerSharc 203, по стоимости, производительности и всему остальному. То следует ли из любви к искусству выбирать младший, равный по деньгам Stratix 2 или большой Cyclone 3, пытаясь сделать все на нем одном?

 

Есть ли у кого-нибудь успешный опыт разработки изделий вроде многоканальных сонаров или радиолокаторов с вычислителем на одной или нескольких FPGA без DSP или комптьютера? Требуется интерполяция сигнала в каналах, ЛЧМ сжатие (с БПФ ОБПФ) при заметном числе каналов 64-128 и длине опорного сигнала 1000.

 

 

Да, по поводу представленных ранее ссылок на Freescale, который с Altivec. Я бегло посмотрел pdfы и app. notes на них и увидел, что потребляют они в разы больше, чем DSP TS203, а работают в разы медленнее. И оптимизирующий компилятор им не помошник.

[Harbour 0]

принцип "любви к искусству" применяется в выборе пива или фильма посмотреть, но никак не в разработке архитектуры цифровых устройств. В последних я применяю 2 универсальных принципа :

 

- доступность и качество ресурсов

- способ их взаимодействия

 

чего и Вам желаю

[jojo 0]

Хм, я Вам ничего не желал. Пока пропущу это.

 

 

Поскольку изначально тема была о ненужности DSP процессоров...

 

На операциях с плавающей точкой FPGA (Altera, до 300 долл.) вообще сравнимы с DSP TS203 по производительности. Не говоря о скорости пересборки проекта FPGA и маленьком объеме внутренней памяти у тех же FPGA.

 

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

 

Прямые свертки с использованием целочисленной арифметики, выполняемые параллельно, на которых принято показывать преимущество FPGA, представляют далеко не весь спектр задач.

 

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

 

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

 

Количество синтезированных АЛУ и умножителей в FPGA ограничено емкостью и количеством "DSP-блоков".

 

Если мне нужны операции 1/x, sqrt(x), 1/sqrt(x), re^re+im^im, плавающие + - и * в _разных_ частях программы/алгоритма, то что, их выполнять в виде сопроцессоров, а потом мультиплексорами подключать к нужным частям схемы? Увеличивая размер конвейера, который и без того 5-10 для плавучих вычислений?

 

А между тем в интернете пишут, что могут сделать по определению "более эффективный datapath", чем в каких-то там DSP...

[Harbour 0]

Расшифрую понятие "ресурсы", видимо не всем понятно :

 

- время

- бюджет

- разработчики, обладающие определенной специализацией и навыками

- технологии (for ex. наработки, алгоритмы, киты, чипы - те же DSP или FPGA)

 

У одной команды ресурсы позволяют делать определенный проект именно таким образом, у другой нет - ну и что ? важен опыт и результат, полученные в конце проекта. For ex. я знал одного дедушку в Киеве, так у него не было ни DSP ни FPGA в 80 годах, он не долго думая на 155 серии сваял CPU + периферию + адаптер локальной сети (!), написал для него ассемблер, на этом ассемблере программу под задачу и успешно продал ряд устройств, проработали они 20 лет. Это я к тому что знающий человек с помощью кувалды и напильника может решить любую задачу именно грамотным использованием ресурсов, которые есть у него в наличии. Как говорится - если у тебя в руке молоток, то все вокруг превращается в гвозди.

Секрет успеха не в том во что упереться рогами - а в том насколько хорошо ты способен смотреть вокруг себя, иначе могут закончиться эти самые ресурсы ;)

[serg'o 0]

Господа мне кажется, или очередной holywar относительно ПЛИС / DSP превратился в спор кто и что быстрее может сосчитать.

Причем ИМХО не заслуженно были забыты DSP младшей серии в массовых устройствах. Например связка DSP+ARM в блютус гарнитурах, плеерах и подобных устройствах.

Тут удобство ДСП на лицо - ставиться слабенькая, малопотребляющая ДСПшка мипсов на 30-60, для которой к тому же есть куча кода на C/C++. Т.е. Большенство алгоритмов существуют в виде исходных С файлов, и могут быть собраны под любой процессор.

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

Плюс ко всему, после выпуска железки, можно свободно выпускать новые прошивки, поддерживающие новые форматы и т.д.

ИМХО на ПЛИС удобно делать то, что уже не будет меняться, либо что-то специфичное, вычислительно сложное, для чего нет готовых примеров.

Ну и еще одни аргументом за разработку на DSP можно считать доступность разработчиков....

Т.е. разработчика умеющего писать на C/C++ гораздо легче найти, чем разработчика на VHDL.

[vovka1960 0]

Вот я тут почитал весь тред - и растерялся...

Читать стал по причине того, что ищем мы тут решение для h264 компрессора для аналоговой камеры (ну - такая задача). плюс - звук.

Вот и поясните, если можно, какова же сегодня диспозиция? Брать решение под BF561 или искать что-то на циклоне?

Посоветуйте. Если не сложно.

Спасибо

[serg'o 0]

Вот я тут почитал весь тред - и растерялся...

Читать стал по причине того, что ищем мы тут решение для h264 компрессора для аналоговой камеры (ну - такая задача). плюс - звук.

Вот и поясните, если можно, какова же сегодня диспозиция? Брать решение под BF561 или искать что-то на циклоне?

Посоветуйте. Если не сложно.

Спасибо

 

Ну BF561 я брать вообще не советую ИМХО очень много кушает. У АД сейчас должна появиться новая линейка процессоров типа BF52X они должны сильно меньше кушать. Во вторых, если не хочешь лишних проблем, то я тебе посоветую вообще посмотреть по поставщикам - у кого есть готовые либы H264. Я в свое время встречался с готовыми либами для под TI и NXP но я думаю что есть и под AD. Кодеки обычно коммерческие, но как правило не очень дорогие, и покупка их обойдется дешевле чем разработка декодера... Таким образом задача выбора процессора сводится к поиску готового решения. А там и смотри на чем готовое решение дешевле...