[anton 0]

Тут почитал материалы с конференции по давинчи.

Однако развивают. :05:

 

Из всех ДСП процессоров ТМС будет дольше всех оставаться востребованным.

[shread 0]

Речь то шла наоборот, о замене 28хх на некий АРМ. ;О)

Я как раз иронизировал на тему того что армы в данном случае только в задаче ногодрыжества в состоянии тягаться с 28xx, при том что это пока еще не DSP=)

Давинчи это оч серьезно. За такие деньги такие процессоры... в очередной раз проникся уважением к TI... и купил пару инженерный образцов и кит под DM6437 :08:

[aser 0]

DSP мертв - это точно.

Любой проц. мертвеет через 3-5 лет.

Не мертвеет платформа.

TMS -это платформа, Пентиум -это платформа,Virtex -это платформа. ARM - платформа.

Платформа - это такая архитектура, которая ГАРАНТИРОВАННО не умирает долгие годы.

Зачем проектировать что-то архиновое, если задача решается на платформе?

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

все хорошо получается?

Если при работе с платформой не бывает проблем с библиотеками, вводом-выводом?

 

Отсюда мораль, DSP не умрет, если это- платформа.

[mse 0]

...

Отсюда мораль, DSP не умрет, если это- платформа.

Дык, речь то и идёт как о платформе. ;О)

[jojo 0]

Еще речь о том, что программисту не нужны мозги, а то, что такой программист не может освоить - не нужно тоже. В FPGA еще быстрее утонет такой, чем в DSP. :/

 

>http://caxapa.ru/96372.html

 

>Стоимость труда программистов. Производители чудо камней регуляно забывают выпустить на рынок brain boost kit для программеров, а без него все это игрушки.

[Singer 0]

Вот вам обычная задача - нарезать в реалтайме сигнал полосой 80 мегагерц на 40 кусочков по 2 мегагерца (банком фильтров). Покажите мне процессор, который сможет осилить хотябы четверть полосы? Virtex4 SX - 35 делает это, и даже еще место остается. При этом параллельно на разных стадиях выполняется больше 150 умножений. Не говоря уже о всяких обменах по интерфейсам. Время разработки и отладки подобного проекта при наличии опыта - пару месяцев (я имею ввиду сам фильтр, обвязка, интерфейсы, плата, наконец - это значительно дольше, но это разрабатывается один раз и надолго). Как человек, пару лет очень плотно работающий с реализацией DSP ПЛИС, могу сказать, что страшного ничего нет, ну усидчивость, внимательность нужна. КИХ фильтры лепятся за день-два (полностью вручную, не из ядер, в ядрах отсутствует нужный функционал, в частности передискретизация, ресамплинг)...нужно только руку набить. Все разговоры про то, что разработка для ПЛИС - нечто сверхъестественное и занимаются этим какие-то гении, вызывают у меня улыбку :) Это предрассудки.

Изменено 26 ноября, 2007 пользователем Singer

[jojo 0]

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

 

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

Автор пишет, что

http://caxapa.ru/96372.html

 

> подтаскивание данных для АЛУ (выборка данных в регистровый файл, генерация при помощи хитрожопых многомерных генераторов адресов индекса в массиве для взятия очередного значения, X, Y и прочие памяти, и т.д.)

* АЛУ - выполнение операций над операндами

* оттаскивание данных из АЛУ

>Все сильно законвейризовано, так что "со стороны" кажется, что DSP все это делает за один такт.

 

 

>Потом наступает очередь тяжелой артилеррии - многоядерность. BF561, и , как вершина достижения,

 

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

 

>DSP железяки предлагают свое собственное пространство примитивов (те самые 4 операции). И пЫсатель софта, прежде всего, должен выполнить сильно нелинейное преобразование одного пространства в другое. Все усложнаятся еще и тем, что изначальное пространство может быть не суперскалярным, а его надо отобразить на суперскалярное пространство. Получается полная засада. Наиболее талантливых представителей рода DSP программистов регулярно отлавливают вредители из Кащенко и Ко, а все остальные вынуждены потратить остатки своих мозгов на профессиональное лепление отмазок типа "почему при хз. скольких GOPS на этом камне никак нельзя сделать MPEG 4 AVC).

 

Непонятно, при самостоятельной разработке тех же фильтров с КИХ или БПФ/ОБПФ предлагается избежать знакомства с упомянутыми выше генераторами адреса блоков памяти, конвейерной структурой вычислительных устройств и параллельной работой этих вычислительных устройств?

 

Или переложение алгоритма на логические ячейки и блоки памяти будет в 10-100 раз легче и веселее, чем для процессора DSP, чтобы программист не попал в Кащенко?

 

>Идельная система:

* проц общего назначения с высокоэффективной DMA (простенький MAC желателен, чтобы делать "медленные" DSP алгоритмы, не тратят ресурсы FPGA). CF 150-240 Мгц самое то :))

 

А где DMA и шины лучше и функциональнее, чем в DSP? И не хуже, чем 150-240 МГц MAC?

 

>* FPGA на шине, со своей локальной памятью.

[anton 0]

:) кстати попался файлик.

PowerPC_or_TigerSHARC_Nov2004.doc

[dtsar 0]

Вот вам обычная задача - нарезать в реалтайме сигнал полосой 80 мегагерц на 40 кусочков по 2 мегагерца (банком фильтров). Покажите мне процессор, который сможет осилить хотябы четверть полосы?

 

Согласен, DSP это не сделает, но он нарежет эти 2МГц куски по 25 КГц, чего ПЛИСина врядли сделает, поскольку больше 15 точечного ДПФ(которое ты используешь в этом проекте ;) ты врядли сделаешь за, как ты сказал "2 месяца". А слабо сделать переключение расфильтровки в реалтайме? (разумеется без БПФ степени 2).

