Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PRR Index time for every touch down #60

Open
kmuthugtk opened this issue Dec 5, 2024 · 1 comment
Open

PRR Index time for every touch down #60

kmuthugtk opened this issue Dec 5, 2024 · 1 comment

Comments

@kmuthugtk
Copy link

Hi,

From the STDF, is it possible to get the index time for every down?

EX:

After end the 1st test and Before start the 2nd test, there is some time gap. That's called as an Index time.

Is it anyway to that?

@cmars
Copy link
Owner

cmars commented Dec 7, 2024

I think you'd have to record and inject information separately, if the ATE software can't get it for you.

It's been a good 20 years, but there's a few ways to track indexing:

  • Subtract total test program run time from total wafer or lot time to measure overall equipment overhead.
  • Subscribe to handler equipment events, record timings from these, and inject them into the STDF as separate records, if you want to measure equipment overhead per device.
  • Collect test program results and equipment data as separate streams and data formats, putting identifiers in them such that they can be correlated in your data warehouse when you extract-load-transform them.

There have been some extensions added to STDF over the years that might be a good fit for indexing, but I'm not sure. I'm no longer in the semiconductor industry. If there's not a record type designed for it, a DTR or GDR between PIR-PRR pairs would always work, just design your own structure.

I've seen all three of the above techniques used, depending on what kind of data infrastructure the manufacturing site had, what kinds of equipment we were dealing with, and what affordances they provided. Some equipment makes it hard to run benchmarks (makes it harder to compare them to other vendors, I'd suspect), so in some cases we tapped into GPIB messages (or driver events derived from these? It's been a minute) to get this sort of stuff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants