From Chip Idea to Delivered ASIC: A Shenzhen Ordering Roadmap

If I wanted to make a little battery-powered leak sensor for under a sink, why would I ever order a chip designed just for that? Wouldn't I buy the chips already on a shelf?

You probably would. An ASIC is a chip designed for a particular job, instead of choosing a general-purpose chip and making it do that job. For a first leak sensor, buying existing parts is usually the sensible move.

What makes it different from just programming a chip?

With a regular microcontroller, you buy a finished chip and put instructions on it. An ASIC's circuit itself is designed around your task before it's manufactured. It might still run some code, but you can't treat a change to the underlying circuit as a software update.

So if my sensor has two metal prongs, is the ASIC the thing that notices water between them?

It could be. Picture two contacts touching a puddle. The circuit puts a small signal on them, checks whether current can pass, and decides whether to raise an alert. Off-the-shelf parts can do all of that. Custom silicon becomes interesting if you have a good reason those parts aren't meeting a requirement.

Such as fitting under a very small sink?

Size might be one reason.

But if I shrink the chip, the battery and the prongs don't shrink with it.

That's the catch. The package around the chip still takes space, and so do the battery, contacts, and whatever sends the alert. Say the existing electronics keep draining the battery while the floor stays dry. A custom circuit might watch the contacts using less power. But you'd want measurements showing which part is draining it, not just the hope that a custom chip sounds efficient.

Wait, wouldn't the radio be the part using all the power?

It might be, especially when transmitting. A leak sensor might spend most of its life waiting, though, so the energy it uses while idle matters too. If the radio is the main drain, redesigning the contact-reading circuit won't fix much. First you measure the device in the states it actually spends time in.

So 'my battery should last longer' isn't enough of a specification?

Not on its own. You'd need a target and a way to test it.

And do I have to decide exactly when the prongs count as wet?

Yes, including messy cases. Tap water, a slightly damp floor, and dirty contacts won't behave identically. You'd decide how fast the sensor should react, how often a false alarm is tolerable, and what kind of battery it's running on. The point isn't that you can predict every kitchen. It's that a chip designer needs to know what counts as working before fixing the circuit in silicon.

I was assuming we'd make the ASIC, then adjust it if the alarms got annoying.

You could adjust settings if the design includes that ability. You can't assume the physical circuit can be patched later. That's one reason to build early versions with readily available parts: you can try the probes, the alert behavior, and battery life before paying to manufacture a custom circuit. You may find the issue is corrosion on the contacts, not the chip at all.

Where does an FPGA fit? I keep seeing that word near ASIC.

An FPGA is a chip whose digital circuits you can reconfigure after it's made. It's handy for trying out certain designs, or when flexibility matters. For this little battery sensor, I'd usually start with a microcontroller instead: it's easy to program and often a better fit for simple control. Neither is automatically a step you must take before an ASIC.

So would a huge order be the reason to switch, even if the first version works?

Possibly. Custom chip design and manufacturing setup have large up-front costs, while a simpler chip might make each device cheaper at scale. But you have to count engineering, testing, and the risk of a redesign against any savings. A small order makes that up-front cost much harder to recover. Until you've got a credible production volume and a stable design, the cheap-per-chip story can be misleading.

Then before asking anyone to make silicon, I'd need to know whether the current sensor actually misses a target, not just that a custom chip sounds tidier. If it does, what do I hand a designer?

I'd hand over what the sensor has to accomplish, with numbers wherever you can defend them. For this one: the battery range, what counts as a leak at the contacts, how quickly it must alert, and how much current it may draw while waiting. Also what stays outside the chip, such as the radio. A design team can help turn fuzzy requirements into testable ones; you don't have to draw the transistors.

So the designer isn't just given my sketch of two prongs?

No. The prongs are only the input.

What would they decide first, then?

The architecture: which jobs go where. Suppose we keep the radio on an existing chip. Our ASIC could gently probe the contacts, decide whether the change persists long enough to count as wet, then wake the rest of the device. That separates a tiny always-on circuit from a radio that only wakes when needed. It's a proposed design, not a promise it'll save power; we'd compare it with measured alternatives.

Would the chip do the wet-or-dry decision itself?

It could, or it could pass a reading to a microcontroller. If you want to change the alarm threshold later, the designer must deliberately leave a setting you can adjust.

But they'd need to know how much adjustment to leave?

Yes. If you only need to move the threshold a little, that's different from needing to change how the sensor reads the contacts. Imagine some water leaves a thin film that makes the circuit see an in-between reading. A setting might change when it calls that wet. It can't make corroded contacts behave like clean ones, and it can't add a missing kind of measurement after manufacture.

Okay. Who actually makes that proposed circuit?

Usually an ASIC design team, whether that's engineers in your company or a design firm you hire. They turn the plan into working circuit designs: some parts deal with the changing signal from the contacts, others make the yes-or-no decisions. They also decide how to check the finished chips. The foundry isn't normally figuring out what your kitchen sensor should do.

When does the foundry enter the picture?

Before layout, not just when you're ready to order. The team chooses a manufacturing process the foundry offers, meaning a particular way it can build transistors and wires. The foundry supplies design rules and models for that process. They tell designers, for instance, which shapes can be printed and how their circuits are likely to behave. A layout for one process isn't a universal file you can casually send to another factory.

So picking a factory locks us in?

It commits this version of the design to that process. Switching later can mean substantial redesign, though it depends on what changes. Before drawing the final chip, designers simulate the sensor circuit against the requirements, including different battery levels and expected manufacturing variation. They can check the decision logic too. Simulations are useful evidence, not proof of how every wet kitchen floor will behave.

I'm still picturing a diagram. Is that the layout?

The diagram says what connects to what. Layout says where things physically sit on the chip and how the tiny wires run between them. That matters here: a poorly placed signal path might pick up interference or add enough electrical loading to change a faint reading from the contacts. Designers check the layout's effects, not just the ideal diagram, before they release it.

And who catches a wire going to the wrong spot?

The design team runs automated checks. One kind asks whether the shapes obey that process's rules; another compares the connections in the layout with the intended circuit. They also rerun behavior checks using the layout's estimated electrical effects. Those can catch a wrong connection or an unexpectedly slow path. They don't replace testing a real sensor with actual contacts and water.

When those checks pass, is the chip finished?

The design may be ready for a manufacturing handoff, often called tapeout, if the team signs off on it. They send the foundry the final layout data in a format it accepts, along with agreed manufacturing instructions. The handoff also has to account for how the chips will be tested and packaged; those choices can't all wait until silicon arrives. The foundry uses the layout to make the patterns for fabrication. Passing checks doesn't mean you've received working chips yet.

Then if I'm coordinating through Shenzhen, how do I tell who's actually making the silicon?

A Shenzhen address won't tell you where the silicon is fabricated. You might contract with a design firm or sourcing partner there, while a foundry at another site makes the wafers. Ask that partner to identify the foundry, its manufacturing site, and the exact process your layout targets. If they can't disclose the site directly, agree on a way to verify it before committing. A sales page saying 'made in Shenzhen' isn't enough.

What's a wafer in this case?

The round slice of silicon on which many copies of your chip are built. The individual chips get separated later.

So our leak circuit isn't shipped as a wafer to my kitchen?

No, not for your finished sensor. The foundry makes wafers; someone checks the circuits on them, and usable pieces are cut out. A packaging company puts each piece in a protective body with connections for your board. That company could be in Shenzhen even if the wafer wasn't made there. The order should say who handles each step, rather than naming one company as 'the factory.'

And I'd order that whole chain from the Shenzhen partner?

You could, if the contract makes the handoffs and responsibilities clear.

What does that mean before the first batch?

For our sensor, I'd start with a small prototype run, if the chosen process offers one. Sometimes your design shares a manufacturing run with others. That can lower the up-front cost, but limits your choices and ties you to a schedule. A run devoted to your chip costs more. Either way, agree on the design version, package, expected delivery form, and who approves a change before placing an order.

Wait, sharing a run means other people see my circuit?

Not necessarily. Sharing manufacturing space doesn't give other customers your design files. But the design partner and foundry need controlled access, so confidentiality and ownership terms matter. Ask who may submit the final layout, who owns the design data, and what records you can obtain later. That matters if there's a mistake or you need another supplier.

I'm thinking the prototype comes back and we just try water on it.

We should try water, but first we need to know whether the chip works. Electrical tests can check its power draw and outputs with controlled inputs. Then you put packaged chips on sensor boards and try the real contacts, dampness, battery levels, and radio wake-up. If an alarm is late, you'll need to tell whether the chip, the contacts, or the board caused it.

Who decides which tests the packaging company does?

The design team specifies how the chip is checked; the manufacturing and test partners agree on equipment, pass limits, and reporting. The packaging company might not do all those tests itself. The important bit is that 'good chips' means something measurable. You don't want the first surprise to be that the packaged chip can't be reached by the planned test equipment.

