Issue link: https://iconnect007.uberflip.com/i/1514189
JANUARY 2024 I DESIGN007 MAGAZINE 33 but we want to control redundancy. As bound- ary scan does not usually need test points, we can analyze the coverage of that strategy and remove the necessity for ICT test points on those nets. is allows test points to be placed on the nets the ICT needs to target for optimal combined test. We go back to the schematic and make the applicable changes, implement the test propo- sitions for the optimized testbed locations, and then go to the layout. is gives optimal cover- age but makes the fixture less expensive, too. We've probably saved an iteration or two on the layout as well. That takes a collaborative effort because a schematic often lines up with the design, or the layout person in that process doesn't come in until later, right? Right. Traditionally, the tools that have been available to the test engineers have required a layout file, and so the test engineer oen gets skipped. ey don't do a proper DFT analysis because they don't have time. Once the layout is complete, that's the end of the design, and each iteration holds up release. If they don't do the DFT, there's a problem. Do we go back and do it twice? Why don't they take the time to really look at DFT? It seems like a critically important operational step. Yes, it will save quite a bit of money, but it's quite technical. Oen, those who make the decisions are non-technical, and those advising them aren't necessarily directly responsible for the DFT. ere are management layers, so the information is lost before it gets from the guy who sees it as important to the guy who needs it to be employed. You mean the person who's in layout? They may have their own process for DFT. Traditionally, the electronics industry tends to work in booths: You do your bit and then throw it over the wall to the next guy; every- one works in isolation. ey do their job to the best of their ability, and they're not really inter- ested in what others are doing. We want the communication between the design and the test engineers to be invisible so they just share information. Some of our tools will allow the development engineer to run the DFT rules that the test engineer has developed without having to send data anywhere. He can just run the tool as it's been set up by the test engineer. As we look at all the other EDA tools, is this a separate package that would integrate into their design tools? Yes. Essentially, we already integrate into Altium, and there is a possibility that we inte- grate into other tools as well. ere's no limi- tation on our side; we can integrate with any- body. It's like Legos: We can plug any module wherever you want it to go. In your selling process, are you talking to the designers or the OEMs? What's your point of contact? It depends on where the problem is. If we are looking at DFT and DFM, it may be in the pro- duction engineering for DFM. If it's DFT, it would be in the design bureau. Depending on how a company wants to work, it may be pre- or post-layout. We have the test engineering team optimize the test to produce the test data to read back the coverage. So, it might be qual- ity, engineering, or even design. It depends on the customer. There must be a trigger point for them to stop, or is it just continuous improvement? If they're interested in improving their process, yields, and their slip rate, they can ask us to do that. But there might be a half-dozen different triggers as to their scenario. Dean, I appreciate your time and your knowledge. It's great to chat with you. ank you. DESIGN007