RITdb facilitates complex testing and enables new test floor analytics
Demand for more and better data for test is driving a major standards effort, paving the way for one of most significant changes in data formats in years.
There is good reason for this shift. Data from device testing is becoming a critical element in test program decisions regarding limits and flows. This is true for everything from automotive and medical components to complex, heterogeneous devices such as processors used in servers or smart phones. And increasingly, all of these devices are expected to function flawlessly for longer periods of time, which can be more than a decade for automotive, industrial, and medical applications.
Test and data analytics vendors have developed a variety of different approaches to ensuring quality, ranging from outlier detection techniques involving dynamic part average testing (DPAT) to on-chip monitoring throughout a chip’s lifetime. The big problem today is in the data itself. Implementing complex test processes with the Standard Test Data Format (STDF) is becoming unwieldy. There is simply too much data from too many sources.
This is why SEMI and its member companies are developing the Rich Interactive Test database (RITdb), a proposed test data standard aimed at reducing the burden for test engineers and test operations. RITdb, which is the work of SEMI’s Collaborative Alliance for Semiconductor Test (CAST) RITdb working group, focused on the scope of test data and test processes required for modern devices and contemporary test process. Their efforts will be voted on later this year.
“There’s a lot of flexibility in RITdb to handle multiple data sources,” said Mark Roos, CEO of Roos Instruments and co-chair of RITdb Taskforce. “This provides the flexibility to deal with the complexity of products that we have today.”
It also provides another check point for devices. “The STDF represents a static view of the data and is useful for analysis after the tests are completed” said Deepak Sood, strategic marketer at Teradyne. “As Industry 4.0 drives more automation, the need for real-time feedback and analysis will drive different ways to access the test data being generated.”
To support test operations, the working group defined a streaming protocol for any data produced by a test cell component. This provides the meta-data about the test process that test factories can use to implement smart manufacturing.
“RITdb establishes a standardized approach for data sharing and consumption of data throughout the IC manufacturing processes from fab to final user and back across the whole ecosystem,” said Paul Trio, senior manager of strategic initiatives at SEMI. “RITdb supports adaptive test and addresses the challenges of data sharing between internal and external facilities and stakeholders.”
RITdb facilitates data analytics for the test floor by including test meta-data for instance test cell components’ data, which at a minimum includes the tester, handler, software apps and board.
Fig. 1: Test cell components. Source: RITdb Task Force
For the test floor, integrating all test cell data into factory operations is basically the equivalent of last mile connections.
“The test floor is relatively heterogeneous in terms of systems,” said Dirk de Vries, R&D director at Synopsys. “It’s different vendors using different protocols and formats. RITdb can really provide a fundamental leap in this respect, rather than being an evolution of existing systems.”
Smart manufacturing promises to effectively manage a diverse factory space by sharing the data within an IoT framework. Proponents say RITdb can deliver what STDF cannot, enabling smarter test processes.
STDF running out of gas
Complaints about STDF fall into three common areas — limited standard records, inability to act on the test data until the file is written, and a lack of information about the test process. Engineers have developed workarounds for these limitations, but they are cumbersome and customized. That, in turn, creates issues in maintainability, readability, and traceability.
“As a container, the STDF is insufficient. It doesn’t hold enough information anymore. It doesn’t have the structures needed to capture what is going on in the program,” said Stacy Ajouri, senior member of the technical staff at Texas Instruments and co-chair of the RITdb Taskforce.
Consider a 5G RF device, for example. “We do high-performance RF measurements, which come as complex numbers, real and imaginary,” said Roos. “STDF doesn’t support any of that. It’s very common in RF to do a sweep of frequencies. STDF doesn’t really support the concept of a sweep. When we put stuff into STDF, we lose a lot of the richness of the data.”
This becomes obvious even with something as simple as a chip ID. “There isn’t really a place in STDF natively to put a 24 alphanumeric character die ID per device easily without inventing something in generic data records that won’t be compatible with different people’s data analysis tool,” said Ian Harrison, product specialist in Cohu’s Semiconductor Test Group.
To handle data types not considered in the STDF, engineers make use of the Generic Data Record (GDR). They also dump test conditions in the GDR. While engineers can store any data they want, it’s different from engineer to engineer and product to product as to how the same data would be stored.
“You would like a container that doesn’t care what you’re testing and only cares that you can provide the structure and can convey it in the future,” said Roos. “And so that’s why RITdb is based on a database technology, SQLite.”
The key advantage is accessibility. “With SQLite, anybody can access the data with open source tools like a SQLite browser,” Ajouri explained. “With a little know how on queries one can read the file and look inside of it. You can’t easily do that with STDF because it’s a custom binary format with proprietary tools.”
Technically, an engineer cannot access an STDF file until the ATE has completed testing the wafer or lot of units. Yet there are a multitude of reasons you would want to know the test results per die/unit during test. Engineers have been inventive in gaining access.
“STDF, as designed, typically gets pushed after the file is closed,” said Ric Dokken, an independent ATE software supplier. “While the tester is writing the STDF file, it is possible to have a local daemon that is reading the file at the same time it’s being written.”
Adaptive test
Yet this only looks at the data generated. To enable some adaptive test methods, engineers need to import data from previous test steps, or from the historical record.
“Adaptive test for us is more on how you interact with the test program, and what data is available on the tester for doing this, and how can it be accessed,” Andre van de Geijn, business development manager at YieldHub. “RITdb might come with a framework to make this happen. Adaptive test might be easier with a simple way to access the data.”
Today, each data analytic company has a daemon in the test cell. “The biggest problem is that for every tester, every OS version on the tester (with the bigger updates), you’ve got new methods for which you need to write an agent to do those kind of things,” said van de Geijn. By streaming the data, RITdb obviates the need for custom solutions.
Not everyone has the daemons extracting data. “Some of our customers have closed the STDF file every few devices and send a piece of the data in the STDF. But then you break all the traceability,” said Cohu’s Harrison. “If you’ve broken that into lots of little pieces, then getting it all back together and not losing a bit impacts data integrity of a lot’s worth of data.”
Today uniting that meta-data with the test result data from an STDF file is possible, but it’s also cumbersome and error-prone.
“If your legacy system produces only STDF files and also sends data through SECS/GEM to the MES (Manufacturing Execution System), at some point the two data sources need to merge,” said Albert Fuchigami, senior software developer at PEER Group. “RITdb will let you take all that information and get it from your test cell, so I don’t have to merge data or worry about losing data if the connection to the MES goes down. It’s much simpler to manage and to extract.”
Enabling consistency and flexibility
Created by each test engineer for their product, custom STDF GDRs add a lot of work for each test program. RITdb will eliminate most of this work by allowing ATE vendors to support a data logging format in which customers can define all the details. Data analytic consumers can port to their data structure of choice.
The RITdb standard defines how engineers can store as a database entry with 6 columns that include sequence (time), entityID, indexID, name, value and value2. This provides a flexible and standardized format.
Fig. 2: RITdb data format. Source: RITdb Task Force
“With all this adaptive test and tuning, etc. we have a two-dimensional surface. It is actually describing the test and it’s per part. Now every part is slightly different,” said Roos. “With RITdb, we can put the adaptive data in the data log with everything else. So it’s one consistent container. We can have the conditions. We can have the adaptive information. Those are things STDF just can’t support.”
With the need for bi-directional real time access, RITdb documents a streaming data protocol based upon the MQTT, an open-source, message-based communication protocol. The inclusion of real-time data, such as streaming data, provides opportunities for factory management. In fact, there is another SEMI standard, Test Event Messaging for Semiconductors, which also streams data and which currently going through the ballot process.
“Teradyne is working with several data transfer technology alternatives like RITdb and TEMS. All the transfer alternatives build on a set of communication standards historically available for tester and test floor management systems,” said Sood. “As an example, we have worked with customers to provide real-time test data using TEMS. TEMS has been deployed at some of our customers that have started on the path of Industry 4.0.”
Streaming data eases data-access mechanisms. “One good thing is to avoid having multiple daemons running on an ATE,” noted de Vries. “The idea of publishing the data in a stream that is really enabling multiple different data consumers satisfied without burdening the ATE vendor with a number of proprietary protocols.”
That data streaming is two ways, meaning you can inject data into the test process. “RITdb is good not only as an output, but also as an input to a test program for some of this adaptive control. Because there really is no standard format for feeding external data into a test program,” said Keith Arnold, senior director of solutions at PDF Solutions. “That’s an area where RITdb could really help because it’s flexible in structure.”
With injecting data into a test cell, the standard addresses data integrity and security. “The integrity challenge is you have to be sure you’re getting the right data to the desired test cell. We address this by ensuring accurate and trusted data provenance in RITdb,” Ajouri said. “We want to have confidence in the data source, i.e. where it came from and who it came from.”
It is not just a matter of collecting the data from different sources. With current systems, merging test cell data from several sources for analysis purposes remains difficult. To effectively leverage multiple data sources requires alignment. Using the legacy systems each test cell component could report up to the MES. With an IoT architecture, a broker locally manages data streams, she said.
Fig. 3: Data streaming with RITdb. Source: RITdb Task Force
“In the end it is a matter of receiving the data, processing the data, and acting upon the data. When data needs to be loaded that is coming from IoT, it needs to be delivered,” said van de Geijn. “Getting data in a consolidated way using RITdb that includes both test results and data from IoT, this is more of an evolution, not revolution.”
Analysis possibilities and efficiency improvements
In combining test process data and test results data, RITdb opens up new analysis possibilities, as well as making current processes more efficient.
“Users will invent new and creative things to do with this streaming data,” said Harrison, noting this will go beyond the obvious adaptive test. “People want yield alarms, they want calibration status, they want configuration monitoring. They want to know if a board comes out of a tester, and a different board goes in. All of those things are enabled by this data about the test process.”
Ajouri agrees. “Smart manufacturing means I’m taking that data along with other information in the factory and making autonomous decisions that either go back or forward into the process,” she said. “I can improve my planning and yield. I can use it to do prescriptive maintenance, meaning I can identify when something should be maintained before it fails and results in a yield loss.”
Test meta-data has many sources. This is evident with probe cards and load boards for the hardware interface between the tester and the device under test. The contactor degrades over time and needs maintenance. The amount of data in this case is growing significantly, but today that data is not connected to the test process.
“The number of interconnects that need to be tested is getting a lot higher,” said Alan Liao, director of product marketing at FormFactor. “With an SoC, we used to have around 10K pin count each. Now they’re coming in at 30K pin count. And we’ve been testing some chips that have multiple ICs integrated together that have reached 60K pin count for just one die. So the probe force required, versus what you can support on the prober, is getting very challenging.”
The problem is that the probe requires enough pressure to make contact, but given the fragility of all of these features developed at advanced nodes, a slight error will cause widespread damage.
“If the force is not sufficient, you may not get a stable contact,” Liao explained. “If it’s too high, then all of the bumps are going to collapse. We’re looking at advanced MEMS processing in our fab to product probes for those features. It’s challenging, but from a probe card perspective we’re okay for now. However, if we keep going in this direction, then probably new materials and new processes will be needed.”
These kinds of issues are cropping up across the test industry, and all of it produces more data. “Looking at the interface between us and the vendor to get board return data that we can correlate with what’s going on our floor,” said Ajouri. “To start this process we’re integrating RITdb into our board shop activities. Eventually, we will integrate the board shop activity with data we’re collecting on the floor. Then we can identify bad boards before they affect yield or identify a problem board that keeps going in and out of the shop.”
Streaming test results enables detecting issues or data trends and acting upon them. “A typical test run for us is five or six hours. During that time stuff happens like the socket fails or the yield has become sporadic. Today we don’t have any way of knowing until the test run is done,” said Roos. “With RITdb streaming data, our customers can watch the data and have a rule to detect these adverse events and stop the test run to enable corrective actions.”
Time is of the essence here. “Real-time data can be used to perform analysis real-time on the tester. Think about running methods like DPAT for final test on the tester. RITdb has a structure that can directly be accessed and makes it easy to quickly find data,” said van de Geijn.
Synopsys’ de Vries noted that meta-data regarding test time is very much needed for improving overall equipment efficiency (OEE). Engineers engage in test time reduction to improve OEE without reducing quality. RITdb provides better insight into test time than STDF.
Making the transition to RITdb
Most ATE vendors have been actively participating during the RITdb’s development, and some already have built in RITdb support. For data analytic platforms there exists no significant obstacle for them to incorporate it.
But moving from STDF to RITdb will not happen immediately. So what will drive this move?
“You’re going to see that the adoption for RITdb is going to be much higher with people that are building complex devices that require complex programs and complex data collection,” said Arnold.
This is particularly important in areas such as communications chips. “5G products will drive early adoption of this standard because the parts are significantly more complicated,” said Roos. “To meet quality/reliability goals, there’s lot more data. So the question for test engineers is, ‘Do I do something myself or do I follow this standard?’ We’re at a good time with wrapping up the standard for people that make that decision.”
Complexity of the device is not the only driver for migrating from STDF and SECS/GEM to RITdb. The inability to take advantage of new capabilities on the test floor will motivate factory managers.
“Standards bring new technologies and new benefits. Factories will see value of having all that data in the same containers so no one needs to worry about merging in data from different sources and it is always accessible,” said PEER Group’s Fuchigami.
“It’s just the nature of the test cells today,” said Ajouri. “Some are legacy. But the complexity of newer test cells is not the same model as it was 10 years. I’m seeing it now as we’re looking at implementing a new test cell that they’re trying to implement into an existing infrastructure. I see this will be really sub-optimal, because you’re wanting to fit into what you already have and it’s not going to be the benefit you think it’s going to be. If you want to get down to the nitty gritty, you need to have a different system.”
“The need for acquiring and acting on real-time test data will drive the shift to RITdb. This will happen in two stages. The first stage will be similar to today with STDF, customers will develop RITdb data importers,” said Sood. “The second stage, which will take longer, is where the MES infrastructure is developed for native RITdb. The need for customers to better manage the utilization of their fleet will accelerate the transition from stage one stage two.”
Conclusion
RITdb will be going through the SEMI ballot process at the end of this year. Active ballots are publicly available on the SEMI website. Only SEMI Standards members may vote, but membership is free. For the most current information check the LinkedIn group.
RITdb possesses the hallmarks of a good standard. All stakeholders in the test process can benefit. It can support current methods, immediately enable improvements, and enable new processes. Finally, it has an open framework that enables consistent device and meta test data shared in a secure manner.
“The important part of working through a standard is that it gains from the participation. Over the years, there have been inputs from the members that caused major changes in direction,” said Roos. “To address situations where there’s very complex testing being performed, we had to make sure that we could handle the complexity of what they did.”
RITdb’s data container in SQlite will facilitate test engineering to support refined test data analysis and associated actions. RITdb’s streaming spec enables test factories to move to smart manufacturing solutions.
“RITdB is clever and elegant,” said ATE supplier Dokken. “Data consumers don’t care where it came from but can understand how to handle all the data. It can come from the same source or from different sources. Data can be stored into structures that that are better defined and in a database table which is indexable. You know that somebody can read it five years now, these are absolutely improvements.”
Others agree. “We’ve been focused for so many years on, let’s get the data about the device in STDF or some other format. Now the data about the test process is becoming as important and we all need to find the right thing to do with it,” said Cohu’s Harrison. “For Industry 4.0 to come along, they need data in a more timely fashion and it needs to be a richer set. RITdb can do all that.”
In the end, a standard represents a set of tools for engineers to solve problems with efficiency, economy and efficacy. RITdb provides a new toolbox for test.
Related Stories
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply