1. Introduction and Status Report 


Marco made a general status report from the last meeting of July. A web page is now available for the module test working group; few drafts of the document on module testing were made available from people responsible of sub-groups. 

Marco pointed out few considerations and questions that need an answer from the working group: 

- testing of the modules has to be the easiest possible: can pedestal and noise test together be enough, at least for the "fast tests" ? 

- CCU design is not final; present CCU needs the use of the interconnecting board TRI3; 

- how do we define the default values for running the APV25 ? Should we make any scan of the registers parameters ? 

- software: can we have only official release of software, such that no changes are made possible to the user ? 
 
 
 

2. Aachen DAQ system with 4 APV25 (including HW setup presentation) 


The Aachen test bench was presented. It comes from the test bench used for the AMS experiment where the APV25 chip has been adopted. The purpose of this test bench is to provide an easy hybrid and module testing. A full description of it can be found on the Web: www.physik.rwth-aachen.de/group/IIIphys/Electronics/PSRD/apv.html . 

The set-up is very light, it consists in: 1 PC, the SRDAPV board, a Power supply board (with external LV power supply) and intermediate board. An additional HV power supply is needed if a complete module is used. 

The core of the set-up is the board SRDAPV, developed in Aachen. It provides all the digital signals needed for the APV25. It also houses 4 ADC's to convert the analog output, and buffer memories.

The set-up can be modified to account for the multiplexer on the APV hybrid. With this set-up 4 APVs can be read (8 APVs if mux on hybrid). The cost is low: the interface costs 100-200 CHF and the SRDAPV about 1200 CHF (plus a desktop PC). 

A demonstration of the set-up was made during the meeting, with a complete well working software/hardware. 
This setup will be upgraded to work with the next generation of hybrids, which will need only one clock line with encoded trigger  to a PLL (programmable via I2C).

Everybody agreed this set-up could be  used for fast hybrid testing, whenever a check is required to verify the working status of the hybrid. It was not encouraged to use this set-up for final test and burn-in of the modules (qualification), where a more flexible system is necessary. 
 
 

3. Progress on the Tracker DBMS user interface 


The query interface of the Tracker Database is now working. Roman presented Several tools provided by the QI: visualization of data, simple analysis tools, way of exporting data for further analysis, creation and updates of objects and others. 

The QI is using already the bar code reader. 

One and two dimensional queries are possible. The system is compatible with Linux. 

The DB is planned to be available centrally in Lyon or at CERN and it will be available locally through the network. 

The schedule of the QI is the following: 

 

Information on the project of the Tracker data base can be found on the Web at: cmsdoc.cern.ch/~cmstrkd . 
 
 

Ariella presented the draft on the Quality insurance and control. The draft describes a clear flow chart of the module production and testing network. 

Important points of the flow chart scheme: 

 

(a)	all electronics active components are tested in specific laboratory;
(b)	test set-up 1 is at hybrid factory to qualify the preproduction;
(c)	test set-up 2 is at CERN to test hybrids after assembly and bonding;
(d)	all FE electronics is tested at Gantry labs with set-up 2;
(e)	a shocking recording system is used for transportation to Gantry labs;
(f)	at the bonding labs a thermal cycle has to be applied after bonding;
(g)	module acceptance test are made with set-up 3;
(h)	test set-up 4 is used for burn-in of modules;
(i)	test set-up 5 is used at the integration centers.

The scheme proposed is a good framework for a decision making process on the quality control strategy. 
 
 

The final hybrid will be equipped with MUX and PLL and therefore it is compulsory the use of the TTC system. 

Wim illustrated the minimal hardware that uses the standard CMS Tracker electronics. On a VME are resident the TTCvi connected to the TTCvx; from here via optical link the FEC is connected. This is programmed via PCI and sends clock and trigger signals to the CCU that then distributes the signal to one or more interface boards (TRI3), each one connected electrically to the hybrid via kapton. 

The analog signal is sent to the TRI3 and from there to the FED electrically, an optical link is not compulsory. 

Discussions followed about how/if to use the Compact PC system developed by the Lyon group, integrated in this scheme. The Compact PC system in this case will not use a timing sequencer on the PCI bus, but has to communicate via VME to the TTCvi. For the rest, all FEDs, FEC and the HV control can stay on the PC. Let's call this scheme a Hybrid solution. 

For test-stand from module production on, it would be advisable (for future developments and possible expansions) to have either a full VME solution (a' la Test Beam) or the hybrid solution.

Mirabito said he would like to analyze whether it can be convenient to stop completely the PC solution, therefore do not go for the hybrid solution, but to concentrate on the full VME one. In this case the efforts could go on the study of a cheap VME processor, running with Linux. Wim told that also the test beam group is interested to this project, since the RIO processor running LynxOS operative system is quite expensive. 

The test of hybrid could be done still with the solution proposed by Aachen, where only a PC plus few light electronics is needed. 

Using Ariella convention (see point 4 of these minutes) the proposed scheme can be: 

-	set-up 2 = Aachen set-up;
-	set-up 3 = hybrid solution OR full VME ;
-	set-up 4 and 5 = full VME;

Wim made a counting of the needed set-ups, the results of the analysis are:

-	15 set-up a' la Aachen;
-	11 set-up type 3;
-	10 set-up 4;
-	5 set-up 4;

Wim also raised the problem of hardware availability, since there is only a restricted amount of CCUs and of TTCvi and TTCvx; also TRI-3 boards are not many. It has also to be taken into account that TRI-3 will be used only for the Milestone 200 and that the CCU board is not the final one, therefore in a year time both will need to be re-done again.
 
 

Lino presented the draft on the testing before and after bonding. During the presentation several comments and discussions were made, the results are reported here: for the main document see the Web page of the test bench. 

Right after reception the module is opened and a simple optical inspection is performed, looking for possible damage during transportation. A test of the hybrid follows taking pedestal, noise and calibration runs. 

After bonding a visual inspection is performed again and an air jet test of the bonding wires follows. Also bond pull tests on test structures are made to check the stiffness of the bonding. 

An I-V test is made right after bonding and the basic electrical tests are made: pedestal, noise and backplane pulsing (if possible). Backplane pulsing test provides an immediate detection of broken, unbonded channels. 

A fast light test is made to check the response of the module to a physical signal. Light can be a infrared laser: a led light was proposed by Karlsruhe group. They should show some result on this subject, and define better the HW needed. This test is made for all modules. 

Alan stressed the importance of having a thermal cycle test (20C to -20C) at this stage to check the mechanics of the module and of the bonding wires. Therefore the fast tests has to be done before and after the thermal cycle, which might be done not powering the module. 

Further test are to check deeply the performance of the module and/or as diagnostic tools. They are the deep laser scan, with a spot of few tens of microns and a penetrating wave length of 1060 nm, and the beta source test. These test will be made for all or most of the Milestone 200 and then will be used on a sample basis during production.
 
 

Valery presented the draft on the module burn-in. 
Since this first version was intended for milestone 200 only, it will be soon modified.
A reference to the new document can be found in: web.iihe.ac.be/cmspriv/silicon/ .
 
 

Minutes taken from : Lino Demaria