Я пока новичок в этом деле, как принято связывать например аудио АЦП с DSP? Использовать ПЛИС для преобразования форматов? Тогда какой предпочтительней?

Последовательные порты большинства DSP "умеют" I2S сами по себе.

можно чуть подробней на примере TMS320C672x
какие именно порты используются для I\O I2S? McASP?

Можно.

А что предпочтительней McASP или McBSP ?

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

DSP для обработки аудио потока, CPLD для преобразование форматов, ARM для управления этим всем хозяйством. Теперь вот не понятно как это все соединять во едино и не понятно по каким интерфейсам, например как организовать память SDRAM, соединять ARM и DSP к одной шине памяти или каждый к отдельной. Как вообще принято организовывать взаимодействие ARM и DSP, у ti есть dMAX, стоит ли его использовать или хватит I2C, SPI?
Так же не понятно как это все завязать на CPLD, с точки зрения гибкости я бы все что можно на нее завязал но тогда не хватит ножек. Может кто подскажет kit у которого можно взглянуть схему и что бы на борту были и DSP и ARM?
На сколько я понимаю I2S, SPI это для управления и для прокачки данных они не подходят, а мне бы хотелось иметь возможность оперативного и не ограниченного доступа к данным DSP от ARM и наоборот, так же необходимо что бы эти данные могли прокачиваться через CPLD дабы изменять их формат. Вот что то типа такого, проблема в том что я за ранее не знаю что мне может понадобится в будущем девайсе поэтому хочу заложить универсальную структуру что бы потом при программировании не чесать репу и вспоминать почему я не проложил "этот"

Уточните сначала:
1. Какой именно DSP.
2. Какой именно ARM.
3. Зачем вообще оказалась нужна CPLD.
4. Роли и задачи каждого компонента в системе.

Устройство предназначено для обработки и воспроизведения высококачественного аудио. Также оно предназначено как эволюшен кит для освоения ARM9, DSP, CPLD
на плате предполагаются слоты расширения для ADC, DAC. например будет возможность воткнуть в это устройство платы с различными микросхемами и реализацией ADC, DAC для сравнения их характеристик.

DSP планирую TMS320C6720 на нем будут висеть задачи по обработке I2S от плат расширения, полосовая фильтрация, усиление, задержка и так далее, во общем различные алгоритмы ЦОС

ARM AT91SAM9XE512 для связи с различной периферией, изернет, usb, flash. Для управления по SPI другими микросхемами то как приемник spdif, для управления начинкой на платах расширения. Понимаю что это как из пушки по воробьям но это нужно для обучения ARM9.
CPLD для связи плат расширения и всего остального хозяйства. Оно может и не нужно но я хочу получить некую гибкость при связи этого всего хозяйства.
также на плате будет дистребютор клока.

Нужна максимальная гибкость и расширяемость без переделки всей платы в дальнейшем.
Вот на пример я не знаю, понадобится мне внешняя SDRAM в CPLD и ARM9, но так как стоит она копейки, а устройство не серийное то почему бы не добавить и т. д.
Сейчас чешу репу как и по каким интерфейсам это все срастить что бы в дальнейшем при программировании и не возникло проблем.

Вот пример, на ARM9 я получаю аудио данные через изернет, мне нужно по внешним поступающим в ARM9 тактам БитКлок и ЛевыйПравыйКлок выдавать данные I2S, то есть ARM будет работать слэйв режиме. В каком виде она их будет выдавать? Смогу ли я их преобразовать силами ARM в нужных фармат I2S или для этого потребуются ресурсы CPLD?

Для процессора понадобится, иначе нет смысла его ставить и осваивать, можно сразу заменить на SAM7X.
Вместо CPLD (которой, кстати, SDRAM - как жучке пятая нога) лучше поставить FPGA.
Процессор с DSP придется "дружить" по последовательным интерфейсам - SPI/SSC на одной стороне и SPI/McASP на другой.


Может. Хотя атмеловские SSC не слишком хорошо дружат с I2S, есть некоторая недоделанность. Но такие вещи в любом случае надо выяснять в процессе проектирования, а не после него.

Тогда третий лишний. Достаточно двух, например, ARM+FPGA

Если FPGA так хороши в качестве сигнальников то почему последние до сих пор выпускают? Низкое энергопотребление?




А DMA? А если потребуется большие потоки перекачивать?

DMA при этом никуда не денется. Большие - это сколько?

Традиции, привычки, наработки, ниши, миграция DSP в сторону универсальных контроллеров общего применения. Разговоры за pro-contra можете найти на форуме, впрочем, как и многое другое. Можете и ARM выбросить, оставив DSP, например, Blackfinn. Третий лишний.

тут по ходу и второй и третий лишние, а не только третий. Речь, как я понимаю, о скоростной плавающей точке - так оставьте один TMS320C674x, там периферии - упериферииться, вплоть до SATA. А если уж очень хочется именно ARM по каким-то там религиозным соображениям и возни по двум раздельным софтинам, совместно работающим - возьмите например OMAP-L138 - там уже все решения по связи обоих ядер (674х и АРМа) решены без Вашего участия. Да и кит есть, на котором можно поэкспериментировать. А вообще, по опыту, то, чем занимается лишний АРМ (другой внешний CPU), всякие там рюшечки-управлюшечки, в большинстве случаев жрет не больше 5-8% производительности DSP, если реализовать в нем же. Имеется в виду загрузка ядра, а не память. Память это уж сколько сами воткнете. Плюс не надо тратить производительность обоих сторон на перекачку потока между собой.

