Quais são os usos típicos de um processador de software como o MicroBlaze?


8

Sei que a combinação FPGA-DSP é normalmente usada para eletrônica de potência de ponta / ultrassom / ressonância magnética / etc. É possível que o processador leve substitua completamente o DSP, mesmo em FPGAs inferiores, como o Spartan 3/6?

Adicionado: Qual seria o motivo de ter vários processadores softcore em um FPGA?


Depende de quão intensivo é seu aplicativo DSP, basicamente.
Fizz

Os odiados winmodems vêm à mente, embora você tenha uma CPU de uso geral para fazer o DSP.
Fizz

Aparentemente, você pode fazer rádio definido por software em um Virtex 5 e também no Altera Stratix .
Fizz

E, aparentemente, alguns tentaram isso em um Spartan 6 LX45. Qual aplicativo você tem em mente?
Fizz

O principal problema que vi nesse segmento é o útil software Vivado (baseado em PC) que funciona para gerar filtros etc. para o Virtex, não permite direcionar o Spartan. Não tenho certeza se isso foi apenas uma decisão de [segmentação] de marketing ou se o hardware Spartan é muito baixo.
Fizz

Respostas:


11

Sinta-se à vontade para ler rapidamente ou pular para o final. Sei que fui um pouco!


Geralmente você não usaria um processador flexível para substituir o material DSP. O hardware dedicado geralmente pode lidar com volumes maiores de dados mais rapidamente, porque você o projetaria para executar uma tarefa específica muito bem, em vez de ser uma CPU de uso geral.

Onde os processadores flexíveis entram em seu elemento é o controle e a coordenação.

Se você projetasse um sistema que precisasse processar um grande volume de dados, digamos aquisição de imagens com alta taxa de quadros, não seria possível usar um processador de núcleo leve para lidar com todos os dados, haveria simplesmente sobrecarga demais na CPU. O que você faria é projetar um firmware dedicado para realizar a tarefa de aquisição específica necessária (por exemplo, filtrar os dados, armazenar na memória, etc.).

No entanto, você ainda precisa de alguma maneira de instruí-lo sobre quando fazer as coisas - quando você deseja capturar, o dispositivo foi instruído para descarregar os dados, etc. Essas coisas não são muito fáceis de fazer em hardware dedicado, não se houver seqüências de eventos com entrada do usuário, basicamente tarefas que não fazem a mesma coisa repetidamente. Nesse caso, você usaria um processador de núcleo leve, pois é muito mais fácil escrever código de procedimento para algumas tarefas.

Outro exemplo (real), tenho trabalhado em um sistema de aquisição de ultrassom que transmite dados via PCIe. As tarefas que ele realiza são comunicadas pelo usuário e várias partes do sistema precisam ser configuradas. A coordenação do sistema não requer grandes volumes de dados, mas precisa de flexibilidade; portanto, é adequada para uma CPU de núcleo macio programada neste caso C. Fazer a mesma coisa em hardware físico exigiria grandes quantidades de recursos a maioria das quais seria usada com pouca frequência, por isso não teria benefícios em comparação com uma CPU.

Vale a pena notar que algumas tarefas podem variar dependendo da entrada do usuário, mas ainda são melhores em hardware dedicado. De fato, uma parte do código (programar controladores DMA para armazenar dados no gatilho) foi originalmente feita na CPU em cerca de 15 linhas de código, mas porque esse bit precisa ser feito no momento em que um gatilho ocorre, usando uma CPU que pode ser ocupado com outras coisas não é o ideal. Em vez disso, a tarefa é programada em um módulo Verilog, mas, no processo, torna-se uma enorme máquina de estado de 500 linhas com cerca de 15 estados e toda uma pilha de lógica de suporte - na verdade não. Mas, apesar de consumir muito mais recursos, é um período crítico, assim como uma necessidade.

Da mesma forma, eu preciso da geração precisa de disparos do ciclo do relógio, portanto, um módulo para executar essa tarefa faz parte do sistema, em vez de fazê-lo em uma CPU. Tanto esse núcleo quanto o acima são exemplos de como você pode usar uma CPU para realizar algumas tarefas, mas para outras críticas, você pode desenvolver hardware para complementar a CPU - da mesma forma que possui temporizadores, etc. em um microcontrolador.


