Minute of the MCC-DSM Design Meeting held on 22nd of January 2003
(Periodic meeting on MCC project progress)
Present: Roberto Beccherle, Giovanni Darbo, Guido Gagliardi, Paolo Morettini, Carlo Schiavi.
- MCC-I2.
MCC-I2 specs: Roberto has brought up some options in the implementation of the specs for the MCC-I2. Those are:
- MCC-FLAG / WMCC reg: the MCC-I2 will generate 4 flags: 3of them are directly connected to the relative Receiver block doing the check, while the fourth is generated in the Event Builder by checking pairs of Receivers. We decided that the WMCC must record only the first 3 flags, mapping each receiver to the corresponding bit of WMCC (note: in the MCC-I1 the MCC-FLAGs are never recorded in the register due to a design bug).
ECR effect on WMCC and WFE regs: We decided that the issuing of an ECR will reset the WMCC and WFE registers. Those register are for debug/reporting info and they will contain information between two ECRs and not for the whole lasting of a run. The information from FE-FLAG and MCC-FLAG are also reported in the data stream for the events where they happens and the cumulative information, stored into the two register, is just for a fast summary report of what has happened.
RdFIFO output uncertainty: The ReceiverFIFO output has one CK time uncertainty from the issued RdFIFO command. This is due to the way the output port works. It is not a misbehaviour of the chip for the real application, but it would make simpler the debugging if would be always the same. Roberto will fix it if it does not need large rewriting of the code.
There are also claims of two MCC-I1 misbehaviours in the operation of modules:
- EoE overflow: The end-of-event overflow should never happen if FE's respond correctly to LV1. Indeed, no more than 16 LV1 may be pending and, so, no more than 16 EoE should be in the ReceiverFIFO. Seems that during last year data taking EoE flags appeared in the output data stream. Is it a MCC bug? Or something else. We decided to try to reproduce the effect on a module in the laboratory.
Errors at high LV1 rates: Kevin noticed that, sending a group of 8 contiguous triggers (where these triggers have associated charge-injection data) and then sending a second group of 8 triggers about 60 crossings (1.5us) later, often there are errors in the MCC event building. Those errors are typically LV1 differences between FE's, and often Hit FIFO overflows (ref. email from Kevin of the 21st of January 2003). We agree that those errors should not happen. Carlo will try to simulate the situation.
SimPix / Verilog simulation: Carlo has rerun the old SimPix scripts on the old MCC-I1 verilog behavioural as control test of the simulation environment. There are some script files that show problems in the SimPix analysis module (they are not correctly interpreted). Is it a SimPix problem? Paolo will look at it. Carlo has also produced new scripts to cover the design errors that were not found before, like MCC/FE flags.
Schedule: We discussed the schedule for the submission of MCC-I2 (see attached MS project plan). According to it the MCC-I2 GDS file should be ready by mid March. In the attached file the time for reticle assembly is put to a nominal value without real evaluation: Gerrit was not contacted.
- Irradiation analysis and new irradiation.
- Appendix 1: Schedule.
