Separando espaços de supervisor e usuário no ARM Cortex-M3

1. Introdução

Os processadores ARM Cortex-M estão integrados a SoCs para domínios diversos, principalmente em muito daquilo que chamamos de dispositivos smart. Esta publicação é uma continuação da anterior, em que demonstrei a implementação de um mecanismo preemptivo mínimo para um ARM Cortex-M3, aproveitando-se dos recursos de hardware especiais para a troca de contexto.

Alguns recursos importantes desta arquitetura serão agora demonstrados como a separação de threads de usuário e kernel – com 2 stack pointers: MSP e PSP e a utilização de Supervisor Calls para implementar chamadas ao sistema.

Apesar de alguns conceitos sobre sistemas operacionais serem abordados porque são inerentes ao assunto, o objetivo é a exploração do ARM Cortex-M3, um processador relativamente barato e de larga aplicabilidade, e como aproveitá-lo para desenvolver sistemas mais robustos.

2. Registradores especiais

São 3 os registradores especiais no ARM Cortex-M3. Você pode consultar a documentação da ARM para entender o papel de cada um deles no processador. O mais importante nesta publicação é o CONTROL.

  • Program Status Registers (APSR, IPSR, e EPSR)
  • Interrupt Mask Registers (PRIMASK, FAULTMASK e BASEPRI)
  • Control (CONTROL).

Registradores especiais somente podem ser acessado através das instruções privilegiadas MRS (ARM Read Special Register) e MSR (ARM Set Special Register):

//Carrega em R0 o atual valor contido no registrador especial
MRS R0, SPECIAL 
//Carrega no registrador especial o valor contido em R0)
MSR SPECIAL, R0 

O registrador CONTROL tem somente 2 bits configuráveis. Quando um serviço de excepção (e.g., SysTick_Handler) estiver a ser executado, o processador estará em modo privilegiado e utilizando o main stack pointer (MSP), e CONTROL[1] = 0, CONTROL[0] = 0. Em outras rotinas que não sejam handlers, este registrador pode assumir diferentes valores a depender da implementação do software (Tabela 1).

No pequeno kernel mostrado anteriormente, as tasks da aplicação (Task1, Task2 e Task3) também eram executadas em modo privilegiado e utilizando o stack pointer principal (MSP). Assim, um programa da aplicação poderia alterar os registradores especiais do core se quisesse.

3. Sistema com 2 stack pointers e diferentes privilégios

Na última publicação ressaltei o fato de o registrador R13 não fazer parte do stackframe, pois é ele justamente que guarda o endereço do stack pointer. O R13 é um registrador do tipo “banked” (não conheço uma boa tradução para português), significando que ele é fisicamente replicado, e assume um valor ou outro a depender do estado do core.

CTRL[1] (0=MSP/1=PSP)CTRL[0] (0=Priv, 1=Non priv)Estado
00Privileged handler* / Base mode
01Unprivileged
10Privileged thread
11User thread
Tabela 1. Estados possíveis do registrador CONTROL
*em rotinas que atendem às exceções este modo estará sempre ativo mesmo que o CTRL[0] = 1.

Com dois stack pointers, um para aplicação e outro para o kernel, significa que uma thread de usuário não poderá facilmente corromper o stack pointer do kernel por um erro de programação na aplicação. Os privilégios por sua vez evitam que a aplicação sobrescreva registradores especiais. De acordo com os manuais da ARM, um sistema operacional robusto tipicamente tem as seguintes características:

  • serviços de interrupção utilizam o MSP (por default da arquitetura)
  • rotinas do kernel são ativadas através do SysTick em intervalos regulares para executar, em modo privilegiado, o escalonamento das tarefas e gerenciamento do sistema
  • aplicações de usuário são executadas como threads, usam o PSP em modo não-privilegiado
  • a memória para as stacks do kernel e handlers são apontadas pelo MSP, sendo que os dados stack só podem ser acessados em modo privilegiado*
  • a memória para a stack das aplicações é apontada pelo PSP

*por enquanto não vamos isolar os espaços de memória

4. Chamadas ao sistema (System Calls)

Em uma perspectiva simples, uma chamada de sistema é um método no qual um software requisita um serviço/mecanismo do kernel ou SO sobre o qual está rodando: gerenciamento de processos (escalonamento, mecanismos de IPC), acesso a algum recurso de hardware, sistema de arquivos, entre outros, a depender da arquitetura do sistema operacional.

Se pretendemos separar nosso sistema em níveis de privilégio é inevitável que o nível da aplicação precise fazer chamadas ao kernel para ter acesso a, por exemplo, serviços de hardware ou o que mais julgarmos crítico para a segurança e estabilidade do sistema.

