DSP (FFT)

[tcpipchip]

Ola

Recentemente participei de algumas bancas de TCC...e fiquei com uma duvida quanto a performance de um DSP.

Em relação aos DSP com FFT por Hardware (micro instruções) já prontas...eu pergunto...são rápidos ? (comparados as transformadas implementadas por sofware em PC).

TCPIPCHIP

[msamsoniuk]

o que seria FFT por hardware? todos os DSPs que eu conheco fazem FFT por software, a unica diferenca eh que o software eh mais eficiente no DSP do que no x86.

Ola

Recentemente participei de algumas bancas de TCC...e fiquei com uma duvida quanto a performance de um DSP.

Em relação aos DSP com FFT por Hardware (micro instruções) já prontas...eu pergunto...são rápidos ? (comparados as transformadas implementadas por sofware em PC).

TCPIPCHIP

[tcpipchip]

Me refiro as microinstruções...tipo FPU.

Bem...podes me dar detalhes da eficiencia ?

[polesapart]

DSP features:
* Hardware modulo addressing, allowing circular buffers to be implemented without having to constantly test for wrapping.
* A memory architecture designed for streaming data, using DMA extensively.
* Separate program and data memories (Harvard architecture)
* Special SIMD (single instruction, multiple data) operations
* Special arithmetic operations, such as fast multiply-accumulates (MACs). Many fundamental DSP algorithms, such as FIR filters or the Fast Fourier transform (FFT) depend heavily on multiply-accumulate performance.
* Bit-reversed addressing, a special addressing mode useful for calculating FFTs
* Deliberate exclusion of a memory management unit. DSPs frequently use multi-tasking operating systems, but have no support for virtual memory or memory protection. Operating systems that use virtual memory require more time for context switching among processes, which increases latency.


Roubei da wikipedia. O Marcelo manja mais que eu então ele explica melhor hehe

Mas como dá pra ver tem recursos que são otimizados pra fazer este tipo de cálculo.

Uma coisa importante é o tipo de dados. Tem DSPs que não fazem cálculo em ponto flutuante, mas geralmente tem instruções específicas pra tratar dados tipo ponto fixo com precisão 16.16 (16 bits pra parte inteira, 16 pra parte fracionaria).


Enfim, DSP é otimizado pra este tipo de cálculo. Mas dependendo do que você vá fazer com o resultado do FFT, talvez você possa fazer com um AVR de 8 bits (tou tentando forçar, não sei se estou conseguindo)

[msamsoniuk]

pois eh... existem otimizacoes em relacao a um processador convencional, mas o ganho depende de vc usar essas otimizacoes corretamente.

a principal caracteristica de um DSP eh a instrucao MAC, cuja ideia eh calcular um segmento de codigo y+=k[i]*x[i] em um unico ciclo de clock. para conseguir isso, o DSP precisa de bancos de memoria separados para os operandos k[i] e x[i], de modo a transferir eles simultaneamente, em um unico clock. para apoiar isso, modos de enderecamento com auto-incremento, mascaras e loop por hardware permitem varrer arrays sem sobrecarga extra.

por exemplo:

Código: Selecionar todos

while(i--)
{
  y += (*x++)*(*k++);
}


isso em um x86 se torna algo parecido com:

Código: Selecionar todos

mov esi,_x // carrega x
mov edi,_k // carrega k
mov ecx,_n // carrega n
loop:
lodsl eax,[esi] // eax = *k++
lodsl ebx,[edi] // ebx = *x++
mul eax,ebx // eax = eax*ebx
add edx,eax // edx += eax
loopnz loop // decrementa ecx e roda enquanto nao-zero.


alguma coisa assim. na parte do loop vc teria que transferir 2 palavras da memoria, multiplicar, somar e entao rodar o loop. como a memoria tem um path unico, no minimo vc vai usar 2 clocks para transferir duas palavras. mais 1 clock para multiplicar, mais 1 clock para somar e mais 1 para fazer o branch. usando um x86 superescalar vc poderia talvez otimizar o branch, pq ele nao depende de nenhum resultado e pode ser calculado em paralelo com a soma por ex. entao vc teria pelo menos 4 clocks por termo y+=k[i]*x[i].

bom, em um DSP hipotetico vc teria:

Código: Selecionar todos

move x,a0 // carrega x
move k,a1 // carrega k
move n,r0 // carrega n
mac *a0+,*a1+,r1,rep r0 // while(n--) r1 += (*a0++)*(*a1++)


neste caso, as operacoes do loop correm em 1 clock.

dae vem a questao do paralelismo. no mesmo core o x86 nao vai alem do que jah temos, mas em um DSP otimizado para video eh possivel trabalhar vetorialmente. o codigo eh praticamente o mesmo, a diferenca eh que os operandos de entrada podem ser vetores. e com isso vc consegue fazer varias instrucoes MAC no mesmo clock.

daih entao vc parte para os multi-cores. e novamente os DSPs costumam estar na frente de um x86 em numero.

