Choosing a VLSI design company comes down to seven checkable things: proven track record at your specific node, real verification discipline, DFT ownership from day one, physical design sign-off maturity, engagement model flexibility, a defensible security posture, and a clear communication cadence. Get these seven right during evaluation, and most of the risk in a chip program is addressed before a contract is even signed.
This isn’t a generic vendor-selection framework borrowed from software procurement. A wrong choice here doesn’t cost you a missed feature release — it costs a respun tape-out, and tape-out costs at any meaningful process node run from the high hundreds of thousands into tens of millions of dollars before engineering time is even counted. That asymmetry is why this decision deserves a structured evaluation, not a gut call based on a polished pitch deck.
This guide goes beyond the checklist itself: it covers the different types of VLSI design companies you’ll encounter, what to verify at each stage of the design flow specifically, how to actually structure an evaluation process from shortlist to contract, and the mistakes that most commonly derail this decision.
What this guide covers
Why this decision carries outsized risk
In most procurement decisions, a wrong vendor choice is recoverable — you switch providers, absorb a delay, move on. A VLSI design engagement doesn’t offer that same margin for error, because the cost of correcting a mistake doesn’t scale like a typical vendor swap. If a design issue isn’t caught until after tape-out, the fix usually isn’t a patch — it’s a respin, and a respin means paying for a new mask set and a new fabrication run on top of whatever was already spent.
The chart below shows why that matters so much: tape-out cost climbs steeply as process node advances, from roughly half a million dollars at a mature 180nm node to well over $100 million at 3nm. A partner who under-invests in verification or bolts DFT on late doesn’t just risk a schedule slip — at advanced nodes, they risk a mistake that costs more to fix than the entire original engagement.
This is also why evaluation depth should scale with node and design complexity. A straightforward mature-node design carries real but bounded risk; an advanced-node SoC program justifies a much more rigorous evaluation process, including the stage-by-stage due diligence covered later in this guide.
Types of VLSI design companies
Not every VLSI design company is built the same way, and matching the type of company to your program’s needs is itself part of the evaluation. Four broad categories show up repeatedly in the market:
| Type | Strengths | Watch for |
| Boutique specialist | Deep expertise in a narrow domain (e.g. RF, high-speed SerDes, a specific node) | May lack breadth for full-flow turnkey programs outside their specialty |
| Full-service / turnkey | End-to-end RTL-to-GDSII capability under one roof | Depth can vary by stage — verify each capability independently, not just the overall pitch |
| Offshore ODC-focused | Cost-efficient, scalable teams for sustained multi-project relationships | Time zone and communication cadence need explicit planning, not assumption |
| Captive / IDM-affiliated | Deep process and foundry-specific knowledge from in-house fabrication experience | May be less flexible on engagement model or less used to external client workflows |
None of these categories is inherently better — the right fit depends on whether your program needs narrow deep expertise, full-flow ownership, sustained team capacity, or foundry-specific insight. The seven-point checklist below applies regardless of which category you’re evaluating within.
The seven-point checklist
Each of the seven areas below maps to a specific point of failure seen repeatedly across VLSI programs — not a hypothetical concern, but a pattern. The graphic below is the checklist in full; the sections that follow unpack what to actually ask about each one, and why a vague answer should concern you.
1. Track record at your node and design type
General VLSI experience is not the same as proven competence at your specific node and design category. A team with a strong portfolio of mature-node automotive designs isn’t automatically qualified for a 5nm AI accelerator, and the reverse is equally true — the tooling, the physical effects that matter, and the sign-off bar all shift meaningfully between node generations.
Ask for reference designs at the same node, in a comparable design category, not just a client logo list. A company confident in its fit will be specific: which node, what class of design, what the outcome was. A company that responds with broad claims about “extensive VLSI experience” without node-specific detail hasn’t demonstrated fit — it’s demonstrated marketing.
It’s also worth asking how recently that track record was built. Node-specific expertise degrades if a team hasn’t worked at that node in several years; tooling, PDKs, and best practices shift enough that recency matters almost as much as the underlying experience itself.
2. Verification discipline and coverage reporting
Verification consumes 60 to 70 percent of a typical chip program’s engineering time, so how a company runs verification says more about program risk than almost anything else you’ll evaluate. Ask specifically how they define and report coverage closure — functional coverage, not just simulation hours logged — and whether formal verification supplements simulation for the properties that are hardest to catch through directed testing.
A team with real verification discipline will be able to walk you through their coverage model: what’s tracked, how gaps are triaged, and how they know when verification is actually done rather than just out of schedule. A team that answers with test count or headcount instead of coverage methodology is telling you, indirectly, that coverage isn’t the metric they manage to.
It’s reasonable to ask for a redacted or representative coverage report from a past project. This is one of the few areas where you can ask for something close to direct evidence rather than a description.
3. DFT ownership from day one
Ask when DFT planning starts relative to RTL. If the honest answer is “after RTL is functionally complete,” that’s a structural schedule risk, not a minor process detail. Scan insertion and test architecture decisions interact directly with RTL structure — planning them together from day one is what separates a team that treats test as a co-design constraint from one that treats it as a checklist item.
Beyond timing, ask what DFT techniques are standard practice: scan insertion and ATPG are baseline, but ask about memory and logic BIST strategy, JTAG/IEEE 1500 implementation, and test compression approach. A team that can discuss test cost per unit at volume, not just “we do DFT,” understands that DFT decisions have downstream manufacturing economics, not just functional ones.
4. Physical design and sign-off maturity
A mature physical design team delivers layouts that pass DRC, LVS, and timing sign-off without repeated rounds of ECO fixes. Ask how many sign-off iterations their typical project requires, and ask to see evidence of timing closure across full PVT corner coverage, not just typical-case results.
It’s also worth asking how the team handles the handoff from front-end: what they need from RTL and verification teams to avoid late-stage surprises, and how often, in their experience, physical design findings send a design back to RTL. A team that says “never” is either unusually good or not being candid — some iteration is normal; what matters is how contained and well-managed it is.
5. Engagement model flexibility
Strong partners offer turnkey, ODC (offshore development center), time-and-material, or KPI-based delivery based on what actually fits your program — not a single model they push on every client regardless of fit. If a company can only describe one way of working, that’s worth probing further; program needs vary too much for a true one-size-fits-all approach to hold up.
KPI-based and milestone-based models are worth asking about specifically, because they tell you something about how confident a company is in its own delivery discipline: a team willing to tie payment to coverage closure or timing closure milestones is signaling that those milestones are things they reliably hit.
6. Security posture and NDA practices
NDAs should be standard practice, offered without friction, before any meaningful technical discussion. Beyond that baseline, ask how the company handles client-specific security requirements — including air-gapped environments for particularly sensitive designs. A company that treats this as a special request rather than a standard capability may not be equipped for programs where IP protection is non-negotiable.
For programs with heightened sensitivity, ask about physical access controls, code repository practices, and whether engineers working on your program are dedicated or shared across multiple clients concurrently. The answers here are as much about operational maturity as about security itself.
7. Communication cadence and escalation path
Ask what the standard reporting rhythm looks like, and — more importantly — what happens when something goes off track. You want a defined escalation path you hear about before it becomes a crisis, not a status update that arrives only once a deadline has already slipped.
A useful diagnostic question: ask for an example of a past project that hit a real problem, and how it was communicated and resolved. A team with nothing to describe has either had unusually smooth history or isn’t being fully candid; a team that can walk through a specific example, including what went wrong and how it was caught, is demonstrating exactly the transparency you’re evaluating for.
Stage-by-stage technical due diligence
The seven-point checklist covers the company-level evaluation. For programs where the stakes justify it — advanced nodes, novel design categories, larger engagements — it’s worth going one level deeper and asking stage-specific questions that map directly to the RTL-to-GDSII flow.
Flow stage | What to verify | Question to ask |
Architecture & RTL | CDC/RDC and lint sign-off discipline | What’s your standard process for CDC and RDC closure before a block is considered RTL-complete? |
Verification | Coverage model and formal methods use | Walk me through how you define functional coverage closure on a typical project. |
DFT | Timing of DFT planning relative to RTL | At what point does DFT architecture get defined, and who owns that decision? |
Physical design | Sign-off iteration count and PVT coverage | How many ECO cycles does a typical project require before clean sign-off? |
Post-silicon | Bring-up planning and characterization rigor | How is the bring-up plan structured, and how do you handle a silicon-simulation mismatch? |
You don’t need to run all five of these in every evaluation — but for a program where the cost of a wrong choice is high, this level of specificity separates a company that can talk about the VLSI design flow from one that can demonstrate it actually runs their programs.
How to structure your evaluation process
Most evaluation processes fail not because the checklist was wrong, but because the process itself was too shallow to surface honest answers. A structured four-step process gets meaningfully better signal than a single round of pitch meetings.
The VLSI design partner evaluation process
1. Shortlist
3–5 companies from track record and node fit
2. Technical deep dive
Coverage methodology, DFT timing, sign-off history
3. Reference & pilot
Reference calls plus a small scoped trial task
4. Decision & contract
Engagement model matched to program needs
Start with a shortlist of three to five companies based on track record and node fit — enough to compare meaningfully without the process itself becoming a bottleneck. From there, run a technical deep dive using the stage-by-stage questions above, focused on companies’ own coverage, DFT, and sign-off practices rather than generic capability descriptions.
The step most often skipped is the reference and pilot stage: actual calls with past clients, ideally at a similar node and design category, plus — where the engagement size justifies it — a small, well-scoped pilot task before committing to the full program. A pilot doesn’t need to be large to be useful; even a bounded verification or DFT-planning exercise reveals more about working style and technical discipline than another round of proposals will.
Only after reference and pilot signal is validated should engagement model and contract terms be finalized — negotiating commercial terms before technical fit is confirmed tends to anchor the conversation on price before the more consequential question of capability has been properly answered.
Common mistakes buyers make
- Weighting a polished pitch deck or a long client logo list over specific, verifiable answers about verification methodology and DFT timing. Logos and decks are marketing; coverage reports and sign-off track records are evidence.
- Treating price as the primary differentiator before technical fit is confirmed. The cost spread between design companies is almost always smaller than the cost of a respin caused by weak verification or late DFT planning.
- Skipping reference calls, or only speaking to references the company hand-picked without asking pointed questions about what went wrong on those past projects, not just what went right.
- Assuming a company’s experience at one node transfers cleanly to another, without checking recency or node-specific tooling familiarity.
- Finalizing an engagement model before technical evaluation is complete, which anchors the relationship on commercial terms rather than capability fit.
Red flags vs. green flags at a glance
Criterion | Red flag | Green flag |
Track record | Portfolio heavy on unrelated nodes or design types | Reference designs at your specific node and category |
Verification | Reports test count or hours, not coverage closure | Defines and reports functional coverage explicitly |
DFT | DFT discussed only after RTL is “done” | DFT planning starts alongside RTL from day one |
Physical design | Vague on sign-off iteration count | Clear DRC/LVS/timing sign-off track record |
Engagement model | Pushes one model regardless of program fit | Offers turnkey, ODC, T&M, or KPI-based, matched to need |
Security | NDA treated as a special request | NDA and security controls offered as standard practice |
Communication | Updates only when something has already slipped | Defined cadence with a proactive escalation path |
Questions worth asking before you sign
- Can you share a reference design at our exact process node and design category?
- How do you define and measure functional coverage closure, and can we see a sample coverage report?
- At what point in the flow does DFT planning begin relative to RTL freeze?
- What’s your typical number of physical sign-off iterations before a clean DRC/LVS pass?
- Which engagement models do you offer, and how do you decide which fits a given program?
- What security controls are available for IP protection, including air-gapped work if needed?
- What does your standard reporting cadence look like, and what triggers an escalation?
- Can we speak with two or three past clients directly, including at least one project that hit a real issue?
A note on evaluating claims you can’t independently verify
Some of what a VLSI design company tells you during evaluation is inherently hard to verify from the outside — coverage methodology, internal sign-off discipline, security practices. The most reliable signal isn’t a single confident answer to any one question; it’s whether the answers across all seven areas, and across the stage-by-stage questions, are specific and consistent with each other, rather than generic reassurance repeated with different words. A team that can’t get specific about how they measure their own verification coverage is unlikely to be rigorous about yours.
Putting it together: a final gut check
By the time you’ve worked through the seven-point checklist, the company-type comparison, and — for higher-stakes programs — the stage-by-stage due diligence, you’ll have far more signal than a typical procurement process generates. The final gut check is simple: do the answers you received hold together as one coherent picture of how this company actually runs a program, or do they read as separate, disconnected reassurances stitched together for the pitch?
A company worth signing should be able to connect its own dots — explain how its verification coverage practices inform its DFT planning timeline, how its physical design sign-off history shapes the engagement models it’s willing to offer, and how its communication cadence reflects lessons from a specific past project, not a generic service commitment. That coherence is difficult to fake convincingly across a full evaluation process, which is exactly why the process matters more than any single question on this list.
This checklist reflects how PQ Angels’ VLSI design services are structured — turnkey or stage-specific, with DFT and verification treated as day-one disciplines rather than downstream add-ons.
Frequently asked questions
How many VLSI design companies should I shortlist before deciding?
Three to five is typically enough to compare meaningfully without the evaluation process itself becoming a bottleneck. Fewer than that risks missing a better fit; significantly more tends to slow decision-making without improving the outcome.
Should I prioritize cost or technical fit when choosing a VLSI design partner?
Technical fit first. The cost difference between design companies is almost always smaller than the cost of a respin caused by weak verification or late DFT planning — the checklist above is designed to screen for exactly that risk before price becomes the deciding factor.
Is it a red flag if a VLSI design company only offers one engagement model?
Not automatically, but it’s worth probing why. Some companies specialize deliberately in one model and do it well. The concern is when a single model is presented as the only option regardless of your program’s actual needs — that’s a sign of a sales-driven pitch rather than a program-fit conversation.
What's the biggest mistake companies make when evaluating a VLSI design partner?
Weighting a polished pitch deck or a long client logo list over specific, verifiable answers about verification methodology and DFT timing. Logos and decks are marketing; coverage reports and sign-off track records are evidence.
Do I need to sign an NDA before a VLSI design company will discuss technical details?
Yes, and you should expect to. A company willing to discuss meaningful technical specifics before an NDA is in place is arguably a bigger concern than one that insists on it early — it suggests IP protection isn’t treated seriously in either direction.
Should I run a pilot project before committing to a full VLSI engagement?
For larger or higher-stakes programs, yes. A small, well-scoped pilot — even limited to verification planning or DFT architecture — reveals more about a team’s working style and technical discipline than additional rounds of proposals or reference calls alone.
What's the difference between a boutique VLSI specialist and a full-service design company?
A boutique specialist typically offers deep expertise in a narrow domain, such as a specific process node or a technology like high-speed SerDes, but may not cover the full RTL-to-GDSII flow. A full-service or turnkey company offers end-to-end capability, but depth can vary by stage — it’s worth verifying each stage independently rather than assuming uniform strength across the whole flow.
