Issues for MCC-I2 Submission

1
Issues for MCC-I2 Submission

• Giovanni Darbo / INFN - Genova
• E-mail Giovanni.Darbo_at_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 dont 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.