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:

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.

I already knew several hardware blocks in isolation — ALU, flip-flops, SRAM, Flash, buses, MUX, DEMUX — but this phase has made one difference even clearer, one I had been underestimating: knowing the blocks is not the same as understanding the system. And in hardware, that gap grows even wider when logic stops existing only in diagrams and begins facing timing, power consumption, physical implementation, and fabrication.

The competition gathers teams in the task of developing a processor based on the RISC-V ISA for a national-level competition. At the end, the winning team may perform a tape-out at an international foundry — that is, send the final design for fabrication.

The important point, however, is that the competition does not start with the complete processor. It starts before that, in a microelectronics training phase. And that makes a lot of sense: before discussing the core, you need to go back to the blocks that make it possible. It is precisely at that stage that I am now, building circuits and studying the fundamental elements that will later serve as the foundation for subsequent phases.

I have enjoyed this process because it has been correcting a limitation I had noticed in myself for some time. Part of what I knew before was correct, but it was too fragmented. There was a lack of continuity between components, a lack of flow. And I think the main gain so far has been exactly that: starting to see how the pieces condition each other when they stop being classroom subjects and begin to exist as designs.

One of the first shifts in perspective came from Verilog. Not exactly because it is possible to describe hardware in a hardware description language, but because of the weight the word synthesisable gains when the circuit stops being just a logic exercise and begins carrying commitments to implementation, timing, and verifiability. At some point, writing the module stops being just “representing a circuit” and starts meaning “taking responsibility for what that circuit will have to sustain when it leaves the page.”

The question that came right after was inevitable: how do you know if the hardware actually does what you imagine it does?

The answer involves testbenches, simulation environments used to apply stimuli to the circuit and observe its outputs over time. Through them, we begin validating the design’s behaviour before any physical implementation. In software, testing is already a basic obligation; in hardware, it takes on another weight. The cost of discovering an error too late changes scale completely.

This was, in fact, one of the most striking differences I found in this beginning. In software, many errors can still be corrected after the fact with an update, a patch, or some relatively inexpensive workaround. In hardware, the situation is far less comfortable. When a problem survives synthesis, implementation, and fabrication, the room for correction shrinks drastically — and not rarely the way out ends up being some kind of firmware workaround. This puts verification in a much more central place than I used to imagine.

Another topic that appeared with great force was bus arbitration. The general formulation of the problem is simple: when more than one agent tries to access a shared resource at the same time, someone has to decide priority, order, and access control. But, as often happens in digital systems, what seems like an operational detail soon reveals architectural impact. These mechanisms directly affect the final quality of a SoC, interfering with predictability, stability, and efficiency.

I also started to have more direct contact with the broader flow of chip creation, from logical description to fabrication. And perhaps this was one of the most valuable parts of this training: realising that designing hardware is not just about writing correct modules and connecting them properly, but understanding the entire traversal between logic, validation, physical implementation, and production. Along the way, we also returned to the microscopic foundation of it all — like MOSFET transistors fabricated in CMOS technology, which are, ultimately, the substrate on which all this abstraction rests.

But the distinction that most reorganised my understanding so far appeared when we moved from ideal logic and began looking at something closer to the circuit as it exists in the real world.

That is where OpenLane enters — an automated open-source digital design flow that chains steps such as synthesis, floorplanning, placement, routing, and physical verifications. The practical effect of this is simple to describe, though far deeper than it appears: Verilog stops being just an abstract description and begins to be treated as something that needs to fit within a real fabrication technology.

Along with that, the PDK (Process Design Kit) also enters — a set of files, models, libraries, and fabrication rules associated with a particular technology. In other words, it defines the ground on which the design can exist: which cells are available, which geometric and electrical boundaries must be respected, which physical constraints are factored in. In our case, we are using SkyWater 130 nm, a well-known open PDK in the open-hardware ecosystem.

It was at this point that an important difference became much more concrete for me: one thing is verifying whether logic works in ideal terms; another is verifying whether it continues to work when physical delays stop being abstraction.

With this flow, we start obtaining artefacts like the SDF (Standard Delay Format), a standardised format for representing delays and timing information of the circuit after synthesis and implementation. This allows running the testbench again, now accounting for a much more realistic approximation of the design’s temporal behaviour. The question then stops being just “is the logic correct?” and becomes also “does it stay correct when physics starts charging its fee?”

This part surprised me quite a bit, because it exposes a gap that is easy to underestimate on a diagram. There is a considerable distance between a circuit that works in an idealised simulation and a circuit that keeps working when interconnections, parasitic capacitances, fanout, and real delays enter the scene. In hardware, much does not fail at the pure logic level — it fails precisely when the physical world finally joins the conversation.

And it is not only timing that enters this account. The same flow also allows observing metrics like power consumption, both when the circuit is active and when it is at rest, along with occupied area and overall design integrity. At some point, the circuit stops being just logical function and becomes, inescapably, an engineering object: it occupies area, dissipates energy, suffers delay, must respect margins.

There is also a very concrete perceptual shift when the design begins to take physical form. Cells, routing, power rails, pins, interconnections, spatial organisation — everything that HDL compresses into a relatively clean abstraction reappears as materiality, commitment, and constraint. It was one of the first times I felt more clearly this passage from circuit as description to circuit as implementable thing.

Below is a physical visualisation of a 4-bit full adder after this traversal from logical to implementable:

After these steps converge, the flow moves toward GDSII, the final file representing the geometric layout used by the foundry in the chip fabrication process.

The fabrication itself could fill a separate text. Between the digital design and the circuit ready for use, there is a long sequence of steps — wafer, die formation, cutting, packaging, testing — and each imposes its own validation criteria. The more contact I have with this flow, the more evident it becomes that designing hardware is, in large part, also designing a verification process rigorous enough that problems do not only appear too late.

If I had to summarise what this first phase has given me so far, it would not just be “more concepts.” I think the main gain was starting to replace a fragmented familiarity with a more continuous view of the architecture. Not because the pieces became simpler, but because the chain between them finally began to appear.

I have always been interested in understanding the internals of software, but that kind of curiosity demands time beyond willingness. Last year, I bought an Asus Zenbook S14 for work, equipped with an Intel Core Ultra 7 258V and 32 GB of integrated RAM. Since the machine came with Windows 11, I quickly set up dual boot with Fedora to closely follow kernel and driver updates.

The peace did not last long: under heavy CPU usage, the laptop would completely freeze, requiring forced reboots. It was that inconvenience that pushed me toward the low level. What began as a search for the cause of the freezes quickly became something more interesting: understanding how recent hardware and software meet in the kernel and, perhaps, how to contribute to the maturation of that platform.

Along the way, I found DRM Xe, Intel’s newest Direct Rendering Manager. It is the successor to i915 on recent architectures and is expected to centralise support for Intel’s next GPU generations on Linux. Although development started in 2021, it already shows itself as a mature driver, built by Intel engineers who actively contribute to the Open Source ecosystem.

Diving into Xe made me realise that managing a modern iGPU (integrated) imposes enormous challenges, especially in memory management and power states (D-states). Unlike i915, which carried years of “legacy,” Xe proposes a clean codebase but introduces complex abstractions like the GuC (Graphics Microcontroller) and the HuC.

The GuC, in particular, is its own universe I did not even know existed. It is a microcontroller integrated into the SoC responsible for orchestrating command submission and GPU scheduling. For this purpose, it uses the GGTT (Global Graphics Translation Table), a table that allows the microcontroller to map and access system RAM. The biggest surprise, however, was discovering that some GuC units use ARM or RISC-V architectures. It makes perfect sense: these are far more energy-efficient architectures for that function than x86 would be.

This discovery of a “computer inside the computer” managing resources made several questions surface:

1. If user processes use the GPU, who controls the memory (VRAM) they use?

A: The driver itself. It maintains internal structures and virtual address spaces that ensure isolation between contexts. The driver knows exactly who “owns” each allocation to guarantee one process cannot access another’s data, but it is agnostic to the content — to the driver, it matters little whether those bits are a texture or a mathematical computation.

2. And how does the driver use DRAM in a shared way to create VRAM?

A: In integrated GPUs, we use UMA (Unified Memory Architecture). There is a complex mapping system so the GPU sees parts of the system RAM as if it were its own local memory. This dynamic mapping is a dense topic I intend to detail in future posts.

