HDI AND HALF-MODULE TEST PROPOSAL ================================= Version 1.0 - 18 December 1997 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, through the web, but also as hardcopies (paper) that travel with the hardware between laboratories. 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 In addition, these resistances should also be checked. In order to check these one needs to probe pads (with bonds) on the HDI itself, and there is a risk of damaging the HDI. These tests will therefore only done once, in MI. - Resistance between QVDD and AVDD - SiBias and EG lines connectivity to the Berg connector - connectivity of the DATA_OUT test pads to the Berg connect 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). Address each chip individually. - Repeat reading from the right. - Repeat using clock/command B, both left/right (last one not strictly necessary). - Repeat everything, but in broadcast mode for masks. (not for control registers because of respond-to-read bit). 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 : 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. Make values of gain/intercept/noise available to institutions downstream, i.e. MI --> Pi and UCSB --> LBNL. Make condensed list of bad channels available. 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 ???? (COMMENTS ??) 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. 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. 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. 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. THE FOLLOWING TESTS SHOULD ALL BE QUICK (EXCEPT FOR TOT, IF WE WANT TO CHECK IT IN FINE STEPS). BASIC PIECES OF SOFTWARE EXIST BUT STILL NEED TO BE PUT TOGETHER. WE WILL DO ALL OF THEM SEQUENTIALLY AT THE CLICK OF A SINGLE BUTTON. 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. Send 4 successive L1 accept commands each preceeded by a cal strobe with a different cal mask. Then send 4 successive read event commands. This verifies that all 4 levels of buffering 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. 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 =============== Do not need to test it. Sampling Rate ============= The test on sampling rate is probably not really necessary. We have to run at 15 MHz, otherwise we do not comply with the required L1 trigger latency of 12 us. If the other sampling rate settings do not work it really does not matter for us.