Я так думаю, что FPGA сложно будет без DSP, как и DSP без FPGA.

[evg123 0]

Какую элементную базу выбирать зависит от

задачи,

габаритов устройства,

энергопотребления,

денежных средств,

имеющихся наработок,

требований начальства, сроков.

 

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

 

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

 

Например, 51-ые контроллеры живут и даже имеют на груди (Silabs) 100 МГц-овые ядра и risc-архитектуру. (Почему? До сегодняшнего момента - на них много было сделано, и сейчас они имеют конкретную нишу - недорогие многоканальные измерительные устройства. )

 

Я, например, недавно поработал с dsPIC в MPLAB и понял, что средства разработки Keil гораздо удобнее, чем MPLAB и, если станет выбор какой процессор брать, PIC или Sygnal (при условии что задача решается там и тут) - я без сомнения возьму Sygnal. Хотя архитектура PIC несравненно более привлекательная.

 

Второй пример - сейчас у меня на плате CygnalF342 (48 MGz) и 320VC5509a, связанные через SPI.

CygnalF342 через UART связан с RS485-ой сетью (на скорости 920кБит/с); 320VC5509a - связан с кампом через USB. Контроллер опрашивает сеть, получает поток - отправляет на обработку в DSP а тот - в комп. Более грамотно было бы поставить один ARM9 и всё; но я его не знаю => временные затраты + требование начальства - "брать DSP", а задачу надо делать быстро. Иначе амба.

 

Третий пример - соседнее подразделение купило DSK6446 со всеми прибамбасами, но разбираться в двух ядрах (даже с учетом солидных наработок по DSP и массе готовых стэков) - долго. По миниатюаризации и энергопотреблению требования у них сняли. Вот они теперь подумывают взять какой-нибудь пень и пару каких-то плис, взять WinCE и закрыть вопрос проще и быстрей (есть в этой части наработки)

 

Вывод 1: Ради искусства народ (особенно старше 30) не работает, а ради денег - а это - работу надо делать быстро и из того, чем умеешь пользоваться.

Вывод 2: Ориентироваться надо на популярные микросхемы и решения, которые имеются или предлагаются в настоящий момент. Почему? Популярность это гарантия того, что эта микросхема не снимется с производства, и, следовательно, ваши наработки не улетят в трубу. (Вспомните 51-ый)

(На семинаре Аналог-Девайса мужичок сказал, что есть у них микросхемы, которые и 20 лет выпускаются, а есть те которые не выдерживают и года - всё зависит от срока)

Вывод 3: Использовать популярные средства разработки (например Keil, CCS) - какая-никакая гарантия того, что вы сможете перенести программное обеспечение на более мощные чипы.

Вывод 4: Наши разработки - зависят от их западного "ненашего" рынка. Их рынок определяется спросом. Спрос можно оценить по поулярности. На это надо направить основное усилие по оценке того, или иного решения.

 

Я, ИМХО, не против ПЛИС, не против DSP. Я за конкретный работающий прибор, который кому-то приносит пользу не на словах, а на деле. Я, ИМХО, не верю в сенсации.

 

 

 

 

 

 

 

 

 

 

 

Хотя, как архитектура - они, являются архаизмом. Я считаю, например, что надо ориентироваться на микросхемы, которые не планируются к снятию с производства. Это значит, что

[1891ВМ12Я 0]

скажите, кто-нибудь добивался на FPGA работу вентилей с частотой, скажем 600 МГц?

Есть задачи где FPGA на 10 МГц благодаря параллельной обработке данных уделает обычный проц на 1 ГГц...

[blackfin 22]

Есть задачи где FPGA на 10 МГц благодаря параллельной обработке данных уделает обычный проц на 1 ГГц...

Есть задачи где обычная кувалда благодаря своему весу уделает любую FPGA.

 

PS. ИМХО, Не нужно додумывать вопросы за автора. ;)

[1891ВМ12Я 0]

Есть задачи где обычная кувалда благодаря своему весу уделает любую FPGA.

PS. ИМХО, Не нужно додумывать вопросы за автора. ;)

Просто мне показалось что автор этого поста решил взвесить вычислительную мощность FPGA в мегагерцах - я не мог пройти мимо такого...

[anton 0]

Есть задачи где FPGA на 10 МГц благодаря параллельной обработке данных уделает обычный проц на 1 ГГц...

 

Интересны как раз конкретные примеры (а то сравнение с куволдой пройдет). Вот как без большого опыта оценить влезит алгоритм в мелкосхему или нет (и это относится ко всем платформам ДСП ПЛИС универсальник) поскольку есть накладные расходы которые могут убить весь проект.

[1891ВМ12Я 0]

Интересны как раз конкретные примеры (а то сравнение с куволдой пройдет). Вот как без большого опыта оценить влезит алгоритм в мелкосхему или нет (и это относится ко всем платформам ДСП ПЛИС универсальник) поскольку есть накладные расходы которые могут убить весь проект.

Да я ж просто хотел намекнуть что на ПЛИСах не в мегагерцах счастье, а уж на что хватит или не хватит это другое дело... Ну а насчет примера, это любая задача которая требует много вычислений, которые необходимо выполнять практически параллельно... И тут либо несколько DSP на большой частоте либо ёмкая плисина... Пример: обработка кодированного OFDM сигнала с частотой 8 МГц, и тут либо DSP на 1 ГГц (и то может мало...) либо очень ёмкая ПЛИС с тактовой 50 МГц... А что если надо более шустрый сигнал обрабатывать, например на 24 МГц - DSP умрёт?

ЗЫ Оценки не точные, просто приблизительные, судя по имеющимся реализациям подобных штуковин :)

ЗЗЫ ИМХО DSP + FPGA = хорошо :)