Então, para resumir:

Os FPGAs são ótimas ferramentas flexíveis, mas a maioria dos projetos precisa de uma combinação de CPUs de núcleo leve, módulos configuráveis ​​(por exemplo, temporizadores) e hardware de tarefa única dedicado.

As CPUs são ótimas para a interação do usuário, controlando a ordem dos eventos, configurando os controladores. Eles são como o coordenador, o cérebro.

Alguns projetos podem precisar executar algumas tarefas bastante repetitivas que podem ser configuradas para se adequar a diferentes entradas - módulos de timer, exibições de caracteres, renúncia de botões etc. Isso pode ser feito facilmente com uma CPU, mas se você quiser executar várias delas com precisão em uma vez que se torna mais complicado - eles estão compartilhando os mesmos recursos da CPU. Portanto, o que você pode fazer é movê-los para um hardware dedicado que está intimamente conectado à CPU - dê à CPU a chance de realizar outras tarefas. Isso ajuda a CPU a fazer seu trabalho e interagir com os arredores, como seus sentidos.

DSP dedicado, transferência de dados (DMA) - basicamente qualquer tarefa que faça a mesma coisa repetidamente em altas velocidades - pode realmente se beneficiar da lógica dedicada em termos de velocidade e, possivelmente, de energia. São como os músculos do dispositivo, fazem todo o trabalho pesado.

Você terá que desculpar-se um pouco, mas eu gosto desse campo de EE. Felizmente, o que foi dito acima é compreensível e oferece uma visão extra do maravilhoso mundo dos FPGAs.


@crosley Entendo o seu ponto, mas se você quiser adicionar dois números de 128 bits em um processador de 32 bits, serão necessários vários ciclos. A ênfase estava no poder . Mas, na realidade, é totalmente dependente do que você está fazendo como um todo. Se tudo o que você queria era a adição, ter uma CPU inteira não faria sentido em um FPGA - apenas instancia um somador. Então eu acho que vou remover esse pedaço.
Tom Carpenter

1

Como Tom mencionou, o MicroBlaze não é apenas uma questão de substituir um DSP, mas substituir um microcontrolador tradicional que, de outra forma, poderia estar na placa.

Isso ocorre porque o núcleo do processador macio MicroBlaze não é um substituto particularmente bom para um DSP, pois carece de recursos especiais, como instruções MAC (multiplicar e acumular), buffers circulares, endereçamento reverso de bits e lógica de saturação.

Portanto, um núcleo flexível DSP separado, como o descrito neste artigo para o Xilinx Virtex-4, seria uma escolha melhor.

Muitos projetos de DSP se beneficiariam de ter ambos os núcleos flexíveis, já que muitos, se não a maioria dos projetos digitais que incluem um FPGA, também precisam de um microcontrolador geral de algum tipo. Desde que haja recursos suficientes disponíveis no FPGA (veja abaixo), processadores leves como o MicroBlaze não apenas eliminam uma parte da BOM (e, é claro, seu custo associado), mas também liberam pinos no FPGA, pois há não é necessário interconectar-se entre o FPGA e um microcontrolador. O espaço necessário para os traços entre as duas partes também é liberado.

O MicroBlaze pode rodar a 210 MHz em um Virtex-5. As versões com um MMU podem executar o Linux. Um MicroBlaze mínimo precisa de cerca de 600 LUTs e pode crescer até 4000 se forem adicionados um FPU, MMU, cache e outros itens. O processador programável DSP mencionado acima usou 1700 LUTs.

Como um FPGA Virtext-5 pode ter de 30.000 a mais de 200.000 LUTs, mesmo incluindo esses dois núcleos flexíveis representa apenas uma fração do chip. A incorporação de ambos permite que as operações convencionais e DSP ocorram em paralelo, se desejado, ao custo de uma complexidade adicional para sincronização entre os dois.

O IP do MicroBlaze é gratuito desde que você o use em um Xilinx FPGA e tenha licenciado o ISE Design Suite Embedded Edition (ou equivalente).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.