Este texto nasce como um registro dessa primeira fase do Champion Chip Experience, mas o que mais tem me interessado nela não é exatamente o processador final. É o caminho até ele.

Eu já conhecia vários blocos de hardware de forma isolada, ULA, flip-flops, SRAM, Flash, barramentos, MUX, DEMUX, mas essa etapa tem deixado mais evidente uma diferença que eu ainda subestimava: conhecer os blocos não é o mesmo que entender o sistema. E, em hardware, essa distância fica ainda maior quando a lógica deixa de existir apenas no diagrama e começa a enfrentar temporização, consumo, implementação física e fabricação.

O campeonato reúne equipes na tarefa de desenvolver um processador baseado na ISA RISC-V para uma disputa em nível nacional. Ao final, a equipe vencedora poderá realizar o tape-out em uma foundry internacional, isto é, enviar o projeto final para fabricação.

O ponto importante, porém, é que a competição não começa no processador completo. Ela começa antes, numa fase de capacitação em microeletrônica. E isso faz bastante sentido: antes de discutir o core, é preciso voltar aos blocos que o tornam possível. É justamente nessa etapa que estou agora, construindo circuitos e estudando os elementos fundamentais que mais adiante servirão de base para as etapas seguintes.

Tenho gostado desse processo porque ele vem corrigindo uma limitação que eu já percebia em mim há algum tempo. Parte do que eu conhecia antes estava correta, mas estava fragmentada demais. Faltava continuidade entre os componentes, faltava fluxo. E acho que o ganho principal até aqui tem sido justamente esse: começar a enxergar como as peças se condicionam mutuamente quando deixam de ser assunto de aula e passam a existir como projeto.

Uma das primeiras mudanças de perspectiva veio do Verilog. Não exatamente por ser possível descrever hardware em uma linguagem de descrição de hardware, mas pelo peso que a palavra sintetizável ganha quando o circuito deixa de ser apenas um exercício de lógica e passa a carregar compromissos com implementação, temporização e verificabilidade. Em algum momento, escrever o módulo deixa de ser apenas “representar um circuito” e passa a significar “assumir responsabilidade pelo que esse circuito terá de sustentar quando sair do papel”.

A pergunta que apareceu logo em seguida foi inevitável: como saber se o hardware realmente faz o que imaginamos que ele faz?

A resposta passa pelos testbenches, ambientes de simulação usados para aplicar estímulos ao circuito e observar suas saídas ao longo do tempo. É por meio deles que começamos a validar o comportamento do projeto antes de qualquer implementação física. Em software, testar já é obrigação básica; em hardware, isso ganha outro peso. O custo de descobrir um erro tarde demais muda completamente de escala.

Essa foi, inclusive, uma das diferenças mais marcantes que encontrei nesse início. Em software, muitos erros ainda podem ser corrigidos depois com uma atualização, um patch ou algum contorno relativamente barato. Em hardware, a situação é bem menos confortável. Quando um problema atravessa síntese, implementação e fabricação, o espaço para correção diminui drasticamente, e não raro a saída acaba sendo algum tipo de workaround em firmware. Isso coloca a verificação num lugar muito mais central do que eu costumava imaginar.

Outro tema que apareceu com bastante força foi a arbitragem de barramento. A formulação geral do problema é simples: quando mais de um agente tenta acessar um recurso compartilhado ao mesmo tempo, alguém precisa decidir prioridade, ordem e controle de acesso. Mas, como costuma acontecer em sistemas digitais, o que parece um detalhe operacional logo revela impacto arquitetural. Esses mecanismos afetam diretamente a qualidade final de um SoC, interferindo em previsibilidade, estabilidade e eficiência.

Também comecei a ter contato mais direto com o fluxo mais amplo de criação de um chip, desde a descrição lógica até a fabricação. E talvez essa tenha sido uma das partes mais valiosas dessa formação: perceber que projetar hardware não é apenas escrever módulos corretos e conectá-los adequadamente, mas entender a travessia inteira entre lógica, validação, implementação física e produção. No meio desse caminho, voltamos também à base microscópica de tudo isso, como os transistores MOSFET fabricados em tecnologia CMOS, que são, em última instância, o substrato sobre o qual toda essa abstração se sustenta.

Mas a distinção que mais reorganizou minha compreensão até agora apareceu quando saímos da lógica ideal e começamos a olhar para algo mais próximo do circuito como ele existe no mundo real.

É aí que entra o OpenLane, um fluxo automatizado de projeto digital open source que encadeia etapas como síntese, floorplanning, placement, routing e verificações físicas. O efeito prático disso é simples de descrever, embora bem mais profundo do que parece: o Verilog deixa de ser apenas uma descrição abstrata e passa a ser tratado como algo que precisa caber em uma tecnologia de fabricação real.

