The unrelenting demand for semiconductors coupled with the complexity of modern IC design has placed an unprecedented importance on chip quality and reliability. Automated Test Environment (ATE) systems ensure the semiconductor manufacturing industry meets and exceeds stringent requirements to certify that chips satisfy customer expectations before their integration into thousands of automotive, computing, consumer and other electronics. SEMI predicts the test equipment segment will expand to US$6.9 billion in 2024.
With product/die the focus in the test environment, SEMI is developing a suite of standards for the test industry built upon SEMI E183 – Specification for Rich Interactive Test Database (RITdb), which defines a data and event sharing and streaming methodology. There is an assumption that RITdb is simply a new version of the Standard Test Data Format (STDF) to store test data. However, RITdb also defines how to send real-time messages over the Message Queuing Telemetry Transport (MQTT) protocol using a publish-subscribe (pub-sub) model. This addresses the test industry’s need to access data as it is generated. RITdb is designed to ensure all information captured in STDF files, plus other data from test operations, can be represented in a RITdb container.
In front-end processing, a high-level manager (factory host or MES) makes command and control decisions that dictate how manufacturing equipment execute recipes of process steps that impact the entire wafer. SEMI Equipment Communications Standard/Generic Model for Communications and Control of Manufacturing Equipment (SECS/GEM) is well suited for these decisions as it provides point-to-point communication in a client/server architecture managing each individual piece of equipment. Recipes and data collection are focused on what the equipment is doing to a wafer and how well it is performing compared to its specification.
Semiconductor front-end processing vs. test environment
With testers, there can be multiple sources and consumers of the test data within the test cell, on the test floor, and across the factory site; the SECS/GEM approach of passing all information through a centralized source does not work well since various levels of data collection, latency, and responsiveness are required. For example:
- Depending on the test cell’s environment while executing the test program, the tester may be instructed to do something different for that product/die, such as perform additional or different tests, or perform an entirely new set of tests on the next product/die. This change is based on current test cell conditions and doesn’t modify the original test program. Decisions and communication to the test hardware need to be made very quickly – often at the sub-second level.
- Consumers positioned near the test cell need huge volumes of data very quickly. As one moves further away from the test cell, the need for immediate access to the data falls. More summary information can be shared at a slower rate at the test floor and factory level.
- There are many different possible permutations of test components, for example, from a simple layout such as handler + tester layout or handler and >1 tester layout, to a more complex layout such as prober + tester + laser + test cell controller + edge server.
- Unlike front-end equipment where changing the hardware configuration is time-consuming, test cell hardware configuration can change easily and frequently. The data available is based on the test hardware and test program being used. As a result, the model of a single server knowing all the possible data collection profiles that could be used prior to the test program executing is difficult to support.
- Critical data generated from the test cell focuses on the product/die and is frequently collected in batches. This is the opposite from front-end processing, which often collects time-series data about how the equipment is performing.
With the pub/sub architecture, RITdb allows all entities to communicate without having explicit knowledge of each other beforehand. A source can publish information over the MQTT protocol to a broker component. Consumers can subscribe to content data that they are interested in from various brokers components, focusing on the data requirements rather than the data source. This architecture supports a collaborative decision-making model that enables different rule engines to contribute to a decision rather than relying on a single point of expertise, such as the Host/MES.
Unlike SECS/GEM or EDA/Interface A, RITdb does not require consumers to set up data collection plans for specific parameters before those parameters are collected. In the beginning, a consumer may not know the data that best suits its needs or which data is available from a source. Consumers can subscribe to topics or request data from a historical repository using the RITdb protocol.
RITdb messages define a storage structure that can be extracted to preserve original raw data in its generated format and minimize potential data precision loss introduced by translating the data into an intermediate storage format. When new analysis rules are developed, these RITdb messages could be replayed to determine if the new analysis rules would detect problems that were missed using the old rules.
The RITdb Task Force is developing new SEMI Standards to describe various use cases in which RITdb can be used in the test environment and the expected behavior when RITdb control messages are received. The Task Force is also defining a dictionary of RITdb event messages and information that should always be included.
To participate fully in Smart Manufacturing, the test floor needs to be more responsive to each test cell’s internal environment. It is no longer sufficient to treat the test cell as a black box and only participate at the end of the test run. RITdb provides the infrastructure to make smarter decisions between test cells and the test floor, optimizing operations to improve the test floor’s overall productivity. Only by taking advantage of real-time data and dynamically adapting test cell activities can the test industry achieve the efficiencies required to help the global semiconductor market reach the US$1 trillion mark.
Get Involved
SEMI Standards development activities take place throughout the year in all major manufacturing regions. Please visit the SEMI International Standards program or our events page.
If you have any questions about the RITdb Standards or Task Force work, please contact the North America RITdb Task Force Co-Leaders Stacy Ajouri (sajouri@ti.com) or Mark Roos (mroos@roos.com).
About the Authors
Stacy Ajouri is a Senior Member of Technical Staff at Texas Instruments in the Test Technology Group. She is the co-chair of the North America Automated Test Equipment (ATE) Technical Committee and the RITdb Task Force. She has over 30 years of experience across multiple disciplines related to test and test operations. Pulling from that experience, she supports the implementation of RITdb proof of concepts (POCs) focusing what is needed by the manufacturing and engineering community.
Mark Roos is CEO of Roos Instruments, a longtime producer of semiconductor ATE. He co-chairs the North America ATE Technical Committee and the RITdb Task Force. Roos has been involved in standards development for ATE for the past 20 years. He is currently heavily involved in the focus of RITdb POCs on scaling and latency.
Albert Fuchigami is a senior software developer at PEER Group. He is active in the SEMI Standards Program and co-leads the North America Data Diagnostic Acquisition (DDA) Task Force. He contributes to the RITdb Standards development by ensuring the differences between front-end processing and the test floor are taken into consideration and by helping users understand these differences so they know when specific SEMI Standards suites are appropriate.