Does a passing prototype mean I can order thousands?

It gives you a reason to consider it, not a guarantee. You'd review test results, failures, and how the complete sensor behaved before authorizing a production run. The foundry makes the wafers; the chips still have to get through assembly and testing. You'd agree on whether you're buying wafers, packaged units, or units that have passed specified tests.

I'd want the passed ones. Are they all from the same place?

They may pass through different places. Wafers could go from the foundry to one company for packaging and another for final testing, then the finished parts to your board assembler in Shenzhen. Ask for the route, who handles shipping at each transfer, and records tying delivered parts to manufacturing batches. If a batch of sensors falsely reports leaks, those records help show whether the trouble follows the chips or the boards.

What if the partner just says it'll take care of it?

Then I'd pin down that promise: who places the order with the foundry, who receives wafers, what tests count as acceptance, and what happens to rejected parts. A partner can coordinate all this without owning a fabrication plant. But without agreed handoff records, you'll have trouble finding who can fix a delayed or failing batch.

So before I ask for chips for 5,000 sensors, do I ask for a quote on packaged, tested chips rather than just wafers?

Yes. Ask for 5,000 packaged, tested chips delivered to your board assembler, if that's what you intend to buy. A bare-wafer quote leaves you paying separately for cutting, packaging, and testing, plus arranging those transfers. Specify that the number means units that passed your agreed tests, not simply pieces cut from silicon.

So I don't just write, “5,000 leak chips”?

Not if you want comparable quotes.

What do I put in instead?

For this sensor, tell them you're buying the revision laid out for the chosen process, in the package that fits your board. Say the chip must stay below the agreed waiting-current limit and wake the radio correctly across the battery range. Attach the proposed production test and pass limits. Then give the delivery point, schedule, and quantity. Otherwise two quotes could cover very different products.

How can they promise 5,000 if some fail?

They can't promise a particular yield in advance without terms for what happens if it comes up short. Ask whether the price is per good, packaged unit, how many wafers they plan to start to target that quantity, and who pays if they need another run. Have them separate one-time setup charges from the unit price. A bargain per chip can hide an expensive start.

Would I send that request to a Shenzhen company?

Possibly a design or sourcing partner there, but ask who will fabricate the wafers and at which site. The layout was made for a particular foundry process; a quote from a different one isn't an interchangeable offer. If the partner can't name the site openly, work out a way to verify it under confidentiality before you commit.

Why recheck the process if the layout's already finished?

Because the wrong process means the quoted run can't use that layout.

Do I attach the layout to every quote request?

No. Start with enough information to quote responsibly, shared under appropriate confidentiality: the selected process, approximate chip size, package drawing, design revision, test needs, and quantity. Before an order is placed, though, name who can submit the final layout to the foundry and who signs off on that exact version. A change to the circuit isn't a quiet substitution. It may need new checks and a new handoff.

What happens after the foundry has that version?

Pin down the route in the order. The foundry makes wafers; an agreed partner checks chips on the wafer, the usable ones get packaged, and a test provider checks the finished parts. Those jobs can be split among companies. Ask for a record linking each delivery batch to its wafer lot and test results, so a failure on a board isn't just a mystery box from Shenzhen.

And do I see samples before committing to all 5,000?

That's the gate I'd put in the agreement. Ask for samples from the prototype or preproduction run, in the intended package, with the same design revision and a test history you can inspect. Confirm what's different from the eventual production flow; a shared prototype wafer, for example, isn't itself evidence that a dedicated run will have the same yield. Hand-selected samples can demonstrate behavior, but not how many saleable chips the full run will produce.

What would I try with the samples?

First, check their reported electrical measurements against the pass limits, especially waiting current and wake-up behavior. Then put them on your actual sensor board with the planned battery and radio. Try dry contacts, a puddle, and that annoying slightly damp surface we talked about; test near the battery limits too. If you adjust the wet threshold, check that the setting actually changes the result as designed. Write down both missed leaks and false alarms.

If one alerts late on the damp surface, do I reject everything?

Not automatically. Was that surface meant to count as a leak under the requirement? If yes, work out whether the contacts, board, or chip missed it, and don't release the production order until the cause is understood. If the requirement never covered it, decide whether it should, then revisit the test and perhaps the design. A passing chip-level test can't settle a sensor-level disagreement for you.

I'd run the packaged samples on our actual board before I release 5,000, and keep track of which version I tested.