pegue como referencia este cara por exemplo:

http://www.freescale.com/webapp/sps/sit ... de=MSC8156

eh um six-core de 1GHz capaz de chegar a 48000 MMAC/s, ou seja, cada core consegue 8000 MMAC/s. comparativamente, um core x86 tipico de 2GHz consegue algo em torno de apenas 500MMAC/s.

mas a coisa nao para por ae, afinal o x86 tem uma unidade vetorial integrada... ou pensa que tem, nao sei. vamos pegar um caso mais realista, como o altivec do powerpc. com 1GHz ele consegue 16000 MMAC/s em teoria. chutando que o x86 tenha algo similar, um dual core x86 tipico de 2GHz poderia atingir os 64000 MMAC/s, deixando para tras os DSPs mais potentes, embora isso seja algo pouco realista: nem o powerpc, nem tao pouco o x86 possuem arquiteturas de IO e memoria capazes de aguentar o tranco para tanto processamento, sem falar que eh um tanto quanto especulativo comparar um DSP otimizado para certas aplicacoes com um processador de uso geral que eh otimizado para outras (ou que nao eh otimizado para nada).

entao, se fosse para apostar no mais eficiente e mais adequado para uma aplicacao especifica, eu apostaria no DSP.

[tcpipchip]

Marcelo

Muito bom mesmo, ficou claro! No TCC do aluno questionei a transformada de FOURIER em maquinas virtuais, o motivo do delay na FFT.
Eu havia sugerido que parte do processamento...poderia ser feito no modo real do X86...para ter maior velocidade...sem concorrencia de processos...e finalmente sugeri para trabalhos futuros o uso de DSP...

Obrigadao pela dissertacao!

T+

TCPIPCHIP

[msamsoniuk]

bom, o que eu comentei eh focado no processamento de sinais, mas existem questoes organizacionais de mais alto nivel.

por exemplo, em sistemas telefonicos eh comum vc encontrar sistemas que operam em tempo real e sistemas que nao operam em tempo real. no caso do sistema telefonico, todo o sistema eh cadenciado em cima de um clock de 125us, entao todos os delays sao multiplos deste valor. os sistemas de tempo real normalmente trabalham em cima de interrupcoes de 125us e buffers de 1 amostra, o que significa que o delay adicionado em cada etapa eh da ordem de 125us. jah nos sistemas que nao sao de tempo real vc trabalha com buffers de 80 ou 160 amostras, o que significa que o delay adicionado a cada etapa eh da ordem de 10 ou 20ms.

o que impacta o sistema de tempo real eh o overhead para trocar contexto e o tempo livre para rodar processos de fundo, necessarios para interface com outros sistemas e gerenciamento. em um DSP ou MPU menor, como o coldfire, esse overhead eh minimo e portanto estes componentes sao mais adequados a essa abordagem que um x86 ou ppc, onde o overhead de troca de contexto eh bem alto. jah no outro caso, o overhead de troca de contexto passa a nao ser tao impactante e MPUs maiores como o ppc e x86 comecam a ficar praticos, bem como permitem opcoes mais robustas em termos de sistema operacional com suporte a mmu. isso significa processos de interface e gerenciamento mais refinados, embora MPUs menores tenham isso tambem.

eh facil pegar um caso pratico em termos de componente para vermos a diferenca. o coldfire mcf5272 eh um componente com uma porta tdm desenhada para operar em realtime, em cima de uma interrupcao fixa de 2KHz (ela possui um buffer para 4 amostras), enquanto o powerpc mpc860 eh um componente com uma porta tdm desenhada para trabalhar flexivelmente com ringbuffers, o que permite um caso pratico de trabalhar com 4 buffers de 160 amostras cada uma e uma cadencia de interrupcao de apenas 50Hz. qual sera melhor?

depende:

eles rodam no mesmo clock e ambos possuem interface ethernet. o powerpc vai ter os buffers mais mastigados e vai ser uma solucao mais robusta, pq roda linux com mmu. o mcf5272 fica um pouco atras, mas ambos rodam bem solucoes de interface e gerenciamento. a diferenca para o leigo eh que dois telefones locais vao ter delay de um para o outro no powerpc, o que nao vai acontecer no caso do mcf5272, alem disso o mcf5272 possui instrucao MAC que o powerpc nao possui, embora o acerto de cache processando 4 amostras seja menor que processando 160. no fim das contas eh dificil saber exatamente qual seria melhor, pq ambos tem vantagens e desvantagens, mas eu chutaria que o mcf5272 seria um produto mais agradavel ao leigo por nao manifestar delay nas portas tdm locais... e isso dah um ponto extra para DSPs e MPUs menores, pq eh o que o cliente encherga.

mas por quanto tempo isso sera uma vantagem?

com a profusao de sistemas voip na telefonia publica, a tendencia futura eh o leigo comecar a aceitar o delay como algo normal e com isso nivelar DSPs e MPUs de todo tipo.