Skip to content
EDA EDA3.0 Tuple

Whose Terms ?

Mark Milton
Mark Milton

Build, Run & Scale · A Watchtower Series — Part 3 of 3

Most chip teams didn’t choose a single cloud. They drifted into one. Here’s what that gravity costs — and what changes when the orchestration layer is yours, not your vendor’s.

Ask a design org which cloud they run on and you’ll often get a slightly sheepish answer: “Mostly one — that’s where we started.” It wasn’t a decision. It was a default. The first hyperscaler a contract happened to land on, or the EDA vendor’s managed cloud bundled with the tools, quietly became the whole world. Nobody chose lock-in. They just never chose anything else.

The cost of gravity

That drift has a price, and it shows up in three places:

  • No arbitrage. You pay one provider’s rate and can’t shop GPU capacity across the neo-cloud providers, even when the same run is dramatically cheaper elsewhere.
  • No portability. Your flows are wired into one environment. Moving a workload — or honoring a partner that wants a different cloud — becomes a project, not a toggle.
  • No real-time support. When a compile farm falls over at 2 a.m. mid-tapeout, a single-vendor cloud answers in 24-hour tickets. During a tapeout, that’s a slipped schedule.
AWSAzureGCPneo-cloudon-prem vendor-neutral orchestration no lock-in EDA workloads self-hosted · cloud-hosted · SaaS — your choice
Fig. 3 — One layer above the stack, no lock-in

Convenient by design — and locked by design

A managed cloud from your EDA vendor is genuinely easy to start with. That’s the point. Your tools, licenses, data, and support all live in one place you don’t control. It works beautifully until the day it constrains you — when the vendor’s environment won’t run the third-party tool you need, or won’t reach the cloud your partner insists on. You find out at the worst possible time, and you find out that “easy” was the same thing as “captured.”

Lock-in is rarely a decision. It’s the absence of one.

And some workloads can’t go to anyone’s public cloud

There’s a category the cloud-only platforms simply can’t serve: IP-sensitive work. Foundry PDKs under NDA, defense-grade controls, partner IP with contractual handling requirements. For those, “just use our SaaS” is a non-answer — and the team ends up standing up a separate, unmanaged on-prem island nobody is watching.

Neutrality is a posture, not a feature

The fix isn’t a better single cloud. It’s a layer that sits above the hyperscalers and orchestrates EDA workloads across all of them — AWS, Azure, GCP, the neo-cloud GPU providers, and on-prem HPC — without caring which one any job lands on. That neutrality buys back the three things gravity took: arbitrage, portability, and one operational picture.

It also means the same flows can run self-hosted (air-gapped, for IP-sensitive work), cloud-hosted, or SaaS — chosen per workload, on your terms.

The through-line

The compute you couldn’t account for in Part 1 and the licenses that starved you in Part 2 are not separate problems for separate teams. They’re symptoms of the same condition: EDA infrastructure you can see pieces of but cannot control as a whole.

Putting that layer back in your own hands — vendor-neutral, cloud-neutral, deployment-neutral — is what it means to build, run, and scale EDA infrastructure on your terms. It’s what Tuple Technologies set out to do with the Stratos platform: not a replacement for your clouds, but the layer above them that finally makes them yours to manage.

The way in is never a demo — it’s a short assessment on one real program, using your own data

Explore Tuple  👉
01 · Compute  ·  02 · Licenses  ·  03 · Neutrality

Share this post