Uma maneira comum de implementar system calls no ARM Cortex-M3 (e em outros cores baseados em ARMv7) é a utilização da interrupção por software chamada Supervisor Call (SVC). O SVC funciona como um ponto de entrada para um serviço que necessita de privilégios para ser executado. O único parâmetro de entrada de um SVC é o seu número (instrução ASM: SVC #N), ao qual associamos a uma chamada de função (callback). Ao contrário da outra excepção disparada via software disponível, que é o PendSV (Pendable Supervisor Call), o SVC pode ser disparado em modo usuário. Apesar de serem destinadas a diferentes usos – o PendSV é tipicamente usado como forma de “agendar” tarefas do kernel menos críticas e não perder ticks do sistema, é possível configurar o core para que usuários também possam disparar o PendSV.

Figura 2. Diagrama de blocos de uma possível arquitetura de sistema operacional no M3. Supervisor Calls funcionam como ponto de entrada para serviços privilegiados. [2]

5. Design

5.1 Utilização de dois stack pointers

Para a utilizar os dois stack pointers disponíveis (MSP e PSP) é fundamental entender 2 coisas:

  • A manipulação do registrador de controle: só é possível escrever ou ler o registrador de controle em modo handler (na rotina que atende à uma exceção) ou em threads privilegiadas.
  • O mecanismo de exceções: quando uma interrupção ocorre, o processador guarda na stack o conteúdo dos registradores R0-R3, LR, PC e xPSR, como explicado na publicação anterior. O valor do LR quando entramos em uma exceção indica o modo que o processador estava a rodar, quando a thread foi interrompida. Podemos manipular este valor de LR juntamente com a manipulação dos stack pointer para controlar o fluxo do programa.
LRBX LR
0xFFFFFFF9Volta para modo “base”, MSP privilegiado. (CONTROL=0b00)
0xFFFFFFFDVolta para user mode (PSP, com o nível de privilégio da entrada) (Control = 0b1x)
0xFFFFFFF1Volta para a interrupção anterior, no caso de uma interrupção de maior prioridade ocorrer durante uma de menor prioridade.
Tabela 2. Valores para retorno de exceção

5.1.1. Um kernel stack para cada user stack

Cada stack dedicada ao usuário terá uma stack de kernel correspondente (one kernel stack per thread). Assim, cada Task (thread principal) terá stacks de kernel e usuário associadas. Uma outra abordagem seria uma stack somente de kernel no sistema (one kernel stack per processor). A vantagem de utilizar a primeira abordagem é que além das threads do kernel poderem ser preemptivas, do ponto de vista de quem implementa o sistema, os programas que rodam no kernel seguem o mesmo padrão de desenvolvimento dos programas de aplicação. A vantagem da segunda abordagem é menor overhead de memória e menor latência nas trocas de contexto.

Figura 3. Cada user stack tem uma kernel stack associada

5.2 Mecanismos de entrada e saída do kernel

Na publicação anterior a interrupção feita pelo SysTick manejava a troca de contexto, i.e., interrompia a thread em execução, salvava seu stackframe, buscava a próxima thread apontada pelo campo next na estrutura TCB (thread control block) e a resumia.

Com a separação dos espaços de usuário e supervisor, teremos dois mecanismos para entrada e saída do kernel: as system calls, explicitamente chamadas em código, e a interrupção por SysTick que implementa a lógica de escalonamento (scheduling). Outro ponto a destacar, é que apesar de continuar utilizando um esquema round-robin simples, em que cada tarefa tem o mesmo tempo de execução, as threads do kernel também funcionarão de forma cooperativa com a a thread do usuário que a evocou, isto é: quando não houver mais nada a ser feito, o kernel pode explicitamente retornar. Se a thread do kernel demorar mais que o tempo entre um tick e outro, será interrompida e reagendada. As tarefas do usuário também poderiam utilizar-se de mecanismo similar, entretanto, por simplicidade para exposição, optei por deixar as tarefas de usuário somente em esquema round-robin fixo.

5.2.1. Escalonador (task scheduler)

O fluxograma do escalonador preemptivo a ser implementado está na Figura 4. O start-up do kernel e aplicação do usuário é também mostrado para maior clareza. O kernel é inicializado e voluntariamente inicia a primeira task de usuário. A cada interrupção por SysTick, a thread tem seu estado salvo e a próxima task agendada é resumida consoante ao estado em que foi interrompida: kernel ou user mode.

Figura 4. Fluxograma do escalonador

5.2.2 Chamadas ao sistema (System Calls)

As chamadas ao sistema ocorrem quando o usuário requisita acesso a um serviço privilegiado. Além disso, também utilizo o mesmo mecanismo para que tarefas privilegiadas do kernel retornem cooperativamente à tarefa do usuário.

Perceba que optei por não executar o as threads de kernel dentro do próprio handler, o que seria mais intuitivo, além de usual. As razões para isto são porque quis aproveitar o próprio mecanismo de interrupção do processador, que no seu retorno faz o POP dos registradores RO-R3, LR, PC e xPSR, e também para evitar o aninhamento de interrupções durante a preempção de tarefas do kernel. Caso eu tivesse optado por utilizar somente uma kernel stack para todas as threads, a implementação dentro do próprio handler julgo que seria melhor.

Figura 5. Fluxograma das system calls

6. Implementação

Abaixo explico os códigos criados para implementar as provas de conceito das funcionalidades anteriormente descritas. A maior parte do kernel propriamente dito é escrito em assembly, exceto para uma porção do handler de supervisor calls que é escrita em C com algum inline assembly. Na minha opinião, mais trabalhoso e suscetível a erros que escrever em assembly é embutir assembly no código C. A toolchain utilizada é a GNU ARM.

6.1. Stacks

Não há nada em especial aqui, exceto que agora além da stack de usuário, declaramos outro array de inteiros para a stack do kernel. Estes serão associados no Thread Control Block.

int32_t p_stacks[NTHREADS][STACK_SIZE]; // stack de usuário
int32_t k_stacks[NTHREADS][STACK_SIZE]; // stack do kernel

6.2. Task Scheduler

A principal diferença deste para o escalonador mostrado na última publicação é que agora manejaremos 2 stack pointers distintos: o MSP e o PSP. Assim, quando entramos em um handler de exceção, a porção do stackframe salvo automaticamente depende do stack pointer utilizado quando a exceção foi disparada. Entretanto na rotina de exceção o stack pointer ativo é sempre o MSP. Desta forma, para podermos manejar um stack pointer quando estamos a operar com outro, não poderemos utilizar as instruções PUSH e POP porque estas têm como endereço base o stack pointer ativo. Teremos de substituí-las pelas instruções LDMIA (load multiple and increment after, i.e, após o primeiro load incrementa-se o endereço base) para o POP, e STMDB (store multiple decrement before, antes do primeiro store decrementa-se o endereço base) para o PUSH, com o sinal de writeback “!” no endereço base [1].

// Exemplo de POP 
MRS R12, PSP // lê o valor do process stack pointer em R12
LDMIA R12!, {R4-R11} // R12 contém o endereço base (PSP)
/* o endereço contido em R12 agora armazena o valor de R4, [R12] + 0x4  
 contém o valor de R5, e assim por diante até que [R12] + 0x20 contém o 
 valor de R11.
 o valor inicial de R12 também é incrementado em 32 bytes 
*/
MSR PSP, R12 // PSP é atualizado para o novo valor de R12

// Exemplo de PUSH
MSR R12, MSP 
STMDB R12!, {R4-R11} 
/* [R12] - 0x20 contém R4, [R12] - 0x16 contém R5, ..., [R12] contém R4 
 o valor inicial de R12 é decrementado em 32 bytes */
MSR MSP, R12 // MSP é atualizado para o novo valor de R12 

Outra diferença é que agora a estrutura TCB precisa conter um ponteiro para cada um dos stack pointers da thread que controla, e também uma flag indicando se a tarefa a ser resumida estava utilizando o MSP ou o PSP quando foi interrompida.

// thread control block
struct tcb 
{
  int32_t*	psp; //psp salvo da ultima user thread interrompida
  int32_t*	ksp; //ksp salvo da ultima kernel thread interrompida	
  struct tcb	*next; //aponta para o proximo tcb
  int32_t	pid; //id da task (é o "i" do kSetInitStack(i))
  int32_t	kernel_flag; // 0=kernel, 1=user	
};
typedef struct tcb tcb_t;
tcb_t tcb[NTHREADS]; //array de tcbs
tcb_t* RunPtr; 

Abaixo a rotina que escrevi para implementação. O código foi escrito de forma a ficar claro em sua intenção, sem tentar economizar instruções. Perceba que na linha 5 o valor de LR assumido na entrada da excepção só é comparado com 0xFFFFFFFD, caso falso assume-se que ele é 0xFFFFFFFF9, isto porque garanto que não haverá interrupções aninhadas (o SysTick nunca interrompe um SVC, por exemplo), assim o LR nunca deve assumir 0xFFFFFFF1. Para propósitos que não uma prova de conceito, o teste deveria ser considerado.

.global SysTick_Handler
.type SysTick_Handler, %function
SysTick_Handler:			
CPSID	I //atomica inicio
CMP	LR, #0xFFFFFFFD //verifica se retornou de uma user thread
BEQ	SaveUserCtxt	//se sim, branch para save user context
B	SaveKernelCtxt  //se nao

SaveKernelCtxt:
MRS	R12, MSP 
STMDB	R12!, {R4-R11}  //push R4-R11
MSR	MSP, R12
LDR	R0,=RunPtr      //RunPtr aponta para a tcb atual
LDR	R1, [R0]
LDR	R2, [R1,#4]
STR	R12, [R2]  //salva stack pointer
B	Schedule

SaveUserCtxt:
MRS	R12, PSP
STMB	R12!, {R4-R11}
MSR	PSP, R12
LDR	R0,=RunPtr
LDR	R1, [R0]
STR	R12, [R1]		
B	Schedule

Schedule:
LDR	R1, =RunPtr //R1 <- RunPtr
LDR	R2, [R1]	
LDR	R2, [R2,#8] //R2 <- RunPtr.next
STR	R2, [R1]    //atualiza valor de RunPtr
LDR	R0, =RunPtr
LDR	R1, [R0]
LDR	R2, [R1,#16]
CMP	R2, #1	     //verifica se kernel_flag=1
BEQ	ResumeUser   //sim, resume user thread
B	ResumeKernel //nao, resume kernel thread

ResumeUser:
LDR	R1, =RunPtr  //R1 <- RunPtr
LDR	R2, [R1]
LDR	R2, [R2]
LDMIA	R2!, {R4-R11} //Resgata sw stackframe 
MSR	PSP, R2		
MOV	LR, #0xFFFFFFFD	//LR=return to user thread
CPSIE	I		//atomica fim
BX	LR 

ResumeKernel:
LDR	R1, =RunPtr   //R1 <- RunPtr atualizado
LDR	R2, [R1]
LDR	R2, [R2, #4]
MSR	MSP, R2
LDMIA	R2!, {R4-R11} //Resgata sw stackframe 
MSR	MSP, R2
MOV	LR, #0xFFFFFFF9	 //LR=return to kernel thread
CPSIE	I		 //atomic fim
BX	LR 

6.3 System Calls

A implementação dos system calls utiliza o SVC Handler. Como dito, o único parâmetro de entrada do SVC é o número que associamos a um callback. Mas então como passamos os argumentos para o callback? Eles precisam ser buscados na stack. O padrão AAPCS (ARM Application Procedure Call Standard), que é seguido pelos compiladores, diz que quando uma função (caller) chama outra função (callee), o callee espera que seus argumentos estejam em R0-R3. Da mesma forma, o caller espera que o retorno do callee esteja em R0. R4-R11 precisam ser preservados entre uma chamada e outra. R12 é o scratch register e pode ser usado livremente.

Não à toa, quando uma exceção ocorre o core salva (PUSH) na stack os registradores R0-R3, LR, PC e xPSR da função que foi interrompida, e no retorno os lança (POP) novamente nos registradores do core. Se trocarmos de contexto, isto é, após a interrupção não retornarmos ao mesmo ponto do programa que foi interrompido, precisamos explicitamente salvar o restante da stackframe para que a thread seja resumida de forma íntegra. É fundamental seguir o AAPCS se quisermos evocar funções escritas em assembly em código C e vice-versa.

Para executar chamadas ao sistema defini uma função macro em C que recebe o código do SVC e os argumentos para a callback (a sintaxe de assembly inline depende do compilador utilizado).

(Há uma razão de eu ter criado uma macro e não uma função comum: tem a ver com o ponto de retorno à user thread e o fato de os callbacks do kernel não serem executados dentro da exceção, o que exige a troca de contexto. Se criasse uma função comum para o system call, o stack pointer do usuário seria salvo dentro da chamada, e ao retornar do kernel, o SVC seria novamente executado.)

#define SysCall(svc_number, args) {					   				      
                                                                        \
	__ASM volatile ("MOV R0, %0 "     :: "r"            (args) );     \
	__ASM volatile ("svc %[immediate]"::[immediate] "I" (svc_number) : );   \
}

O valor de args é armazenado em R0. A chamada do SVC é feita com o imediato “svc_number”. Quando o SVC é disparado R0-R3 serão automaticamente salvos na stack. O código foi escrito da seguinte forma, sem economizar instruções, para clareza:

.global SVC_Handler
.type	SVC_Handler, %function
 SVC_Handler:
 MRS R12, PSP		 //salva psp
 CMP LR, #0xFFFFFFFD
 BEQ KernelEntry
 B   KernelExit

//salva contexto do usuário
KernelEntry: 
MRS	R3, PSP
STMDB	R3!, {R4-R11}
MSR	PSP, R3
LDR	R1,=RunPtr
LDR	R2, [R1]
STR	R3, [R2]	
LDR	R3, =#0  
STR	R3, [R1, #16] //kernel flag = 0
MOV	R0, R12   //psp da chamada no r0 do CORE pra recuperar svc number
B svchandler_main //branch para rotina em C 
KernelExit:
//recarrega frame do usuário
LDR	R0, =RunPtr
LDR	R1, [R0]
LDR	R2, [R1]
LDMIA	R2!, {R4-R11}
MOV	LR, #0xFFFFFFFD
MSR	PSP, R2
LDR	R12, =#1 //kernel flag = 1
STR	R12, [R1, #16]
BX	LR 

O restante da rotina para entrada no kernel é escrito em C [2, 3]. Perceba que na rotina escrita em assembly um branch simples ocorre (linha 20) e portanto ainda não retornamos do handler de exceção.

#define SysCall_GPIO_Toggle  1 //codigo svc para gpio toggle
#define SysCall_Uart_PrintLn 2 //codigo svc para uart print line

void svchandler_main(uint32_t * svc_args)
{		
    uint32_t svc_number;
    uint32_t svc_arg0;
    uint32_t svc_arg1;
    svc_number = ((char *) svc_args[6])[-2]; // recupera o imediato 
    svc_arg0 = svc_args[0];
    svc_arg1 = svc_args[1]; 
 
 switch(svc_number)
 {
 case SysCall_GPIO_Toggle: 
	k_stacks[RunPtr->pid][STACK_SIZE-2] = (int32_t)SysCallGPIO_Toggle_; //PC
	k_stacks[RunPtr->pid][STACK_SIZE-8] = (int32_t)svc_arg0; //R0
	k_stacks[RunPtr->pid][STACK_SIZE-1] = (1 << 24); // T=1 (xPSR)
	__ASM volatile ("MSR MSP, %0" : : "r" (RunPtr->ksp) : );
	__ASM volatile ("POP {R4-R11}");
	__ASM volatile ("MOV LR, #0xFFFFFFF9");
	__ASM volatile ("BX LR"); //retorna da excecao
	break;
 case SysCall_Uart_PrintLn: 
	k_stacks[RunPtr->pid][STACK_SIZE-2] = (int32_t)SysCallUART_PrintLn_; 
	k_stacks[RunPtr->pid][STACK_SIZE-8] = (int32_t)svc_arg0;
	k_stacks[RunPtr->pid][STACK_SIZE-1] = (1 << 24); // T=1
	__ASM volatile ("MSR MSP, %0" : : "r" (RunPtr->ksp) : );
	__ASM volatile ("POP {R4-R11}");
	__ASM volatile ("MOV LR, #0xFFFFFFF9");
	__ASM volatile ("BX LR"); //retorna da excecao
	break;
 default:
	__ASM volatile("B SysCall_Dummy");
	break;
 break;
 }
}

O svc_number, por sua vez, é recuperado ao andarmos dois bytes (por isso o cast para char) descrescentes a partir endereço do PC que está 6 posições acima de R0 na stack [1, 2, 3]. Note que foi preciso assinalar a R0 o valor contido em PSP logo após a entrada na interrupção, antes de salvarmos o restante da stack (linhas 4 e 19 do código assembly).

Após recuperar o número do SVC e os argumentos, inicializamos a stack do kernel, MSP é sobrescrito com o valor armazenado no TCB, mudamos o valor de LR para que a exceção ao retornar vá para o modo base, pois não iremos executar o callback dentro do handler. Quando a instrução BX LR é executada o restante do stackframe é automaticamente ativado nos registradores do core.

Um callback tem a seguinte cara:

static void SysCall_CallBack_(void* args)
{
	BSP_Function((int32_t) args); //funcao do BSB com unico argumento int32
	exitKernel_(); // //qualquer chamada ao svc aqui ira sair do kernel (Figura 5)
}

6.4. Start-up

O start-up é um ponto crítico. O sistema inicializa em modo base. As stacks são montadas. A primeira tarefa a ser executada pelo kernel após a inicialização do sistema é configurar o SysTick, mudar para o modo de usuário e disparar a primeira thread de usuário.

//inicializacao da primeira stack
tcb_t* RunPtrStart;
RunPtrStart = tcb[0];
void kFirstThreadInit(void)
{
	kSetInitStack(0); /* esta função segue o mesmo padrão da última postagem */
	k_stacks[0][STACK_SIZE-2] = (int32_t) UsrAppStart; // LR = UsrAppStart
}
// RunPtr e o restante dos tcbs é configurado da mesma forma da última publicacao 

As rotinas em assembly para o startup são as seguintes:

.equ SYSTICK_CTRL, 0xE000E010 
.equ TIME_SLICE,	999

.global kStart  // esta é a função principal de init 
.type kStart, %function
kStart:
LDR	R0, =RunPtrStart
LDR	R1, [R0]
LDR	R2, [R1,#4]
MSR	MSP, R2	  // MSP <- RunPtr.ksp
POP	{R4-R11}  //carrega stackframe 0 na callstack
POP	{R0-R3}
POP	{R12}
ADD	SP, SP, #4
POP	{LR}	 //LR <- PC = UsrAppStart
ADD	SP, SP, #4
BX	LR // vai para UsrAppStart

//esta função prepara a stack para disparar a primeira user thread
.global UsrAppStart 
.type	UsrAppStart, %function
UsrAppStart:				
LDR	R1, =RunPtr //R1 <- RunPtr
LDR	R2, [R1]		
LDR	R2, [R2]
MSR	PSP, R2
BL	SysTickConf //configura systick
MOV	R0, #0x3
MSR	CONTROL, R0 //habilita thread unprivileged mode
ISB		    /* inst sect barrier: garante que CONTROL 
                     estara atualizado nas proximas instrucoes*/
POP	{R4-R11}   //carrega stackframe 0 na callstack
POP	{R0-R3}
POP	{R12}
ADD	SP, SP, #4
POP	{LR}	   //LR <- PC
ADD	SP, SP, #4
BX LR
	
SysTickConf:
LDR	R0, =SYSTICK_CTRL 
MOV	R1, #0
STR	R1, [R0]  // zera contador
LDR	R1, =TIME_SLICE  
STR	R1, [R0,#4] // RELOAD <- TIME_SLICE
STR	R1, [R0,#8] // CURR_VALUE <- TIME_SLICE (mas tanto faz)
MOV	R1, #0x7   // 0b111:
		    // 1: Clock source = core clock 
		    // 1: Habilita irq
		    // 1: Habilita contador
STR	R1, [R0]		
BX	LR	    //volta pro caller

7. Teste

Para fazer um pequeno teste, vamos escrever na tela do PC através da UART. O callback para chamada de sistema foi escrito da seguinte forma:

static void SysCallUART_PrintLn_(const char* args)
{
	__disable_irq();
	uart_write_line(UART, args);		
	while (uart_get_status(UART) != UART_SR_TXRDY); //espera fim da transmissão
	__enable_irq();
	exitKernel_();
}

É preciso tomar cuidado na hora de utilizar multithreading concorrendo para utilizar serviços de hardware, já que ainda não inserimos nenhum mecanismo de semáforo. Entretanto, fiz a operação atômica e não será interrompida pelo SysTick. O programa principal é o seguinte:

#include <commondefs.h> //board support package, libs padrão, etc.
#include <kernel.h>  
#include <tasks.h>

int main(void)
{
  kHardwareInit(); //configura clock, interrupcoes, uart, entre outros
  kAddThreads(Task1, (void*)"Task1\n\r", Task2, (void*)"Task2\n\r", Task3, (void*)"Task3\n\r");
  RunPtrStart = &tcbs[0]; 
  RunPtr = &tcbs[1];
  uart_write_line(UART, "Inicializando kernel...\n\r");
  delay_ms(500); //delay para dar tempo de tirar o printscreen da tela 😛
  kStart();	
  while(1);
}

As tasks (threads principais) têm a seguinte cara:

void Task1(void* args)
{
	const char* string = (char*)args;
	while(1)
	{
		SysCall(SysCall_Uart_PrintLn, string);
	}
}

Na figura abaixo o sisteminha em execução:

8. Conclusões

A utilização de dois stack pointers, um para aplicação e outro para o kernel isola estes espaços não permitindo que a aplicação corrompa a stack do kernel. Os privilégios por sua vez evitam que a aplicação sobrescreva registradores especiais. Adicionar mais um stack pointer ao sistema exigiu mudanças na rotina do escalonamento porque agora manipulamos duas stacks no domínio de 2 stack pointers distintos, em que ambos estão sujeitos à preempção. Além disso, também foi adicionado um mecanismo cooperativo para que as tarefas do kernel liberem o processador para o usuário.

O mecanismo de system calls é utilizado como ponto de entrada a serviços de hardware, ou ao que mais julgarmos crítico para a segurança e estabilidade do sistema. Isto fará ainda mais sentido ao separarmos não só as stacks em níveis de privilégio mas também as regiões da memória com a MPU.

Para as próximas publicações ainda iremos: 1) incluir mecanismos de semáforos e IPCs, 2) configurar a MPU e 3) adicionar níveis de prioridades às tarefas que até então rodam em um esquema round-robin fixo.

9. Referências

[1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337e/DDI0337E_cortex_m3_r1p1_trm.pdf

[2] The definitive Guide to ARM Cortex M3, Joseph Yiu

[3] https://developer.arm.com/docs/dui0471/j/handling-processor-exceptions/svc-handlers-in-c-and-assembly-language

SOA para diminuição da hardware-dependência em C

aa480021.aj1soa01(en-us,msdn.10)
(MS Software Architecture Journal, 2004)

1. Impacto do software hardware-dependente (HdS)

É dito na literatura que o custo do software embarcado tem dominado o projeto de sistemas eletrônicos [1]. Sistemas embarcados, tradicionalmente limitados em memória e processamento, conseguem hoje rodar aplicações mais complexas fruto do avanço no projeto e fabricação de circuitos integrados. Ora, a introdução de hardware mais complexo permite a utilização de recursos de programação também mais complexos. De fato, mais de 90% das inovações na indústria automotiva da última década são decorrência direta do desenvolvimento em software embarcado. A especialização do dispositivo leva à especialização do software e ao conceito de software hardware-dependente:

  • é especialmente desenvolvido para um bloco de hardware específico: o software é inútil sem aquele hardware
  • software e hardware juntos implementam uma funcionalidade: isto é, o hardware é inútil sem aquele software

Muito provavelmente ao ler esta descrição pensaste em um sistema operacional para determinada plataforma e seus controladores (drivers). Abaixo segue um diagrama em camadas de um típico sistema embarcado. Conforme subimos as camadas, menos hardware-dependente será o nosso software, de forma que para escrevermos em linguagem interpretada, digamos, eu não preciso tomar conhecimento do microprocessador, e muito menos das tensões de operação dos meus dispositivos. O HAL (camada de abstração de hardware) é onde encontra-se o software mais hardware-dependente, i.e., mudanças no hardware invariavelmente implicarão em mudanças no software desta camada (Figura 1).

hal

Figura 1. Componentes e camadas de um típico sistema embarcado [ECKER]

2. Orientação a objetos para aumentar a coesão

O paradigma de orientação a objetos parte de um conceito muito intuitivo que é particionar um sistema em objetos classificados consoante à sua natureza. Não é necessário muito para perceber como isto aumenta o reuso e a portabilidade. A utilização do paradigma aumenta a coesão dos componentes de nossa arquitetura na medida da nossa habilidade em pensar de maneira orientada a objetos. Ao contrário do domínio de software aplicativo, em software embarcado sobretudo quando os requisitos são bastante específicos e o hardware limitado, a portabilidade e reuso esbarram na hardware-dependência. Se a OO é um bom paradigma para escrever software coeso, muitas vezes nestes domínio este recurso está indisponível. Podemos utilizar o C para escrever em um (meta-)padrão orientado a objetos, se soubermos fazer bom uso de ponteiros.

3. Exemplo de arquitetura orientada a serviços em C

Como exemplo vou descrever uma arquitetura para desacoplar a aplicação do hardware e que se beneficia dos conceitos de OO, entre eles o polimorfismo. O objetivo é escrever software para comunicação serial coeso o suficiente para quando o hardware mudar (ou for definido), somente o código mais fortemente hardware-dependente precise ser adaptado (ou escrito). O conceito de arquitetura orientada a serviços está presente em sistemas operativos baseados em microkernel (dois exemplos extremos: Windows NT e MicroC/OS). A arquitetura proposta está representada na Figura 2. Todo o software representado daqui em diante refere-se somente à camada de Serviços. A camada Board Support Package desacopla (ou diminui o acoplamento) entre o HAL e os Serviços; é a API do HAL para o programador dos Serviços.

layers

Figura 2. Layers em uma arquitetura orientada a serviços [do autor]

É uma boa ideia permitir que a aplicação utilize dois únicos métodos para transferir e receber um número de dados via serial, aplicados sob diferentes componentes de hardware: enviar(interface, x_bytes) e receber(interface, x_bytes). Estes são métodos que assumem uma forma ou outra a depender do objeto. Assim chegamos aos conceitos de interface (Classe abstrata), herança e polimorfismo. Abaixo o diagrama de classes da proposta. A assinatura completa dos métodos foi omitida.

class
Figura 3. Diagrama de classes da proposta

O padrão de design Proxy/Server permite que o hardware seja configurado de forma genérica abstraindo seus detalhes específicos. As mudanças no BSP são isoladas pela proxy ao programador da aplicação. O servidor por sua vez sustenta-se nos dados de configuração da proxy e na API do HAL para configurar e inicializar os serviços (this_proxy->this_service).

(Errata: na figura 3 os métodos de construção/inicialização e enviar/receber da classe SPI_proxy estão representados como se fossem iguais ao da UART, porém são métodos distintos.)

3.1. Implementação da Classe Abstrata

Uma interface pode ser percebida como um barramento de funções virtuais que aponta para um método ou outro em tempo de execução. Este apontamento segue por um caminho de endereços até chegar ao método para ser executado naquele contexto (etapa do fluxo do programa). Poderíamos também atribuir através de setters os métodos de cada objeto, i.e., ainda em tempo de compilação.

Começaremos por implementar a estrutura de dados que compreende a classe. Esta estrutura implementa 2 métodos que recebem e enviam frames de bytes. Uma classe Serial_Comm, portanto dá cria a um objeto que contém uma tabela de funções genéricas de enviar e receber. Os métodos públicos da interface são somente construtores e desconstrutores. Os métodos de enviar e receber ficam privados, haja vista que o objeto a ser utilizado pelo programador da aplicação é que vai defini-los. A estrutura com as funções virtuais Serial_Table é declarada mas não definida inicialmente. Mais adiante declaramos que a estrutura é somente leitura (definida em tempo de compilação) contém dois ponteiros para funções, e finalmente as definimos de forma limitada ao escopo. Isto é necessário para que ocorra o alinhamento do endereço desta tabela ao endereço da tabela do objeto que a utiliza em tempo de execução.

Abaixo o cabeçalho do Serial_Comm.

serial_comm_h-e1569800116804.png
Figura 4. Cabeçalho da classe Serial_Comm

No programa .c da interface, uma estrutura SerialTable é inicializada com endereço de funções dummy. A definição destes métodos com o assert(0) é uma forma de acusar um erro de programação em tempo de execução, se estas funções forem chamadas sem a devida sobrescrita.

serial_comm_c
Figura 5. Programa da Classe Virtual

3.2. Implementação do serviço UART

As classes de comunicação serial seguirão este padrão de design. O construtor inicialmente define uma estrutura SerialTable. Perceba que esta estrutura só pode ser definida uma vez, mas os elementos de vtbl podem assumir qualquer valor; i.e., se construímos um objeto que herda esta classe podemos estender os parâmetros e definir o endereço dos métodos, que ficarão ligados a uma e somente uma interface de funções virtuais.

Na estrutura de dados de uma classe herdeira a sua superclasse precisa ser declarada primeiramente. De outro modo não poderemos estender os atributos desta.

Na construção da proxy, uma tabela de funções definidas localmente é o endereço destino que contém a definição dos métodos virtuais da interface.

uart_proxy_hhh.png
Figura 6. Cabeçalho da classe Uart_proxy
uart_proxy_c-e1569704959728.png
uart_proxy_c_2
Figura 7. Programa uart_proxy.c

Um ponto chave é o downcast (linhas 51 e 57) feito nos métodos privados Uart_Send_ e Uart_Get_. Um ponteiro para Uart_proxy é inicializado com o endereço de uma interface Serial_Comm. O alinhamento da memória permite que acessemos os métodos desta proxy a partir desta interface. Além disso como servidor e proxy estão agregados, os metodos do BSP podem ser chamados na proxy. As funções que começam com “_” (_uart_init, _uart_get …) fazem parte deste BSP, cujo cabeçalho uart_driver_api.h está incluído no programa. No BSP podem-se utilizar as mesmas técnicas, para permitir por exemplo, que a definição do endereço do dispositivo a ser construído se dê também por uma interface abstrata que não muda com as características do dispositivo (mapeado em porta ou memória, plataforma alvo, etc.)

uart_server_hh
Figura 8. Cabeçalho da classe Uart_Server

Logicamente, a implementação do serviço para SPI segue o mesmo padrão de design.

4. Utilização dos serviços

Para a utilização dos serviços pela camada de aplicação, basta construir uma proxy com parâmetros de inicialização do dispositivo, neste exemplo UART ou SPI, e utilizar os métodos SendFrame e GetFrame que acessam a interface de cada objeto proxy.

main2.png
Figura 9. Um programa utilizando os Serviços e seus métodos polimórficos
run
Figura 10. Programa em execução

5. Conclusões

Conceitos do paradigma de programação orientado a objetos podem ser implementados, virtualmente, em qualquer linguagem se partirmos da ideia de que classes são estruturas de dados agregadas a um conjunto de funções que fornecem uma interface externa comum. Tanto estes métodos quanto estes dados podem ser privados ou não. No primeiro caso está o conceito de encapsulamento. A alocação destas estruturas com seus valores e funções, é a instância de um objeto. A instanciação de um objeto de uma classe dentro de outra classe implementa a herança. Uma interface que não implementa métodos pode ser utilizada para conectar-se à interface de uma outra classe, o que chamamos de funções virtuais. As funções virtuais podem então assumir uma forma ou outra a depender do fluxo do programa, o que caracteriza o polimorfismo.

Uma arquitetura orientada à serviço eleva a coesão dos componentes e a consequente reutilização e portabilidade, mitigando os problemas gerados pela natural hardware-dependência do software para sistemas embarcados. A orientação a objetos por sua vez é o paradigma natural para a construção de sistemas orientado a serviços. Este artigo demonstrou uma forma de aplicar estes conceitos em sistemas embarcados quando linguagens OO (comumente neste domínio C++ ou Ada) não estão disponíveis.


O texto desta postagem bem como as figuras não referenciadas são do autor.
As seguintes referências foram consultadas:
[1] Hardware-Dependent Software: Principles and Practices. Ecker, Muller, Dommer. Springer, 2009.
[2] Design Patterns for Embedded Systems in C. Bruce Douglass. Elsevier, 2001.
[3] Object-Oriented Programming in C: Application Note. Quantum Leaps. April, 2019.

Abordagens para projeto low power (2/3)

17zhswf3uasrj.jpg

(Um PDA da Nokia com acesso à internet, 1995. Fonte: gizmodo.com)

5 Abordagens low power no nível arquitetural

Penso que desenhar a arquitetura de um projeto é, para todos os efeitos, definir como cada módulo do sistema se comunica com os outros módulos para trabalharem em conjunto, e através de análises, seja pela experiência do projetista ou por resultados de modelos, elaborar a melhor forma de construí-los. Abaixo seguem algumas abordagens utilizadas na indústria para elaborar arquiteturas eficientes em consumo.

5.1 Redução dinâmica da tensão de alimentação e frequência (DVFS)

Apesar dos avanços, o problema entre o poder computacional disponível e o tempo de bateria ainda são os principais desafios da indústria. O seu smartphone aguenta 1 único de dia de uso pesado com navegação, músicas, redes sociais e sinal intermitente? O meu não.

Mas como disse, uso pesado. Quer dizer, o seu smartphone sabe quando mais e quando menos energia serão necessárias para aplicação, reduzindo ou aumentado a tensão e/ou a frequência fornecidas dinamicamente para os periféricos do microprocessador.

Os próprios microprocessadores em geral são especificados de forma que a frequência de operação máxima depende da tensão fornecida. Assim quando a performance não estiver crítica a tensão (e a frequência) podem ser reduzidas. Infelizmente isto não vale para sistemas de tempo real cujo principal requisito é atender aos deadline. Existem soluções que incorporam DVFS entre o escalonador e o disparador do RTOS.

5.2 Múltiplas tensões

Projetar um chip utilizando uma única tensão de alimentação é comum e também tem a penalidade de que os piores caminhos de tempo a serem cumpridos terão a mesma força de drive dos demais. Ou seja, haverá slack times bastante altos para poder compensar os caminhos críticos. Claro que um bom projeto e uma boa ferramenta tentam encontrar um compromisso.

O ponto chave é que se todos os caminhos forem críticos, o consumo global vai ser o menor possível. A forma mais simples é: operar todos os caminhos que não são críticos em tensão mais baixa, e os críticos em tensão mais alta. A penalidade se dará principalmente em área pela adição de layers para comunicar blocos em diferentes tensões.

Formas mais eficientes adicionam inteligência nas ferramentas de projeto para escolher as tensões de cada caminhos. Falando de forma muito simplificada, um algoritmo calcula o slack de uma célula, e decide se ela pode ou não ser substituída por uma célula low voltage. Caso os demais caminhos continuem positivos esta célula é então substituída. Se não, será preciso sacrificar o consumo em detrimento da performance naquela célula.

Ainda, alguns autores sugerem que o caminho crítico de um circuito não é o caminho mais longo, mas sim o caminho mais longo e mais demandado na operação – uma variável a mais. Esta técnica demonstrou alguns ganhos em relação a anterior, e é chamada de PVCS (path-oriented clustered voltage scaling).

É preciso dizer que os layers adicionados para comunicar módulos em diferentes tensões também consumirão energia tanto estática quanto dinâmica. Existem pesquisas com as mais diversas soluções para a utilização de múltiplas tensões, inclusive com técnicas livres de conversores de nível de tensão.

5.3 Clock-gating

Em primeiro lugar é importante dizer que a árvore de clock consome aproximadamente 50% da energia em um circuito integrado digital. Depois, cada vez que um gate é chaveado, energia dinâmica será consumida. Se o dado a ser disponibilizado após o chaveamento é o mesmo que lá está, por que então consumir esta energia? Condições para habilitar ou não o clock são as técnicas chamadas de clock gating.

Está apresentada aqui em nível arquitetural pois, assim como as outras técnicas neste nível, é implementada no projeto através das diretivas de síntese que o projetista lança e das células disponíveis no PDK (Process Design Kit). Entretanto o código em que o hardware é descrito também tem forte influência no que a ferramenta vai conseguir fazer, pois é a partir desta descrição que as melhores ‘condições’ para habilitar ou não o clock serão inferidas.

A forma mais comum de clock-gating, simplesmente compara se a entrada D de um banco de registradores é igual ou não à saída Q.

clockcombinacional

Figura 1: Clock gating combinacional (figura retirada de Mohit Arora)

Na figura acima, uma condição de enable permite ou não que aquele registrador seja ‘clockado’, e o dado segue adiante na pipeline. (perceba que o segundo registrador não tem uma lógica de clock gating representada, e muitos menos relacionada com a primeira)Estima-se que 5-10% de energia dinâmica é salva com essa técnica se implementada combinacionalmente.

Pensando num pipeline onde lógicas são encadeadas entre um banco de registro e outros podemos também reduzir o chaveamento redundante na porção do circuito que está conectada à saída banco de registradores que estão sob clock gating, se toda a cadeia subsequente da pipeline for chaveada levando em conta as condições de enable da anterior. Na literatura costumam chamar esta técnica de “clock-gating avançado”.

clocksequencial

Figura 2: Clock gating sequencial (de Morit Ahora)

5.4 Power gating

Desabilitar completamente um módulo quando ele não está em uso, é consideravelmente importante nas atuais tecnologias onde a componente de consumo estático é dominante. Os módulos são habilitados ou desabilitados conforme a necessidade da aplicação. As chaves utilizadas para habilitar ou desabilitar passagem de corrente para o módulo são comumente chamadas de sleep transistors. As chaves conectadas entre Vdd e o módulo são os chamados ‘headers’ e entre o módulo de Vss são os ‘footers’. A inserção destes sleep transistors insere agora dois grandes domínios de tensão no sistema: um permanente, conectado à fonte de alimentação, e um virtual que é o visto pelo módulo de fato. O maior desafio é projetar uma chave que permita que o domínio de tensão real e virtual sejam muito similares em todas as suas características.

header-footer-swithces

Figura 3: Diagrama de blocos de dois circuitos utilizando sleep transitors, (a) header e (b) footer. (de Mohit Arora)

Não é difícil imaginar que o tamanho do sleep transistor seja bastante considerável (no dedão: ~3x a capacitância a ser driveada). Devido ao seu tamanho, ligar ou desligar um módulo através do seu chaveamento leva um tempo. Assim, não parece uma boa política adicionar estas chaves a módulos que ficarão pouco tempo em idle na operação típica do sistema. Assim, ou fazemos um sistema de power gating de baixa granularidade ou alta granularidade.

No modo fine-grain (alta granularidade) cada módulo tem um sleep transistors que são construídos como parte do PDK e adicionados durante a síntese, o que traz imensas vantagens na facilidade de projeto. A economia de corrente de leakage pode chegar a 10X.

No sistema de baixa granularidade, menos sleep-transitors são disponibilizados na forma de ‘grid’ que ligam ou desligam os domínios de módulos conforme a aplicação. Isto implica em menor overhead de área (e por consequência, menor variação de processo). Nesta abordagem os sleep-transistors são de fato parte das linhas de alimentação do circuito, não células adicionadas na síntese lógica, e portanto mais próximos do projetista de back-end.

Por outro lado, nesta abordagem de grid, com menos sleep-transistors chaveando mais circuitos, teremos mais domínios de power, com maiores variações de IR entre eles, maiores correntes de pico de power-up, que podem, entre outros problemas, ocasionar transições indesejadas em módulos vizinhos, o que vai exigir contra-medidas no back-end. Além de é claro, fritar um circuito cujas linhas foram subdimensionadas.

coarsepower

Figura 4: Representação de um esquema de power-gating de baixa granularidade com sleep transistor do tipo footer (de Mohit Arora)

Na prática não existe uma linha bem definida entre fine-grain e power-grain, e um misto de ambos é utilizado em um projeto real.

5.5 Sub-threshold/near-threshold design

A diminuição da tensão de alimentação (mantendo uma tensão de threshold fixa) resulta na diminuição quadrática do consumo dinâmico, às custas de performance, o que a depender da área de aplicação (sensores biomédicos, para dar um único exemplo) não é um problema.

Indo um pouco além, podemos pensar em utilizar o que seria a corrente de leakage desperdiçada para de fato implementar a lógica do sistema, o que é atingido quando se reduz a tensão de alimentação para um valor menor ou muito próximo de Vth. A corrente de sub-threshold é exponencialmente dependente da tensão no gate. A literatura demonstra algumas reduções de até 20X quando comparados com circuitos operando com (super)-Vth.

O grande problema? A pequeníssima diferença na corrente de um transistor ligado e um desligado, faz com que as variações de processo sejam muito impactantes no circuito construído. As contra medidas partem da arquitetura do sistema e chegam ao nível de transistor.

* * *

A próxima e última publicação vai falar das técnicas em nivel RTL.

Se não concorda, não entendeu, achou muito bom ou muito ruim, comentários são muito bem vindos.

O texto desta publicação é original. As seguintes fontes foram consultadas: The Art of Hardware Architecture, Mohit Ahora Ultra-Low Power Integrated Circuit Design, Niaxiong Nick Tan et al.

Abordagens para projeto low-power (1/3)

iphone-battery

1 Eficiência

Na última publicação sugeri que a Compaq teria percebido a portabilidade como requisito mais que desejável para a computação pessoal. Apesar de os primeiros computadores da companhia terem ~12 kg (!) e serem considerados “portáteis” simplesmente por serem apresentados em uma maleta com alças, ainda precisavam de uma tomada de corrente para funcionar.

Um pouco mais tarde, com a popularização das tecnologias multimídias e dos PDAs (personal digital assistants, ou “palmtops”), a computação portátil começa a precisar de cada vez mais performance, e aí a otimização de consumo passou a ser critério determinante em um projeto. O objetivo é ser eficiente: realizando tanto ou mais trabalho com menos energia, as baterias duram mais. Não sei dizer exatamente quando e nem quem começou as pesquisas no assunto, mas um dos trabalhos acadêmicos mais relevantes na área é datado de 1992 (Low-power CMOS Digital Design, CHANDRAKASAN et. al).

Nesta publicação quero falar um pouco sobre técnicas de baixo consumo e a oportunidade de aplicá-las nas diferentes fases e camadas de abstração de um projeto. Aqui estou assumindo que os circuitos são essencialmente digitais. O projeto low-power para circuitos (integrados) analógicos tem técnicas distintas que podem ser assunto para outra postagem.

2 Consumo estático e dinâmico

Dois componentes gerais de consumo são o consumo estático e o consumo dinâmico. Este refere-se ao consumo ocasionado pelas transições de uma porta lógica e é proporcional à corrente circulante, à frequência de transições e às capacitâncias que são carregadas e descarregadas nessas transições. O consumo estático se refere às correntes que circulam entre Vdd e Gnd mesmo quando os módulos de um dispositivo estão desligados. Com os comprimentos de canais dos transistores cada vez menores, as correntes de leakage passaram a ser uma significativa parcela do consumo total, quando não a componente dominante. Quanto menor o canal de um transistor, menor será a sua tensão de threshold e menor será a diferença entre a corrente de operação e a corrente de leakage. Na verdade, a corrente de leakage aumenta exponencialmente com a diminuição da tensão de threshold.

De maneira geral, para um gate lógico:

Potência total = Potência dinâmica + Potência estática [W]

Potência dinamica = Vdd^2 * Freq * Cl* p [W]

onde p é a probabilidade de uma transição lógica ocorrer.

3 Níveis de abstração de um projeto digital

Fazendo uma analogia com carros, uma Lamborghini Diablo 1991 é um sistema igual a um Renault Clio 2010. Ambos são automóveis, do tipo “carro”, compostos por carroceria, 4 rodas, motor, diferencial, volante, transmissão e etc. Porém arquiteturalmente são projetos radicalmente distintos.

Um sistema é concebido para prover uma solução. No caso dos automóveis o problema a ser resolvido é como deslocar algo de um lugar a outro. Se eu preciso levar uma pessoa de um ponto ao outro, eu posso escolher construir um carro, uma moto ou um patinete (que não é um automóvel!). Enfim, as escolhas em nível de sistema, são aquelas que irão definir o que é o meu projeto e quais são suas características. Estas escolhas terão como ponto de partida os requisitos do produto. Se o propósito é deslocar até 5 pessoas de um ponto ao outro e com economia de energia, o Clio faz muito mais sentido que a Lamborghini, se o requisito for um carro.

De maneira geral, podemos representar a estrutura de um projeto, nos seguintes níveis de abstração:

Nível de Sistema: refere-se a definição do conjunto de módulos de um projeto e suas conexões (microprocessador+RAM+NVM+I/O, etc.)

Nivel Arquitetural: refere-se a forma como são construído os módulos definidos no sistema e como eles interagem: a definição de interfaces, dos protocolos de controle, comunicação, etc. (ex.: microprocessador RISC-V 32-bit, 8KB de RAM, 64KB de memória NAND Flash, transreceptor compatível com NFC, camada MAC comunica-se com a PHY através de uma interface AMBA-PB, etc.)

Nível de Registradores (Register Transfer Level): representação do circuito digital como um conjunto de registros, ULAs, Muxes, contadores, etc. Pode ser chamado de “microarquitetura”.

Nível lógico: mapeamento do RTL como um conjunto de portas lógicas, latches e flip-flops.

Nível de Circuito: a representação elétrica do sistema, através de um esquemático de transistores e outros componentes elétricos.

4 Abordagens low-power no nível de sistema

Quando pensamos em sistemas digitais o consumo geralmente estará relacionado à área e performance. Uma maior performance exige uma operação em alta freqüência e com suficiente força de drive. A área relaciona-secom o tamanho dos dispositivos que por sua vez dita o tamanho das capacitâncias a serem carregadas/descarregadas.

4.1 Faça um SoC

O advento dos SoCs, sistemas inteiramente construídos em um único circuito integrado, possibilitou drástico aumento na eficiência energética. Se falamos de um sistema que está construído na forma de chips e componentes discretos conectados em uma placa, a transformação em SoC pode ser vista como uma técnica para redução de consumo. E das mais eficientes.

4.2 Capriche no co-projeto de hardware+software

O que implementar em hardware e o que implementar em software? Tipicamente as implementações em hardware consumirão menos energia que as suas contrapartes em software.

Podemos simplesmente identificar aquelas rotinas que consomem mais processamento e escolher implementá-las em hardware.

Entretanto em um fluxo de projeto que realmente aproveite a oportunidade de se poder implementar qualquer parte de um sistema em hardware ou software, uma abordagem baseada em modelos deve ser considerada. Existem linguagens como o SystemC ou SystemVerilog que permite a confecção de modelos em alto nível de abstração. Outras ferramentas como SystemVue, Matlab/Simulink são dedicadas a modelar sistemas. Depois de o sistema modelado, as simulações são utilizadas para fazer estimativas da performance e consumo das funcionalidades, e pode-se fazer escolhas direcionadas sobre o que será implementado em hardware ou software. As funcionalidades que consomem mais recursos beneficiarão todo o sistema se forem construídas com arquitetura visando baixo consumo. Ou seja, as análises no nível do sistema guiam nossas escolhas arquiteturais mais adiante.

A validação da arquitetura pode ser feita através de uma abordagem TLM (Transaction-Level Modeling).

lowpower_hwswcodesignflow

4.3 Software eficiente

Idealmente o seu compilador deve conseguir produzir um código objeto otimizado, mas ele não tem nenhuma outra informação a não ser o código que você entrega a ele, puro e duro. Compiladores “system aware” só amanhã.

Quantas instruções tem a task mais executada do sistema? Quantos ciclos de clock cada instrução consome? Se um sistema rodando a 5 MHz acorda o processador a cada segundo para executar 500 instruções, admitindo 1 instrução/ciclo, ao diminuírmos somente uma instrução desta task, estaremos dando uma sobrevida a bateria de ~ 6,5 segundos por ano, num sistema 24/7. Escalone isso para mais MHz de operação e mais instruções economizadas, e veja por si só.

Assim, o nosso código, como regra geral deve evitar primitivas complexas e ser otimizado em desempenho. Considero que conhecer o processador e o compilador, e a utilização de boas práticas de engenharia de software como a refatoração, são as melhores forma de escrever códigos eficientes. Abaixo alguns exemplos:

Código original

Código otimizado

if ((i % 10) == 0 )
{
   // faça algo
}
i++;
If (counter == 10)
{
   // faça algo
   counter=0;
}
else
{ 
   i ++
}
counter++;

A operação ‘módulo’ usualmente toma mais ciclos de instrução. É mais econômico reproduzir o mesmo efeito com operações mais baratas.

Código original

Código otimizado

for(i=0;i<10;i++)
{
   // faça algo 1
}
for(i=0;i<10;i++)
{
   // faça algo 2
}
for(i=0;i<10;i++)
{
   // faça algo 1
   // faça algo 2
}

Uma chamada de loop com inicialização, incremento e comparação é economizada.

Código original

Código otimizado

unsigned int x;
 for (x = 0; x < 100; x++)
 {
     A[x] = B[x];
 }
unsigned int x; 
 for (x = 0; x < 100; x += 5 )
 {
     A[x]   = B[x];
     A[x+1] = B[x+1];
     A[x+2] = B[x+2];
     A[x+3] = B[x+3];
     A[x+4] = B[x+4];
     
 }

No código acima, 100 elementos do vetor A serão copiados para as primeiras 100 posições do vetor B. A segunda implementação faz com que o loop precise ser rodado 20 vezes, ao invés de 100.

(Link externo: este AN da Atmel indica no capítulo 9 algumas formas de otimizar tamanho e tempo de execução para AVRs 8-bit)


 

Na parte 2 vou falar sobre técnicas aplicadas no nível arquitetural (power-gating, clock gating, multi Vdd, multi Vth, DVFS…).

Até mais!

O texto desta publicação é original. As seguintes fontes foram consultadas:
The Art of Hardware Architecture, Mohit Ahora
Ultra-Low Power Integrated Circuit Design, Niaxiong Nick Tan et al.