Choose timezone
Your profile timezone:
VTX - OBELIX design meeting
→
Europe/Berlin
Bonn & Remote
Bonn & Remote
Description
This day will be devoted to review the general concept and still open options for OBELIX and go through technical discussion among designers.
The workshop is held in hybrid form, partly in Bonn and partly via SpeakApp/ZOOM. The agenda is still preliminary but should allow ample time for questions & answers.
We require registration just to know whethear you will attend in person or remotely.
Connection links:
Meeting ID: 692 9368 8162
Passcode: obelix
Jerome Baudot, Jochen Dingfelder, Thomasz Hemperek
Participants
* Participants half-half in Bonn and remote.
The meeting was essentially a succession of technical discussions triggered by slides. Check the "CONCLUSION" keyword, indicating when a conclusion was reached.
* Digital parts, supported by Tomek's slides
- the general digital functionalities are reminded
o command, config, output data format and serialisation
can be re-used from TJ-Monopix2, which inherits from RD53 read-out circuit
o the bloc with pixel/hit memories managing triggers is the key new module to be added
x format of pixel/hit memory & state machine proposed and discussed a bit
includes address-in-matrix, ToT, timestamp (bunch-crossing ID for LHC), triggerID (if trigger associated)
x reminder that the format might include "clustering",
that means embeds in a single word the position of a neighbouring fired pixels
it is not really clustering but rather data compression
=> decision delayed for a time when the cluster size will be characterised
x initial dimension can be derived from simple calculations (document to be made public)
x the memory size depends of course on the trigger delay
o reminder that APV25 is the current limitation, leading to a trigger delay ~5 us
o OBELIX should target 5 us but quote the needed area to go up to 10 us
x Physics Monte-Carlo coupled to circuit test-bench will allow robust performance checks
but iterations (design-test) to be expected
CONCLUSIONS:
x The Vienna group will work on the pixel/hit memory bloc with Tomek
x we re-use as much as possible from TJ-Monopix2 for the other blocs
- discussion about the need for ToT
o benefit of 1 bit output is to save memory (7bits used for ToT)
o benefit of ToT for identification (PID) with dE/dx is not demonstrated for thin (~50 um) sensitive layers
o benefit of ToT for spatial resolution is small (<1 um)
CONCLUSIONS: stick to the 7 bits of TJ-Monopix2 for now, but keep in mind some margin for memory saving there
- communication protocol from the RD53 read-out chip
o more than slow-control, this simple protocol allows continuous data stream
o For LHC, a 160 MHz is used to match the 40 MHz machine clock and the 4 bit coding trigger#
=> note that this 160 MHz is the only input clock and is then propagated to pixels for timestamping
o The clock here should be used for the data stream if no PLL is included
CONCLUSIONS: OBELIX adopts this protocol but will adapt the clock frequency, see below
- data output format
o 8b10b is currently used on RD53 chip, but other schemes may be used
- SEU protection
o not clear yet how severe SEU might be at nominal luminosity (currently impact not measurable)
o latchup was also mentioned, again probability yet unknown
o consideration to reconfigure regularly the sensors
x agreed that pixel configuration should be refreshed probably after every injection
x pixel thresholds and masks could be refreshed at lower rate
CONCLUSIONS: we need estimation of TJ-Monopix2 sensitivity to ions
triplication (TMR) will be used in OBELIX only in places where we identify it is critical (not on data memory for instance)
- discussion on high level of occupancy from background
o hit storms occur and matrix can be swamped by hits (either expected from injection or not)
o in such conditions, veto signal can be used to not transmit fired pixels in the matrix to memories
x if no veto, the nb of fired pixels will anyway be limited by the column drain architecture -> no memory overfill
o though initial indications are positive, readiness time for the Front-End after such storms should be checked
CONCLUSIONS: dedicated simulation of the front-end will be conducted
- Frequency domain and timing for OBELIX
o initial reminder that the RF clock from SuperKEKB at 508.9 MHz is available in Belle II
o trigger granularity in Belle II is defined with a 127.2 MHz clock (=508.9/4)
o OBELIX should use frequencies which are dividers of SuperKEKB RF clock
o VTX performance simulation have shown that 100 ns sensitive window for the sensor is OK
x discussion whether it might be necessary to sum 2 or 3 pixel integration periods to build this sensitive window
the issue is of course the sensor time-walk (~40 ns for 100 e-) and trigger-jitter (~20 ns)
x it is argued that a single integration period is enough for the sensitive window
IF the trigger delay is well phased with the timestamping inside the pixel
That means the trigger decision arrives at the beginning of the pixel integration period
x The clock distributed in the matrix around 20 MHz would allow
integration periods around ~50 ns and still the possibility to sum up two periods if needed
x being significantly smaller than the current 40 MHz distributed in TJ-Monopix2, a substantial power gain is expected
o first estimations of the data rate in the inner layers, indicate that a single output at ~320 MHz (160 MHz using both fronts) is enough
CONCLUSIONS:
x A single input clock of 169.6 (from RF 508.9/3) would allow to match the requirements for the output and the integration period (21.2 MHz = 169.6/8)
x A priori a PLL is not needed, but Strasbourg said one is available from MIMOSIS in TJ-180nm
x It is desirable to be able to program the number of integration periods summed up to form the sensitive window (1,2,3)
- verification & test-bench
o already shared by Tomek for TJ-Monopix2
=> demonstration at a meeting to be organized
o uses Python currently, additional effort with UVM welcome
- scan chain (to check digital functionality on wafer during production)
o can be added at implementation stage
o since this is related to production, OBELIX-1 might not need it
o let's delay this decision
* Design Flow
- digital on top
o digital integration is handled by Bonn
o analogue integration could be handled by Strasbourg
- for analogue integration, person responsible provides 2 blocs
o IO pads
o pixel matrix + DACS + biasing
- storage on GIT (Desy one)
o for source of digital and simulation and assembly
- Cliosoft
o for layout
o SOS server to be setted up => Mail by Carlos to andreas.gellrich@desy.de
* Pixel matrix, supported by Kostas's slides on TJ-Monopix 1 & 2
- detailed review of TJ-Monopix1 pixel performance & comparison with TJ-Monopix2 (please read the slides)
o power/pixel 0.9 uW => current in pixel 500 nA
o threshold for TJM2 expected to go down close to 100 e- with 60 e- overdrive (consequence of time-walk effect)
o large signals can be detected, the dynamic (linear) range of ToT extents to a few thousands e-
o there is a compensation mechanism (delays) to minimize BCID (timestamp) dispersion to 4ns within the column height
- FE versions
o 4 in TJ-Monopix2: 2 amplifiers (w & wo additional cascode for higher gain) x 2 couplings to diode (DC and AC)
o Note the AC coupling allow to reach similar depletion level wrt DC but without HV bias on the substrate => system simplification
o OBELIX-1 could also have various FE versions BUT they should fit the present matrix organisation
and demonstrate benefits (then there is the question whether we have actually time for testing these alternatives)
OBELIX-1 is not an exploratory device but a demonstrator
o OBELIX needs larger iteration time (50-100 ns range) which allow lower analogue current
BUT consider gain depends on current as well => any optimisation requires strong validation / detection performance
- Pixel size
o TJ-Monopix2 pitch (33x33 um2) leads to a pixel fully packed => no more room
o OBELIX pitch could be relaxed by a few microns (like 35x35 or 33x40 um2)
if necessary for higher robustness, eg larger supply lines for lower voltage drop across matrix
CONCLUSION: there was a rather low attendance of analogue experts,
additional discussion on shared work is needed during next meeting
- HitOR
o present in TJ-Monopix2, every other column propagates if any hit in 2 columns within 30-100 ns
x HitOR turns the pixel sensor in a strip detector ~66 um pitch, 1.7 cm long
o Interest for OBELIX
x very high interest for z-trigger
x but additional read-out system will increase material budget
CONCLUSION: baseline is to keep HitOR in OBELIX-1 and we need an gain/cost evaluation (NOT IDENTIFIED)
* Powering discussion
- TJ-Monopix2 powering architecture
o power pads located on the short-side (with pads) => power lines horizontal along the rows
voltage drop appears between columns, but within 1 entire column same supply voltage
o threshold dispersion is mitigated by compensation circuits at the bottom
for local groups of columns (within which the supply voltages are similar)
- Note: lower analogue current sensors (ALPIDE, MIMOSIS) use vertical power distribution along columns
- OBELIX with horizontal powering (like TJ-Monopix2)
o almost no change to the pixel architecture
o requires pads all along the short side
=> large gaps between sensors along beam-axis
- OBELIX with vertical powering
o requires significant re-working of the pixel architecture and matrix
x introduce risks (potential delay) wrt validation of the detection performance
x manpower available at least in Strasbourg for that
o requires re-working of the interconnexion of the pixel matrix with the digital part at the bottom
o minimize gaps between sensors along beam-axis
o proposal by Strasbourg to use 7th metal layers to allow distribution from chip 2 chip and avoid power flex cable
- LDO regulators
o not present in TJ-Monopix2
o preferred option to simplify power distribution system on ladders
o initial design proposed by CPPM, but currently manpower issue
o proposal to contact Fachschule Dormunt who did regulators (for RD53?)
CONCLUSION
o baseline options is to stick to horizontal powering
BUT we need an assessment of tracking performance with the expected gaps (~500 um)
o alternatives can be studied BUT their benefits / risks ratio has to be carefully evaluated
* Analogue parts for monitoring
- We should consider having an ADC for monitoring bias, temperature, ...
CONCLUSION: need to identify manpower for that
* NEXT STEPS
- we currently target a submission in June 2022, though early to say how robust this timeline is, we should have one
- in the short-term: remote meeting on digital design and test-bench
- next large meeting in hybrid form before the end of 2021
There are minutes attached to this event.
Show them.
