Proposal for a set of tests to be run during production on the modules with the HDIs (and on the HDIs alone) based on our experience at UCSB. It includes suggestions from Natalie Roe. This proposal does not include tests on the bare hybrids, since at UCSB we have no experience with this. One important component of the procedure is communication between sites, as first the hybrid and then the half modules are passed on from one laboratory to the next. The results of all the tests should be made easily available, perhaps through the web, but also as hardcopies (paper) that travel with the hardware between laboratories. I also assume that it is the responsibility of the half-module assembly sites (PI and UCSB) to input a summary of the results in the SVT construction database. Visual Inspection ================= Who/When : MI before sending HDI to PI and SB. PI and SB upon receipt of HDI from MI. How : Microscope. Time : 30 min Docs : Checklist, note any anomalies. Notes : Must come up with list of things to check, e.g. are all the bonds there, are all the components there, is anything damaged. Input from MI needed. Basic Connection Check ====================== Who/When : MI, PI, and SB before DAQ tests How : With the flat kapton test-tail inserted and the edge card connector in place, check with an ohmmeter the following - Termination resistance between command (clock) lines and D5. - Resistance of termistor (n side only) - No shorts - Resistance between voltage level and sense lines (A0,A2,A5,D5,D0) - A0 must be shorted to D0 Time : 10 min Docs : Checklist, note any anomalies. Notes : We have wasted a lot of time with bad connections. This very basic set of tests insures that the connections that we can check are OK. In the long run, this test saves time. Basic HDI Digital Functionality =============================== Who/When : MI before sending HDI to PI and SB. PI and SB upon receipt of HDI from MI (unbonded). PI and SB before shipping to LBNL (bonded). How : With calibration software. - Read/Write tests of all registers, reading from the left, using clock/command A. Test all bits (walking ones and walking zeroes). - Repeat reading from the right. - Repeat using clock/command B, both left/right (last one not strictly necessary). Time : 10 min Docs : Checklist, note any anomalies. Feed information into global list of problems. Notes : All necessary software exists and works. Will write macro to do all of this at the click of a single button. Gain - Intercept - Noise - Bad Channels ======================================= Who/When : MI before sending HDI to PI and SB. PI and SB upon receipt of HDI from MI (unbonded). PI and SB before shipping to LBNL (bonded, after final rework). How : With calibration software. Analysis with PAW kumacs. - Three (or possibly only two) threshold scans at different values of charge injection. - Fire some number of channels together (but not all). - Shaping time = nominal shaping time for given layer - Readout direction, A/B selection does not matter. Time : ? see below ? Docs : Make values of gain/intercept/noise available to institutions downstream, i.e. MI --> Pi and UCSB --> LBNL. Histos from the noise/gain/intercept runs should be available via the web; the file name should be recorded in the traveler together with date and person who took data. ***** (Do we need this level of detail ?). ************ Make condensed list of bad channels available. (Definitely need this). All values to be communicated in units of DAC counts. Notes : Number of channels to be fired at one time is compromise between accuracy and speed. Speed also depends on quality of ethernet connection. Need to study effect of firing multiple channels on V2 rad hard chips. Note that due to bug in LBNL ROM (perhaps only some ROMs, not all ROMs), cannot fire ALL channels at a time (ROM cannot read events that are too long). Basic test using one shaping time only. Perhaps if it is fast enough do it for more shaping times ???? This test also completely verifies that calibration mask works. It partially verifies that channel mask works, see below. DAQ software exists and works, except that at present can only fire either one channel at a time or all selected channels together. Modifications to allow variable number of channels to fire together is easy and will be done. PAW kumacs to extract gain/noise/intercept exist and work. Need some customization and need to be made more user friendly. PAW kumacs to flag bad channels exist, but need to be improved. Channel Mask Test ================= Who/When : MI before sending HDI to PI and SB. PI and SB upon receipt of HDI from MI (unbonded). PI and SB before shipping to LBNL (bonded, after final rework). How : With calibration software. Fire charge injection circuit on all channels with channel masks OFF. Verify that no channel turns on. Time : 5 min Docs : Checklist, note any anomalies. Feed information into global list of problems. Notes : The "Gain - Intercept - Noise - Bad Channels" test does not verify that channels can be turned OFF. Software to do scan exists, works. Software to report problems does not exist yet. Readout Short Test =================== Who/When : PI and SB before shipping to LBNL (bonded, after final rework). How : With calibration software. Inject charge on channel N, look for charge on channels N-3 ..... N+3. Time : 5 min Docs : Checklist, note any anomalies. Feed information into global list of problems. Notes : Software exists, works. Can also be used to quickly find dead channels. On earlier version of the chip, pinholes could also clearly be seen in this test. LED Test ======== Who/When : SB and (perhaps) PI. On bonded detector. How : With calibration software, see Notes below Time : N.A. Docs : N.A. Notes : Not a standard test, done only to resolve ambiguities, time permitting. System and software ready ibn SB. No hardware in PI, as far as I know. Then there are other things that we probably want to check, but for which I do not have a clear picture of the testing procedure. On-Chip Buffers =============== The standard calibration software can be setup to use more than one buffer. Unfortunately, the LBNL ROM as kludged up in our test stand always uses trigger count = 1. It is therefore not possible to check that the on chip buffers work propoerly using the trigger count value. One possibility would be to first store an event with no hits, and then an event with a large number of hits (generated by charge injection) and then make sure the events are read out correctly. Another possibility would be to send 4 successive L1 accept commands each preceeded by a cal strobe with a different cal mask. Then send 4 successive read event commands. Tthis verifies that all 4 levels of buffer are working. Next do same thing but issue a clear readout command before sending the read event. This verfies that clear readout is working also. TOT === A full test of the TOT circuitry is probably too complicated (?). One possibility would be to verify that the TOT works at some basic level by injecting first a small amount of charge and then a large amount of charge, and then verifying that the TOT response for the two case is within some acceptable range. It is also possible to do it in finer steps.... NB: I have seen in the past cases where the ON/OFF response of a channel was OK, but the TOT values did not make sense. Sampling Rate ============= I do not really know how to quantitatively check that this works in all cases. (NB for the charge injection/threshold scans to work at all, the sampling rate circuit must work at some high level). Time Stamp ========== One simple possibility is to inject charge, and verify that the time stamp is within some allowed range. A more complicated possibility is to change the hardware delay by a known amount and verify that the time stamp moves by the right amount. But ideally we do not want to tweak hardware delays between one test and the next..... It may be possible to set up the logic so that a few delay settings would be computer-controlled. Jitter Time =========== Could be checked at a primitive level by squeezing the jitter window until the hit goes away. Needs more thought. Clock-thru mode =============== Set clock-thru bit true in control register Clock should appear on data out line (as seen with a scope) (Do we really want to look at this ?).