3. How is a program’s interface transformed into pixels on screen?

A: This is a point I am still studying in depth, but it involves resources inherited and shared with i915. The driver is responsible for managing BOs (Buffer Objects), chunks of memory containing raw data, and orchestrating their display through KMS (Kernel Mode Setting), controlling which monitor to update and at what frequency.

Answering those questions led me to another conclusion: if there are mappings for processes, there are execution contexts. And who controls the switching of those contexts at the software level is, again, the driver.

To better visualise where DRM Xe fits into this flow, I drew this macro pipeline:

Interestingly, although the system sees the iGPU as a PCI device, in Lunar Lake this communication bypasses the physical PCIe wires and runs through an internal silicon fabric (Fabric), which explains why a bug here brings the system down so quickly: we are sharing the same main data highway as the CPU.

It is important to remember that this “resource manager” role of the driver is vital not just for video, but for multiprocessing via GPU kernels — an essential feature for Machine Learning models, for example.

The path to contribution

But how do you enter this game? I found that development for new contributors happens in a branch focused on integration: drm-tip. Although there are internal processes that keep the main kernel in parity with this branch, it is in drm-tip that new features are validated.

Intel’s own engineers review patches and suggest improvements. To ensure stability, there is a massive test suite (like IGT GPU Tools) and a repository for running automated live tests on real hardware, validating each change before it is even merged into the main code.

I know this is only the first post on this topic and that much remains to be explained. My biggest challenge right now is exactly this vastness of details, but the goal is clear: document everything until I land my first patch in DRM.

Follow along this journey.

Sempre tive interesse em entender as entranhas do software, mas esse tipo de curiosidade exige tempo além da vontade. No ano passado, comprei um Asus Zenbook S14 para trabalho, equipado com um Intel Core Ultra 7 258V e 32 GB de RAM integrados. Como a máquina veio com Windows 11, logo fiz o dual boot com Fedora para acompanhar de perto as atualizações de kernel e drivers.

A paz durou pouco: em uso pesado de CPU, o laptop congelava completamente, exigindo reinicializações forçadas. Foi esse incômodo que me empurrou para o baixo nível. O que começou como uma busca pela causa dos travamentos logo se tornou algo mais interessante: entender como o hardware recente e o software se encontram no kernel e, quem sabe, como contribuir para o amadurecimento dessa plataforma.

Nesse caminho, encontrei o DRM Xe, o Direct Rendering Manager mais novo da Intel. Ele é o sucessor do i915 nas arquiteturas recentes e deve concentrar o suporte às próximas gerações de GPU da Intel no Linux. Embora o desenvolvimento tenha começado em 2021, ele já se mostra um driver maduro, construído por engenheiros da Intel que contribuem ativamente no ecossistema Open Source.

Mergulhar no Xe me fez perceber que gerenciar uma iGPU (integrada) moderna impõe desafios imensos, especialmente no gerenciamento de memória e nos estados de energia (D-states). Diferente do i915, que carregava anos de “legado”, o Xe propõe uma base de código limpa, mas que introduz abstrações complexas como o GuC (Graphics Microcontroller) e o HuC.

O GuC, inclusive, é um universo à parte que eu sequer sabia que existia. Ele é um microcontrolador integrado ao SoC responsável por orquestrar a submissão de comandos e o escalonamento (scheduling) da GPU. Para isso, ele utiliza o GGTT (Global Graphics Translation Table), uma tabela que permite ao microcontrolador mapear e acessar a memória RAM do sistema. A maior surpresa, porém, foi descobrir que alguns GuC utilizam arquiteturas ARM ou RISC-V. Faz total sentido: são arquiteturas muito mais eficientes energeticamente para essa função do que o x86 seria.

Essa descoberta de que existe “um computador dentro do computador” gerenciando recursos fez várias perguntas borbulharem na minha mente:

1. Se os processos de usuário usam a GPU, quem controla a memória (VRAM) usada por eles?

R: O próprio driver. Ele mantém estruturas internas e espaços de endereçamento virtual que garantem o isolamento entre contextos. O driver sabe exatamente quem é o “dono” de cada alocação para garantir que um processo não acesse os dados de outro, mas ele é agnóstico ao conteúdo, para o driver, pouco importa se aqueles bits são uma textura ou um cálculo matemático.

2. E como o driver usa a DRAM de forma compartilhada para criar uma VRAM?

R: Em GPUs integradas, utilizamos a UMA (Unified Memory Architecture). Existe um complexo sistema de mapeamento para que a GPU enxergue partes da memória RAM do sistema como se fosse sua própria memória local. Esse mapeamento dinâmico é um tema denso que pretendo detalhar nos próximos posts.

3. Como a interface de um programa é transformada em pixels na tela?

R: Este é um ponto que ainda estou estudando a fundo, mas envolve recursos herdados e compartilhados com o i915. O driver é responsável por gerenciar os BOs (Buffer Objects), pedaços de memória contendo os dados brutos, e orquestrar sua exibição através do KMS (Kernel Mode Setting), controlando qual monitor atualizar e com qual frequência.

Responder a essas dúvidas me levou a outra conclusão: se existem mapeamentos para processos, existem contextos de execução. E quem controla a troca desses contextos a nível de software é, novamente, o driver.

Para visualizar melhor onde o DRM Xe se encaixa nesse fluxo, desenhei este macro-pipeline:

Curiosamente, embora o sistema enxergue a iGPU como um dispositivo PCI, no Lunar Lake essa comunicação ignora os fios físicos do PCIe e corre por uma malha de silício interna (Fabric), o que explica por que um bug aqui derruba o sistema tão rápido: estamos compartilhando a mesma estrada principal de dados da CPU.

É importante lembrar que esse papel de “gerente de recursos” do driver é vital não só para vídeo, mas para o multiprocessamento via kernels de GPU, recurso essencial para modelos de Machine Learning, por exemplo.

O caminho para a contribuição

Mas como se entra nesse jogo? Descobri que o desenvolvimento para novos contribuintes acontece em um ramo (branch) focado em integração: o drm-tip. Embora existam processos internos que mantêm o kernel principal em paridade com esse ramo, é no drm-tip que as novas funcionalidades são validadas.

Os próprios engenheiros da Intel analisam os patches e sugerem melhorias. Para garantir a estabilidade, existe uma suíte de testes gigantesca (como o IGT GPU Tools) e um repositório para execução de live tests automatizados em hardware real, validando cada alteração antes mesmo de ela ser fundida ao código principal.

Sei que este é apenas o primeiro post e que ainda falta muita coisa para ser explicada. A minha maior dor agora é justamente essa vastidão de detalhes, mas a meta é clara: documentar tudo até conseguir lançar meu primeiro patch no DRM.

Me acompanhem nessa jornada.

Quero usar este espaço para três coisas.

1. Registrar conceitos novos antes que eles evaporem.
2. Organizar investigações que deram trabalho e merecem referência futura.
3. Publicar artigos mais completos quando um assunto pede contexto, exemplos e trade-offs.

Os temas devem variar, mas o eixo é relativamente estável: engenharia de software, computação, embarcados, IoT, microeletrônica, telecom e qualquer assunto em que teoria e implementação real se encontrem.

Não espero uma linha editorial rígida. Algumas publicações vão ser curtas, quase como notas de laboratório. Outras vão exigir mais elaboração, especialmente quando envolverem arquitetura, protocolos, hardware, depuração ou explicações que eu gostaria de encontrar prontas quando comecei a estudar o tema.

Se funcionar como espero, o blog vira menos vitrine e mais arquivo vivo de estudo e prática. Esse é o tipo de texto que eu mesmo gostaria de revisitar daqui a alguns meses.

I want to use this space for three things.

1. Record new concepts before they evaporate.
2. Organise investigations that took effort and deserve a future reference.
3. Publish more complete articles when a topic calls for context, examples, and trade-offs.

The subjects will vary, but the axis is relatively stable: software engineering, computing, embedded systems, IoT, microelectronics, telecom, and any topic where theory and real implementation meet.

I do not expect a rigid editorial line. Some posts will be short, almost like lab notes. Others will require more elaboration, especially when they involve architecture, protocols, hardware, debugging, or explanations I would have liked to find ready-made when I started studying the topic.

If it works as I hope, the blog becomes less of a showcase and more of a living study and practice archive. That is the kind of text I would like to revisit myself a few months from now.