When you're working for a fabless semiconductor company, nothing can quite match the excitement that comes with production ramp-up once silicon works and orders are waiting. Although it may result in added pressure on the test development and product engineering team, this can be managed if you follow the right path. We've put together four tips to help your team when that clock starts ticking to deliver volume and quality:
1) Make sure you have that gage R&R done
With volume comes manufacturing complexity. The chips won’t all be tested in the same set-up so make sure you have your guardbands properly set to take the variations into account. Automated tools, now applied to repeatability datalogs done on each set-up, will quickly help sort this out for you. In our opinion, this shouldn't take days anymore. The ability to share Gage reports back and forth in real-time with your test subcon is now possible. Having this step done properly will make test run efficiently and help reduce PPM.
2) Make sure your test facility follows an agreed re-screen plan
You need to know what is happening in test and then help the test subcon test your product efficiently. Having access to all the raw and rescreen data is critical. So make sure that you and your test subcon agrees on a way to mark the rescreen datalogs appropriately and follows any rescreen plan diligently.
3) Make sure you have a modern & cost-effective yield management system in place
The basic requirements here have moved on. Today, every company should be able to have its datalogs processed automatically into a YMS database hosted externally or internally. The database should be viewable securely over the web even by the test subcon for the chips they test for you. The YMS system should also allow the user to set up scheduled reports, set appropriate alerts and SPC limits. Further, the user should be able to interact fast with high volume data without having to download it first. Time is of the essence and modern cloud systems save time.
4) Make sure you have a responsive foundry willing to learn from the back-end performance
A modern YMS system links the WAT data with the test and sort data automatically. Ideally, you can share access to the YMS with your foundry and let them do the correlations and help reduce parametric sensitivities. By providing such accessibility to your fab foundry you should be able to sleep better at night especially when the ramp-up begins.
For other tips, check out our other blogs or if you would like to talk to someone, you can find contact details here.
Frequently asked questions
Gage R&R measures how repeatable and reproducible your test setup is. At volume, chips are tested across multiple setups, so guardbands have to account for that variation. Automated tools applied to repeatability datalogs on each setup return the answer in hours, not days, and gage reports can be shared with your test subcontractor in real time.
A re-screen plan defines how retested units are handled and marked. You and your test subcontractor need to agree on how rescreen datalogs are flagged, and the plan has to be followed consistently. Without that, you can't separate raw from rescreen data, and your yield numbers stop meaning anything.
Process datalogs automatically into a YMS database, hosted internally or externally. Be viewable securely over the web, including by your test subcontractor for the chips they test for you. Support scheduled reports, alerts, and SPC limits. And let engineers interact with high-volume data quickly without downloading it first.
Yes, scoped appropriately. Your subcontractor needs visibility into the products they test for you. Your foundry, given access, can run correlations against back-end results and help reduce parametric sensitivities, which is difficult for them to do blind.
A modern YMS links WAT data to test and sort data automatically. That link is what lets you trace a yield or parametric issue at test back to fab process variation rather than chasing it at the back end.
Setup-to-setup variation that guardbands don't account for, rescreen data that isn't marked consistently, and a reporting cycle too slow to catch a drift before it becomes scrap. All three are visible early if the data is centralized and monitored.








