SemiWiki.com - Podcast EP353: What Real-Time Visibility Is and Why it Matters with yieldHUB’s John O’Donnell

Episode Date: July 3, 2026

Daniel is joined by John O’Donnell, Founder and CEO of yieldHUB, a pioneering leader in advanced data analytics for the semiconductor industry. Since establishing the company in 2005 he has transformed it from a two-person startup into a trusted multinational partner that empowers some of the world’s leading semiconductor … Read More

Hello, my name is Daniel Nenny, founder of SemaiWiki, the Open Forum for Semiconductor Professionals. Welcome to the Semiconductor Insiders podcast series. My guest today is John O'Donnell, founder and CEO of Yield Hub, a pioneering leader in advanced data analytics for the semiconductor industry. Since establishing the company in 2005, he has transformed it from a two-person startup into a trusted multinational partner that empowers some of the world's leading semiconductor companies to improve yield, reduce costs, boost engineering, efficiency and enhanced quality. Welcome to the podcast, John. Glad to be here, Dan. Thank you for the invite. Yeah, I got to tell you, it's been a pleasure working with Yield Hub, and you have some amazing things coming up. And more recently, you've been talking about the need for real-time visibility. Let me ask, when did you first realize the industry needed real-time visibility?

And maybe you can tell us a little bit more what real-time visibility is. Well, first of all, I've walked around enough test and probe floors in my time to realize that there's a lot going on that is not visible just using historical analysis. By real time, I mean, if you have, say, dozens of testers or probers, do you know, does a system know somewhere or does a person know what the levels of binning and parametric behavior is happening right now? It's not about. been able to analyze something in on it going on a tester and looking at a way from that this is about the behavior right now on the test floor and how it compares with what it should be as well as what it has been doing so it's the live awareness by either a system or people managing the test

floor of what is going on right now the idle times that are happening the various behaviors of of bins, of retesting, of parametric intersite behavior, all that stuff. Do you know what's going on now? So I have known this for many years that there's a huge amount of information. It's like a gold mine in there, if only people took advantage of it. Okay, that makes sense. So is it used in Waifer Pro 2 or just final test? In one word, both.

Okay, and what types of issues can real-time monitoring detect that might otherwise go unnoticed? list? Sure. Everything from unexpected yield loss, say a quarter way through a wafer, which if not detected would waste tester time because maybe the fixtures need to be fixed, etc. by a technician. To idle time, I have passed, in my time, I'm sure any listeners who are familiar with test floors will be aware that testers aren't running all the time. To be able to capture when idle time happens, are there patterns involved in when idle time happens? All this is available and is possible to, first of all, detect, but also analyze if you have a real-time system. Often lots are retested, certain bins are retested.

What if the, because of real time, the tester itself knew that there was no point in retesting certain bins because of the success rate of retest is very low. So if you have, there's two aspects. One is the actual generation of real-time information and also the second part of it is using that in real-time, using this information in real-time to make a decision. So it's the real-time monitoring plus you add then using that information while the testing is happening. Because what can happen is if you do not take advantage of that information. If that information from real time is not available, often the decision is, do we need to retest this lot? Yeah, because certain retest rates are certain bins need to be retested, maybe not on information that would have been gained from having

the real-time intelligence on the tester. Interesting. So how difficult is this to implement? Well, there's two aspects. One is to develop. The solution has taken a few years, to actually implement real time on a test floor in a big facility would take a few weeks and but the great thing is that the insights happen within days so you're talking about years to develop the whole thing implementation for a customer in a few weeks and insights then within a few days when you say a few days what are you talking about how quickly can users actually see the results Once it's sentimented, you will start seeing results real time. You will start seeing the idle times.

You'll start seeing the time it takes between lots, the shift change over time that might be affecting things. All these are available straight away, like within, you know, within probably 24 hours of having it on a test floor. This will highlight potential KPIs then that can be automatically generated from the data. So when operations managers look at the data, they'll say, oh, there is something we can monitor here. We can generate some information from this data, for example, KPIs for retest success rate or something, or maybe idle time, and monitor those KPIs. And these then will cause operational changes. and over time, real results have improved OEE, which is effectively tester utilization, these things will be seen pretty quickly after the KPI are implemented,

and these will be implementable across shifts. So, for example, a KPI about maybe the average number of sites that you're testing each lot on, that kind of thing. That's so powerful. This information will transform how. a test floor or probe floor is managed. That's exciting. What if you have different types of testers or even different manufacturers' testers?

