посоветуйте 32-битный процессор

Thu, 20 Jan 2005 17:08:24 +0300 Vladimir Vassilevsky wrote to Harry Zhurov:

[...]

HZ>>>> Что касается DSP. Аналогично - по каким признакам? HZ>> А прогу-то ты поди на сях писал? Или на асме честно пытался?

VV> Реальный пример из реальной жизни. Hа 2810 (100MHz) выполнение VV> 32-битных Biquad Type I занимает по ~200 тактов на биквад. VV> Hа ассемблере. Вместе со всеми оверхедами. Hа 16-битном BlackFin DSP VV> то же самое занимает ~ 25 тактов. VV> Hе надо приводить в пример аппноты от TI - там, мягко говоря, VV> не то написано.

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

HZ>> MOVL XAR2,#X ; XAR2 = pointer to X HZ>> MOVL XAR7,#C ; XAR7 = pointer to C HZ>> SPM -5 ; Set product shift to ">> 5" HZ>> ZAPA ; Zero ACC, P, OVC HZ>> RPT #(N/2)-1 ; Repeat next instruction N/2 times HZ>> ||DMAC P,*XAR2++,*XAR7++ ; ACC = ACC + (X[i+1] * C[i+1]) >> 5 HZ>> ; P = P + (X[i] * C[i]) >> 5 i++ HZ>> ADDL ACC,@P ; Perform final accumulate HZ>> MOVL @sum,ACC ; Store final result into sum

HZ>> "Hеплохая прибавка к пенсии" (с).

VV> В том-то и дело, что это не совсем то, что нужно.

Ну, это кому что нужно. Мне дык нужен именно коррелятор. И тут как-то не видно серьезных недостатков.

VV> Hужно честное 40-битное накопление без сдвигов.

А чем чревато это нечестное? Ошибкой в МЗР результата?

VV> Еще нужны циклические буффера.

Не везде и не всегда.

VV> И округление. И арифметика с насыщением.

То же самое.

В общем, DSP'шность - понятие непонятное. :) Т.е. растяжимое. Базовые DSP операции TMS320F28xx могет делать пристойно. Слабее современных DSP, но значительно лучше любого МК общего назначения, лишенного аппаратного МАС, параллельной вычислениям загрузки операндов за такт и т.д.

Сказать, что TMS320F28xx не обладает возможностями DSP - это тоже самое, что сказать, что чел, не разбирающийся в тонкостях частичной специализации шаблонов, совершенно не знает С++.

VV> За сколько тактов выполнит такую HZ>> операцию (вот это вычисление отсчета свертки) ADSP-218x?

VV> i0 = ^data; VV> i4 = ^coeff; VV> cntr = N; VV> mr = 0, mx0 = dm(i0,m0), my0 = pm(i4,m4); VV> do dotprod until ce; VV> dotprod: mr = mr + mx0*my0(ss), mx0 = dm(i0,m0), my0 = pm(i4,m4);

Ну, т.е. вычисление одного отсчета за N тактов. А DMAC в примере выше позволяет это сделать на N/2 тактов. Или это опять не то?

Привет Sergei!

Сpд Янв 19 2005 10:28, Sergei Tuchinski -> Anton Abrosimov:

AA>>>> ARM7TDMI. ST>>> насколько я ничего не понимаю, это же не конкретный процессор, ST>>> а название ядра? меня же интересует именно конкретика (в теории ST>>> про ядро АРМ я сразу подумал), однако внезапно оказалось, что не ST>>> так-то просто найти конкретные варианты AA>> Hо и не так-то и сложно. Пpоцессоpов на его основе много, AA>> напpимеp атмеловские и филипсовские. ST> процессоров много, а найти - трудно :) с перечисленными мной ST> пожеланиями (не такими уж и навороченными, по-моему) с USB нашелся ST> только один, а без него - еще пара филипков В начальном письме эти пожелания не упоминались. Если же нужен USB-Host, то ваpиантов вообще мало.

Hа этом все, пока. Anton Abrosimov. ... Это письмо совершило ошибку и будет закрыто [OK]

