Many first-time ASIC conversations fail before they begin.
Not because the idea is wrong, but because expectations are misaligned. Teams approach vendors too early with vague goals, or too late after internal assumptions have already hardened into unrealistic plans.
The result is frustration on both sides: slow quotes, wide cost ranges, missed schedules, and a feeling that ASIC is “harder than it should be.”
This article provides a practical checklist of what you need before talking to ASIC vendors for the first time. You do not need perfect answers, but you do need clarity in the right areas.
Vendors will always ask the same question first, even if they phrase it differently: “Why ASIC?”
This is not a philosophical question. It drives architecture, node choice, verification scope, and cost.
Common valid drivers include:
If the answer is “because FPGA is expensive” without context, the discussion will stall. Be clear about what problem ASIC is meant to solve.
You do not need exact forecasts, but you do need a credible range.
Volume affects almost every decision: node, package, test strategy, NRE amortization, and risk tolerance. Vendors do not expect certainty, but they do expect honesty.
Helpful framing looks like this:
A rough but honest range is far more useful than a single optimistic number.
Specification maturity is one of the most important and least discussed variables.
Vendors can work with incomplete specs. What they cannot work with is uncertainty disguised as certainty.
Before engaging, ask yourself:
Low maturity does not mean “don’t talk to vendors.” It means the conversation should focus on feasibility and de-risking, not fixed pricing.
Every ASIC project has constraints. The mistake is listing too many without prioritization.
The most important constraints usually include:
Vendors need to know which constraints are negotiable and which are not. Without that, they will assume worst-case scenarios.
You do not need a budget line item approved, but you do need alignment on tolerance.
If the organization expects a full custom ASIC for a minimal NRE, the conversation will break down quickly.
A more productive approach is:
This allows vendors to propose trade-offs rather than reject the project outright.
ASIC projects stall when ownership is unclear.
Vendors need to know:
If every decision requires consensus across multiple teams without a clear owner, timelines stretch and confidence drops.
This is not a technical issue, but it is one of the most common causes of failed engagements.
Experienced vendors expect risk. What they need is visibility.
It is always better to say “we are unsure about X” than to hide uncertainty and let it surface later during integration or verification.
Common early risks include:
Surfacing these early builds trust and leads to better proposals.
It is equally important to know what you do not need before the first conversation.
You do not need:
Those come later. Early conversations are about direction and feasibility, not commitment.
If this checklist feels manageable, you are likely ready for a serious ASIC discussion. If several items feel unclear, that does not mean ASIC is wrong. It means the next step should be clarification, not quotation.
Before reaching out to vendors, it helps to answer one foundational question: does ASIC make sense for this product now, later, or not at all?
Run the 2-minute ASIC or Not? Decision Wizard to get a clear, non-sales recommendation and understand what gaps to close before engaging vendors.
👉 /asic-or-not
