Jump to content

    
Sign in to follow this  
ilo

64-битные вычисления на 32-битном DSP ?

Recommended Posts

сделал в фильтре накопитель MAC на 32 разряда, все стало лучше, правда размер ПП вырос раза в 4 также и скорость вычислений упала также примерно, зато результат порадовал - даже 1 битный сигнал проходил через фильтр как следует и

Что это за сигнал такой - 1бит? И зачем его ещё и фильтровать??

Share this post


Link to post
Share on other sites
Что это за сигнал такой - 1бит? И зачем его ещё и фильтровать??

..сигнал амплитудой 1 бит.

Почему такой сигнал нельзя фильтровать?

Share this post


Link to post
Share on other sites
Что это за сигнал такой - 1бит? И зачем его ещё и фильтровать??

С цифровых микрофонов (с сигма-дельта АЦП) может такой сигнал приходить. Его обязательно нужно фильтровать.

Share this post


Link to post
Share on other sites

чем один бит хуже 2-х, 4-х, 8-ми?

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

для меня был важен сигнал от 2-х бит до всех 16 и даже 1 битный сигнал представлял ценность - например его частота.

 

Что это за сигнал такой - 1бит? И зачем его ещё и фильтровать??

если фильтровать фильтром с 16 битным накопителем 6 битный сигнал, проверять АЧХ фильтра, видно, что она не соответствует прототипу, на 12, 14 битах уже картинка красивее.

а вот 32 разрядный накопитель дает картинку АЧХ и при 4 битном сигнале как надо.

видно, что налицо шумы квантования упали в разы...

Share this post


Link to post
Share on other sites
Кстати - при операциях типа "крест-накрест" (если разрядности операции умножения не хватает), достаточно 3 операций, так как умножение младших частей можно отбросить :rolleyes:

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

 

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

 

 

вам вероятнее всего даже хватит только разрядность накопителе MAC увеличить.

 

ну, учитывая, что разрядность коэффициентов должна быть больше 32, чтобы подобрать именно ту характеристику, которая нужна, только разрядность MAC меня не спасёт. 64 бита - наше всё...

fdatool матлабовский придётся помучить, он шумы вроде умеет оценивать. но это уже после выбора платформы. пока главное, что быстродействие раза в 4-5 уменьшается отн-но 32-бит.

Edited by ilo

Share this post


Link to post
Share on other sites
тоже интересная идея, но просто отбросить младшую часть - вариант плохой, как написали уже выше.

Если результат данной MAC-операции дальше используется для следующей MAC - то нормальный вариант. Так как в след. MAC опять будет использоваться только старшие 32 бита,

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

Share this post


Link to post
Share on other sites
будет только на самый младший бит. Не более.

Это если всего два слагаемых. Если четыре - то на два бита. Если восемь - то на четыре, и т.д.

Share this post


Link to post
Share on other sites
ну, учитывая, что разрядность коэффициентов должна быть больше 32, чтобы подобрать именно ту характеристику, которая нужна,

что за характеристика такая?

Share this post


Link to post
Share on other sites
...на операцию "умножение с накоплением" можно также не рассчитывать.

Какие ещё подводные камни я не вижу?

...

Странное суждение. "Умножение с накоплением" и нормировкой при необходимости - основной инструмент для построения "целочисленных" цифровых фильтров.

Скорее всего Вы не видите механизмов накопления ошибки вычислений и их возможных последствий. Т.е. несколько переоцениваете их значение.

 

..не разбираюсь в цифровых фильтрах - но всегда думал что 32 битный результат уже даст динамический диапазон в 190 дБ.

Сколько же вам надо?

ДД результата будет сопоставим с ДД сигнала, если только речь не о совсем узкой полосе по сравнению со входной.

Для КИХ с 16-битным входом сгодился бы и 32-битный результат перемножения с типичными для сигнальников дополнительными битами аккумулятора для накопления.

Ошибка коэффициентов скажется только на форме характеристики, что для большинства 16-битных систем не критично.