Fri Jan 21 2005 07:21, Harry Zhurov wrote to Vladimir Vassilevsky:

VV>> Реальный пример из реальной жизни. Hа 2810 (100MHz) выполнение VV>> 32-битных Biquad Type I занимает по ~200 тактов на биквад. VV>> Hа ассемблере. Вместе со всеми оверхедами. Hа 16-битном BlackFin DSP VV>> то же самое занимает ~ 25 тактов. HZ> Во-первых, никто и не пытается сравнивать этот МК с настоящими HZ> крутыми DSP процессорами новейшего поколения.

BTW, фирма TI утверждает, что 28xx это DSP. Фирма AD утверждает, что BlackFin - микроконтроллер. Маркет.

VV>> Hужно честное 40-битное накопление без сдвигов. HZ> А чем чревато это нечестное? Ошибкой в МЗР результата?

Cумма сдвинутых слагаемых != сдвинутая сумма слагаемых. Больше слагаемых - больше сдвиг - больше ошибка.

VV>> Еще нужны циклические буффера. HZ> Hе везде и не всегда.

Для того же FIR фильтра на аппаратных циклах вещь очень удобная.

VV>> И округление. И арифметика с насыщением. HZ> То же самое.

Округление и насыщение - необходимые арифметические операции. Конечно, можно сделать в виде подпрограмм, но оверхед.

HZ> Сказать, что TMS320F28xx не обладает возможностями DSP - это тоже HZ> самое, что сказать, что чел, не разбирающийся в тонкостях частичной HZ> специализации шаблонов, совершенно не знает С++.

Hе надо все принимать так близко к сердцу :)

VV>> do dotprod until ce; VV>> dotprod: mr = mr + mx0*my0(ss), mx0 = dm(i0,m0), my0 = pm(i4,m4);

HZ> Hу, т.е. вычисление одного отсчета за N тактов. А DMAC в примере выше HZ> позволяет это сделать на N/2 тактов. Или это опять не то?

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

VLV

"Evil will prevail because good is dumb" (c) Dart Weider

Sat, 22 Jan 2005 19:25:01 +0300 Vladimir Vassilevsky wrote to Harry Zhurov:

VV>>> Реальный пример из реальной жизни. Hа 2810 (100MHz) выполнение VV>>> 32-битных Biquad Type I занимает по ~200 тактов на биквад. VV>>> Hа ассемблере. Вместе со всеми оверхедами. Hа 16-битном BlackFin DSP VV>>> то же самое занимает ~ 25 тактов. HZ>> Во-первых, никто и не пытается сравнивать этот МК с настоящими HZ>> крутыми DSP процессорами новейшего поколения.

VV> BTW, фирма TI утверждает, что 28xx это DSP.

Если зайти на сайт TI, то 28хх сидит в разделе Microcontrollers вместе с TMS470 (который, afair, АРМ) и прочими МК. А DSP - это у них другой раздел, где С5000, С6000 и другие сигнальники.

VV> Фирма AD утверждает, что BlackFin - микроконтроллер. Маркет.

Да? Ну, может быть. Мне попадалось только, что АД утверждала, будто бы микроконтроллерный код на Блекфине выполняется даже эффективнее, чем на микроконтроллере АРМе.

VV>>> Hужно честное 40-битное накопление без сдвигов. HZ>> А чем чревато это нечестное? Ошибкой в МЗР результата? VV> Cумма сдвинутых слагаемых != сдвинутая сумма слагаемых. VV> Больше слагаемых - больше сдвиг - больше ошибка.

Насколько я понимаю это просто заставляет разработчика больше думать о зависимости ошибки от условий. И учитывать это. Т.е. дополнительная головная боль. Кстати, 40-битный аккумулятор - это, конечно, хорошо, но и он не решает всех проблем - если надо гонять 16-разрядные данные в массивах длиннее 256, то и он может переполниться. Т.е. тут тоже надо думать. Можно, наверное, было бы сделать и больше 40 бит, но решили, что 40 бит достаточно. Всегда ищут разумный компромисс. В случае с 28хх решили, видимо, что компромисс лежит в стороне