Я планирую 8 слотов на прием и 8 на выход.
Каждый слот имеет интерфейс I2S, I2C, SPI
Также будет пара слотов для ADC с параллельным интерфейсом.
Ну и вспомогательные слоты для плат расширения типа ресивер трансмиттер SPDIF, дисплей, карты памяти и т. д.
завяжу ли я это все добро на один DSP? То что производительности хватит это спору нет, а портов?


Как по рекомендовал zltigo я наверно остановлюсь на связке DSP+FPGA
На FPGA повешу все разъемы может в будущем найду для нее работу.
А теперь другой вопрос, какой DSP применять, TMS320C6720 не подойдет так как периферии мало. Критерии, простой в освоении, всякие там ассемблеры изучать нет желания, только C.

Так я уже сказал - TMS320C674x (там их много разных, но все шустроплавучие, и все аудиоориентированные). Компилятор С у него достаточно мощный и неплохо оптимизирующий в т.ч. DSP-алгоритмы, но надо почитать об особенностях оформления циклов и функций (restrict, прагмы и интринсики). А на АСМе его программировать себе дороже. Он VLIW-архитектуру имеет, код операции до 256 бит - программирование на его "параллельном асме" может снести крышу неподготовленному программисту. И семейство это новое, которое явно призвано заменить 672х. Интерфейсы карт памяти, дисплея и к SPDIF-портам там есть на борту. Как и USB с Ethernet-ом.

----
кстати насчет FPGA. Ее можно иметь только ради защиты от сдирания девайса, если выбрать с внутренней и реально защищенной флешой, навроде LatticeXP2

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

А вот ее, родимую, и реализовать, причем такую, что без нее ничего не работает вообще - вот и защита.

Решил все таки на блекфин 537 остановится, подкупает наличие хороших китов, плюс есть модуль с спартаном 3. К тому же у аналога уже на сайте много готовых примеров реализации готовых алгоритмов, не знаю как у TI в этом плане, но китов на 674 пока не видел да и фрагментарность доступной информации у TI как то отпугивает. Сейчас думаю как заказать кит, таможня добро даст?

Киты можно купить в России. Например компании Элтех и Аргуссофт.

Кит на OMAP-L138 позиционируется как для разработки на 647х.
Зря на блекфине остановились. Если уж ADI - то для Ваших целей лучше шарк. Все же плавающая точка.

SM
то есть тип float и double float на блэкфине будут не доступны?

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

ну для обработки аудио данных его хватит?
А вот этот вариант как TMDXOSKL137BET ?

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


Хороший вариант.

уберите от тактовой один-два нолика... Вам хватит?

Как вариант ARM от Samsung. 600 MHz, float аппаратный, GCC, можно Linux(а можно и без ОС)... правда еще и туча лишнего ...

А я думал что наоборот из пушки по воробьям собрался стрелять



я правильно понимаю что у TMDXOSKL137BET уже есть jtag эмулятор на борту?

Ну так действительно, смотря какая обработка то...

Есть. (ну не станут же тахасовцы отровенно врать в описании?)

частота дискретизации 44.1, один стерео канал
например нужно реализовать ASRC и фильтр
примерно такой объем



ну мало ли, а то мне цена на BH-USB-510L ну совсем не понравилась

На мой взгяд, плавучка для этого не нужна. Если нужно портировать кем-то писаный на плавучке длииинный алгоритм в железо, то да, плавучка - это самое то.. Если же алгоритм пишется с нуля, то можно все промежуточные вычисления делать в 32-х битных целых. Это затормозит 16-битный DSP максимум в 4 раза. С учетом запаса по частоте, любой современный 16-битный DSP с частотой ядра ≥ 100МГц легко справится с этой задачей.

Правильно понимаете.

Что касается плавучки - это де-факто стандарт для аудио с большим ДД.

то есть создавать свою структуру для реализации вещественных?

В VDSP-шном компиляторе есть встроенный тип fract32 для вещественных чисел [-1.0,+1.0) в формате 1.31 и есть поддержка операций int32 = int32*fract32 самим DSP. Для фильтров и преобразователей частоты этого обычно достаточно.. При этом ДД примерно равен 6*31 = 186 дБ..

Как запустить CCS? Запускаю cc_app.exe поевляется какая та фигня в трее, он что без железа не запускается?

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

SM

Разобрался. Проблема была в другом. Под windows 7 нужно под администратором заходить, под созданным пользователем даже если у него назначены права администратора возникают проблемы со всякого рода софтом который пытается залезть поглубже в системы. Вот такие вот дела причем это не только с CCS.

Нашел примеры как сращивают MATLAB и CCS
http://cnx.org/content/m22943/latest/
Кто нибудь проделывал нечто подобное? Какие версии CCS и MATLAB это потдерживают.
Я правильно понял что в состав CCS уже идут модели Simulink *.mdl для различных кит боардов.
Но не понятно каким образом происходит связь MATLAB и CCS. Через COM, OLE?
В конечном итоге меня интересует, смогу ли я генерировать через выше описанные механизмы если они конечно поддерживаются код C для CCS через визуальную среду Simulink
это бы очень облегчило мою работу.

Да, через COM/DCOM. Но подробностей, что там можно, что нет - я не знаю.
*.mdl я в составе CCS не видел. Если что и есть, то в составе матлаба.