Microcontroladores Multicore – Parte 1

Olá caro leitor. Vamos começar a leva de artigos de 2017, eu costumo selecionar assuntos à medida que vejo discussões e dúvidas aparecendo, seja no meu ambiente de trabalho ou visitando comunidades de desenvolvimento. A indústria de semicondutores, em específico microcontroladores e SoCs (System on Chip), tem premiado os desenvolvedores de firmware com microcontroladores cada vez mais poderosos, seja velocidade processamento, recursos como set de instruções DSP, mais memória. O fato é que os fabricantes estão fazendo ainda melhor. Um processador poderoso é pouco? Então que tal se eu colocar dois processadores e vender tudo em um único circuito integrado? Melhor ainda, colocarei dois processadores específicos para necessidades diferentes, e venderei sob um único encapsulamento. E aqui chegamos à era dos microcontroladores multicore.

Multicore assimétrico, acho que já ouvi falar disso

O leitor mais atento vai perceber que essa realidade de multiprocessamento já existe a anos, quando falamos de desktops, notebooks e dispositivos mobile, com seus diversos cores ARM Cortex-A (alguma coisa) ou aquele Intel Core 2 (alguma coisa). Porém notem que nesses casos existem processadores iguais, para que tarefas possam ser realizadas em paralelo. Assim um único sistema operacional gerencia qual aplicação deve rodar em qual processador e porque. A esse cenário nomeamos como multiprocessamento simétrico (SMP).

O que muda no mundo dos microcontroladores? O que os fabricantes perceberam foi o seguinte cenário:

• Aplicação envolvendo processamento intensivo de dados e execução periódica, que não pode parar ou perder sua periodicidade de execução atendendo uma requisição que veio pela porta serial, ou um pressionamento de um touchscreen;
• Aplicação que processa dados de touchscreen, entrada de dados de usuário, interage por meio de telas, mas que não consegue realizar um processo de tempo real ou que exija baixo tempo de resposta.

Percebam que são aplicações distintas, assim sendo não faz sentido duplicar o processador, pois a necessidade de cada aplicação é distinta. Então o que eles fizeram, colocaram um núcleo de processamento que possui mais afinidade cada um com seu cenário, vejam os dois exemplos abaixo:

Esse processador da figura trata-se de um conhecido, apesar de irreconhecível à primeira vista. Lembram do Arduino 101? Correto, o que pouca gente falou para você, caro leitor, é que essa placa se baseia num SoC dual core, onde temos:

• Um microcontrolador Intel Quark compatível com set x86 (32 bits), dedicado para aplicações que envolvam interação com o usuário e que não necessitem de resposta em tempo real. Esse pequeno microcontrolador roda a 32 MHz e possui boas características de controle de energia;
• Do outro lado, à direita, temos um ARC EM core. ARC é um núcleo de processamento RISC. Os detalhes estão fora do escopo desse artigo, mas o que adiantamos é que esse core possui ponto flutuante por hardware e um set de instruções DSP (sim, similar a um ARM Cortex-M4/M7), indicado para processamento de dados, fusão de sensores, e outras aplicações que demandem intensivo cálculo ou tempo de resposta preditivo.

Esse SoC é um pequeno notável, indicado para processamento de sensores, apenas como lembrete dentro do módulo que vai no Arduino 101. Ainda existe um terceiro core que cuida da interface Bluetooth low energy, mas está externo ao microcontrolador. Por isso não foi contabilizado. Vamos agora ao segundo exemplo:

Um velho conhecido e lançado há alguns anos, mas que tem se tornado notável pela queda de preço. A NXP colocou num mesmo chip:

• Um processador ARM Cortex-M4 de 180 MHz (variantes que chegam a 204 MHz) com a conhecida FPU com set register próprio, instruções DSP  e SIMD, para processamento de sinais, fusão de sensores e processos de tempo real;
• Um processador ARM Cortex-M0 também de 180 MHz (e com variantes que vão a 204 MHz) indicado para controlar a aplicação de tempo real e cuidar de tarefas como entrada e saída, além de interação com usuário.

O que esses dois chips têm em comum? Bem, além da aplicação prática que serão demonstradas nas partes 2 e 3 desta série, eles fazem parte de um segundo cenário de multiprocessamento designado por assimétrico (AMP), o que na prática significa que em um mesmo chip podem existir mais de um núcleo de processamento, porém eles não serão iguais, mas escolhidos para cuidar de um tipo de aplicação em especifico.

