Issues for MCC-I2 Submission

1. Issues for MCC-I2 Submission Giovanni Darbo / INFN - Genova E-mail: Giovanni.Darbo@ge.infn.it Talk highlights: Design corrections / changes. SEU improvements. Schedule.

2. MCC-I2: Changes for the new design For MCC-I2 we foresee 3 categories of modifications: • Bug fixes: they are relatively small and almost all easy to fix (the list of changes/bugs collected up to now sumup to ~10). No one is critical for detector operation, are just lost of debug functionality or not the best implementation of specs. • Specification changes: • R/O of scoreboard (useful for system debug) • SEU improvement: • From PS data MCC is just at the limit for the operation at LHC. • Improvement should look at design changes but also to ROD operation.

3. SEU: Design Changes • For radical improvement we should redesign FIFO cell and FF. This is too late at this stage and would require additional manpower and expertise that are not available. • Options that are available at this stage of the design are the use of redundant logic design in the critical components of the chip (even those difficult to identify): • An easy way to add redundancy is to make 3 replica of critical memory elements (global registers) or state machines and use majority decision of their outputs. • We have identified 3 corners where to implement the changes: • Storing of EoE (end-of-event) in the FIFO; • FEEN and CSR register; • Command decoder. • If we restrict to the former changes the chip area should increase by 3 mm2 that means 0.5 mm of the two short MCC sides. Pads used by Flex will keep the same position.

4. SEU: Options at ROD level • The improvements proposed may be not enough for safe operation of the whole detector for the few hours of a run at LHC. • The other option we have at system level is the ROD: • RODs must be able to reset the MCC/FE data path and to reload the FEEN and CSR every ~100s (issue of ECR). • RODs should be able to monitor for corrupted events, then stop the acquisition of that module and reload configuration asynchronously from other modules

5. MCC-I2 Design Flow • The design flow used for the MCC-I1 showed to be successfully and we don’t want to change. • The design changes are reflected to changes in the behavioural Verilog code and to resynthesise the whole chip. • Layout will be executed by already existing MCC-I1 Silicon Ensemble scripts modified for the slightly expanded chip size. • Simulation will use the same test vectors and tools (SimPix) as for MCC-I1. • Final timing verification and LVS/DRC will validate the new design.

6. Submission Schedule • We consider that the changes in the design will require 3 months (starting from end of October). The 3 months do not include DRC/LVS. • We consider that the chip might be ready by mid/end of February 03, about 1 month behind FE-I2 foreseen submission. • Next December we will check the advance of both design and we will decide whether to go on the same engineering run or to split.

7. Summary • MCC-I1 is working according to ATLAS specs. The test of the chips in the lab, in the beam (Pixel modules) and their irradiation show that the design methodology used is correct. • Design errors are very few and none of them has implication in normal detector operation. They limit some debugging features of the system. They will be fix in the next submission. • SEU is a critical issue that we will address in two ways: add redundancy in sensitive chip structures (global registers, ReceiverFIFO and command decoder) and implement functionality in the ROD to detect and recover from anomalies. • The submission schedule is very tight, we will keep open the option of separate submission times for FE-I2 and MCC-I2.