Most Indian chip startups set up in Bengaluru. We picked Coimbatore. People ask why, so here is the short version.

The cost stack actually closes here​

Engineering salaries in Coimbatore are 25 to 35 per cent below Bengaluru for equivalent experience, and the gap widens at the senior end where physical-design and verification leads are scarce nationally but extraordinarily scarce in Bengaluru, where the multinationals have already absorbed them at premium rates. For a small fabless company spending two crore per year on engineers, that delta is the difference between making payroll and making payroll plus running a regression cluster.

Real estate, office costs, and cost of living all move in the same direction. None of these by themselves justify a move, but stacked they buy us a quarter or two of runway on the same balance sheet — and runway is the thing that determines whether a fabless company sees first silicon or not.

The talent pipeline is real, not hypothetical​

PSG Tech, Amrita Vishwa Vidyapeetham, Coimbatore Institute of Technology, GCT, and Kumaraguru graduate strong electronics and VLSI students every year. Many of them go to Bengaluru because that is where the jobs are. We give them a serious VLSI engagement in their own city.

The precision-engineering ecosystem matters​

Coimbatore has Pricol, LMW, Roots, ELGI, and several hundred precision machining shops — companies that already supply parts to global manufacturing chains. That matters for two reasons. First, evaluation boards, test fixtures, and small enclosures get built locally on short turns. Second, the operational discipline of running a precision-engineering business — documentation, traceability, calibration, on-time delivery — is in the water here. Translating that into chip design is easier than building it from scratch.

Tamil Nadu is leaning in​

The Tamil Nadu Semiconductor Mission 2030 has earmarked five hundred crore for design, manufacturing, testing, and skilling. The Sulur and Palladam semiconductor parks are under development, and the state stacks an additional fifty per cent reimbursement on top of the central Design Linked Incentive for approved projects. None of these subsidies are wired to your bank account on day one — they are reimbursement-based, and you have to spend first to claim later — but they meaningfully change the math at the two-year mark when you can claim against your actual spending.

What this is not​

It is not a knock on Bengaluru. The MNCs and the bulk of Indian fabless talent are there for good reasons, and we partner with people in Bengaluru constantly. Most of our customers are likely to be there, too. It is just not where we need to spend our overheads.

Coimbatore is where we build the company. The customers are wherever the customers are.

When customers describe a new chip, the first question is almost always “what node?” — and the assumption is usually that smaller is better. It is not. Here is how we think about it.

What “mature” means​

A mature node is one where the foundry process has been in volume production for a decade or more — 180nm, 130nm, 65nm, and increasingly 40nm now fall into this bucket. The process design kits are stable, the IP libraries are complete, the analog characterisation is well understood, and the yield is predictable. Mask costs are a fraction of an advanced node, multi-project shuttle slots are easy to book, and the foundry will actually quote you for small wafer volumes.

Why we default here​

For ninety per cent of the chips we build — power management ICs, sensor front-ends, small mixed-signal SoCs, custom digital glue — mature nodes are simply the right answer.

• Cost. A full reticle mask set at 180nm runs in low single-digit crores. At 28nm it is six to ten times that. At 7nm it is twenty times. For a product that ships fifty thousand parts, the mask amortisation alone kills the business case at advanced nodes.
• Analog performance. Most analog circuits get worse, not better, as you shrink. Headroom collapses, matching degrades, and the foundry analog libraries on advanced nodes are aimed at digital-heavy SoCs. For a power-management or sensor part, mature is genuinely better.
• Yield. Mature processes have been characterised to death. Yield is predictable, defect densities are low, and the foundry test infrastructure is fully built out.
• Time to silicon. Multi-project shuttle slots at 180nm or 65nm are available every quarter. You can be in silicon in eight to twelve months. Advanced nodes have longer queues and more rigorous qualification gates.

When to go smaller​

There are a handful of cases where pushing past mature is the right answer:

• High-volume digital. If you are shipping millions of units of a digital-heavy SoC, the per-die savings from a denser node eventually pay back the mask cost. The crossover is usually around five million units.
• Power and performance constrained. If the product needs the device to run for years on a coin cell, or to clock above several hundred megahertz at acceptable power, you eventually run out of room at mature nodes.
• Existing IP commitment. If the customer already owns sub-100nm IP and wants to reuse it, the node choice is partially made.

For everyone else, mature nodes are not a compromise. They are the right tool.

What this means in practice​

We start every engagement by talking through node selection explicitly. If the part can be built at 180nm and the volume is under five million, that is where we will recommend it goes. If there is a real reason to push smaller, we will say so — and we will say so before the first line of RTL is written, because the node decision drives almost every other choice on the project.

A part that works at 65nm beats a part that almost works at 7nm. The boring choice is usually the right one.

A bug found in simulation costs an engineer an afternoon. The same bug found in silicon costs the project a respin — six months and a few crore. The arithmetic on verification is unforgiving, so we treat it that way.

What sign-off actually means​

There are two kinds of verification claims a design house can make at tape-out.

The first sounds like “we ran all our tests and they passed.” That tells you almost nothing. Tests pass when the testbench is wrong; tests pass when the stimulus does not exercise the bug; tests pass on the design with the bug in it. A passing test is necessary but nowhere near sufficient.

The second sounds like “we hit ninety-eight per cent functional coverage with no open holes, all assertions are passing under one hundred thousand random seeds, and the formal proofs on the safety-critical blocks closed.” That is sign-off.

The difference between the two is the difference between a chip that works and a chip that wastes a year.

How we get there​

For any non-trivial block we build a UVM testbench from day one of the RTL work. The same engineer does not write both — the RTL author and the verification author argue about the spec, which is exactly the conversation you want happening early.

The verification plan is a real document. It names every feature in the spec, maps it to a coverage point, and maps the coverage point to a test or family of tests. As the project progresses we measure progress against the coverage plan, not against test pass counts.

For corner cases that constrained-random will not reach efficiently, we layer assertions and selective formal proofs. Formal is not appropriate for entire SoCs, but for arbiters, FSMs, and protocol blocks it routinely catches bugs that simulation never would. We use it where it earns its license cost.

The boring bits that matter​

A few practical things that matter more than they sound:

• One regression dashboard. Every test, every seed, every revision is in one place. If you cannot answer “is the design getting better or worse this week?” in under ten seconds, you are flying blind.
• Pass rate is not coverage. A bench with broken tests will have one hundred per cent pass rate and zero coverage. Coverage tells you whether stimulus is hitting the design; pass rate tells you whether the design hits the bench's expectations.
• Triage is a job. Failures pile up faster than you can fix them on a real project. Someone has to triage daily and route bugs to RTL, testbench, or environment. Without that role, every regression becomes a wall of red.
• Coverage holes get a name. Every open coverage point at sign-off is either closed, waived with a written reason, or it blocks tape-out. There is no fourth option.

What we tell customers​

Before we tape out anything, we hand the customer the coverage report, the regression history, the assertion summary, and the waiver list. If a hole is waived, we say why. If a feature is going to silicon untested, we say so explicitly so the customer can decide whether they accept that risk.

We have never been thanked for catching a bug in silicon. The work is invisible when it is done well. That is the deal.