OpenTPU: an open source AI accelerator built by AI

An AI helped design the chip that runs AI. That's basically what OpenTPU promises: an open source AI accelerator, inspired by Google's TPU, with the hardware design developed by language models. The repo hit the top of dev discussions this week, and for good reason. The pitch sounds like a recursive joke, but the project is real and the code is there for anyone who wants to open it.

I'm not a hardware engineer. I write TypeScript, React and SQL all day. That's exactly why I found the project interesting. It shows how far AI can go outside the comfort zone of CRUD, and where it still needs someone watching over its shoulder.

So what is OpenTPU?

TPU stands for Tensor Processing Unit. It's the chip Google built to speed up neural networks. The first generation, described in a 2017 paper, had a 256 by 256 grid of multiply-and-add units working with 8-bit integers. It does nothing else. It just does that very fast.

The trick is called a systolic array. Picture a grid of small cells. Each one multiplies two numbers, adds the result to what it got from its neighbor and passes it along. Data "pulses" through the grid like blood through a heart, hence the name. At the end, out comes a full matrix multiplication, which is what a neural network does almost all the time.

OpenTPU follows that idea. It's a hardware design described in code (HDL), meant to be simulated and, in theory, synthesized on an FPGA. It's not a chip you can buy. It's an open blueprint.

One detail to avoid confusion: there was already an academic OpenTPU, from UC Santa Barbara, back in 2017, written in PyRTL. This week's project is a different one, from the user FeSens on GitHub. Same name, same inspiration, different origin.

How does an AI write hardware?

The same way it writes your React component: by generating text. The difference is that this text describes wires, registers and clock cycles, not divs.

To give you an idea of the format, a multiply-accumulate cell in Verilog looks roughly like this (my own simplified example, not the repo's code):

module mac_cell (
  input  wire        clk,
  input  wire [7:0]  a_in, b_in,
  output reg  [7:0]  a_out, b_out,
  output reg  [31:0] acc
);
  always @(posedge clk) begin
    acc   <= acc + a_in * b_in;
    a_out <= a_in;  // pass to the neighbor on the right
    b_out <= b_in;  // pass to the neighbor below
  end
endmodule

It's just a few lines. A language model writes this without breaking a sweat. The challenge isn't the cell. It's placing thousands of them side by side, feeding the data in with the right delay, managing memory, controlling the instruction flow and making sure nothing lands one cycle late.

In software, an off-by-one-cycle error is a bug you fix in the next deploy. In hardware, once it becomes silicon, it's a bug carved in stone.

Why does this matter if you don't work on chips?

Because the bottleneck moved, and that applies to your code too.

Writing HDL has always been an expensive niche. Few people know it, the tools are hostile and the feedback loop is slow. If a model can get a working accelerator off the ground, even a simple one, the barrier to entry drops a lot. Students, hobbyists and small startups get a starting point that used to cost months of specialist time.

But notice what's left for the human. The AI generates the design. Someone has to prove it works.

Generating code got cheap. Proving it's right is still expensive.

Hardware has taken this seriously for decades. Chip teams usually spend more effort on verification than on design. Testbenches, cycle-by-cycle simulation, comparison against a reference model in software. It's exactly the kind of discipline we in the web world treat as optional.

What changes in your workflow

OpenTPU is a great mirror for how we use AI day to day. The pattern that works in hardware is the same one that works in any stack:

• Have a reference model. In hardware, you compare the chip's output with a matrix multiplication done in NumPy. In your project, that's the test that says what "correct" means before the AI writes anything.
• Test behavior, not appearance. AI-generated code tends to look correct. Looking correct doesn't count.
• Shrink the blast radius. One cell at a time, one module at a time. Asking for the whole system in a single prompt means debugging the whole system later.

In practice, the reference test is something as simple as this:

import { expect, test } from 'bun:test'

test('accelerator output matches the reference', () => {
  const a = randomMatrix(4, 4)
  const b = randomMatrix(4, 4)
  expect(simulate(a, b)).toEqual(matmul(a, b))
})

simulate could have been written by you, by a model or by an intern at three in the morning. The test doesn't care. That's why it's worth more than the code.

Can you actually use OpenTPU?

Depends on what you mean by "use". To run your LLM in production, no. An off-the-shelf GPU or a cloud instance will keep winning by a huge margin, and that's no knock on the project. Commercial chips have years of optimization, cutting-edge fabrication processes and entire teams behind them.

To learn, yes, and a lot. If you've always wanted to understand why matrix multiplication dominates the cost of AI, reading a small open design teaches more than ten threads explaining "how the TPU works". You see the data coming in, moving through the grid and coming out.

If you want to explore, here's how I'd go about it:

1. Clone the repo and read the README carefully.
2. Find the basic cell of the systolic array and understand its input and output signals.
3. Run the simulation or whatever tests the project offers and look at the waveforms.
4. Break something on purpose, like delaying a signal, and watch the result come out wrong.

Step 4 is the most valuable one. You only really understand a system after you've seen it fail.

An honest warning: I haven't audited the design line by line, and projects written with AI deserve an extra dose of skepticism. Read the tests before trusting what the README says. That goes for this one and any other.

The part nobody likes to hear

It's tempting to read "open source AI accelerator built by AI" and conclude that hardware engineering is a dying profession. I think it's the opposite.

The project only makes sense because there's an objective way to tell if it's right. Hardware has simulation, reference models, hard metrics. AI shines exactly where feedback is fast and binary: pass or fail. Where that ground is missing, it produces pretty, wrong things with a lot of confidence. Just like an excited junior dev, only typing much faster.

So the skill that gains value isn't writing Verilog or writing TypeScript. It's knowing how to specify what "correct" means and building the safety net of tests that holds everything else up.

My take: OpenTPU won't change the chip market. It will change how many people dare to understand one. And that's why open source is still the best lab we have to test how far AI can go. If you like watching experiments turn into working things, take a look at what I've been building in my projects.

An AI helped design the chip that runs AI. And the code is open on GitHub.

OpenTPU is an accelerator inspired by Google's TPU, with the hardware design written by language models.

I'm not a hardware engineer, but the project taught me something that applies to any stack: generating code got cheap, proving it's right is still expensive.

AI shines where feedback is objective, when the test either passes or fails. Without that ground, it delivers pretty, wrong things with a lot of confidence.

The most valuable skill now isn't writing Verilog or TypeScript. It's defining what "correct" means and building the tests that hold everything else up.

I wrote more about it on the blog. If you're into the topic, the link is in the comments.

#ArtificialIntelligence #OpenSource #Hardware #SoftwareDevelopment #Testing