English / 日本語
← Back to the Fundamentals home Preface: introduction / big picture

Preface　What is “computer architecture,” really?

The aim of this chapter. There are two things to take hold of. One: what “computer architecture” is — its identity can be sorted into three layers. The other: a map showing that what we actually do in this Fundamentals section is not to design a CPU from scratch, but to “choose, assemble, and check” ready-made parts. No hard math appears. Think of it as the preparatory chapter where we lay blocks out on a desk.

P.1　Who carries out the “contract”?

In Chapter 3 of the reader The Cambrian Explosion of Chips, there was the idea of the instruction set (ISA) = an invisible contract. It is the agreement struck between software and hardware that no one is conscious of, yet everyone follows.

But if we call it a contract, there are two parties. The “software” side that uses the contract, and the “machine” that actually carries it out. The reader explained the contract, but it has not yet touched the machine that carries it out. This Fundamentals section is the corner where we go to understand that machine. Once the machine’s shape is clear, you can sort out: “so that is why the ISA (contract) takes this form.”

P.2　Computer architecture = three layers

The term “computer architecture” actually has a clear origin. In 1964, the designers of IBM’s mainframe System/360 defined it this way — “the structure of a system as seen by the programmer.” It means a term that refers to the promises visible from outside, set apart from how it is actually built inside (circuits and wiring).

This is the crucial point. “Architecture” in the strict sense refers to the topmost layer = the contract (ISA) itself. Then what do we call the machine that carries out that contract — how you assemble the ALU and registers, and in what order you run instructions? This is called microarchitecture, and it is distinguished from architecture. And below it there is the layer of physical substance = implementation, of transistors and wiring. As a diagram, it looks like this.

The three layers of computer architecture From the top: architecture (the ISA, the promises), microarchitecture (the machine's insides), and implementation (circuits, physical). They correspond to the reader Chapter 3, this Fundamentals section, and the LibreLane course. Top = the view from software Architecture (ISA) the “promises” visible from software Microarchitecture the “machine’s insides” that keep the promise Implementation (circuits, physical) transistors and wiring themselves Bottom = the substance as physical matter Reader · Ch. 3 ★ This Fundamentals section LibreLane course
Even with the same “contract (ISA),” there are many possible “machines (microarchitectures)” that keep it. The reader handles the contract, this Fundamentals section the machine, and the bottom physical layer is handled by manufacturing (the LibreLane course).
The three layers, terms sorted.
· Architecture (ISA) = the contract. How instructions and registers “appear.” The layer the reader dealt with.
· Microarchitecture = how the machine that keeps that contract is assembled. The lead of this Fundamentals section.
· Implementation = the physical substance of transistors and wiring.

And this term is used in two ways, a broad sense and a narrow sense. “Computer architecture” as used in university lectures and textbooks is the broad sense, bundling the top two layers. Meanwhile the strict sense of the word is only the very top (the contract). That is why we titled this Fundamentals section “How CPUs Work.” The lead is the middle layer (the machine), and we call it “behind the instruction set.”

P.3　The same contract, a different machine — so we think of them separately

Why go to the trouble of thinking about “contract” and “machine” separately? An example is the quickest way. A smartphone’s low-power core and a PC-class high-performance core have exactly the same instruction set (contract), yet the way their insides are assembled is completely different — this actually happens all the time. If the contract is the same, the same software runs. But the speed and the power draw are different things. Share the contract; choose the machine. This sense becomes the groundwork of the whole Fundamentals section.

P.4　So what do we “do” in the Fundamentals section?

Here, one honest word. The “flow in which an instruction passes through five steps” that appears in Chapter 3 later — fetch, decode, execute, and so on. It is actually a fairly old story, largely settled in the 1980s. So we do not redesign that machine from scratch.

In Chapter 5 of the reader there was the idea that “RISC-V opened up the ‘language.’” This also means that the “machine” that carries out the contract is, likewise, already available as a finished product, released for free. So our job comes to this — not to invent from zero, but to choose, configure, assemble, and check. Look at the next map.

The map of what we decide for our own chip On the left, open resources (existing cores, the RISC-V ISA, LibreLane, the SkyWater PDK, an FPGA for verification). In the center, the four areas we decide (brain, memory, peripherals, physical). On the right, the flow of verifying, taping out, and arriving at your own chip. Resources Existing cores RISC-V ISA LibreLane SkyWater PDK FPGA (verify) Just choose What you decide Brain core · ext. · stages Memory amount · layout Peripherals connections · bus Physical clock · process Assemble Verify on FPGA → tape-out Your chip
Choose from the “open resources” on the left, decide the four areas in the center, then verify and go to manufacturing on the right. The Fundamentals section is the groundwork for making that central judgment properly, with your own hands.

In short, there are roughly four things to decide. Brain (which CPU core to use / how far to take instruction extensions / how many pipeline stages), Memory (the amount and layout of memory), Peripherals (which bus to connect UART/SPI and the like), Physical (clock in MHz, power, the area budget of the manufacturing process). And what you can use is a full set of “no need to write — just choose” resources: free RISC-V, open core families and EDA, the PDK, and an FPGA for verification.

A point to watch: “learning the basics” does not mean “building a CPU from scratch.” What we learn is not for building a datapath ourselves, but for getting “an eye for choosing” and “a clue for fixing.” For judging how speed and area move when you choose the number of stages (single-cycle / 2-stage / 5-stage). And for isolating, when a dev board “won’t run,” which step an instruction is stuck at. Turning textbook knowledge into a tool for judgment and verification — that is the role of this Fundamentals section.

P.5　How to walk through this Fundamentals section

The whole is in three parts. After them, we placed a chapter that is the destination, and a bridge to the courses. At the end of each chapter, we always add “which decision is this knowledge for.” It is so you don’t lose sight of where, on that earlier “decisions map,” you are currently deciding.

Ready? In the next Chapter 1, we start laying out the smallest block on the desk — the register. Why does a CPU need a “workbench close at hand”? Let’s untangle it from there.