Overview of rules
for radiation mitigation
D. Breton
ETD parallel session – Elba Meeting
June 2nd 2010
ETD/Online - SuperB Elba Workshop - May 2010
Introduction
• In the CDR: « Because of the very high event rates anticipated, it will be
important to push as much of the task of feature extraction as possible into
intelligence in the front-end electronics ».
=> This was a natural feeling if one didn’t take the radiation problem into
account
• BaBar drift chamber electronics was upgraded in 2003
=> intelligence (Xilinx FPGA) was put on the DCH end plate
=> the first effects of radiation was “discovered” then
• Particles (especially neutrons) above a few MeV may interact with silicon.
– Medium energy neutron interaction break the Si nucleus and create
heavy ionizing nuclear recoil.
• Neutron flux (produced by particles hitting something massive) should be
directly linked to luminosity (we hope anyway to have a lumi term ~10% of
BABAR’s).
Effects of radiation
• Single Events Effects and total dose are the two subjects of concern.
– It looks like, besides SVT, total dose should not be a main worry
– Except maybe for in-detector electronics making use of voltage regulators.
• Single Events Effects can be split into two families:
– Single Event Transients and Single Event Upsets: non destructive.
• SET just leave some charge which is not memorized.
• SEUs may touch the memory cells and thus mainly concerns:
– Control registers
– Event data
– Configuration of RAM-based FPGAs.
– Single Event Latchup: potentially destructive. Needs higher energy.
• In order to ensure a safe functioning, our electronics has to be mitigated for
radiation.
– If SEL may occur, all used circuits have to be validated for this kind of
events
– The problem with SEL is that one has to cut the power to recover from
it => delatchers have to be used
Example
• From SEU cross-section and neutron flux, the probability of SEU (single
event upset can be determined)
– Example of SEU rate simulation for FPGAs in LHCb calorimeter electronics in
February 2001
Rate    ( E ) ( E )dE
108 bits/Crate
~1 SEU/ (hour x crate)
Which corresponds here to
0.27x10-4 SEU / (bit x year)
SEU cross-section
Neutron flux
cm2/bit
Electronics
/cm2/an
2m
8m
MeV
8m
MeV
Mitigation methods
Sensitivity to Single Events rapidly
increases when silicon technology
gets smaller.
Mitigation methods depend on the expected rate of SEUs:
• If the rate is very low, standard FPGA could be used
– Mitigation must concern both user data and configuration:
• Concerning configuration, the latter has to be checked regularly and
reloaded if a bit flip was detected (=> potential source of dead time!)
• Concerning user data, TMR (triple modular redundancy) methods
can be used in the FPGA code, as well as encoded redundancy in
the RAMs.
• If the rate is higher, radiation tolerant families have to be used
(like ACTEL’s EEPROM based ProAsic FPGAs).
Design rules
• Commercial components have to be carefully selected
– Lists of components already exist
• NASA
• CERN => LHC experiments
– If new components are used, they have to be validated
• Sometimes the technology ensures the hardness (like ECL), but with
CMOS it is necessary to check it
• ACTEL ProAsic3 family is the best FPGA candidate as of today
– Configuration based on Flash EEPROM
– We are currently validating it for LHCb upgrade in Orsay
• Delatchers are the adequate solution for SEL
– It detects an over-current and cuts the power of the corresponding circuits
– DAQ/control has to be informed
=> Drawback : board/system has to be reloaded
• When sure of the component hardness, just buy the production lot at once!
Conclusion
• Due to the potential radiation level on the detector, only really useful electronics
has to sit in there.
 the FEE design has to get rid of any unnecessary complexity.
 moreover, the DAQ and control systems have to be informed if any serious
problem due to radiation occurred on the front-end.
• Components used on the detector have to be validated for radiation (especially
concerning their robustness to Single Event Latch-up).
• Safe configuration of FPGA also has to be guaranteed
• Either by using rad-tolerant families (favoured solution)
• Or by scanning the configuration and correcting errors (may cause deadtime)
• In the FEE:
• Critical paths and items must be identified and properly protected
• Registers have to be triple-voted
• FIFO pointers have to be protected and potential errors have to be forwarded.
• Parity bits have to be added for travelling data. Special care has to be taken
for trigger data.
It is very important to take radiation into account at the very
beginning of the design, because if having a mitigated system without
radiation is just a little more complicated, the opposite could be a
catastrophe!