32-битного аккумулятора со сдвигом.

VV>>> Еще нужны циклические буффера. VV> Для того же FIR фильтра на аппаратных циклах вещь очень удобная.

Удобная тем, что не надо перегружать заново адрес массива коэффициентов. Без этого - да, оверхедик на одну команду. Но он, имхо, мелочь. В 21хх, кстати,

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

VV>>> И округление. И арифметика с насыщением. HZ>> То же самое.

VV> Округление и насыщение - необходимые арифметические операции. VV> Конечно, можно сделать в виде подпрограмм, но оверхед.

Про округление не помню, а насыщение аккумулятора, насколько помню, имеется. Хотя, возможно, это не то же самое, что насыщение во время MAC.

HZ>> Сказать, что TMS320F28xx не обладает возможностями DSP - это тоже HZ>> самое, что сказать, что чел, не разбирающийся в тонкостях частичной HZ>> специализации шаблонов, совершенно не знает С++.

VV> Hе надо все принимать так близко к сердцу :)

:)

VV>>> do dotprod until ce; VV>>> dotprod: mr = mr + mx0*my0(ss), mx0 = dm(i0,m0), my0 = pm(i4,m4);

HZ>> Hу, т.е. вычисление одного отсчета за N тактов. А DMAC в примере выше HZ>> позволяет это сделать на N/2 тактов. Или это опять не то?

Т.е. признаешь, что тут ф28 почти вдвое быстрее за счет DMAC? :)

VV> Учти еще подготовку данных для dmac,

Какую подготовку? Берутся точно те же самые массивы данных. Просто одна половинка DMAC работает с четными адресами массива, а вторая - с нечетными.

VV> входное/выходное форматирование округление и насыщение данных, возможные VV> проблемы с точностью.

Соглашусь, что проблем, о которых надо думать, тут больше, чем с тем же ADSP. И кое-где они добавляют тормозов. Но тут неплохо бы сравнить этот 28хх с твоим новым фаворитом от Моторолы (раз ты утверждаешь, что оный может претендовать на звание DSP МК с не меньшим успехом). :) Вот взять, к примеру, этот же пример:

========= begin ============== VV>>> do dotprod until ce; VV>>> dotprod: mr = mr + mx0*my0(ss), mx0 = dm(i0,m0), my0 = pm(i4,m4); ========= end ================

Какой тут цикл у этого мотороллера получится? За сколько тактов будет вычислен отсчет свертки при длине сигналов, например, в 32 отсчета?

Sun Jan 23 2005 10:18, Harry Zhurov wrote to Vladimir Vassilevsky:

VV>> BTW, фирма TI утверждает, что 28xx это DSP. HZ> Если зайти на сайт TI, то 28хх сидит в разделе Microcontrollers HZ> вместе с TMS470 (который, afair, АРМ) и прочими МК. А DSP - это у них HZ> другой раздел, где С5000, С6000 и другие сигнальники.

Что ты такое говоришь :) Зайди на сайт TI и посмотри DSP Product tree. Так и называется: C28xx DSP. VV>> Фирма AD утверждает, что BlackFin - микроконтроллер. Маркет. HZ> Да? Hу, может быть. Мне попадалось только, что АД утверждала, будто HZ> бы микроконтроллерный код на Блекфине выполняется даже эффективнее, чем HZ> на микроконтроллере АРМе.

Врут, однако. General Purposе код на BF получается очень рыхлый, примерно как и на всех прочих DSP. Встроенная периферия скудная. Более-менее сложная задачка занимает десятки килобайт. Практически это значит что нужна внешняя память со всеми сопутствующими неудобствами. HZ> Кстати, 40-битный аккумулятор - это, конечно, хорошо, но и HZ> он не решает всех проблем - если надо гонять 16-разрядные данные в HZ> массивах длиннее 256, то и он может переполниться.

Если требуется FIR фильтр с длиной больше ~32...64, то это явный признак того, что алгоритм построен неоптимально.

HZ> думать. Можно, наверное, было бы сделать и больше 40 бит, но решили, что HZ> 40 бит достаточно. Всегда ищут разумный компромисс.

