Commit d2a1565d authored by David Cussans's avatar David Cussans

Merge branch 'master' of https://ohwr.org/project/fmc-mtlu-gw

parents 737d5bfc 5101290b
......@@ -4,50 +4,56 @@
0
1
Main_TLU.tex
12
12
10
14
14
0
Main_TLU.tex
TeX
135278587 4 -1 4701 -1 4702 75 75 1448 573 0 1 249 561 -1 -1 0 0 43 -1 -1 43 1 0 4702 -1 0 -1 0
403714043 0 -1 678 -1 2990 75 75 1448 573 0 1 217 0 -1 -1 0 0 43 -1 -1 43 1 0 2990 -1 0 -1 0
:\Dati\Latex files\2018 - 05 - TLU_Paper\TLU_paper.tex
TeX:UNIX
1159163 0 -1 0 -1 111 0 0 1913 677 0 1 241 51 -1 -1 0 0 34 -1 -1 34 1 0 111 -1 0 -1 0
ch_TLU_Preparation.tex
TeX
1060859 0 -1 2411 -1 2429 150 150 1523 648 0 1 41 255 -1 -1 0 0 43 -1 -1 43 1 0 2429 -1 0 -1 0
1060859 0 -1 16860 -1 19018 150 150 1523 648 0 1 41 765 -1 -1 0 0 43 -1 -1 43 1 0 19018 -1 0 -1 0
O:\LatexFiles\Glossary\myGlossary.tex
TeX
1060859 0 -1 1671 -1 1676 300 300 2213 977 0 1 393 204 -1 -1 0 0 61 -1 -1 61 1 0 1676 -1 0 0 0
ch_TLU_Hardware.tex
TeX
1060859 0 -1 4713 -1 4713 200 200 1573 698 0 1 1417 493 -1 -1 0 0 41 -1 -1 41 1 0 4713 -1 0 -1 0
1060859 0 -1 14258 -1 14258 200 200 1573 698 0 1 1169 697 -1 -1 0 0 41 -1 -1 41 1 0 14258 -1 0 -1 0
ch_TLU_clock.tex
TeX
1060859 0 -1 914 -1 1896 100 100 1473 598 0 1 809 204 -1 -1 0 0 31 -1 -1 31 1 0 1896 -1 0 -1 0
1060859 0 -1 31 -1 923 100 100 1473 598 0 1 385 85 -1 -1 0 0 31 -1 -1 31 1 0 923 -1 0 -1 0
DUT_signals.tex
TeX
1060859 0 -1 291 -1 313 75 75 1448 573 0 1 105 34 -1 -1 0 0 42 -1 -1 42 1 0 313 -1 0 -1 0
ch_TLU_triggerInputs.tex
TeX
17838075 0 -1 26160 -1 25586 100 100 1473 598 0 1 385 221 -1 -1 0 0 48 -1 -1 48 1 0 25586 -1 0 -1 0
17838075 0 -1 20962 -1 20962 100 100 1473 598 0 1 161 493 -1 -1 0 0 48 -1 -1 48 1 0 20962 -1 0 -1 0
ch_EventBuffer.tex
TeX
1060859 0 -1 2037 -1 2050 125 125 1498 623 0 1 225 697 -1 -1 0 0 44 -1 -1 44 1 0 2050 -1 0 -1 0
ch_TLU_Functions.tex
TeX
1060859 0 -1 1975 -1 3888 0 0 1386 472 0 1 233 561 -1 -1 0 0 39 -1 -1 39 1 0 3888 -1 0 -1 0
1060859 0 -1 2939 -1 2902 0 0 1386 472 0 1 201 323 -1 -1 0 0 39 -1 -1 39 1 0 2902 -1 0 -1 0
ch_TLU_IPBusRegs.tex
TeX
17838075 0 -1 7964 -1 8054 25 25 1411 497 0 1 289 306 -1 -1 0 0 45 -1 -1 45 1 0 8054 -1 0 -1 0
ch_EUDAQParameters.tex
TeX
1060859 0 -1 11640 -1 11739 175 175 1561 852 0 1 1081 934 -1 -1 0 0 45 -1 -1 45 1 0 11739 -1 0 -1 0
1060859 4 -1 6425 -1 6426 175 175 1561 852 0 1 1129 714 -1 -1 0 0 45 -1 -1 45 1 0 6426 -1 0 -1 0
ch_EUDAQProducer.tex
TeX
286273531 0 -1 1617 -1 2773 275 275 2188 952 0 1 521 884 -1 -1 0 0 -1 -1 -1 -1 1 0 2773 -1 0 -1 0
17838075 0 -1 32 -1 46 275 275 2188 952 0 1 409 0 -1 -1 0 0 44 -1 -1 44 1 0 46 -1 0 -1 0
ch_TLU_Appendix.tex
TeX
1060859 0 -1 189 -1 194 175 175 1548 673 0 1 377 51 -1 -1 0 0 37 -1 -1 37 1 0 194 -1 0 -1 0
1060859 0 -1 48 -1 72 175 175 1548 673 0 1 305 17 -1 -1 0 0 39 -1 -1 39 1 0 72 -1 0 -1 0
*Main_TLU.tex
>
*O:/LatexFiles/Glossary/myGlossary.tex
*//ads.bris.ac.uk/filestore/MyFiles/Staff3/phpgb/LatexFiles/Glossary/myGlossary.tex
*ch_TLU_Preparation
*ch_TLU_Hardware
*ch_TLU_clock
......
\chapter{DUT signals}\label{ch:DUTsignals}
In the old versions of the \gls{tlu} the direction of the signals on the \verb|HDMI*| connectors were pre-defined. The new hardware has separate lines for signals going into the \gls{tlu} and signals out of the \gls{tlu}. See section~\ref{ch:hwDUT} for further details.\\
\ No newline at end of file
In the old versions of the \gls{tlu} the direction of the signals on the \verb|HDMI*| connectors were pre-defined. The new hardware has separate lines for signals going into the \gls{tlu} and signals out of the \gls{tlu}. See section~\ref{ch:hwDUT} for further details. \\
\ No newline at end of file
%% Creator: Inkscape 0.48.3.1, www.inkscape.org
%% PDF/EPS/PS + LaTeX output extension by Johan Engelen, 2010
%% Accompanies image file 'tlu_trigger_logic2.pdf' (pdf, eps, ps)
%%
%% To include the image in your LaTeX document, write
%% \input{<filename>.pdf_tex}
%% instead of
%% \includegraphics{<filename>.pdf}
%% To scale the image, write
%% \def\svgwidth{<desired width>}
%% \input{<filename>.pdf_tex}
%% instead of
%% \includegraphics[width=<desired width>]{<filename>.pdf}
%%
%% Images with a different path to the parent latex file can
%% be accessed with the `import' package (which may need to be
%% installed) using
%% \usepackage{import}
%% in the preamble, and then including the image with
%% \import{<path to file>}{<filename>.pdf_tex}
%% Alternatively, one can specify
%% \graphicspath{{<path to file>/}}
%%
%% For more information, please see info/svg-inkscape on CTAN:
%% http://tug.ctan.org/tex-archive/info/svg-inkscape
%%
\begingroup%
\makeatletter%
\providecommand\color[2][]{%
\errmessage{(Inkscape) Color is used for the text in Inkscape, but the package 'color.sty' is not loaded}%
\renewcommand\color[2][]{}%
}%
\providecommand\transparent[1]{%
\errmessage{(Inkscape) Transparency is used (non-zero) for the text in Inkscape, but the package 'transparent.sty' is not loaded}%
\renewcommand\transparent[1]{}%
}%
\providecommand\rotatebox[2]{#2}%
\ifx\svgwidth\undefined%
\setlength{\unitlength}{526.93890012bp}%
\ifx\svgscale\undefined%
\relax%
\else%
\setlength{\unitlength}{\unitlength * \real{\svgscale}}%
\fi%
\else%
\setlength{\unitlength}{\svgwidth}%
\fi%
\global\let\svgwidth\undefined%
\global\let\svgscale\undefined%
\makeatother%
\begin{picture}(1,0.26872186)%
\put(0,0){\includegraphics[width=\unitlength]{tlu_trigger_logic2.pdf}}%
\put(0.13385461,0.23835781){\color[rgb]{0,0.25490196,0.76862745}\makebox(0,0)[rb]{\smash{clk_160 (MHz)}}}%
\put(0.13385461,0.19281173){\color[rgb]{0,0.25490196,0.76862745}\makebox(0,0)[rb]{\smash{in1}}}%
\put(0.13385461,0.14726565){\color[rgb]{0,0.25490196,0.76862745}\makebox(0,0)[rb]{\smash{in1_del_str}}}%
\put(0.13385461,0.10171957){\color[rgb]{0,0.25490196,0.76862745}\makebox(0,0)[rb]{\smash{in5}}}%
\put(0.13385461,0.01062742){\color[rgb]{0,0.25490196,0.76862745}\makebox(0,0)[rb]{\smash{trigger}}}%
\put(0.27960206,0.17307509){\makebox(0,0)[b]{\smash{t1}}}%
\put(0.55287853,0.15030206){\makebox(0,0)[b]{\smash{t2}}}%
\put(0.21887396,0.19736634){\makebox(0,0)[b]{\smash{a}}}%
\put(0.34033017,0.15182026){\makebox(0,0)[b]{\smash{b}}}%
\put(0.40105827,0.15182026){\makebox(0,0)[b]{\smash{c}}}%
\put(0.70469879,0.15182026){\makebox(0,0)[b]{\smash{d}}}%
\end{picture}%
\endgroup%
......@@ -86,6 +86,8 @@
\end{tikzpicture}
}
\newdateformat{monthyeardate}{%
\monthname[\THEMONTH], \THEYEAR}
%\usepackage{mathpazo}
%\usepackage[protrusion=true,expansion=true]{microtype}
......@@ -122,9 +124,10 @@
}
\makeatother
\author{Paolo Baesso}
\title{AIDA Trigger logic unit (TLU)}
\title{AIDA Trigger logic unit (TLU v1E)}
\date{\today}
\loadglsentries{O:/LatexFiles/Glossary/myGlossary.tex}
%\loadglsentries{O:/LatexFiles/Glossary/myGlossary.tex}
\loadglsentries{//ads.bris.ac.uk/filestore/MyFiles/Staff3/phpgb/LatexFiles/Glossary/myGlossary.tex}
%\input{O:/LatexFiles/Glossary/myGlossary.tex}
%\makeglossaries
......@@ -144,9 +147,12 @@
\null\vfill
\begin{flushleft}
\textit{Board \brd.}\newline
\textit{Documentation for \brd.}\newline
\newline
Paolo Baesso - \monthname, \the\year\newline paolo.baesso@bristol.ac.uk
Paolo Baesso - \monthname, \the\year
\newline paolo.baesso@bristol.ac.uk
\newline
\newline Please report any error or omission to the author.
\bigskip
\end{flushleft}
......
......@@ -8,10 +8,17 @@ The parameters must be included in the INI or CONF file passed to the main windo
\label{fig:EUDAQGui}
\end{figure}\\
Not all parameters are needed; if one of the parameters is not present in the files, the code will generally assume a default value, indicated in brackets in the following document \verb|[type, default]|.
\begin{alertinfo}{Case sensitiveness}
All parameters names are case sensitive!\\
Please ensure to use the correct capitalization.\\
A misspelled parameter will be ignored and its default value will be used instead.
\end{alertinfo}
\section{INI file}
\begin{description}
\item[initid] \verb|[string, "0"]| Does not serve any purpose in the code but can be useful to identify configuration settings used in a specific run. EUDAQ will store this information in the run data.
\item[initid] \verb|[string, "0"]| Does not serve any purpose in the code but can be useful to identify configuration settings used in a specific run. As an example, the user can write a mnemonic such as `Testbeam\_April' or `2017\_10\_init' to help identifying a specific configuration. EUDAQ will store this information in the run data.
\item[ConnectionFile] \verb|[string, "file://./FMCTLU_connections.xml"]| Name of the xml file used to store the information required to communicate with the hardware, such as its IP address and the location of the address map. The default location indicates a file that must be located in the \texttt{bin} folder.
\item[skipini] \verb|[int, 0]| When this flas is set, the producer will skip the whole initialization phase for the \gls{tlu}. This can be useful to avoid disturbing any other piece of hardware connected to the unit, as it avoid re-initializing the \gls{dac}s, \gls{hdmi} connectors, clock chip, etc.
\item[DeviceName] \verb|[string, "fmctlu.udp"]| The name of the type of hardware to be contacted by the IPBus.
\item[TLUmod] \verb|[string, "1e"]| Version of the \gls{tlu} hardware. Reserved for future use.
\item[nDUTs] \verb|[positive int, 4]| Number of \gls{dut} in the current \gls{tlu}. This is for future upgrades and should not require editing by the user.
......@@ -20,28 +27,34 @@ Not all parameters are needed; if one of the parameters is not present in the fi
\item[I2C\_CLK\_Addr] \verb|[positive int, 0x68]| \gls{i2c} address of Si5345 clock generator installed on the \gls{tlu}.
\item[I2C\_DAC1\_Addr] \verb|[positive int, 0x13]| \gls{i2c} address of \gls{dac} installed on the \gls{tlu}. The \gls{dac} is used to configure the threshold of the trigger inputs.
\item[I2C\_DAC2\_Addr] \verb|[positive int, 0x1F]| \gls{i2c} address of \gls{dac} installed on the \gls{tlu}. The \gls{dac} is used to configure the threshold of the trigger inputs.
\item[I2C\_ID\_Addr] \verb|[positive int, 0x50]| \gls{i2c} address the unique ID \gls{eeprom} installed on the \gls{tlu}. The chip is used to provide a unique identifier to each kit.
\item[I2C\_EXP1\_Addr] \verb|[positive int, 0x74]| \gls{i2c} address the bus expander used to select the direction of the \gls{hdmi} pins on the board.
\item[I2C\_EXP2\_Addr] \verb|[positive int, 0x75]| \gls{i2c} address the bus expander used to select the direction of the \gls{hdmi} pins on the board.
\item[I2C\_ID\_Addr] \verb|[positive int, 0x50]| \gls{i2c} address of the unique ID \gls{eeprom} installed on the \gls{tlu}. The chip is used to provide a unique identifier to each kit.
\item[I2C\_EXP1\_Addr] \verb|[positive int, 0x74]| \gls{i2c} address of the bus expander used to select the direction of the \gls{hdmi} pins on the board.
\item[I2C\_EXP2\_Addr] \verb|[positive int, 0x75]| \gls{i2c} address of the bus expander used to select the direction of the \gls{hdmi} pins on the board.
\item[I2C\_DACModule\_Addr] \verb|[positive int, 0x1C]| \gls{i2c} address of the \gls{dac} installed on the power module and used to control the \gls{pmt} outputs.
\item[PMT\_vCtrlMax] \verb|[float, 1]| value, in volts, of the maximum control voltage for the \gls{pmt}s. For EUDET telescopes this should normally be left to 1~V. If the \gls{tlu} is going to be used with different \gls{pmt}s, then a new value can be used but the hardware must be tweaked accordingly by changing the voltagi divider on the power module.
\item[I2C\_EXP1Module\_Addr] \verb|[positive int, 0x76]| \gls{i2c} address of the first expander used to control the indicators on the power module.
\item[I2C\_EXP2Module\_Addr] \verb|[positive int, 0x77]| \gls{i2c} address of the second expander used to control the indicators on the power module.
\item[intRefOn] \verb|[boolean, false]| If true, the \gls{dac}s installed on the \gls{tlu} will use their internal voltage reference rather than the one provide externally.
\item[VRefInt] \verb|[float, 2.5]| Value in volts for the internal reference voltage of the \gls{dac}s. The voltage is chosen by the chip manufacturer. This is only used if \verb|intRefOn= true|.
\item[VRefExt] \verb|[float, 1.3]| Value in volts for the external reference voltage of the \gls{dac}s. The voltage is determined by a circuit on the \gls{tlu} and the value of this parameter must reflect such voltage. This is only used if \verb|intRefOn= false|.
\item[CONFCLOCK] \verb|[boolean, true]| If true, the clock chip Si5345 will be re-configured when the INIT button is pressed (see figure~fig.\ref{fig:EUDAQGui}). The chip is configured via \gls{i2c} interface using a specific text file (see next parameter). After a power cycle, the chip is not configured and must be reconfigured to operate the \gls{tlu} correctly.
\item[CONFCLOCK] \verb|[boolean, true]| If true, the clock chip Si5345 will be re-configured when the INIT button is pressed (see figure~fig.\ref{fig:EUDAQGui}). The chip is configured via \gls{i2c} interface using a specific text file (see next parameter). After a power cycle, the chip is its default state and must be reconfigured to operate the \gls{tlu} correctly\footnote{As long as the unit is powered, the clock chip will maintain its setup, so the user can set this flag to 0 after the first initialization, in order to save time.}.
\item[CLOCK\_CFG\_FILE] \verb|[string, "./../user/eudet/misc/fmctlu_clock_config.txt"]| Name of the text file used to store the configuration values of the Si5345. The file can be generate using the Clockbuilder Pro software provided by \href{https://www.silabs.com/products/development-tools/software/clock}{SiLabs}.
\end{description}
\section{CONF file}
\begin{description}
\item[confid] \verb|[string, "0"]| Does not serve any purpose in the code but can be useful to identify configuration settings used in a specific run. EUDAQ will store this information in the run data.
\item[verbose] \verb|[int, 0]| Defines the level of output messages from the \gls{tlu}. 0 indicates minimum output.
\item[verbose] \verb|[int, 0]| Defines the level of output messages from the \gls{tlu}. 0= only errors (minimum), 1= warning (default), 2= info, 3= all.
\item[skipconf] \verb|[int, 0]| When this flag is set, EUDAQ will skip the whole configuration phase for the \gls{tlu}. When the user configures the hardware in EUDAQ, the board will remain in its current state and no configuration parameter will be written. This can be useful to avoid disturbing other pieces of electronics.
\item[HDMI1\_set] \verb|[unsigned int, 0b0001]| Defines the source of the signal on the pins for the \verb|HDMI1| connector. A 1 indicates that each pin pair is an driven by the \gls{tlu}, a 0 that they are left floating (with respect to the \gls{tlu}). This can be used to define the signal direction on each pin pair. The order of the pairs is as follow:\\
bit 0= CONT, bit 1= SPARE, bit 2= TRIG, trig 3= BUSY. Note that the direction of the DUTClk pair is defined in a separate parameter.\\
bit 0= CONT, bit 1= SPARE, bit 2= TRIG, bit 3= BUSY.\\
Note that the direction of the DUTClk pair is defined in a separate parameter (see HDMI\_clk).\\
Example to configure the connector to work with an EUDET device:\\
- in this configuration the BUSY line is driven by the device under test, so it is an input for the \gls{tlu} and should not be driven by it (bit 3= 0)\\
- TRIGGER line is an output for the \gls{tlu} so is driven by it (bit 2= 1)\\
- SPARE line is used to provide control signals, such as the reset signal to initialize the devices at the start of a run (\texttt{T$_0$}). It should be configured as driven by the \gls{tlu} (bit 1= 1)\\
- CONT is used by the \gls{tlu} to issue control commands and should be configured as a signal driven by the \gls{tlu} (bit 0= 1).\\
Therefore the value of this parameter would be 0x7 (b1110).
Therefore the value of this parameter would be 0x7 (b0111).
\item[HDMI2\_set] \verb|[unsigned int, 0b0001]| Defines the direction of the pins for the \verb|HDMI2| connector.
\item[HDMI3\_set] \verb|[unsigned int, 0b0001]| Defines the direction of the pins for the \verb|HDMI3| connector.
\item[HDMI4\_set] \verb|[unsigned int, 0b0001]| Defines the direction of the pins for the \verb|HDMI4| connector.
......@@ -52,6 +65,10 @@ Not all parameters are needed; if one of the parameters is not present in the fi
\item[HDMI3\_clk] \verb|[unsigned int, 1]| Defines the driving signal on the corresponding \gls{hdmi} connector.
\item[HDMI4\_clk] \verb|[unsigned int, 1]| Defines the driving signal on the corresponding \gls{hdmi} connector.
\item[LEMOclk] \verb|[boolean, true]| Defines whether a driving clock is to be provided on the differential LEMO connector of the \gls{tlu}. By default (value= 1), the clock is driven from the clock chip. If the value is set to 0 no clock will be driven.
\item[PMT1\_V] \verb|[float, 0.0]| Defines the control voltage for PMT 1, in volts. The value can range from 0 to 1 V.
\item[PMT2\_V] \verb|[float, 0.0]| Defines the control voltage for PMT 2, in volts. The value can range from 0 to 1 V.
\item[PMT3\_V] \verb|[float, 0.0]| Defines the control voltage for PMT 3, in volts. The value can range from 0 to 1 V.
\item[PMT4\_V] \verb|[float, 0.0]| Defines the control voltage for PMT 4, in volts. The value can range from 0 to 1 V.
\item[in0\_STR] \verb|[unsigned int, 0]| Defines the number of clock cycles used to stretch a pulse once a trigger is detected by the discriminator on input 0. This feature allows the user to modify the pulses that are then fed into the trigger logic within the \gls{tlu}.
A minimum lenght of 6.25~ns is provided if the value is 0. Any extra clock cycle extend the pulse by 6.25~ns (160~MHz clock). An example of the effect on the stretch setting is shown in figure~\ref{Fig:exampleExtendedTriggers}.
\item[in0\_DEL] \verb|[unsigned int, 0]| Defines the delay, in 160~MHz clock cycles, to be assigned to the discriminated pulse from input 0, in order to process the logic for the trigger. This can be used to compensate for differences in cable lengths for the signals used to create a trigger.
......
\chapter{EUDAQ Producer}\label{ch:eudaqprod}
\chapter{Control software}\label{ch:controlsw}
The preferred method to run the \gls{tlu} is by using the \href{https://github.com/eudaq/eudaq}{EUDAQ}\footnote{https://github.com/eudaq/eudaq} data acquisition framework.\\
A \gls{tlu} producer, based on C++, has been written to integrate the hardware in EUDAQ and is regularly pushed to the master repository. Checking out the latest EUDAQ software ensures to also have a stable version of the producer.\\
In addition to the EUDAQ producer, a set of Python scripts has been developed to enable users to configure and run the \gls{tlu} using a minimal environment without having to setup the whole data acquisition framework. The scripts are meant to reflect all the functionalities in the EUDAQ producers, i.e. using the scripts it should be possible to perform any operation available on the EUDAQ producer. However, they should only be used for local debugging and testing.\\
\begin{alertinfo}{Warning}
When fixing bus or developing new software for the \gls{tlu}, priority will be given to ensure that the EUDAQ producer is patched first. As a consequence, there is a higher chance to find bugs in the Python scripts.
\end{alertinfo}
\section{EUDAQ Producer}\label{ch:eudaqprod}
Current structure of a fmctlu producer event:
\lstset{language=XML}
\scriptsize
\scriptsize
\begin{lstlisting}
<Event>
<Type>2149999981</Type>
......@@ -60,3 +69,9 @@ Current structure of a fmctlu producer event:
\item[???] Event type from \gls{tlu} is missing?
\item[???] Input trig, i.e. the actual firing inputs should be in TRIGGER but there seems to be nothing there
\end{description}
\section{Python scripts}
The scripts used to debug work locally with the \gls{tlu} are located in a dedicated folder in the \href{https://github.com/PaoloGB/firmware_AIDA/tree/master/TLU_v1e/scripts}{firmware repository}\footnote{https://github.com/PaoloGB/firmware\_AIDA/tree/master/TLU\_v1e/scripts} and rely on additional packages and software.
First of all, the user should download the \href{https://github.com/PaoloGB/firmware_AIDA/tree/master/packages}{packages} used to control the various components of the hardware\footnote{https://github.com/PaoloGB/firmware\_AIDA/tree/master/packages}. It is also necessary to have a local installation of \href{https://ipbus.web.cern.ch/ipbus/doc/user/html/index.html}{IPBUS and uHAL}\footnote{https://ipbus.web.cern.ch/ipbus/doc/user/html/index.html}.\\
Once all the necessary packages have been installed and the environment is set to point to the right folders, it is possible to run the \verb|startTLU_v1e.py| script to start an interface that allows to operate the \gls{tlu}.
\ No newline at end of file
\chapter{Appendix}\label{ch:appendix}
\section{Layout of Enclustra FPGA.}
\includepdf[link,pages={1}]{./Docs/PM3TopView.pdf}
\section{Connections between TLU and FPGA package.}
\includepdf[link,pages=-, angle=90]{./Docs/Connections.pdf}
\includepdf[link,pages=-, angle=90]{./Docs/schematics.pdf}
\ No newline at end of file
\section{Schematics for main TLU electronics.}
\includepdf[link,pages=-, angle=90]{./Docs/schematics.pdf}
\section{Schematics for LED and PMT power module.}
\includepdf[link,pages=-, angle=90]{./Docs/schematicsLED.pdf}
\ No newline at end of file
\chapter{Functions}\label{ch:functions}
The following is a list of files containing the code for the \gls{tlu}:
\begin{itemize}
\item \verb|./eudaq2/user/eudet/misc/fmctlu_runcontrol.ini|:\newline initialization file for the hardware. The location of the file can be passed to the EUDAQ code in the \gls{gui}.
\item \verb|./eudaq2/user/eudet/misc/fmctlu_runcontrol.conf|:\newline configuration file. It contains all the parameters to be loaded in the \gls{tlu} at the beginning of the run. If this file is not found, EUDAQ will use a list of default settings. The location of the file (and its name) can be passed to the EUDAQ code in the \gls{gui}.
\item \verb|./eudaq2/user/eudet/misc/fmctlu_connection.xml|:\newline define the IP address and address map of the \gls{tlu}. The one listed is the default location for the file. A different location can be specified with the \verb|ConnectionFile| option in the \emph{conf} file for the \gls{tlu}.
\item \verb|./eudaq2/user/eudet/misc/fmctlu_address.xml|:\newline address map for the \gls{tlu}. The location of the file is specified in the \verb|fmctlu_connection.xml| file.
\item \verb|./eudaq2/user/eudet/misc/fmctlu_clock_config.txt|:\newline configuration for the Si5345 clock chip. In order for the hardware to work a configuration file must be present. Those listed are the default name and location for the file; a different file can be specified with the \verb|CLOCK_CFG_FILE| option in the \emph{conf} file for the \gls{tlu}.
\item \verb|./eudaq2/user/eudet/misc/aida_tlu_test.ini|:\newline initialization file for the hardware. The location of the file can be passed to the EUDAQ code in the \gls{gui}.
\item \verb|./eudaq2/user/eudet/misc/aida_tlu_test.conf|:\newline configuration file. It contains all the parameters to be loaded in the \gls{tlu} at the beginning of the run. If this file is not found, EUDAQ will use a list of default settings. The location of the file (and its name) can be passed to the EUDAQ code in the \gls{gui}.
\item \verb|./eudaq2/user/eudet/misc/aida_tlu_test_connection.xml|:\newline define the IP address and address map of the \gls{tlu}. The one listed is the default location for the file. A different location can be specified with the \verb|ConnectionFile| option in the \emph{conf} file for the \gls{tlu}.
\item \verb|./eudaq2/user/eudet/misc/aida_tlu_test_address.xml|:\newline address map for the \gls{tlu}. The location of the file is specified in the \verb|fmctlu_connection.xml| file.
\item \verb|./eudaq2/user/eudet/misc/aida_tlu_test_clock_config.txt|:\newline configuration for the Si5345 clock chip. In order for the hardware to work a configuration file must be present. Those listed are the default name and location for the file; a different file can be specified with the \verb|CLOCK_CFG_FILE| option in the \emph{conf} file for the \gls{tlu}.
\item \verb|./eudaq2/user/eudet/module/src/FMCTLU_Producer.cc|:\newline eudaq producer for the \gls{tlu}. Contains the methods to initialize, configure, start, stop the \gls{tlu} producer.
\item \verb|./eudaq2/user/eudet/hardware/src/FmctluController.cc|:\newline Contains the definition of the hardware class for the \gls{tlu} and the methods to set and read from its hardware, such as clock chip, DAC, etc. This lever is abstract with respect to the actual hardware, so that if a future version of the board uses different components it should be possible to re-use this code.
\item \verb|./eudaq2/user/eudet/hardware/include/FmctluController.hh|:\newline Headers for the controller.
\item \verb|./eudaq2/user/eudet/hardware/src/FmctluController.cxx|:\newline Executable for the controller.
\item \verb|./eudaq2/user/eudet/hardware/src/FmctluHardware.cc|:\newline This is the code that deals with the actual hardware on the \gls{tlu}, and contains specific instructions for the chips mounted in the current version. It contains several classes for the ADC, the clock chip, the I/O expanders etc.
\item \verb|./eudaq2/user/eudet/hardware/include/FmctluHardware.hh|:\newline Header for the hardware.
\item \verb|./eudaq2/user/eudet/hardware/src/FmctluI2c.cc|:\newline core functions used to read and write from \gls{i2c} compatible slaves.
\item \verb|./eudaq2/user/eudet/hardware/include/FmctluI2c.hh|:\newline Headers for the \gls{i2c} core.
\item \verb|./eudaq2/user/eudet/hardware/src/AidaTluController.cc|:\newline Contains the definition of the hardware class for the \gls{tlu} and the methods to set and read from its hardware, such as clock chip, DAC, etc. This lever is abstract with respect to the actual hardware, so that if a future version of the board uses different components it should be possible to re-use this code.
\item \verb|./eudaq2/user/eudet/hardware/include/AidaTluController.hh|:\newline Headers for the controller.
\item \verb|./eudaq2/user/eudet/hardware/src/AidaTluController.cxx|:\newline Executable for the controller.
\item \verb|./eudaq2/user/eudet/hardware/src/AidaTluHardware.cc|:\newline This is the code that deals with the actual hardware on the \gls{tlu}, and contains specific instructions for the chips mounted in the current version. It contains several classes for the ADC, the clock chip, the I/O expanders etc.
\item \verb|./eudaq2/user/eudet/hardware/include/AidaTluHardware.hh|:\newline Header for the hardware.
\item \verb|./eudaq2/user/eudet/hardware/src/AidaTluI2c.cc|:\newline core functions used to read and write from \gls{i2c} compatible slaves.
\item \verb|./eudaq2/user/eudet/hardware/include/AidaTluI2c.hh|:\newline Headers for the \gls{i2c} core.
\end{itemize}
\section{Functions}
......
......@@ -6,9 +6,9 @@ Board \brd is an evolution of the miniTLU designed at the \gls{uob}. The board s
The board must be plugged onto a \gls{fmc} carrier board with an \gls{fpga} in order to function correctly. The connection is achieved using a low pin count \gls{fmc} connector. The list of the pins used and the corresponding signal within the \gls{fpga} are provided in appendix at page~\pageref{ch:appendix}.\\
\subsubsection{Device under test}\label{ch:dut}
The \gls{dut}s are connected to the \gls{tlu} using standard size \gls{hdmi} connectors\footnote{In the miniTLU hardware there were mini\gls{hdmi} connectors.}.\\
The \gls{dut}s are connected to the \gls{tlu} using standard size \gls{hdmi} connectors\footnote{In the miniTLU hardware these were mini \gls{hdmi} connectors.}.\\
In the current version of the hardware, up to four \gls{dut}s can be connected to the board. In this document the connectors will be referred to as \verb|HDMI1|, \verb|HDMI2|, \verb|HDMI3| and \verb|HDMI4|.\\
The connectors expect 3.3~V \gls{lvds} signals and are bi-directional, i.e. any differential pair can be configured to be an output (signal from the TLU to the DUT) or an input (signals from the DUT to the TLU) by using half-duplex line transceivers. Figure~\ref{fig:LVDSTransceiver} illustrates how the differential pairs are connected to the transceivers.
The connectors operate with 3.3~V \gls{lvds} signals and are bi-directional, i.e. any differential pair can be configured to be an output (signal from the TLU to the DUT) or an input (signals from the DUT to the TLU) by using half-duplex line transceivers. Figure~\ref{fig:LVDSTransceiver} illustrates how the differential pairs are connected to the transceivers.
\begin{alertinfo}{Note}
The input part of the transceiver is configured to be always on. This means that signals going \emph{into} the \gls{tlu} are always routed to the logic (\gls{fpga}). By contrast, the output transceivers have to be enabled and are off by default: signal sent from the logic to the \gls{dut}s cannot reach the devices unless the corresponding enable signal is active.
\end{alertinfo}
......@@ -129,7 +129,23 @@ The \gls{cdr} is used in conjunction with the \gls{sfp} cage to recover data and
The clock for \brd can be generated using various external or internal references (see section~\ref{ch:clock} for further details). In order to reduce any jitter from the clock source and to provide a stable clock, the board hosts a Si5345 clock generator that needs to be configured via \gls{i2c} interface.\\
The configuration involves writing $\thicksim$380 register values. A configuration file, containing all the register addresses and the corresponding values, can be generated using the ClockBuilder tool available from \href{http://www.enclustra.com/en/home/}{Silicon Labs}.\\
The registers addresses between 0x026B and 0x0272 contain user-defined values that can be used to identify the configuration version: it is advisable to check those registers and check that they contain the correct code to ensure that the chip is configured according to the \gls{tlu} specifications. As an indication, files generated for the current version of the \gls{tlu} should have a configuration identifier in the form \verb|TLU1E_XX|, where \verb|XX| is a sequential number.\\
\begin{alertinfo}{TLU Producer}
When using the TLU producer to configure hardware, the location of the configuration file can be specified by setting the \texttt{CLOCK\_CFG\_FILE} value in the \emph{conf} file for the producer.\\
\begin{alertinfo}{\gls{tlu} Producer}
When using the \gls{tlu} producer to configure hardware, the location of the configuration file can be specified by setting the \texttt{CLOCK\_CFG\_FILE} value in the \emph{conf} file for the producer.\\
If no value is specified, the software will look for the configuration file \texttt{../conf/confClk.txt} i.e. if the \texttt{euRun} binary file is located in \texttt{./eudaq/bin}, then the default configuration file should reside in \texttt{./eudaq/conf}. The configuration will produce an error if the file is not found.
\end{alertinfo}
\section{Power module and led}\label{ch:frontpanel}
The \gls{led}s and \gls{pmt} connectors on the front panel are part of an auxiliary board installed together with the \brd. All the functionalities on the board, such as the indicators and the \gls{dac} are controlled via \gls{i2c} bus.\\
Is the \gls{tlu} is controlled using EUDAQ, the \gls{dac} can be steered by means of a parameter in the configuration file (see section~\ref{ch:EUDAQPar} for details).\\
Three green \gls{led} on the front panel are used to indicate the presence of power (+12 V) and the correct functioning of the +5 V and -5 V voltage regulators. Further indicators are assigned to the \gls{hdmi} and trigger inputs to provide information on their status. These indicators are \gls{rgb}. At the moment there is not defined scheme to assign a meaning to each colour.\\
The LEMO connectors used to power the \gls{pmt}s are wired according to the following scheme, inherited from what already in use in beam telescopes:
\begin{enumerate}
\item POWER: +12~V
\item not connected
\item CONTROL, voltage signal from 0 to +1~V
\item GND
\end{enumerate}
\begin{alertinfo}{\gls{tlu} Control voltage on modified units}
Some users requested the possibility to use different types of \gls{pmt}s. To enable this, a few power modules have been modified to provide +5~V (instead of +12~V) and to have a maximum control voltage of 1.1~V (instead of 1~V).\\
The modified units are clearly labelled and use different style of \gls{pmt} connectors, so that confusion should be minimized.
\end{alertinfo}
\ No newline at end of file
\chapter{Introduction}\label{ch:introduction}
This manual describes the AIDA \gls{tlu} designed for the \href{http://aida2020.web.cern.ch/}{AIDA-2020 project} by David Cussans\footnote{University of Bristol, Particle Physics group} and Paolo Baesso\footnote{University of Bristol, Particle Physics group}.\\
Congratulations on acquiring an AIDA2020 \gls{tlu}. We hope that the unit will help you to collect lots of useful data during your hardware tests.\\
This manual describes the \gls{tlu} designed for the \href{http://aida2020.web.cern.ch/}{AIDA-2020 project} by David Cussans\footnote{University of Bristol, Particle Physics group} and Paolo Baesso\footnote{University of Bristol, Particle Physics group}.\\
The unit is designed to be used in High Energy Physics beam-tests and provides a simple and flexible interface for fast timing and triggering signals at the AIDA pixel sensor beam-telescope.\\
The current version of the hardware is an evolution of the \href{https://twiki.cern.ch/twiki/bin/view/MimosaTelescope/TLU}{EUDET-TLU} and the \href{https://www.ohwr.org/projects/fmc-mtlu/wiki}{miniTLU} and is shipped in a metallic case that includes an \gls{fpga} board and the \gls{tlu} \gls{pcb}: the \gls{fpga} is responsible for all the logic functions of the unit, while the \gls{pcb} contains the clock chip, discriminator and interface blocks needed to communicate with other devices.\\
The current version of the hardware is an evolution of the \href{https://twiki.cern.ch/twiki/bin/view/MimosaTelescope/TLU}{EUDET-TLU} and the \href{https://www.ohwr.org/projects/fmc-mtlu/wiki}{miniTLU} and is shipped in a metal enclosure that includes an \gls{fpga} board, the \gls{tlu} \gls{pcb} and an additional power module: the \gls{fpga} is responsible for all the logic functions of the unit, while the \gls{pcb} contains the clock chip, discriminator and interface blocks needed to communicate with other devices. The power module contains programmable \gls{dac} to power photomultipliers and \gls{led} indicators.\\
The current version of the \gls{pcb} is \brd and is designed to plug onto a carrier \gls{fpga} board like any other \gls{fmc} mezzanine board, although its form factor does not comply with the ANSI-VITA-57-1 standard.\\
\section{Overview}
The AIDA \gls{tlu} provides timing and synchronization signals to test-beam readout hardware.\\
The hardware can provide an internally generated low-jitter 40~MHz clock or can accept and external clock reference.\\
It accepts the asynchronous trigger signals from up to six external sources, such as beam-scintillators, and generate synchronous signals (including global trigger or control signals) to send to up to four devices under tests. The logic function used to generate the trigger can be defined by the user among all the possible logic combinations of the inputs.\\
Depending on the chosen mode of operation, the \gls{tlu} can accept busy signals or other veto signals from \gls{dut}s and react accordingly, for instance avoinding any further trigger until all the busy signals have been de-asserted.\\
Whenever a global trigger is generated by the unit, a 48-bit time-stamp is attached to it. This time stamp is based on the 40~MHz clock. Additionally ???\\
The configuration parameters and data are sent and received via the \href{https://www.ohwr.org/projects/ipbus}{IPbus}. IPbus is a simple way to control and communicate TCA-based hardware via the UDP/IP protocol.
When used for within AIDA-2020 specifications, the hardware generates a low-jitter 40~MHz clock or can accept an external clock reference. The external reference clock frequency is not required to be 40~MHz but other values require a dedicated configuration of the clock circuitry on the board. Similarly, by changing the configuration file it is possible to operate the hardware at different clock frequencies.\\
The \gls{tlu} accepts asynchronous trigger signals from up to six external sources, such as beam-scintillators, and generate synchronous signals (including global trigger or control signals) to send to up to four \gls{dut}. The logic function used to generate the trigger can be defined by the user among all the possible logic combinations of the inputs.\\
Depending on the chosen mode of operation, the \gls{tlu} can accept busy signals or other veto signals from \gls{dut}s and react accordingly, for instance avoiding any further trigger until all the busy signals have been de-asserted.\\
Whenever a global trigger is generated by the unit, a 48-bit coarse time-stamp is attached to it. This time stamp is based on the internal clock. The unit also records a fine-grain time stamp with 780~ps resolution for each signal involved in the trigger decision.\\
The configuration parameters and data are sent and received via the \href{https://www.ohwr.org/projects/ipbus}{IPbus} which provides a simple way to control and communicate TCA-based hardware via the UDP/IP protocol.\\
The \gls{tlu} is shipped with an \gls{fpga} board already programmed with the latest version of the firmware needed to operate the unit. New features and bug fixes are continuously being implemented by the developing team and it is possible to flash the unit with a new firmware as described in section~\ref{ch:flashFPGA}.\\
The unit requires 12~V to operate. Power can be provided using the circular socket located on the back panel. See section~\ref{ch:backpanelintro} for details on compatible connectors.\\
During normal operation the current drawn by the unit is about 1~A.\\
\section{Hardware modules}\label{ch:hardwaretypes}
The unit is provided in two different configurations: a table-top enclosure and a 19"-rack mount enclosure. The difference is only cosmetic; the hardware inside the unit is identical\footnote{With the only exception that the 10"-rack unit has and additional \gls{lcd}.} so the information contained in the rest of this manual apply to both types of \gls{tlu} unless otherwise specified.
\section{FPGA}
The \gls{tlu} is shipped with an \gls{fpga} board already programmed with the latest version of the firmware needed to operate the unit.\\
\subsection{Table-top unit: front panel}\label{ch:frontpanel}
The front panel of the \gls{tlu} is shown in figure~\ref{fig:tabletop} (top); from left to right, the main elements are:
\begin{itemize}
\item \gls{sfp} cage
\item 4 \gls{hdmi} connectors for devices under test. Each connector has a \gls{rgb} LED used to indicate the port status (see section~\ref{ch:frontpanelintro}).
\item 1 LEMO connector for \gls{lvds} clock input/output. This is a 2-pin LEMO series 00 connector\footnote{Part number EPG.00.302.NLN. An example of mating part is LEMO FGG.00.302.CLAD35}. A \gls{rgb} \gls{led} indicator is used to signal whether the port is configured as input or output.
\item 6 LEMO Trigger inputs. These are standard 1-pin LEMO connectors\footnote{LEMO EPK.00.250.NN. Mates with any LEMO 00.250 connector}. Each input has a \gls{rgb} \gls{led} indicator.
\item 4 LEMO connectors to provide power to photomultipliers. This is a 4-pin connector with 9-mm diameter\footnote{LEMO part number EXP.0S.304.HLN. Mates with LEMO part FFA.0S.304.CLAC44 or similar.}. For the pin-out see section~\ref{ch:frontpanel}.
\begin{alertinfo}{Note}
To reduce the cost of a unit, some modules are not equipped with these connectors and the front panel holes are blanked by a plastic board.\\
If necessary, it is possible to solder the connectors at a later stage, since all the necessary circuitry is present. This requires disassembling the unit, removing the top cover. See section~\ref{ch:inspection} for details.
\end{alertinfo}
\item Green \gls{led} indicators for power (+12 V) and regulators (+5 V and -5 V).
\end{itemize}
\begin{figure}
\centering
\includegraphics[width=.990\textwidth]{./Images/TLU_front_back.pdf}
\caption{View of the table-top TLU front (top) and back (bottom) panels.}
\label{fig:tabletop}
\end{figure}
\subsection{Table-top unit: back panel}\label{ch:backpanelintro}
The \gls{tlu} back panel is shown in figure~\ref{fig:tabletop} (bottom); from left to right, the main elements are:
\begin{itemize}
\item RJ45 connector: this is the connector used to communicate with the hardware using IPBus.
\item \gls{usb}-B port used to flash the internal logic with a new version of the firmware. See section\ref{ch:fpgahardware} for details.
\begin{alertinfo}{Note}
This port should be left disconnected if planning to use the self-boot capability of the internal logic. If a cable is detected, the \gls{fpga} will not load the pre-flashed firmware at power-up.
\end{alertinfo}
\item \gls{usb}-B port used to communicate with the \gls{fpga} \gls{uart} port.
\item Power connector\footnote{All TLUs shipped after 17/06/2018 use Switchcraft 721A; mates with a $\phi$~5.5 mm jack with $\phi$~2.5 mm central pin. For instance use Lumberg 1634 02.\\ TLUs shipped before that date use Switchcraft 722A instead, which mates with a $\phi$~5.5 mm jack with $\phi$~2.1 mm central pin. For instance use Lumberg 1633 02. Only 3 units are currently still using the 2.1~mm connector.}. Central pin is +12 V. It is recommended to use a power supply capable of providing at least 1~A.
\end{itemize}
A cooling fan is also mounted on the back panel.
\subsection{Rack mount unit: front and back panels}\label{ch:rackmountpanel}
The front and back panels for the 19"-rack unit are shown in figure~\ref{fig:rackmountpanels}. All the components are identical to those of the table-top enclosure with the following exceptions:
\begin{itemize}
\item this version has a \gls{lcd} used to display information.
\item the unit is powered with 220~V (AC) instead of 12~V (DC). A standard mains lead\footnote{IEC 60320 type C13.} is required.
\item The \gls{usb} ports are placed on the front of the unit leaving only the RJ45 and power connectors on the back.
\item A power switch is located on the front panel.
\end{itemize}
\begin{figure}
\centering
\includegraphics[width=.990\textwidth]{./Images/TLU_19rack.pdf}
\caption{View of the 10"-rack mount TLU front (top) and back (bottom) panels.}
\label{fig:rackmountpanels}
\end{figure}
\section{Setup}\label{ch:setup}
At the moment of shipping, each \gls{tlu} is pre-configured with the most recent version of the firmware. It is therefore possible to power the unit and start using it almost immediately. The following steps are required to use the unit:
\begin{enumerate}
\item Ensure no \gls{usb} cable is plugged in the unit
\item Power the unit using the provided power supply (+12~V) or an equivalent power supply. The pre-configured firmware will automatically load.
\item Plug an Ethernet cable in the back panel and connect it to the computer used to run the control software. Note that currently the unit uses a pre-defined IP address of 192.168.200.30. In future version of the firmware the address will be configurable.
\item Use the control software to configure the unit. In particular, after each power up it is necessary to re-configure the clock chip. See chapter~\ref{ch:controlsw} for details on the software and chapter~\ref{ch:clock} for details on the clock chip.
\end{enumerate}
\section{FPGA and firmware}\label{ch:fpgahardware}
The firmware developed at University of Bristol is targeted to work with the Enclustra AX3 board, which must be plugged onto a PM3 base, also produced by \href{http://www.enclustra.com/en/home/}{Enclustra}. The firmware is written on the \gls{fpga} using a \gls{jtag} interface. Typically a breakout board will be required to connect the Xilinx programming cable to the Enclustra PM3. All these components are included in the \gls{tlu} enclosure so the user can upload a new version of the firmware by simply connecting a \gls{usb}-B cable in the back panel of the unit.\\
At the time of writing this work\footnote{Oct 2017} the AX3 is the only \gls{fpga} for which a firmware has been developed. However, we plan to ship future versions of the \gls{tlu} with a custom made \gls{fpga} designed by Samer Kilani.
At the time of writing this work\footnote{\monthyeardate\today} the AX3 is the only \gls{fpga} for which a firmware has been developed. However, we plan to ship future versions of the \gls{tlu} with a custom made \gls{fpga} designed by Samer Kilani.\\
Each unit is shipped with the latest version of the firmware written onto its boot loader \gls{eeprom}; at power up, the unit will automatically retrieve the firmware from the \gls{eeprom} and program itself.
\begin{alertinfo}{Note}
If the \gls{fpga} detects a programming cable connected it will not load the firmware from its memory after a power cycle.\\
It is recommended to leave the \gls{usb} cable disconnected from the back panel unless there is the intention to re-program the firmware.
\end{alertinfo}
The latest version of the firmware can be found on the project github repository (named \href{https://github.com/PaoloGB/firmware_AIDA}{firmware\_AIDA}).\\
The user can decide to configure the unit with a new version of the firmware that will remain active until the \gls{tlu} is powered off (standard programming). It is also possible to write the \gls{eeprom} to replace boot program with a new one (configuration memory programming). Both procedures are described below.
Programming the \gls{fpga} requires the Vivado Lab Tools, available free on the \href{https://www.xilinx.com/support/download.html}{on the Xilinx website}\footnote{https://www.xilinx.com/support/download.html}. Depending on the hardware installed internally, some additional drivers might be required to correctly use the \gls{jtag} cable.\\
At the time of writing, the preferred cable is the Digilent HS2 and the corresponding driver package is ADEPT 2, available on the \href{https://reference.digilentinc.com/reference/software/adept/start}{Digilent website}\footnote{https://reference.digilentinc.com/reference/software/adept/start}.
\subsection{Standard programming}\label{ch:flashFPGA}
Updating the firmware on the \gls{tlu} requires writing a bit stream file to its \gls{fpga}.
This operation is performed using the left \gls{usb} port located on the back panel, labelled \verb"FPGA PROGRAMMING" in figure~\ref{ch:backpanelintro}.\\
Once the Vivado tools have been installed the user should also install the drivers for the programming cable in the enclosure (see previous section for software sources).\\
The bit stream is provided as a \verb".bit" file. They can be found on the firmware \href{https://github.com/PaoloGB/firmware_AIDA/tree/master/bitFiles}{git repository} for the \gls{tlu}\footnote{https://github.com/PaoloGB/firmware\_AIDA/tree/master/bitFiles}.\\
Once these prerequisites are met, the procedure is as follows:
\begin{enumerate}
\item Open the Vivado tools and select "Hardware manager", figure\ref{fig:hw_open}
\item Select open target
\item Identify the cable corresponding to the unit to be written and click open. The cable identifier is generally written on the back panel of the \gls{tlu}. If only one programming cable is connected to the computer, it is possible to use the auto-connect option.\\
Once done, the Vivado window will be populated, showing the cable and the \gls{fpga} attached to it.
\item Right click on the \gls{fpga} (typically xc7...) and select \verb"Program device" (see figure~\ref{fig:hw_addMemory})
\item Locate the \verb".bit" file to be used and program
\end{enumerate}
\begin{figure}
\centering
\includegraphics[width=.80\textwidth]{./Images/hw_open.jpg}
\caption{Vivado interface.}\label{fig:hw_open}
\end{figure}
\begin{figure}
\centering
\includegraphics[width=.80\textwidth]{./Images/AddMemory.png}
\caption{Program interface.}\label{fig:hw_addMemory}
\end{figure}
\subsection{Configuration memory programming}
The procedure to write a permanent program in the \gls{eeprom} is very similar to the one followed to write a bit stream file, with the exception that the user should select \verb"Add configuration memory device" in the options, as shown in figure~\ref{fig:hw_addMemory}.
This will open a new window, shown in figure~\ref{fig:hw_eeprom}, from which it is possible to indicate the file to use (with extension \verb".mcr").
\begin{figure}
\centering
\includegraphics[width=.80\textwidth]{./Images/hw_prog.png}
\caption{\gls{eeprom} interface. The options shown in the picture are suitable to configure the device correctly.}
\label{fig:hw_eeprom}
\end{figure}
Make sure that the options are set as shown in figure~\ref{fig:hw_eeprom}.
\section{Inspection (table top unit)}\label{ch:inspection}
At some point someone, somewhere, will want to disassemble the unit to poke at its internal electronics; the top cover of the unit can only slide away when either the front or back frame are removed.
\begin{alertinfo}{Note}
Simply removing the corner screws on the panels will only allow to remove the plates but not accessing the inside of the unit.
\end{alertinfo}
The frames are held in place by 4 screws hidden behind the corner covers.\\Figure~\ref{fig:dismantle} shows the correct procedure to remove the cover:\\
A) the easiest way to remove the cover is by removing the back frame, rather than the front one.\\
B) Do not remove the corner screws in the plate.\\
C) Remove the two corner covers from the frame. They are only held in place by pressure and can be removed pulling by hand. Once done, remove the 4 Philips screws located behind (green circles).\\
D) unscrew the Philips screw at the bottom of the unit holding the frame in place.\\
E) remove the frame and the back panel. Be careful to not damage the cables connecting the panel to the electronics.\\
F) Slide the top cover away.\\
The same procedure can be repeated with the front frame, if necessary. In this case, the user must also disconnect the front panel from the electronics by removing the countersunk screws connected to the \gls{hdmi} ports and the powermodule.
\begin{figure}
\centering
\subfloat[A]{\includegraphics[width=.45\textwidth]{./Images/View1.png}}\hfil
\subfloat[B]{\includegraphics[width=.45\textwidth]{./Images/View6.png}}
\subfloat[C]{\includegraphics[width=.45\textwidth]{./Images/View2.png}}\hfil
\subfloat[D]{\includegraphics[width=.45\textwidth]{./Images/View3.png}}
\subfloat[E]{\includegraphics[width=.45\textwidth]{./Images/View4.png}}\hfil
\subfloat[F]{\includegraphics[width=.45\textwidth]{./Images/View5.png}}
\caption{Steps to remove the cover from the unit.}
\label{fig:dismantle}
\end{figure}
\section{Power}
The \gls{tlu} requires 12~V to operate. Power can be provided using the circular jack on the back panel of the unit.\\
During normal operation the current drawn by the unit is about 0.5~A.
\section{Inspection (19"-rack unit)}
Accessing the hardware on the 19"-unit is more straightforward: simply remove the four M2.5 Pozi screws located on the top panel and slide the panel away. Please note that this unit has an internal AC-DC converter that can potentially store an harmful amount of energy even when powered-off and disconnected from the mains: always use care when accessing the unit.
%\section{Preparation}
%Before powering the \gls{tlu} it is necessary to follow a few steps to ensure the board and the \gls{fpga} work correctly.\\
%
......
\chapter{Clock}\label{ch:clock}
The \gls{tlu} can use various sources to produce a stable 40~MHz clock\footnote{For some applications a 50~MHz clock will be required instead}. A \gls{lvpecl} crystal provides the reference 50~MHz clock for a Si5345A jitter attenuator. The Si5345A can accept up to four clock sources and use them to generate the required output clocks.\\
In \brd the possible sources are: differential LEMO connector LM1\_9, one of the four \gls{hdmi} connectors (\verb|HDMI4|), a \gls{cdr} chip connected to the \gls{sfp} cage. The fourht input is used to provide a zero-delay feedback loop.\\
The low-jitter clock generated by the Si5345A can be distributed to up to ten recipients. In the \gls{tlu} these are: the four \gls{dut}s via \gls{hdmi} connectors, the differential LEMO cable, the \gls{fpga}, connector J1 as a differential pair (pins 4 and 6) and as a single ended signal (pin 8). The final output is connected to the zero-delay feedback loop.\\
The low-jitter clock generated by the Si5345A can be distributed to up to ten recipients. In the \gls{tlu} these are: the four \gls{dut}s via \gls{hdmi} connectors, the differential LEMO cable, the \gls{fpga}, connector J1 as a differential pair (pins 4 and 6) and as a single ended signal (pin 8). The final output is connected to the zero-delay feedback loop. Note that it is possible to program the clock chip to generate a different frequency for each of its outputs.\\
The \gls{dut}s can receive the clock either from the Si5435A or directly from the \gls{fpga}: when provided by the clock generator, the signal name is \verb|CLK\_TO\_DUT| and is enabled by signal \verb|ENABLE_CLK_TO_DUT|; when the signal is provided directly from the \gls{fpga} the line used is \verb|DUT_CLK_FROM_FPGA| and is enabled by \verb|ENABLE_DUT_CLK_FROM_FPGA|.\\
The firmware uses the clock generated by the Si5345A except for the block \verb|enclustra_ax3_pm3_infra| which relies on a crystal mounted on the Enclustra board to provide the IPBus functionalities (in this way, at power up the board can communicate via IPBus even if the Si5345A is not configured).
\section{Input selection}
The Si5345 has four inputs that can be selected to provide the clock alignment; the selection can be automatic or user-defined. For further details on this aspect the user should consult the chip documentation.
The Si5345 has four inputs that can be selected to provide the clock alignment; the selection can be automatic or user-defined. For further details on this aspect the user should consult the \href{https://www.silabs.com/documents/public/data-sheets/Si5345-44-42-D-DataSheet.pdf}{chip documentation}\footnote{https://www.silabs.com/documents/public/data-sheets/Si5345-44-42-D-DataSheet.pdf}.
\begin{table}[]
\small
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment