O que realmente é a arquitetura harvard
A arquitectura Harvard separa fisicamente o acesso aos dados e ao código. Memória de instruções num barramento, memória de dados noutra. CPU não precisa partilhar caminho único para buscar opcode e ler operandos ao mesmo tempo. Isso elimina um gargalo que existe na arquitectura von Neumann, onde tudo passa pelo mesmo barramento. Parece simples. É simples. O problema é que o mundo real raramente respeita essa separação limpa.
Vou ser directo sobre como isso funciona na prática. A arquitectura harvard permite execução paralela de busca de instrução e acesso a dados dentro de um mesmo ciclo de relógio. Em pipelines, isso significa que enquanto um estágio busca o próximo bytecode, outro estágio já está carregando um operandos da memória de dados. Sem contenção. Clock rate mais alto com menos stalling. Isso se traduz em ganhos reais de performance em DSPs e microcontroladores embarcados, onde a latência de barramento compartilhado é um fator crítico.
Arquitetura harvard na prática: onde ela brilha e onde ela quebra
Eu trabalhei durante meses num projeto de processamento de sinal em tempo real usando um DSP baseada em arquitectura Harvard. O setup era simples: memória de programa em flash, memória de dados em SRAM interna, dois barramentos independentes ligadas ao core. A performance era boa. Muito boa. Mas teve um momento que quase destruiu o prazo do projecto. O problema era um bloco de rotinas de interrupção que precisavam escrever dados temporários na memória de programa durante execução. Sim, você lê certo. Código que precisava também atuar como armazenamento. Na arquitectura Harvard pura, isso é impossível porque os dois espaços são isolados por hardware. Não existe maneira de fazer load/store cruzado entre os dois domínios de memória.
A solução que eu encontrei foi usar uma região de memória mapeada espelhada no espaço de dados que apontava para os primeiros endereços da memória de programa. Era um workaround sujo, mas funcionava. O core via duas cópias do mesmo conteúdo, uma pelo barramento de instrucciones e outra pelo barramento de dados. Desvantagem: memória duplicada na prática, e qualquer alteração no código exigia sincronização manual entre as duas regiões. Foi um lembrete útil de que arquitectura Harvard não é bala de prata. O conceito básico da arquitetura Harvard é o seguinte. Instruções residem numa memória com acesso optimizado para leitura only, tipicamente mais rápida para fetch. Dados residem noutra memória, com acesso read/write completo. Os barramentos são fisicamente separados dentro do chip. O processador tem pelo menos duas interfaces de memória distintas.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Você encontra isso em muitos lugares. AVR da Atmel, PICs, diversos DSPs da Texas Instruments e Analog Devices, e os núcleos RISC-V modernos que oferecem optionais Harvard. Até o PlayStation 2 usava uma variante interessante, com memória de textura separada da memória de processamento vetorial. Aqui vai algo que poucos mencionam. A separação física cria um problema de consistência de cache que a maioria dos engenheiros subestima. Quando você tem instruction cache e data cache funcionando independentemente, e um bloco de código é modificado em runtime (auto-modifying code ou código gerado dinamicamente), o cache de instruções pode continuar servindo uma versão antiga do código enquanto o cache de dados já recebeu a versão nova. O processador executa código obsoleto sem nenhum aviso. Nada quebra. Nada exception é levantada. O resultado é simplesmente errado.
A correção é limpar a instruction cache depois de qualquer modificação no código. Em alguns chips isso é trivial, um registrador para escrever. Em outros, você precisa inserir instruções de flush sequenciais manualmente, o que custa ciclos preciosos em loops críticos. Eu já vi projetos inteiros quebrarem por esse motivo, e a depuração demorou semanas porque o comportamento era intermitente, dependente do estado dos caches. Outro ponto que ninguém destaca é a complexidade de linkers e toolchains. Compilar para arquitectura Harvard exige configurções específicas no linker script. Você precisa definir separadamente os segmentos de texto e dados, mapeá-los para os endereços corretos nos dois barramentos, e garantir que tabelas de vetor de interrupção, strings literal, e dados const fiquem na região de memória de programa. Se o linker colocar um dado readonly na região errada, o compilador não reclama. O programa compila limpo. Só funciona errado em runtime.
Isso muda completamente quando você entra no território de sistema embarcado com MMU. A arquitectura Harvard pura não escala bem para sistemas operacionais multi-tarefa com proteção de memória. Cada processo precisa do seu próprio espaço endereçado isolado, e manter dois endereçamentos independentes por processo dobra a complexidade daa e aumenta a pressão sobre a TLB. É por isso que a maioria dos processadores de propósito geral modernos, x86, ARM A-profile, são von Neumann com elementos Harvard em nível de cache, não de arquitectura. Se você está começando com um microcontrolador Harvard, aqui vai o guia prático. Primeiro, entenda o mapeamento de memória do seu chip. Leia o datasheet inteiro sobre memory map, não apenas a tabela de specs. Anote os endereços base de cada banco de memória. Segundo, configure o linker script com cuidado. Separe claramente code, rodata, e data. Teste com um programa mínimo que escreva na FLASH e leia depois para verificar se a separação está funcionando como esperado. Terceiro, se for usar interrupções que modificam dados em tempo real, verifique imediatamente se o seu core tem mecanismos de flush de cache ou se você precisa implementá-los software.
O custo de desenvolvimento em arquitectura Harvard é tipicamente 20 a 30% maior do que em soluções von Neumann equivalentes, devido à complexidade de toolchain, linker scripts, e gestão manual de caches. Se o seu projecto não precisa daquela performance extra ou daquele throughput de DSP, a arquitectura von Neumann pode ser a escolha mais sensata. Você ganha em simplicidade de desenvolvimento, e em muitos casos a diferença de performance é irrelevante para a aplicação final. A minha recomendação é usar arquitectura Harvard apenas quando o hardware do seu processador realmente a oferece de forma nativa, e quando o domínio do problema se beneficia diretamente da paralelismo de barramento. Para aplicações gerais, sistemas com OS, ou protótipos rápidos, von Neumann continua sendo a opção mais pragmática. Não adianta forçar uma arquitectura que não se encaixa só porque soa mais sofisticada no papel.