Hикто ничего не ищет. Всегда все делается наскоро и нахаляву.

VV>>>> Еще нужны циклические буффера. VV>> Для того же FIR фильтра на аппаратных циклах вещь очень удобная.

HZ> Удобная тем, что не надо перегружать заново адрес массива HZ> коэффициентов. HZ> Без этого - да, оверхедик на одну команду. Hо он, имхо, мелочь.

???? Тот же FIR фильтр. Hа каждой итерации нужно поместить данные в циклический буффер и пройтись по ним от головы буффера. Если нет аппаратного заворота указателей, придется разбивать вычисление на два цикла плюс оверхед на вычисления указателей на входах в циклы. Кстати, бывает ли RPT с неконстантным счетчиком или придется делать самомодифицирующийся код?

HZ> В 21хх, кстати, HZ> за это удобство приходилось платить необходимостью иметь размер буфера, HZ> кратный степени двойки ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Hе обязательно. Заблуждение происходит из-за глюков в линкере от DSP tools версий 5--

HZ>, и размещения такого буфера по адресу, кратному HZ> размеру буфера.

Hе представляет проблем. Автоматически делается линкером.

HZ>>> Hу, т.е. вычисление одного отсчета за N тактов. А DMAC в примере выше HZ>>> позволяет это сделать на N/2 тактов. Или это опять не то? HZ> Т.е. признаешь, что тут ф28 почти вдвое быстрее за счет DMAC? :)

Hе признаю :-I Сделай полную функцию s16 FIR(s16 x, s16 *z) С 16-битной точностью, округлением и насыщением. Посмотрим, сколько тактов на один выходной отсчет получится с учетом всего.

VV>> Учти еще подготовку данных для dmac, HZ> Какую подготовку? Перезарядку буфферов, потребную для 28xx.

HZ> Берутся точно те же самые массивы данных. Просто HZ> одна половинка DMAC работает с четными адресами массива, а вторая - с HZ> нечетными.

Что будем делать, если длина нечетная?

HZ> Соглашусь, что проблем, о которых надо думать, тут больше, чем с тем HZ> же ADSP. И кое-где они добавляют тормозов. Hо тут неплохо бы сравнить HZ> этот 28хх с твоим новым фаворитом от Моторолы (раз ты утверждаешь, что HZ> оный может претендовать на звание DSP МК с не меньшим успехом).

Ой, лучше не спрашивай :) Уел меня :)

VLV

"Быть честным - лучший способ оставаться бедным" (c) Hаполеон Бонапарт

Sun, 23 Jan 2005 16:29:34 +0300 Vladimir Vassilevsky wrote to Harry Zhurov:

VV>>> BTW, фирма TI утверждает, что 28xx это DSP. HZ>> Если зайти на сайт TI, то 28хх сидит в разделе Microcontrollers HZ>> вместе с TMS470 (который, afair, АРМ) и прочими МК. А DSP - это у них HZ>> другой раздел, где С5000, С6000 и другие сигнальники.

VV> Что ты такое говоришь :) VV> Зайди на сайт TI и посмотри DSP Product tree. VV> Так и называется: C28xx DSP.

А если посмотреть еще ближе - просто навести мышку на пункт Microcontrollers прямо в левом верхнем углу, где Products, то выпадает менюшка, в которой перечислено:

MSP430 MCUs TMS470 MCUs C2000 Controllers 8051-Based MCUs Other MCUs

Кто же прав?

VV>>> Фирма AD утверждает, что BlackFin - микроконтроллер. Маркет. HZ>> Да? Hу, может быть. Мне попадалось только, что АД утверждала, будто HZ>> бы микроконтроллерный код на Блекфине выполняется даже эффективнее, чем HZ>> на микроконтроллере АРМе.

VV> Врут, однако. General Purposе код на BF получается очень рыхлый, примерно VV> как и на всех прочих DSP. Встроенная периферия скудная. VV> Более-менее сложная задачка занимает десятки килобайт. Практически это VV> значит что нужна внешняя память со всеми сопутствующими неудобствами.

А TMS320F28xx как на твой вкус по рыхлости кода?

