Module Testing at UCSB: Simulated Production 11-04

1
Module Testing at UCSBSimulated Production 11-04

• Derek Barge
• On behalf of the UCSB testing group

2
Purpose

• To show a testing rate of 30 modules per day can
  be comfortably sustained at UCSB
• To identify potential problems bottlenecks
• ARCS Software (requests for Aachen)
• ARCS Software configuration
• Mechanics Logistics
• Test Checklists data management
• Test automated uploading to TrackerDB
• Crowding in the Lab

3
Testing Rates

• 30 Modules Tested
• 15 OB2, 9 OB1, 6 Stereo OB2
• Simulated worst case scenario
• Artificially high fault rate
• Mixed module types (OB1 OB2)
• Tests Rates
• A Total of 36 tests were performed (4 repairs, 1
  unbiased, 1 with wrong cuts)
• Testing complete in 8 hours, 13 man hours
• 2.75 tests per man hour
• 4.5 tests per hour !!!
• 3.75 modules finished per hour, 2.3 per man hour
• Average test takes 26 minutes

4
Testing Results

• Grading
• 28 Grade A
• 0 Grade B
• 2 Grade C (both failed)
• 26/30 Modules processed (passed or failed) on
  first test
• 24/26 passed
• 2/26 failed
• 1 CMN
• 1 with 11 opens due to problems bonding 3 noisy
  channels
• 4/30 Modules needed repairs
• 6063 2 expected pinholes, 1 unexpected open
• 6075 1 pinhole, 1 expected short, 1 unexpected
  short, 2 expected noisy
• 6077 3 expected pinholes, 1 unexpected pinhole,
  1 unexpected open, 2 noisy
• 6079 2 expected pinholes

5
Problems Encountered

• Mechanics Logistics
• Solder broke on adapter card, took 20 min to
  fix
• DB relay down for 15 minutes, switched relay
• Flying wires need to be taped down to avoid
  damage
• Software Data
• Minor software improvements from Aachen
• Should gain 1 min per test and reduced bad test
  rate
• False flag rate
• 1 test in 1 mode falsely flagged good channel as
  a likely 1SO
• Incomplete bonding data
• Some unexpected opens were encountered, channels
  that could not be bonded were not entered in the
  DB. This was fixed immediately.

6
Success Stories

• Data Management
• New version of Module Checklist worked well
• 3 minor bugs discovered, mostly aesthetic
• More automation than previous version only bad
  channels need to be entered
• Automatic uploading of module data via XML is
  implemented
• Half of the XML files uploaded successfully on
  first try
• Other half failed due to incorrect tool id for
  one stand, fixed and uploaded fine
• Crowding in the Clean room
• Clean room was not overcrowded
• Good communication between testing stations

7
Conclusions

• 30 modules per day is sustainable
• Could potentially test 36 PERFECT modules in a
  day
• Otherwise testing rate depends on rate of modules
  needing repair
• Simulated repair rate of 4/30 in this excercise
  .13
• ST qualification repair rate was 1/10 .1
• HPK about 1/30 modules have an expected fault,
  unexpected fault rate expected to be even lower
  for HPK
• Performace should improve with HPK silicon