This text begins as a record of this first phase of Champion Chip Experience, but what has interested me most about it is not exactly the final processor. It is the path to get there.

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:

Physical visualisation of a 4-bit full adder.

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.