[...]

HZ>> думать. Можно, наверное, было бы сделать и больше 40 бит, но решили, что HZ>> 40 бит достаточно. Всегда ищут разумный компромисс.

VV> Hикто ничего не ищет. Всегда все делается наскоро и нахаляву.

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

VV>>>>> Еще нужны циклические буффера. VV>>> Для того же FIR фильтра на аппаратных циклах вещь очень удобная.

HZ>> Удобная тем, что не надо перегружать заново адрес массива HZ>> коэффициентов. HZ>> Без этого - да, оверхедик на одну команду. Hо он, имхо, мелочь.

VV> ???? VV> Тот же FIR фильтр. Hа каждой итерации нужно поместить данные в циклический VV> буффер и пройтись по ним от головы буффера. Если нет аппаратного заворота VV> указателей, придется разбивать вычисление на два цикла плюс оверхед VV> на вычисления указателей на входах в циклы.

Я тормоз. А ты не прав. Все там есть. И насыщение. И циклическая косвенная адресация. Для насыщения надо включить режим - установить бит OVM. Когда этот бит установлен, то автоматом происходит насыщение аккумулятора в 32 битах. Если этот бит сброшен, то происходит переполнение и специальный счетчик переполнений OVC (6 бит) считает количество переполнений - вот тебе расширение аккумулятора, если угодно.

Для реализации циклических буферов есть специальный режим косвенной адресации с заворотом, как ты выражаешься, указателя: *AR6%++. Количество слов при завороте задается в регистре AR1. При этом сравниваются младшие 8 бит AR6 и AR1, если совпадают, AR6[7:0] = 0. Если не совпадают, то AR6[7:0] += 1 в случае

16-битных операндов и AR6[7:0] += 2 в случае 32-битных.

VV> Кстати, бывает ли RPT с неконстантным счетчиком или придется делать VV> самомодифицирующийся код?

Бывает. Можно загружать 8-битную константу, а можно переменную. Разница в том, что загрузка переменной занимает больше времени (константа - 1 цикл, переменная - 4 цикла).

HZ>> , и размещения такого буфера по адресу, кратному HZ>> размеру буфера.

VV> Hе представляет проблем. Автоматически делается линкером.

Там дырки образуются из-за этого требования. Т.е. такой буфер не может быть размещен по любому адресу.

HZ>>>> Hу, т.е. вычисление одного отсчета за N тактов. А DMAC в примере выше HZ>>>> позволяет это сделать на N/2 тактов. Или это опять не то? HZ>> Т.е. признаешь, что тут ф28 почти вдвое быстрее за счет DMAC? :)

VV> Hе признаю :-I VV> Сделай полную функцию s16 FIR(s16 x, s16 *z) VV> С 16-битной точностью, округлением и насыщением. VV> Посмотрим, сколько тактов на один выходной отсчет получится с учетом VV> всего.

Насчет полной/неполной не возьмусь, не специалист я в этом. Но вот модифицированный пример вычисления отсчета FIR фильтра с циклическим буфером:

FIR16_16s: MOVL XAR6,@Xpointer ; Load XAR6 with current X pointer MOVL XAR7,#C ; Load XAR7 with start address of C array MOV @AR1,#N ; Load AR1 with size of data array N, SPM -4 ; Set product shift mode to ">> 4" ZAPA ; Zero ACC, P, OVC RPT #N/2-1 ; Repeat next instruction N/2 times ||DMAC P,*AR6%++,*XAR7++ ; ACC = ACC + (X[i+1] * C[i+1]) >> 4 ; P = P + (X[i] * C[i]) >> 4 i++ ADDL ACC,P << PM ; Final accumulate

Насыщение включить по вкусу. Округление тут, по-моему, не при чем. Правильность работы не проверял.

HZ>> Берутся точно те же самые массивы данных. Просто HZ>> одна половинка DMAC работает с четными адресами массива, а вторая - с HZ>> нечетными.

VV> Что будем делать, если длина нечетная?

Это не страшное ограничение. Всегда можно "добить" до четного.

Доброго здоровья, Anton!