Для БИХ всё несколько хуже. 32-битного результата умножения может не хватить. Если не в шум ударит, так в форму х-ки.

 

...

ну, учитывая, что разрядность коэффициентов должна быть больше 32, чтобы подобрать именно ту характеристику, которая нужна, только разрядность MAC меня не спасёт. 64 бита - наше всё...

...

А почему не 64/128? И что же это за такая характеристика?

Даже если коэффициенты БИХ будут отличаться на 3 порядка (10 бит), никаких принципиальных отличий от 32 бит Вы не найдёте.

На самом деле, нормировка, включая промежуточные стадии, это наше всё. 32x32 -> 64 это реально очень много.

А задранные требования к точности - гарантия получения неадекватных затрат при разработке и производстве.

Share this post


Link to post
Share on other sites
Ошибка коэффициентов скажется только на форме характеристики, что для большинства 16-битных систем не критично.

Для БИХ всё несколько хуже. 32-битного результата умножения может не хватить. Если не в шум ударит, так в форму х-ки.

А почему не 64/128? И что же это за такая характеристика?

 

Да, дело именно в форме характеристики. Коэффициенты изменяются пользователем, причём обычно имеются очень узкополосные фильтры для вырезания очень низких частот, где-то от 30Гц. Форма характеристики должна соответствовать ожидаемой пользователем (а пользователю ни к чему знать про ошибки цифровых фильтров, он считает, что характеристики очень близки к аналоговым ф., и по большому счёту он прав). Коэффициенты таких цифровых фильтров имеют значения 0.999... и только потом идут различия, которые и надо не потерять.

Share this post


Link to post
Share on other sites

Да все там довольно просто реализуется. Вот так выглядит пятиполюсный БИХ ФНЧ, Cortex-M3.

#define CHLPF_SHIFT (27)
//1.5kHz, 1dB, 5 poles, Z-transform
#define CHLPF_K0 (         961)
#define CHLPF_K1 (    98213853)
#define CHLPF_K2 (   521724849)
#define CHLPF_K3 (  1109599598)
#define CHLPF_K4 (  1181066974)
#define CHLPF_K5 (   629195138)

#pragma inline=forced
static long long FMULADD64(long long r, long long a, UREG32 k)
{
 asm("SMLAL    %L0,%H0,%H1,%2":"+Rp"®:"Rp"(a),"r"(k));
 asm("UMULL    %L0,%H0,%L0,%1":"+Rp"(a):"r"(k));
 a+=0x80000000;
 asm("ADDS     %L0,%L0,%H1":"+Rp"®:"r"(a):"cc");
 asm("ADC      %H0,%H0,#0":"+Rp"®);
 return r;
}

#pragma inline=forced
static long long FMULSUB64(long long r, long long a, UREG32 k)
{
 asm("SMLAL    %L0,%H0,%H1,%2":"+Rp"®:"Rp"(a),"r"(-k));
 asm("UMULL    %L0,%H0,%L0,%1":"+Rp"(a):"r"(k));
 a+=0x80000000;
 asm("SUBS     %L0,%L0,%H1":"+Rp"®:"r"(a):"cc");
 asm("SBC      %H0,%H0,#0":"+Rp"®);
 return r;
}

   //Filter I
   {
     static signed long long y1,y2,y3,y4,y5;
     signed long long result;
     result=(long long)I*CHLPF_K0;
     result=FMULADD64(result,   y1,CHLPF_K1);
     result=FMULSUB64(result,y1=y2,CHLPF_K2);
     result=FMULADD64(result,y2=y3,CHLPF_K3);
     result=FMULSUB64(result,y3=y4,CHLPF_K4);
     result=FMULADD64(result,y4=y5,CHLPF_K5);
     y5=result<<(32-CHLPF_SHIFT);
     I=(INT32)(result>>(CHLPF_SHIFT));
   }

 

Усиление, правда, не совсем точно 1, из-за малой получающейся разрядности K0. И стоит оставлять сверху один защитный бит, т.е. диапазон по входу +-2^30, а не 2^31.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this