Junto com isso, entra também o PDK (Process Design Kit), que é o conjunto de arquivos, modelos, bibliotecas e regras de fabricação associados a uma determinada tecnologia. Em outras palavras, ele define o terreno em que o projeto pode existir: quais células estão disponíveis, quais limites geométricos e elétricos precisam ser respeitados, quais restrições físicas entram na conta. No nosso caso, estamos usando o SkyWater 130 nm, um PDK aberto bastante conhecido no ecossistema de hardware livre.

Foi nesse ponto que uma diferença importante ficou muito mais concreta para mim: uma coisa é verificar se a lógica funciona em termos ideais; outra é verificar se ela continua funcionando quando os atrasos físicos deixam de ser abstração.

Com esse fluxo, passamos a obter artefatos como o SDF (Standard Delay Format), um formato padronizado para representar atrasos e informações temporais do circuito após síntese e implementação. Isso permite rodar novamente o testbench já levando em conta uma aproximação muito mais realista do comportamento temporal do projeto. A pergunta, então, deixa de ser apenas “a lógica está certa?” e passa a ser também “ela continua certa quando a física começa a cobrar a conta?”.

Essa parte me surpreendeu bastante, porque ela expõe uma diferença que, no diagrama, é fácil subestimar. Existe uma distância considerável entre um circuito que funciona numa simulação idealizada e um circuito que continua funcionando quando interconexões, capacitâncias parasitas, fanout e delays reais entram em cena. Em hardware, muita coisa não falha na lógica pura; ela falha justamente quando o mundo físico finalmente participa da conversa.

E não é só temporização que entra nessa conta. O mesmo fluxo também permite observar métricas como consumo de energia, tanto quando o circuito está ativo quanto quando está em repouso, além de área ocupada e integridade geral do projeto. Em algum ponto, o circuito deixa de ser apenas função lógica e passa a ser, de forma incontornável, um objeto de engenharia: ele ocupa área, dissipa energia, sofre atraso, precisa respeitar margens.

Há também uma mudança de percepção muito concreta quando o projeto começa a adquirir forma física. Células, roteamento, trilhas de alimentação, pinos, interconexões, organização espacial, tudo aquilo que a HDL comprime numa abstração relativamente limpa reaparece como materialidade, compromisso e restrição. Foi uma das primeiras vezes em que senti com mais clareza essa passagem do circuito como descrição para o circuito como coisa implementável.

Abaixo está uma visualização física de um full adder de 4 bits já depois dessa travessia do lógico para o implementável:

Visualização física de um full adder de 4 bits.

Depois que essas etapas convergem, o fluxo caminha para o GDSII, arquivo final que representa o layout geométrico usado pela foundry no processo de fabricação do chip.

A fabricação em si já renderia um texto à parte. Entre o projeto digital e o circuito pronto para uso existe uma sequência longa de etapas, wafer, formação dos dies, corte, encapsulamento, testes, e cada uma delas impõe seus próprios critérios de validação. Quanto mais contato tenho com esse fluxo, mais evidente fica que projetar hardware é, em larga medida, projetar também um processo de verificação suficientemente rigoroso para que os problemas não só apareçam tarde demais.

Se eu tivesse que resumir o que essa primeira fase tem me dado até agora, não seria apenas “mais conceitos”. Acho que o ganho principal foi começar a substituir uma familiaridade fragmentada por uma visão mais contínua da arquitetura. Não porque as peças tenham ficado mais simples, mas porque o encadeamento entre elas começou finalmente a aparecer.

No próximo texto, quero comentar um pouco sobre o desenvolvimento de um processador RISC-V simples implementando o RV32I, a base inteira de 32 bits da ISA. Aqui vale uma distinção importante. A ISA (Instruction Set Architecture) define a interface visível ao software: o conjunto de instruções, os registradores, os formatos e as regras que o processador expõe para quem programa. Já a microarquitetura é a forma concreta de implementar essa ISA em hardware: pipeline, unidade de controle, caches, forwarding, tratamento de hazards e assim por diante. É por isso que processadores diferentes podem implementar a mesma ISA e, ainda assim, terem organizações internas bastante distintas. Quando se diz informalmente que um processador tem “arquitetura RISC-V”, o que normalmente se quer dizer é que ele implementa a ISA RISC-V; a microarquitetura, por sua vez, é a forma específica escolhida para realizar isso em silício.

Mesmo sendo o subconjunto mais enxuto, o RV32I já expõe várias das decisões que tornam um processador legível não apenas como coleção de blocos, mas como sistema.

Por enquanto, a parte mais valiosa desse campeonato tem sido justamente essa: sair da convivência com componentes isolados e começar, enfim, a acompanhar com mais clareza o caminho inteiro que vai da lógica ao silício.