21 Jan 05 11:50, Anton Abrosimov написал для Sergei Tuchinski:

AA>>>>> ARM7TDMI. ST>>>> насколько я ничего не понимаю, это же не конкретный процессор, ST>>>> а название ядра? меня же интересует именно конкретика (в теории ST>>>> про ядро АРМ я сразу подумал), однако внезапно оказалось, что не ST>>>> так-то просто найти конкретные варианты AA>>> Hо и не так-то и сложно. Пpоцессоpов на его основе много, AA>>> напpимеp атмеловские и филипсовские. ST>> процессоров много, а найти - трудно :) с перечисленными мной ST>> пожеланиями (не такими уж и навороченными, по-моему) с USB нашелся ST>> только один, а без него - еще пара филипков AA> В начальном письме эти пожелания не упоминались. Если же нужен USB-Host, AA> то AA> ваpиантов вообще мало.

ну я в первом письме про развитую периферию упоминал, и про флеш/ОЗУ, а что касательно USB, тут уже не до большого, похоже, придется брать без USB, а может и с внешним ОЗУ. кстати, в связи с этим вопрос, что лучше - внешняя периферия или внешнее ОЗУ/ПЗУ?

WBR, Сергей. ICQ: 101347299

Привет Sergei!

Пон Янв 24 2005 13:00, Sergei Tuchinski -> Anton Abrosimov:

AA>> В начальном письме эти пожелания не упоминались. Если же нужен AA>> USB-Host, то ваpиантов вообще мало. ST> ну я в первом письме про развитую периферию упоминал, и про То есть у филипсовских или атмеловских аpмов пеpифеpия недоpазвитая? :)

ST> флеш/ОЗУ, а что касательно USB, тут уже не до большого, похоже, ST> придется брать без USB, а может и с внешним ОЗУ. кстати, в связи с Вpоде фуджитсу какие-то есть с юсб-хостом.

ST> этим вопрос, что лучше - внешняя периферия или внешнее ОЗУ/ПЗУ? Пpи таком выбоpе я бы пpедпочел внешнюю память, если это не скажется на скоpости, достаточно ног и нет тpебований по защищености мк.

Hа этом все, пока. Anton Abrosimov. ... Это письмо совершило ошибку и будет закрыто [OK]

Sergei, ты ещё здесь сидишь?

Понедельник Январь 24 2005 13:00, Sergei Tuchinski wrote to Anton Abrosimov:

ST> ну я в первом письме про развитую периферию упоминал, и про ST> флеш/ОЗУ, а что касательно USB, тут уже не до большого, похоже, ST> придется брать без USB, а может и с внешним ОЗУ. кстати, в связи с ST> этим вопрос, что лучше - внешняя периферия или внешнее ОЗУ/ПЗУ?

Внешняя периферия обычно требует меньше соединений, внутренние ОЗУ/ПЗУ обычно работают быстрее. Вывод напрашивается сам-собой ;)

Георгий

Доброго здоровья, Anton!

25 Jan 05 20:28, Anton Abrosimov написал для Sergei Tuchinski:

AA>>> В начальном письме эти пожелания не упоминались. Если же нужен AA>>> USB-Host, то ваpиантов вообще мало. ST>> ну я в первом письме про развитую периферию упоминал, и про AA> То есть у филипсовских или атмеловских аpмов пеpифеpия недоpазвитая? :)

про филипс ничего не скажу, уже образцы заказали, а у атмела камней и с флешем, и с периферией очень мало

ST>> флеш/ОЗУ, а что касательно USB, тут уже не до большого, похоже, ST>> придется брать без USB, а может и с внешним ОЗУ. кстати, в связи с AA> Вpоде фуджитсу какие-то есть с юсб-хостом.

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

ST>> этим вопрос, что лучше - внешняя периферия или внешнее ОЗУ/ПЗУ? AA> Пpи таком выбоpе я бы пpедпочел внешнюю память, если это не скажется на AA> скоpости, достаточно ног и нет тpебований по защищености мк.

спасибо, твое мнение учел

WBR, Сергей. ICQ: 101347299

... У некоторых на лице написано: "Морда".