Decisões, decisões:Acelerador de hardware ou DSP?

Em meus dois primeiros blogs sobre este tópico, falei sobre por que os DSPs estão surgindo repentinamente em todos os lugares e por que, particularmente, estão começando a substituir alguns aceleradores de hardware personalizados (HWA) como uma opção mais flexível e preparada para o futuro. Neste blog, quero falar sobre uma análise mais detalhada que você pode seguir para decidir se deve pensar em um DSP em vez de uma implementação de HWA.

(Fonte:CEVA)

Mencionei no último blog alguns dos aplicativos ideais para DSPs. O processamento de sinais para modem ou sinais de áudio são exemplos óbvios. Outro exemplo muito comum é o processamento de sinais em radares para carros autônomos, que é bastante semelhante ao processamento de sinais em um modem. Muitos deles foram construídos em torno de um acelerador de hardware combinado com um pequeno controlador. Agora estamos vendo uma tendência significativa entre esses provedores de soluções de mudar para arquiteturas nas quais mais da funcionalidade é baseada em software rodando em um DSP, combinando o processamento de sinal atualmente tratado pelo HWA e até mesmo algum controle. O raciocínio é simples:o software oferece mais flexibilidade em termos de funcionalidade e custo muito mais baixo e capacidade mais oportuna de se adaptar aos padrões de comunicação em evolução.

O posicionamento global é outra aplicação, neste caso, alavancando fortemente os recursos matemáticos inerentes aos DSPs para os cálculos de triangulação. Você pode inicialmente pensar que o suporte GPS é tudo que você precisa e talvez possa construir uma implementação realmente rápida em um acelerador de hardware. No entanto, no padrão GNSS global, você também precisa considerar o suporte para GLONASS (Rússia), Galileo (Europa) e BeiDou (China). Uma implementação com fio para GPS pode limitar seus mercados desnecessariamente, uma vez que o suporte a todas as variantes pode ser realizado no software se você estiver executando em um DSP.

Até agora, tudo bem em princípio, mas como será o desempenho de uma implementação de DSP em comparação com uma implementação de hardware personalizado? Ilustrarei com um exemplo popular hoje:digamos que você esteja construindo um aplicativo IoT e planeja usar o NB-IoT para comunicação. O comprimento do subquadro é de 1 ms, o que define um limite para determinado processamento que deve ser concluído dentro desse tempo. Neste exemplo, isso incluiria os algoritmos da camada física, o código de controle L1 e a pilha de protocolo. Para uma plataforma DSP / NB-IoT típica de baixa potência rodando a 100 MHz, 1 ms oferece 100k ciclos para completar esses cálculos.

Para estimar que tipo de desempenho você pode esperar em uma implementação de DSP equivalente, você precisará trabalhar com um fornecedor de DSP incorporado. Essa empresa já deve oferecer soluções de software em suas plataformas para vários aplicativos, que eles terão caracterizado por desempenho e potência. Para desempenho, eles devem ser capazes de fornecer uma estimativa da contagem de ciclos para sua função, neste caso um modem NB-IoT, e fornecer um gráfico semelhante ao mostrado abaixo. Cada ponto no gráfico representa o número de ciclos necessários para executar e o gráfico é mapeado em um intervalo de cargas com variação no tempo. O gráfico também deve mostrar os ciclos de pico permitidos, dada uma frequência de operação selecionada.

(Fonte:CEVA)

Agora você tem um método para estimar se a carga do seu aplicativo funcionará nessa frequência ou se você pode precisar aumentar a frequência para ter mais espaço. Claro que esta estimativa é baseada na implementação de software do fornecedor, embora seja razoável esperar que seja muito bem ajustado. Você não precisa se comprometer em usar o software deles, mas a estimativa deve ser boa o suficiente para orientar sua tomada de decisão.

Se você tiver bastante espaço em sua frequência de operação preferida, talvez possa mover mais funções HWA para o DSP ou talvez adicionar mais recursos diferenciadores, como suporte de localização GNSS. Se, por outro lado, você precisar aumentar a frequência para atender aos requisitos de latência, isso também é possível, embora você deva levar em consideração que aumentar a frequência aumentará o consumo de área e energia.

Uma maneira rápida de obter uma estimativa de poder é olhar quanto do software irá para o verdadeiro código DSP, usando paralelismo, unidades MAC etc., e quanto irá para o código de controle - o geral usual funções de chamada de código de propósito, tomada de decisões e outras operações padrão. Normalmente, você pode visualizar essa divisão, digamos 40% do código de controle e 60% do código DSP. Um fornecedor de DSP geralmente fornece números de potência típicos para esses dois casos, por exemplo 2mW para código de controle e 4mW para código DSP (em cada caso a 100 MHz). Em seu cálculo, você deve levar em consideração a atividade média do DSP, por exemplo, 50% da frequência. Portanto, neste exemplo, você estimaria (0,4 * 2 + 0,6 * 4) * 0,5 =potência média de 1,6 mW (assumindo 50% da atividade média).

Em resumo, você deve ser capaz de desenvolver uma estimativa bastante razoável de qual desempenho e potência pode esperar de uma implementação DSP de sua função aceleradora (a menos que esteja desenvolvendo algo realmente incomum - neste caso, você deve modelar seu aplicativo nos DSP's Ferramentas de SW para obter uma estimativa bastante precisa da contagem do ciclo). Quando você considera a flexibilidade adicional obtida com a implementação de um software e a capacidade de economizar custos combinando vários aceleradores em um processador, uma solução DSP parece muito atraente.