| 45 |
|
\item[TSC] The Trigger Sequencer Card or TSC~\cite{bib:specs:tsc} generate the |
| 46 |
|
40~MHz clock for the entire system and triggers as well, either |
| 47 |
|
internally via software or by accepting external inputs. It has up to four |
| 48 |
< |
electrical clock/trigger outputs, enough to drive the FEDs, and an optical clock/trigger |
| 49 |
< |
output for the FEC. |
| 50 |
< |
The TSC may also generate the RESET and CALIBRATION signal that are |
| 48 |
> |
electrical clock/trigger outputs, enough to drive the FEDs used during the |
| 49 |
> |
integration, and an optical clock/trigger output for the FEC. |
| 50 |
> |
The TSC may also generate the reset and calibration signal that are |
| 51 |
|
also encoded on the clock/trigger line.\\ |
| 52 |
|
\item[FED] The analog-to-digital conversion is done by special PCI FEDs~\cite{bib:fedpci}, |
| 53 |
|
with electrical differential analog input, mounted on |
| 54 |
|
PCI carrier boards and installed in an industrial PC. |
| 55 |
< |
The opto-electrical conversion of the analog signals is done externally by a 24-channel unit. |
| 55 |
> |
The opto-electrical conversion of the analog signals coming from the module under test |
| 56 |
> |
is done externally by a 24-channel unit. |
| 57 |
|
A setup containing 3 FEDs, with the electro-opical converter, is able |
| 58 |
|
to readout 48 APV; this is equivalent to 12 single sided modules |
| 59 |
|
%(four complete strings) |
| 61 |
|
%(one string plus one module). |
| 62 |
|
These figures are |
| 63 |
|
pefectly suited for the tests during the integration.\\ |
| 64 |
< |
For obvious reason the readout of the data from the APVs is not |
| 65 |
< |
synchronous with the L1 trigger. A crucial capability of the FED is the |
| 64 |
> |
Since the readout of the data from the APVs is not |
| 65 |
> |
synchronous with the L1 trigger, a crucial capability of the FED is the |
| 66 |
|
\textit{header finding}, i.e. the automatical tagging of the |
| 67 |
|
analog data stream from APV pairs with respect to the idle |
| 68 |
|
signals at its inputs. This is possible since the APVs embeds the |
| 69 |
|
analogue data stream within a {\em digital frame} made up of a leading |
| 70 |
< |
digital header and a trailing tick-mark. The peculiarity of the PCI FED |
| 71 |
< |
with respect to the VME FED that will be used in the experiment, other than having electrical inputs |
| 72 |
< |
instead of optical ones, is the timing system: the VME FED is able to |
| 73 |
< |
perform the header finding on each input channel independently; the PCI FED has |
| 74 |
< |
this capability only on the first channel of the eight available |
| 75 |
< |
and assumes that the all input signals are synchronised. |
| 76 |
< |
This makes the PLL-based time alignment procedure of crucial |
| 77 |
< |
importance in a setup with PCI FEDs. Furthermore, PCI FEDs are not |
| 78 |
< |
able to insert a programmable delay on their inputs and thus |
| 79 |
< |
it is important that the clock/trigger connections from the TSC to |
| 80 |
< |
FEDs have all the same delay. Last, PCI FEDs cannot perform an online |
| 81 |
< |
pedestal subtraction and zero suppression (they cannot run in |
| 82 |
< |
Processed Raw data nor in Zero Suppression mode). |
| 70 |
> |
digital header and a trailing tick-mark. |
| 71 |
> |
%The peculiarity of the PCI FED |
| 72 |
> |
%with respect to the VME FED that will be used in the experiment, other than having electrical inputs |
| 73 |
> |
%instead of optical ones, is the timing system: the VME FED is able to |
| 74 |
> |
%perform the header finding on each input channel independently; the PCI FED has |
| 75 |
> |
%this capability only on the first channel of the eight available |
| 76 |
> |
%and assumes that the all input signals are synchronised. |
| 77 |
> |
%This makes the PLL-based time alignment procedure of crucial |
| 78 |
> |
%importance in a setup with PCI FEDs. Furthermore, PCI FEDs are not |
| 79 |
> |
%able to insert a programmable delay on their inputs and thus |
| 80 |
> |
%it is important that the clock/trigger connections from the TSC to |
| 81 |
> |
%FEDs have all the same delay. Last, PCI FEDs cannot perform an online |
| 82 |
> |
%pedestal subtraction and zero suppression (they cannot run in |
| 83 |
> |
%Processed Raw data nor in Zero Suppression mode). |
| 84 |
|
\item[FEC] The special FEC used during the integration is the {\em FEC |
| 85 |
|
mezzanine} also installed into a PC on a PCI carrier. It supports |
| 86 |
|
the optical trigger/clock provided by the TSC and features an |
| 89 |
|
|
| 90 |
|
|
| 91 |
|
\subsubsection{Software} |
| 92 |
< |
The software used to carry out integration tests is {\em TrackerOnline}, the CMS |
| 93 |
< |
tracker implementation of a more general software, named |
| 94 |
< |
xDAQ~\cite{ref:xdaq}, which is the official CMS DAQ framework. |
| 92 |
> |
The software used to carry out integration tests is |
| 93 |
> |
based on the CMS general data acquisition framework |
| 94 |
> |
%{\em TrackerOnline}, the CMS |
| 95 |
> |
%tracker implementation of a more general software, |
| 96 |
> |
named xDAQ~\cite{ref:xdaq}. |
| 97 |
> |
% which is the official CMS DAQ framework. |
| 98 |
|
In place of a database as in the |
| 99 |
|
experiment version, the integration version of TrackerOnline uses a set of |
| 100 |
< |
xml files for all the configurations needed to perform a test run. |
| 100 |
> |
xml files for all the configurations needed to perform a test run. |
| 101 |
> |
A description of the xml configuration files follows. |
| 102 |
|
%, i.e. all the parameters needed by the devices and the |
| 103 |
|
%software involved in the test run, |
| 104 |
|
%\begin{figure}[bth!] |
| 108 |
|
%Part of the data is not shown for simplicity.} |
| 109 |
|
%\label{fig:fecmodulexml} |
| 110 |
|
%\end{figure} |
| 111 |
< |
\begin{description} |
| 112 |
< |
\item[Configuration of the DAQ hardware and software, daq.xml] The hardware |
| 113 |
< |
and software configuration of the DAQ is written in a single xml file, which |
| 114 |
< |
reflect the setup used for the test and has to be rarely changed |
| 115 |
< |
during the integration procedures. |
| 116 |
< |
\item[Configuration of the control system, fec.xml] The most important |
| 117 |
< |
part of this configuration section is the settings the FEC must |
| 118 |
< |
upload to the modules and AOHs and in general any configurable |
| 119 |
< |
$I^2C$ device, before starting the data |
| 120 |
< |
taking. Altough these settings are not specifically |
| 121 |
< |
related to the control system, it is duty of the control system to |
| 122 |
< |
write them to the devices' $I^2C$ registers and read them back for verification. |
| 123 |
< |
\item[Configuration of the readout, module.xml] All other information needed by the DAQ to |
| 124 |
< |
rearrange data coming from the FEDs is in module.xml that allows each |
| 125 |
< |
FEDs input channel to be mapped to an APV pair of a specific module as |
| 126 |
< |
identified by ring, CCU and $I^2C$ addresses (i.e. the correspondance |
| 127 |
< |
between readout coordinates and Control System coordinates); |
| 111 |
> |
The hardware and software configuration of the DAQ is written into the file |
| 112 |
> |
named daq.xml. It reflects the setup used for the test and has to be rarely changed |
| 113 |
> |
during the integration procedures. The system settings uploaded, and |
| 114 |
> |
read back for verification, by the FEC are contained into fec.xml. |
| 115 |
> |
The data decoding map (i.e., information needed to map each FED input to an APV |
| 116 |
> |
pair of a specific module) is written into module.xml. |
| 117 |
> |
|
| 118 |
> |
%\begin{description} |
| 119 |
> |
%\item[Configuration of the DAQ hardware and software, daq.xml] The hardware |
| 120 |
> |
% and software configuration of the DAQ is written in a single xml file, which |
| 121 |
> |
% reflect the setup used for the test and has to be rarely changed |
| 122 |
> |
% during the integration procedures. |
| 123 |
> |
%\item[Configuration of the control system, fec.xml] The most important |
| 124 |
> |
% part of this configuration section is the settings the FEC must |
| 125 |
> |
% upload to the modules and AOHs and in general any configurable |
| 126 |
> |
% $I^2C$ device, before starting the data |
| 127 |
> |
%taking. Altough these settings are not specifically |
| 128 |
> |
% related to the control system, it is duty of the control system to |
| 129 |
> |
% write them to the devices' $I^2C$ registers and read them back for verification. |
| 130 |
> |
%\item[Configuration of the readout, module.xml] All other information needed by the DAQ to |
| 131 |
> |
%rearrange data coming from the FEDs is in module.xml that allows each |
| 132 |
> |
%FEDs input channel to be mapped to an APV pair of a specific module as |
| 133 |
> |
%identified by ring, CCU and $I^2C$ addresses (i.e. the correspondance |
| 134 |
> |
%between readout coordinates and Control System coordinates); |
| 135 |
|
%Each row corresponds to an APV |
| 136 |
|
%pair, an AOH laser, an optical fibre and a FED input.\\ |
| 137 |
|
%The second table of module.xml reassembles the information on a module basis. |
| 138 |
|
%Here all the active modules are listed, with a row for every module. |
| 139 |
|
%The Control System coordinates are repeated both in module.xml and fec.xml, |
| 140 |
|
%so that they can be used as a pivot between the 3 tables.\\ |
| 141 |
< |
\end{description} |
| 141 |
> |
%\end{description} |
| 142 |
|
|
| 143 |
|
The tasks performed by the integration software are the following: |
| 144 |
|
execution of the commissioning runs needed to optimal adjust of the |
| 146 |
|
of the test runs with complete and automated logging; fast analysis |
| 147 |
|
for immediate feedback; archival of xml configuration files to log the |
| 148 |
|
test conditions; archival of the raw data. |
| 136 |
– |
|
| 137 |
– |
|
| 149 |
|
%\begin{figure} |
| 150 |
|
%\centering |
| 151 |
|
%\includegraphics[width=.9\textwidth]{Figs/integration_package.pdf} |
| 156 |
|
%\textit{Sheet}: a file.} |
| 157 |
|
%\label{fig:integration_package} |
| 158 |
|
%\end{figure} |
| 148 |
– |
|
| 159 |
|
%Figure~\ref{fig:integration_package} shows a scheme of the relations between all the software |
| 160 |
|
%components that will be described, the local files and the remote database. |
| 161 |
< |
|
| 162 |
< |
This is achieved by using a specific set of components of TrackerOnline. |
| 161 |
> |
This is achieved by using a specific set of components of integration |
| 162 |
> |
data acquisition software as summarized in the following. |
| 163 |
|
\begin{description} |
| 164 |
|
\item[FecTool.] |
| 165 |
|
FecTool is GUI based front-end to two standalone |
| 166 |
< |
applications deployed with TrackerOnline, FecProfiler |
| 166 |
> |
applications: FecProfiler |
| 167 |
|
and ProgramTest, aimed to ease the creation of the device |
| 168 |
|
description. |
| 169 |
|
FecProfiler is able to detect |
| 184 |
|
%Hence tests proceed with the data |
| 185 |
|
%readout from modules, which rely on . |
| 186 |
|
\item[The Integration Package.] |
| 187 |
< |
TrackerOnline as any xDAQ implementation requires an expert user as |
| 188 |
< |
many run-specific parameters must be set and there is no input |
| 189 |
< |
validation. |
| 187 |
> |
%TrackerOnline as any xDAQ implementation requires an expert user as |
| 188 |
> |
%many run-specific parameters must be set and there is no input |
| 189 |
> |
%validation. |
| 190 |
|
%\begin{figure} |
| 191 |
|
%\centering |
| 192 |
|
%\includegraphics[width=0.35\textwidth]{Figs/FedGuiMain.png} |
| 193 |
|
%\caption{Main GUI window.} |
| 194 |
|
%\label{fig:fedgui} |
| 195 |
|
%\end{figure} |
| 196 |
< |
The integration setup is mode more user-friendly by a special {\em |
| 196 |
> |
The integration setup is made more user-friendly by a special {\em |
| 197 |
|
Integration Package}, a GUI based front end that interacts with |
| 198 |
< |
TrackerOnline to automatically set all relevant parameters and to harvest all data at the end |
| 198 |
> |
the data aquisition program to automatically set all relevant parameters |
| 199 |
> |
and to harvest all data at the end |
| 200 |
|
of a run. The package is organized as a finite state machine by which |
| 201 |
|
the user can cycle between the various states, i.e. the following integration test steps: |
| 202 |
|
\begin{enumerate} |
| 203 |
< |
\item TrackerOnline initialisation (only once); |
| 203 |
> |
\item Daq initialisation (only once); |
| 204 |
|
\item choice of the the desired run; |
| 205 |
< |
\item execution of the run via TrackerOnline; |
| 205 |
> |
\item execution of the run via Daq program; |
| 206 |
|
\item on run completion (i.e. after a given number of events), stop |
| 207 |
|
data taking and execution of the fast data analysis; |
| 208 |
|
\item presentation of the run outcome on summary GUIs; |
| 235 |
|
\item[Find connections.] This commissioning run is used associate each |
| 236 |
|
FED input channel to a module. The procedure, repeated in sequence |
| 237 |
|
for all AOHs laser drivers, consists of switching on only a given |
| 238 |
< |
AOH laser driver while checking the signal on all the FED inputs. If |
| 238 |
> |
AOH laser driver at a time while checking the signal on all the FED inputs. If |
| 239 |
|
the difference of the signal seen on a FED channel is above |
| 240 |
|
a given threshold, the connection between that laser and input channel is tagged and stored |
| 241 |
|
in module.xml. |
| 248 |
|
signal are properly sampled by the FEDs. This requires also the clock |
| 249 |
|
to all the FEDs to be synchronous, but this is guaranteed |
| 250 |
|
by using cables equal in length between the TSC and the FEDs.\\ |
| 251 |
< |
The time alignment run uses of the periodic tick mark signal issued by |
| 251 |
> |
The time alignment run uses the periodic tick mark signal issued by |
| 252 |
|
the idle APVs every 70 clock cycles. The APV signals are sampled by FEDs in |
| 253 |
|
scope mode, i.e. without waiting for an header but continously, |
| 254 |
< |
sampling the inputs at the full clock frequency as with a 40~MSample |
| 254 |
> |
sampling the inputs at the full clock frequency as with a 40~MSample/s |
| 255 |
|
scope. The measurement is repeated after all the PLL delays are |
| 256 |
< |
icreased by the minimum delay step, 25/24~ns. After 24 such cycles the |
| 256 |
> |
increased by the minimum delay step, 25/24~ns. After 24 such cycles the |
| 257 |
|
idle APV output and thus the tick mark signal also are measured with |
| 258 |
< |
an effective 960~MSample scope. |
| 258 |
> |
an effective 960~MSample/s scope. |
| 259 |
|
\begin{figure} |
| 260 |
|
\centering |
| 261 |
|
\includegraphics[width=.6\textwidth]{Figs/tickmark.pdf} |
| 279 |
|
fec.xml. If the setup is correctly aligned in time, a further time |
| 280 |
|
alignment procedure should not propose delay corrections greater than |
| 281 |
|
$\sim 2$ns. |
| 282 |
< |
It is worth noticing that by the time alignment procedure all APVs are |
| 283 |
< |
made sampling synchronously, since in the integration setup AOH fibres |
| 284 |
< |
and ribbons are all equal in length. This is not important during |
| 285 |
< |
integration quality checks, as no external signal is ever measured, |
| 286 |
< |
but it would be so in trying to detect ionising particles. |
| 282 |
> |
%It is worth noticing that by the time alignment procedure all APVs are |
| 283 |
> |
%made sampling synchronously, since in the integration setup AOH fibres |
| 284 |
> |
%and ribbons are all equal in length. This is not important during |
| 285 |
> |
%integration quality checks, as no external signal is ever measured, |
| 286 |
> |
%but it would be so in trying to detect ionising particles. |
| 287 |
|
\item[Laser Scan.] By this commissioning run a scan of any bias and |
| 288 |
|
gain value pair is done to determine the optimal working point for |
| 289 |
|
each AOH. |
| 314 |
|
\end{center} |
| 315 |
|
\end{figure} |
| 316 |
|
% |
| 317 |
< |
For each trigger sent to FEDs, the is sampled twice and all other samplings fall |
| 317 |
> |
For each trigger sent to FEDs, the tick mark is sampled twice and all other samplings fall |
| 318 |
|
on the baseline. The tick mark's top samples are used to estimate the higher limit of the signal |
| 319 |
|
for a given gain/bias setting pair and the baseline samples provide an estimate of the lower limit. |
| 320 |
|
For each gain setting the tick mark top samples and the baseline samples are measured as a |
| 338 |
|
specific APV register, know as {\em VPSP}, which controls a voltage |
| 339 |
|
setting within the deconvolution circuitry. The procedure consists of |
| 340 |
|
a scan of VPSP values while acquiring data frames from modules in the |
| 341 |
< |
standard way, i.e. trigger sent to the modules and FEDs in |
| 342 |
< |
``header finding'' mode. |
| 343 |
< |
The optimal VPSP setting correspond to a pedestal baseline placed |
| 344 |
< |
around 1/3 of the available dynamic range, a good compromise to keep |
| 341 |
> |
standard way. |
| 342 |
> |
%%, i.e. trigger sent to the modules and FEDs in |
| 343 |
> |
%%``header finding'' mode. |
| 344 |
> |
In the final tracker operation the optimal VPSP setting correspond to a pedestal baseline placed |
| 345 |
> |
around 1/3 of the available dynamic range. This is a good compromise to keep |
| 346 |
|
the baseline not too close the lower saturation value while leaving a good |
| 347 |
|
range for particle signals, corresponding to $\sim 6$ MIP. |
| 348 |
+ |
During the integration tests the only important point is to keep the baseline |
| 349 |
+ |
away from the saturation levels; in such a way the module noise measurements will |
| 350 |
+ |
not be affected by the wrong common mode subtractions which are present in case |
| 351 |
+ |
of events with baseline saturation. |
| 352 |
|
At the end of the run a set of values are proposed to the user for |
| 353 |
< |
approval andin case written in the relevant xml file. |
| 353 |
> |
approval and in case written in the relevant xml file. |
| 354 |
|
\begin{figure} |
| 355 |
|
\begin{center} |
| 356 |
< |
\subfigure[Strip pedestals of a module in ADC counts vs.\ strip number.] |
| 356 |
> |
%\subfigure[Strip pedestals of a module in ADC counts vs.\ strip number.] |
| 357 |
> |
\subfigure[] |
| 358 |
|
{ |
| 359 |
|
\label{fig:saturationpedestal} |
| 360 |
|
\includegraphics[width=.45\textwidth]{Figs/saturation_pedestal.pdf} |
| 361 |
|
} |
| 362 |
|
\hspace{5mm} |
| 363 |
< |
\subfigure[Strip noise of a module in ADC counts vs.\ strip number.] |
| 363 |
> |
%\subfigure[Strip noise of a module in ADC counts vs.\ strip number.] |
| 364 |
> |
\subfigure[] |
| 365 |
|
{ |
| 366 |
|
\label{fig:saturationnoise} |
| 367 |
|
\includegraphics[width=.45\textwidth]{Figs/saturation_noise.pdf} |
| 368 |
|
} |
| 369 |
< |
\caption{The pedestal of strips after \#{}640 is low, approaching to the bottom of the |
| 370 |
< |
dynamic range, and their noise is therefore lower.} |
| 369 |
> |
\caption{Pedestal (left) and noise (right) vs. strip number for a 6 APV module. |
| 370 |
> |
The pedestals of strips after strip \#{}640 are low, approaching to the bottom of the |
| 371 |
> |
dynamic range. Their noise is therefore altered with respect to the not saturated |
| 372 |
> |
channels.} |
| 373 |
|
\label{fig:saturation} |
| 374 |
|
\end{center} |
| 375 |
|
\end{figure} |
| 377 |
|
since the default VPSP setting is adequate in most of the |
| 378 |
|
cases. Nevertheless, VPSP optimal values change considerably within |
| 379 |
|
the APV population and are strongly temperature dependent and is |
| 380 |
< |
tather common to have a stuation in which the pedestal of few readout |
| 380 |
> |
rather common to have a stuation in which the pedestal of few readout |
| 381 |
|
channels approaches to the lower edge of dynamic range |
| 382 |
|
(Fig.~\ref{fig:saturationpedestal}) resulting in a lower RMS (see |
| 383 |
|
Fig.~\ref{fig:saturationnoise}). The VPSP scan allows for this issue to be |
| 401 |
|
common to a given group of channels (tipically an entire APV). |
| 402 |
|
The common mode noise subtraction method implemented in ORCA and |
| 403 |
|
TrackerOnline is similar to that performed by the final FEDs.\\ |
| 404 |
< |
Noise comparison between different APV pairs requires a |
| 405 |
< |
renormalization, because of the difference in gain between the various |
| 406 |
< |
optical links. The normalization procedure relies on the digital |
| 404 |
> |
Because of the difference in gain between the various |
| 405 |
> |
optical links, noise comparison between different APV pairs requires a |
| 406 |
> |
normalization. This procedure relies on the digital |
| 407 |
|
headers whose amplitude, being the same on each APV, is used to |
| 408 |
|
estimate of the relative gain of optical links so to apply an |
| 409 |
|
appropriate correction. In such a way noise and gain are |
| 411 |
|
The normalisation factor is chosen so as to bring the normalised |
| 412 |
|
header height to 220 ADC counts, as measured in quality controls |
| 413 |
|
during the module production. This allowed the scaled measurements to be easily |
| 414 |
< |
compared with those done during module production tests.\\ |
| 415 |
< |
At the end of the run, pedestal ando noise profiles and distributions |
| 414 |
> |
compared with those done during module production tests~\cite{ref:modtest}.\\ |
| 415 |
> |
At the end of the run, pedestal and noise profiles and distributions |
| 416 |
|
are shown to the user. |
| 417 |
|
\begin{figure}[t!] |
| 418 |
|
\centering |
| 427 |
|
for each strip are plotted against the strip index. The first 256 strips belong to the |
| 428 |
|
first APV pair and are multiplexed to a single optical line and the strips from 257 to 512 |
| 429 |
|
belong to the second APV pair. It can be noted here that the |
| 430 |
< |
raw noise without normalisation suffers from a different gain of |
| 431 |
< |
optical links, corrected by the normalisation procedure.\\ |
| 430 |
> |
raw noise without normalisation reflecs the different gain of |
| 431 |
> |
optical links, this is corrected by the normalisation procedure.\\ |
| 432 |
|
If validated by the user, data are packed along with |
| 433 |
|
possible comments and sent to the central archive system, where they are processed |
| 434 |
|
again and made available on a web page. |
| 454 |
|
is very important to perform the test of as soon as possible. In |
| 455 |
|
fact, a safe removal and replacement of either an AOH or the MC is a |
| 456 |
|
difficult intervention possibly requiring the dismounting of many |
| 457 |
< |
modules already put in place. |
| 458 |
< |
safe removal of a MC from the shell \\ Since After the |
| 457 |
> |
modules already put in place. \\ |
| 458 |
> |
Since the |
| 459 |
|
I$^2$C test FecTool checks the identity of the components with respect |
| 460 |
< |
to the construction database. The results of the tests can then be |
| 460 |
> |
to the construction database an alarm issued in case of mismatch. |
| 461 |
> |
The results of the tests can then be |
| 462 |
|
monitored through a web page. |
| 463 |
|
\item[String] |
| 464 |
|
When the third and last module or double sided assembly is mounted on |
| 465 |
|
a string, all the commissioning runs described above are performed |
| 466 |
|
just after the I$^2$C communication tests. The ``Find |
| 467 |
< |
connections'' run allows for the full functionality to be checked. |
| 467 |
> |
connections'' run allows for the devices accessibility to be checked. |
| 468 |
|
Afterwards a ``Time Alignement'' run, a ``Laser scan'' run and |
| 469 |
< |
finally a ``Pedestal and Noise'' run with HV bias are performed. The |
| 469 |
> |
finally a ``Pedestal and Noise'' run with bias voltage at 400V are performed. The |
| 470 |
|
``Laser scan'' run is done limiting the laser gain to the lower value |
| 471 |
|
which is found to be enough for the integration setup needs. |
| 472 |
|
\item[Control Ring and Redundancy.] |
