The tapeout we did not finish

By early 2025 we had an architecture we believed in. The next question was the honest one. Would it become silicon. This is the account of taking that design into a full physical flow, how far it went, where it stopped, and what stopping taught us.

We were not measuring tools

We did not start this to benchmark EDA. We started it to answer one question about our own design. Could the architecture we had drawn survive placement, routing, and the physical reality of a process. Everything we did was in service of that single answer.

What we were trying to place

The architecture was built to run a mix of models on one edge die. Small models for quick decisions. Large models where accuracy mattered. Video processing models for the streams that never stop. All of it close to the sensor, inside a tight power and cost budget. To do that on one die, the design leaned on dense on chip memory, many SRAM hubs sitting next to the compute, because the moment data has to leave the die is the moment power and latency both rise.

That memory density is not a detail of the design. It is the design. It is what lets several classes of model share one small die and still answer in time. We were not willing to treat it as negotiable.

Open infrastructure took us to the start line

Open PDKs and open source EDA gave us a first implementation. A floorplan. A power grid. Placement. Routing. Without them, a small team would not have reached the physical flow at all, and we say that plainly. What follows is not a story about a tool falling short. It is a story about a design meeting a constraint that no amount of tooling could argue with.

We went further than a demonstrator

This was not a toy run. Millions of cells. Dozens of SRAM macros. A full power distribution network. Antenna repair. A clock tree. The flow did a great deal of correct work, and for a long stretch it looked like it would go all the way. The design placed. The early stages closed. The trouble arrived later, and it arrived from the geometry.

Where it stopped

It stopped in routing. The process we were on offers five metal layers. The two lowest go mostly to the internals of the standard cells. The top layer carries the power grid that feeds the entire die. That leaves two layers in the middle to route every global signal, every clock path, and every wide bus between the memory hubs.

For a memory dense AI layout, two routing layers between large SRAM macros is very little room. The buses that move data between the hubs need width, and the width had nowhere to go. The router worked within the space the geometry allowed. The geometry was the wall. This was not a single mistake we could point at and correct. It was the shape of the problem: a memory dense architecture asking a thin metal stack for room it did not have.

The choice we would not make

There was an obvious way to make it route. Shrink the memory. Lower the clock. Cut the compute. Give the router room by making the design smaller. It would have worked. It would also have quietly turned our architecture into a weaker, different one, the exact thing we set out not to build.

So we did not finish that tapeout. We chose to stop rather than ship an architecture we had hollowed out to fit a limit we could already name. The right home for this design is a node with more metal, seven to nine layers, where the routing layers stay free while power sits above them. That was the real answer, and it lived on the other side of a closed process. We still hold that line. The architecture is the point. When a constraint asks us to give it up, the constraint is the thing to change, not the design.

The cost was not the failure. It was not knowing why.

Here is the part that actually moved us. Through all of it, the flow told us pass or fail. It did not tell us what kind of failure. Was it the floorplan. The macro placement. The power grid. The routing. The technology itself. Each of those points to a different fix, and the flow would not say which. So we learned it the slow way, by hand, one theory at a time. Weeks went into discovering something a flow that understood its own failure could have said in minutes.

That gap is the whole thing. A flow that only says pass or fail hands the hardest question, why, back to the engineer. For a small team, that question is the entire budget.

What we decided to build

We did not set out to build EDA in order to sell EDA. We set out to build it because we needed answers our flow could not give. Before we commit real money to a node, we want to know, early, whether this architecture will route, what the power envelope truly is, where the timing margin sits, and when something fails, which of those it was. Not pass or fail. The category. The reason.

That is the tool we started building. Not a replacement for a commercial flow, but a flow that understands what it is doing well enough to tell us where it went wrong. The chip asked the question. The tools are our answer to it.

The next piece follows the question that comes straight out of this one. How do you build trust in an EDA tool with no customer history?