How does that come into play? Yeah. Our solution called Yieldtub Live, we don't really care about the tester manufacturer as such, the type of tester, believe it or not. We really need to know two things. One is what the operating system is running on the tester. For example, it could be Windows 10 or something or it could be Linux or Unix. It could be Windows XP or whatever.

And then the second thing we need to know is what the data format coming out of the tester is. So as a company, we have like about a thousand different parsers written over the years. So very likely we can parse that data fairly quickly, get that route up and running. Sometimes only bin data has been generated, not just parametric data. But that's okay. But also we can provide parametric real time. In other words, say, for example, to detect differences between the sites, that are tested on a tester in parallel testing and for parametric things like leakage or

linearity or something like that and these are really interesting insights into maybe testing issues and if those issues are solved if you can make all of your test sites behave the same or very similarly statistically then your yield is automatically going to rise okay so we again we don't care about the tester manufacturer as much as we care about the operating system that that really enables this. Great. So does Yield Hub Live affect test time? Zero effect in test time.

I met a company recently who were having their own efforts in implementing real time. They were having difficulty because they were having to add hardware per tester, et cetera. There's no need. For hardware, there's no addition in test time. This is a seamless implementation of real time and it's hard to believe but we are steeped in this for many years this whole the

knowledge base required to develop such a system great what if you have multi-site testing does that add complexity no in fact this is we it's it's better still if you've multi-you can get more out of a system like this if it's multi-site because you will be able to refine your test capability across sites and as as I mentioned earlier if you make the sites behave similarly, statistically, then your yield is going to go up. So we monitor parametric bins, yields down to the site level. Can it help with the concept of feed forward? Maybe you can talk a little bit about what feed forward is as well. Well, feed forward from our experiences when you can get information from a previous manufacturing step as part of making decisions with the current stage

of your test flow. For example, using AI for prediction, for example, you might be able to predict that from what data that this wafer is supposed to behave really well, that the yield should be very high. And that information can be used then by the real-time system to detect, well, actually, the yield is pretty low on this wafer. We should stop it because it's very likely to be a test issue, right? So the feed-forward information that this is supposed to be a really good wafer would allow you to, actually detect test issues very early for when you're actually probing the wafer. And similarly, the feed forward from wafer start to final test, it might have detected that certain parameters are a lot better than, and, you know, could be automotive quality, for example,

could show automotive quality, and then in final test, maybe there is an issue. Again, if that, if, when you're starting to test a final test, a lot, or test lot in final test, and you know that it's supposed to behave in a certain manner because of the probe results, for example, or the watt data, then that gives you intelligence. That gives it effectively the tester intelligence to do something different. That might be to alert an operator or technician, or it might be to put the lot and hold because things are happening that are unexpected,

that kind of thing. So the fact that the tester effectively is now intelligent because it's using real-time information, it can integrate information from feed forward from say the previous manufacturing step and even have a more intelligent decision to make and that will help the operations of testing great explanation thank you so john you mentioned AI so i have to ask do you see AI being integrated into such real-time systems absolutely we already implement AI to reduce test time in particular retest test time for example but there's

huge opportunity here for integrating AI. You know, there's low-hanging fruit here in this whole real-time realm. So just big picture, you know, what's the future of real-time? I think the future of real-time is the fact real-time should, in my opinion, be standard practice in any factory trying to scale efficiently in probing or testing semiconductors. So the future should be, this should be standard. If I was responsible for a facility which is growing fast, because of orders to test much higher volumes than before and look like I needed to add more test cells, I would not be happy to do that without knowing how efficient I can become because of having real-time data by making the current test cells intelligent. Effectly, that's what it's doing. It's making the test cells intelligent.

Make them intelligent and then buy more test cells if you need to. But you will probably find that Real time, the implementation of real time already makes your test floor 10 plus percent more efficient. So the future for me is this should be a default. It should be real time, whether it's from us or whoever, should be real time for any test facility, our probe facility for that matter. Yeah, I agree completely. So final question, John, how does customer engagement work with Yield Health? You know, has that changed over the years? How do you acquire customers now?

I know you're very active in the ecosystem and you have a great new website. How do you engage with customers? So it's easier than ever to contact us, either via our web page or brand new webpageeadop.com. We have a very active LinkedIn presence. And we have agents in different countries across the world. We have in North America, in Europe, in multiple countries in Asia as well. So we're easy to contact, but the first point of contact might be our Yieldtub.com web page, which is all the details. Thank you for your time, John. I look forward to catching up with you at the end of the year.

Thanks, Danny. My pleasure. Thank you very much. That concludes our podcast. Thank you all for listening and have a great day.