Design considerations for a possible next CLICpix version

Design considerations for a possible next CLICpix version Pierpaolo Valerio

Issues with the current chip �Charge injection from discriminator output to the input pad. ◦ This is the most “serious” issue. It raises the minimum threshold significantly and creates a different threhsold between left/right pixels and between positive/negative polarity �Charge injection from digital side ◦ This issue is more limited and it causes increased noise for a certain range of clock frequencies �Compression bug ◦ Very simple logic bug that slows down the readout when using cluster/column compression

Design limitations �Small counters ◦ 4 bits TOA is not enough (even for a CLIC application) ◦ 4 bits TOT seems to be ok, but a longer counter would allow more accurate measurements ◦ 4 bits event counter results in really long and tedious testing routines �Small matrix (64 by 64 pixels) ◦ Small area increases the time it takes to get statistics �“Clunky” readout ◦ A few interface design choices resulted in a more complicated test setup than what was forseen

Architecture improvements �Larger Counters ◦ 5 bits TOA for sure ◦ 8 -9 bits TOT is possible – higher if the TOA counter is shared every two pixels ◦ Event counter could use the TOT register �Bigger matrix (128 by 128? ) �More complex readout ◦ 8/10 bit encoding for high speed readout �A few more IP blocks can be used (and tested)

Is it worth it? �Legitimate question: is a CLICpix redesign necessary? �A possible CLICpix 2 would undeniably be better than the first iteration ◦ Bugs can be solved and it can be improved to make data collection easier and faster �On the other hand, CLIC is a long term project and CLICpix 2 would still be a prototype built with a technology which would probably be obsolete when the design will need to be finalized

Possible timeframe �The analog part needs to be laid out again from scratch to merge structures among adjacent pixels and to reduce cross-talk �The digital part requires less work to be updated ◦ The only bug found in the logic took about a minute to correct �A more robust testbench for the digital side is required to avoid bugs �My estimate is that the design could be conceivably done in ~6 months, barring major issues being discovered