No caso das duas SoC apresentadas percebam que temos uma voltada para aplicações em geral, e outra com capacidades mais específicas (unidade de ponto flutuante, set de instruções diferenciados para processamento de sinais).

Como esses núcleos conversam entre si?

Agora que já sabemos conceitualmente o que são SoC multicore assimétricos, vem uma segunda pergunta na cabeça do leitor. Se estão no mesmo chip, como uma CPU conversa com a outra? Para começar, respondendo a essa pergunta visualmente observe a figura abaixo.

Essa figura demonstra o sistema de comunicação entre as CPUs da SoC mostrada no tópico anterior (o LPC4337 da NXP). O Intel Quark C1000 possui um mecanismo similar. O que a figura ilustra é um sistema de memória compartilhada, com dois canais separados, um com mensagens do master para o slave e vice-versa. Com os ponteiros de escrita e leitura existe a formação de uma estrutura de dados bem conhecida, uma fila, assim os Write pointer vão depositando dados na área de memória que serão lidos pelo Read pointer destinatário. Dessa forma o que existe é um trafego de dados puros sem qualquer detalhe dependente de arquitetura, esse mecanismo costuma ser chamado de IPC ou IPM (inter-processor messaging). Esse detalhe sobre os dados basicamente beneficia uma aplicação  do ponto em que uma CPU não precisa saber em detalhes o que está acontecendo na outra, mas apenas seus dados de interesse.

Um caso de uso simples

Clássico uso de multicore assimétrico em microcontroladores é a conhecida aplicação denominada Control Law Accelerator. Apesar do nome impactante, não é nada além de dedicar uma das CPUs (geralmente a mais especializada para processamento de dados) apenas para efetuar computação de malhas de controle em tempo real. O único trabalho diferente disso dos CLAs consiste em receber comandos vindos pelo IPM, alteração dos ganhos, mudança da taxa de amostragem, requisição do valor corrente de entrada e saída, mudanca para modo de economia de energia, e com isso atualizar o comportamento da malha de controle corrente sem que tenha que se preocupar com a lógica que resulta nessa mudança de comportamento. Isso fica a cargo da CPU destinada a tomar conta da aplicação que gerencia as malhas. O CLA também pode responder pelo IPM dados sobre o estado corrente da malha ou mesmo requisitar algum parâmetro importante inserido por algum canal de comunicação (um comando vindo pela UART).

A figura acima ilustra um pouco melhor o conceito do CLA, comumente encontrado nos processadores especializados para controle da Texas Instruments baseados na família C2000.

E como vou lidar com um projeto multicore assimétrico?

Respondendo rapidamente, você não lida com um projeto apenas, mas sim com dois projetos. Sabemos que em um processador com suporte a multiprocessamento assimétrico as arquiteturas serão diferentes, então porque o firmware seria o mesmo? Fato é que o desenvolvedor lida com duas aplicações distintas. Como já dito antes, uma aplicação não sabe da existência da outra, apenas sabe que existe um canal de comunicação externo ao seu Address Space para falar com outra unidade de processamento. Assim, durante o processo de desenvolvimento, dois projetos podem ser desenvolvidos de forma totalmente independente, sendo acordadas apenas as ações tomadas por ambas as aplicações no momento que em que um dos cores utilizar o recurso de IPC para se comunicar.

Nos próximos artigos desta série veremos como criar os projetos independentes, e utilizar o mecanismo de IPC para fazer com que as CPUs se conversem.

Conclusão

Os microcontroladores com suporte a multiprocessamento chegaram para ajudar no desenvolvimento de características especificas de um projeto, enquanto tentam manter a solução final em um único chip. Observamos nesta série o que conceitualmente envolve o multiprocessamento assimétrico e aplicamos o mesmo conceito ao ambientes de deep embedded (microcontroladores com recursos limitados).

Nos próximos artigos sairemos um pouco da teoria e vamos mostrar como duas SoCs diferentes com dois exemplos de aplicação que se beneficiam da possibilidade de ter dois núcleos no mesmo chip.

Referências

1 – NXP LPC4337 User manual

2 – Intel Quark C1000 User manual

3 – Assymetric multiprocessing basics by QNX

4 – Assymetric multiprocessing by ARM