\section{The prototype DAQ configuration file structure}
+
+
+
+
+\begin{figure}[H]
+\centering
+\includegraphics[width=.8\textwidth]{confHierarchy.pdf}
+\caption{Graphical representation of the configuration file hierarchy}
+\label{fig:confHierarchy}
+\end{figure}
In this section the MVD DAQ prototype configuration file structure is explained top to bottom.
+
+The MVD configuration files serve two main purposes:
+\begin{itemize}
+\item
+Store the information about the structure of the hardware set-up.
+(In other words: Which components are connected to which and what are their addresses and IDs?)
+\item
+Store the information about how the hardware components are to be configured before the detector
+is put into operation.
+\end{itemize}
+
+The information is stored hierarchically, i.e. in form of a tree, while different levels of
+tree depth are split into different files.
+To understand the hierarchy the following concepts have to be introduced:
+\paragraph{system}
+We define a (readout) system as all hardware that is controlled and read out via the same
+gigabit ethernet link. At the moment this equals the definition that each TRB3 board
+is a separate system. The parameters of the system are defined in the
+\hyperref[sec:systemFile]{system configuration file}.
+\paragraph{setup}
+A (readout) setup is defined as set of sensors that are read out together, as well as
+their corresponding front-end electronics and peripheral FPGAs.
+A setup always includes hardware belonging to the same readout system.
+Per system an arbitrary number of setups can be defined, while setups are allowed to overlap,
+i.e. having hardware components in common.
+The parameters of a system are defined in the
+\hyperref[sec:setupFile]{setup configuration file}.
+
+
+
+% \begin{Verbatim}[label=/path/to/file]
+% This is a text in my Verbatim
+% \end{Verbatim}
+
\subsection{Directories (draft)}
-[Which file is stored where?]
+Every type of configuration file has its proper storage directory.
\begin{description}
\item[JTAG configuration XML files]
are stored in mvdconfig/config/
\item[System configuration XML files]
are stored in mvdconfig/system/
\item[Setup configuration XML files]
-are stored in mvdconfid/setup/
+are stored in mvdconfig/setup/
\item[Sensor specification XML files]
are stored in mvdsensorcontrol/spec
\end{description}
+
+
\subsection{The system configuration file}
\label{sec:systemFile}
-The system configuration file is the top level configuration file for a MVD prototype DAQ system.
-It defines the FPGA addresses of the central control unit (ccu), the TRBnet hub (hub) and the
-gigabit ethernet link (gbe). All three entities may be located in the same FPGA and may consequently
-have the same address, which is usually the address of the central FPGA in a TRB3 set-up.
+The system configuration file is the top level configuration file for an MVD prototype DAQ system.
+It defines the FPGA addresses\footnote{TrbNet address}
+of the central control unit (ccu), the TRBnet hub (hub) and the
+gigabit ethernet link (gbe). All three entities are usually located in the same central FPGA and
+may consequently have the same address.
A system may have multiple readout controllers (roc), which are usually implemented in the
peripheral FPGAs of the TRB3.
-Apart from a description text for the system, also the daqopserver\footnote{
-[hostname]:[port] of the computer on which the TRBnet daemon is running
+Apart from a description text for the system, also the daqopserver
+\footnote{[hostname]:[port] of the computer on which the TRBnet daemon is running
} for the entire system is defined in this file.
-
-
-Example:
-% \begin{Verbatim}[frame=single,
-% framesep=2mm,
-% label=jtag\_cmd\_m26c Port,labelposition=all,commandchars=\\\{\}]
-\begin{Verbatim}[frame=single, framesep=2mm, fontsize=\small, label=mvdconfig/system/ELab.xml]
+\paragraph{Example:}
+\begin{Verbatim}[label=mvdconfig/system/ExampleSystem.xml]
<?xml version="1.0" encoding="utf-8" ?>
-<DaqSetup xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+<system xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../schema/detectorsetup.xsd"
- name="Elab"
+ name="ExampleSystem"
>
- <description>The Elab maps system setup file</description>
-
- <daqopserver>jspc55:88</daqopserver>
+ <description>This is the configuration file
+ for the Example System.</description>
+ <daqopserver>DAQhostname:88</daqopserver>
+
<ccu address="8880" />
<hub address="8880" />
- <roc address="d882" name="roc1" />
<gbe address="8880" port="50088" name="central link" />
-</DaqSetup>
+ <roc address="d880" name="roc0" />
+ <roc address="d881" name="roc1" />
+ <roc address="d882" name="roc2" />
+ <roc address="d883" name="roc3" />
+</system>
\end{Verbatim}
The setup configuration file groups and defines all entities that make up a detector setup.
The entire detector setup, which can consist of multiple sensors connected to multiple rocs,
must be associated with one single readout system.
-In the current DAQ configuration a detector setup can have up to four controllers\footnote{rocs},
+In the current DAQ configuration, a detector setup can have up to four controllers\footnote{rocs},
one in each peripheral TRB3 FPGA.
Each controller can have up to two (JTAG)chains, while each chain can contain up to two sensors.
-Overall, one TRB3 can accommodate $4\times2\times2=16$ sensors.
-Each sensor must be assigned a unique id, since this id will later be found inside the
-sensor data headers to make different data chunks attributable to their respective origin.
-(??)
-% [serial, enabled]
-The sensor also has the attribute "config", which assignes a (high level) JTAG configuration XML
-file to the sensor, from which it will acquire its JTAG register content.
-(The position information is not used yet.)
-Each chain node inside the setup file can have multiple config\footnote{
+Overall, one TRB3 can accommodate $4\times2\times2=16$ sensors
+\footnote{This is the goal of the concept, however at the moment, the readout controller
+can handle only two sensors in one JTAG chain.}.
+
+A setup (top level) node contains one or more controller nodes, which in turn can have
+one or two chain nodes as children. Each (JTAG) chain node can incorporate one or two
+sensor nodes.
+
+Apart from that, a setup has a system node that defines its affiliation to its parent
+readout system. This is done by setting the name attribute of this node to the name
+of the correspoding system.
+
+Each sensor must be assigned an id that corresponds to its position in the JTAG chain
+(either 0 or 1).
+The sensor node has the attribute "config", which assigns a
+\hyperref[sec:The_JTAG_configuration_file]{JTAG configuration XML file}
+to the sensor, from which it will acquire its JTAG register contents.
+% (see section \ref{sec:JTAG_programming} for further information).
+
+Each chain node inside the setup file can have multiple JtagConf\footnote{
for details about these parameters, see Bertram Neumann -
Dokumentation: JTAG-Chain-Controller (fuer
TRB V3) und JTAG-Monitor}
child nodes. When the
sensors are programmed, all text content of the config nodes will be interpreted as additional
settings for the corresponding JTAG controller.
-Config nodes outside a chain node are settings for the JTAG controller as well, but not chain
+JtagConf nodes outside a chain node are settings for the JTAG controller as well, but not chain
specific.
-Example:
-\begin{verbatim}
+CbConf nodes contain settings for the converter boards that are connected to the corresponding
+chain/ladder of sensors. They can exist in chain nodes or sensor nodes.
+A CbConf node can contain multiple attributes which directly
+correspond to the data fields of the converter board control registers.
+(?? link to the table in appendix)
+Some converter board registers have multiple slices to represent identical configuration
+options for multiple sensors. If a CbConf node is the child node of a sensor node,
+its attributes are interpreted as a sliced ("per sensor") settings.
+The correct slice is then automatically selected, according to the id of the sensor node.
+If a CbConf node is the child node of a chain node, its attributes are applied as non-sliced
+settings.
+
+\paragraph{Example:}
+\begin{Verbatim}
<?xml version="1.0" encoding="utf-8" ?>
-<DetectorSetup xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+<setup xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../schema/detectorsetup.xsd"
- name="Prototype"
+ name="Example Setup"
>
- <description>The main MVD prototype system setup file</description>
+ <description>Configuration file for the Example Setup
+ in the Example System.</description>
- <readoutsystem name="ELab" />
+ <system name="ExampleSystem" />
- <controller id="0" address="d882" name="board01">
+ <controller id="0" address="d882" name="controller 0">
<chain id="0" name="chain0">
<sensor id="0000"
serial="20"
config="sensorG03.xml"
enabled="true">
<description>Sensor G03 on CB13 no 2</description>
- <position
- x="0"
- y="0"
- z="0"
- flippedx="false"
- flippedy="false"
- phi="0"
- />
+ <CbConf
+ EnaA="1"
+ EnaD="1"
+ DisA="0"
+ DisD="0"
+ SensorEn="1"
+ JtagEn="1"
+ />
+ </sensor>
+ <sensor id="0001"
+ serial="11"
+ name="sensor11"
+ config="sensor11.xml"
+ enabled="true">
+ <description>Sensor 11 on CB13 no 2</description>
+ <CbConf
+ EnaA="1"
+ EnaD="1"
+ DisA="0"
+ DisD="0"
+ SensorEn="1"
+ JtagEn="1"
+ />
</sensor>
- <config>delay0</config>
- <config>set_timing_10mhz</config>
- <config>set_inout</config>
- <config>maps_reset_before_off</config>
- <config>maps_reset_after_on</config>
+ <JtagConf>delay0</JtagConf>
+ <JtagConf>set_timing_10mhz</JtagConf>
+ <JtagConf>set_inout</JtagConf>
+ <JtagConf>maps_reset_before_off</JtagConf>
+ <JtagConf>maps_reset_after_on</JtagConf>
+ <CbConf
+ OvRideLed1="1"
+ Led1="1"
+ </CbConf
</chain>
- <config>waitbeforestart_6us</config>
- <config>trigger_init_sequence</config>
+ <JtagConf>waitbeforestart_6us</JtagConf>
+ <JtagConf>trigger_init_sequence</JtagConf>
</controller>
-</DetectorSetup>
-\end{verbatim}
\ No newline at end of file
+</setup>
+\end{Verbatim}
+
+\subsection{The JTAG configuration file}
+\label{sec:The_JTAG_configuration_file}
+As mentioned before, in the setup configuration file each sensor is assigned a proper JTAG
+configuration file that defines the content of the sensor's JTAG registers and thus determines
+its behaviour. The configuration of the JTAG registers involves an excessive supply of options
+that massively complicates keeping an overview over the important settings.
+As a counter measure an elaborate configuration software concept was developed wich is explained
+in detail in the following section (section \ref{sec:JTAG_programming}).
Meanwhile the TRB3 hardware platform and the associated software framework are developed and maintained
by the TRB collaboration that includes contributors from several different countries.
-It is equipped with five Lattice ECP3-150EA FPGAs, i.e. one central and four peripheral FPGAs.
-The board possesses eight SFP ports that are able to accommodate optical or electrical ethernet adaptors.
+The TRB3 is equipped with five Lattice ECP3-150EA FPGAs, i.e. one central and four peripheral FPGAs.
+The board possesses eight SFP ports that are able to accommodate optical or electrical network adaptors.
Next to each peripheral FPGA a compact 200 pin extension connector is located, that can be equipped
with specialized adaptor or interface boards. This way a wide range of data acquisition applications
is possible. Each FPGA has an internal flash storage for its design configuration.
the distribution of trigger signals and the transport of large amounts of acquired
data. A TrbNet link transports triggers, data and slow control calls over a single serial
transmission line (optical fiber or wire) by multiplexing.
-For realtime performance reasons, the trigger packets have priority over the data packets,
-which in turn have priority over the slow control packets. At each network node the packets
-are being demultiplexed into independent channels again while each channel
-has its proper receive buffer.
+% For realtime performance reasons, the trigger packets have priority over the data packets,
+% which in turn have priority over the slow control packets. At each network node the packets
+% are being demultiplexed into independent channels again while each channel
+% has its proper receive buffer.
In a TrbNet network, there are two different kinds of nodes: endpoints and hubs.
Endpoints are nodes that insert and/or extract data packets to/from the network,
-while hubs route packets between other nodes (each hub is connected to one endpoint
-so it can be configured via slow control).
+while hubs route packets between other nodes.
+% (each hub is connected to one endpoint
+% so it can be configured via slow control).
(For a detailed description of the HADES DAQ see \cite{jan_dissertation}.)
+
In the MVD set-up, the TRB3 is used as a network controlled data readout board for the MIMOSA26 MAPS.
The connection to the converter board is achieved by attaching an ADA-AddOn board to one
of the peripheral extension connectors. This board is a passive adaptor that provides two 80 pin
\hyperref[sec:CbController]{converter board controller} (CbController)
(see figure \ref{fig:peripheral_FPGA}).
Apart from these front-end specific functional groups the design incorporates a TrbNet endpoint
-that connects the above entities to the DAQ network. The media interface entity serves as an
-adaptor between the abstract/generic endpoint and the physical data transmission medium,
-which can be an optical transceiver, or in this case, a differential line between two FPGAs.
+that connects the above entities to the DAQ network.
+% The media interface entity serves as an
+% adaptor between the abstract/generic endpoint and the physical data transmission medium,
+% which can be an optical transceiver, or in this case, a differential line between two FPGAs.
The central FPGA houses a TrbNet hub as well as a gigabit ethernet
link entity (GbE) and the so called central control unit (CCU).
The gigabit ethernet entity allows to use an attached SFP module to establish a gigabit ethernet
link to the computer that runs the data acquisition, configuration and monitoring software.
This way all endpoints connected to the central hub (i.e. all peripheral FPGAs) can be accessed
-by the user or automated DAQ software.
+by the user or by automated DAQ software.
-The central control unit is an entity that generates trigger signals for the readout controllers.
+% The central control unit is an entity that generates trigger signals for the readout controllers.
The CBM MVD is a detector that is designed to be free running, i.e. triggerless, while the
-hardware concepts are adapted from the HADES system, which is a triggered detector.
+hardware concepts are adapted from HADES, which is a triggered detector.
In the MVD setup the central control unit resumes the task of the HADES
CTS\footnote{central triggering system \cite{jan_dissertation}}
-but in a much simpler fashion. It sends trigger signals with a fixed frequency that corresponds
-to twice the sensor frame rate. This way such a readout request is guaranteed to occur within one
+but in a much simpler fashion. It sends readout request trigger signals to the readout controllers
+which answer by sending the data from their acquisition buffers.
+The trigger frequency corresponds to twice the sensor frame rate,
+so a readout request is guaranteed to occur within one
frame and there is at least half a frame period to transmit the data before a new frame is acquired.
+The data packages are forwarded to the DAQ computer via the gigabit ethernet link.
\subsubsection{Readout controller}
\label{sec:ReadoutController}
-The readout controller\footnote{Implemented by Borislav Milanovic during his PhD. studies}
+The readout controller\footnote{Implemented by Borislav Milanovic during his PhD studies}
captures the synchronous serial data stream coming from the sensor.
By means of the front-end electronics and dedicated FPGA pins the readout controller receives
the following (differential) signals from the sensor:
the entity allows for the switching of power and signal lines to and from the sensor via slow control.
Furthermore it is involved in the acquisition of sensor status information,
such as sensor temperature and power consumption.
-The ADC data acquisition and the converter board components are controlled by the on-board
+The \hyperref[sec:ADC]{ADC} data acquisition and the converter board components are controlled by
+the on-board
\hyperref[sec:Microcontroller]{microcontroller}.
To communicate with the microcontroller the entity incorporates an SPI slave interface and a
bidirectional UART.
The CbController entity forwards slow control commands to the converter board via the UART
and receives status information in return.
-The SPI slave constantly receives a joint data stream from the microcontroller.
-It contains all voltage and current measurements performed by the ADCs on the converter board.
+The SPI slave receives a continuous data stream from the microcontroller, including
+all voltage and current measurements performed by the ADCs on the converter board.
The readings are stored in dedicated registers in the FPGA and are refreshed continuously.
These registers can then be read out via slow control requests.
% \usepackage{framed}
\usepackage{fancyvrb}
+% my macros
+
+\RecustomVerbatimEnvironment
+{Verbatim}{Verbatim}
+{frame=single, framesep=2mm, fontsize=\small}
+
+
\begin{document}
% \bibliographystyle{plain}
% %\bibliographystyle{plainnat}
\include{daqsetup}
\include{config_structure}
\include{jtag}
+\include{gui}
\include{daqscripts}
\include{bib}
--- /dev/null
+\section{High level graphical user interfaces}
+\label{sec:gui}
+
+
+\subsection{Graphical JTAG Editor}
+\label{sec:jtageditor}
+To further facilitate JTAG register manipulation an editor with graphical user interface has been
+implemented. When "mvdsensorcontrol/tools/jtageditor.pl" is invoked from a browser, the user will be
+presented with a three panel layout (see figure \ref{fig:jtageditor_ssht}). In the top panel
+the user can select an existing configuration file or create a new one, based on a distinct
+specification file.
+The bottom left panel provides a hierarchical view of the sensor's registers and data fields
+as defined in the specification XML file. The register tabs can be unfolded to view the underlying
+data fields. The values in the left panel can not be edited,
+whereas the bottom right panel becomes an editable representation of the previously selected or created
+configuration XML file.
+A newly created configuration file is empty. Entries can be added by clicking on the arrow symbols
+next to the data fields and registers in the bottom left panel. The selected entry is subsequently
+duplicated on the right panel, including its default value. This value can then be altered by
+editing the value in the corresponding text field or removed again by clicking on the "x" symbols
+next to the values.
+Values can be entered as hex (with prefix "0x"), binary (with prefix "0b") or decimal number
+(no prefix). By clicking on the equals sign in the center of a data field tab a small menu appears,
+that lets the user convert the current value to each of the other numeric bases.
+All changes in the bottom right panel are immediately applied to the configuration file
+(there is no "save" button).
+
+When the mouse pointer is held still over a register or data field in either of the columns a help
+message is displayed in a box next to the pointer.
+The message shows the register or field description from the specification file (taken from the
+MIMOSA26 datasheet) and the possible value range.
+
+A configuration file can also inherit settings from another (existing and valid) configuration file.
+Therefore an ancestor file can be selected in a dropdown menu at the top of the bottom right panel.
+All settings from the ancestor file are imported as new defaults, which are then partially overridden
+by the configuration's own settings. This feature can be used for example to operate a multitude
+of sensors with the same parameters from a common ancestor file, while each sensor's own configuration
+file contains merely individual tuning parameters.
+
+The editor assumes, that the configuration XML files are stored in "../../mvdconfig/config/"
+and the specification files are stored in "../specs/"
+(relative to the location of jtageditor.pl).
+
+\begin{figure}[H]
+\centering
+\includegraphics[width=.85\textwidth]{jtageditor.png}
+\caption{Screenshot of the JTAGeditor GUI}
+\label{fig:jtageditor_ssht}
+\end{figure}
+
+\subsection{Testgui}
+The Testgui application was designed to test the data acquisition of the sensors on the fly.
+It greatly facilitates experimenting with distinct sensor parameters
+while the reaction of the sensors can be directly observed.
+
+When "mvdsensorcontrol/tools/testgui.pl" is invoked from a browser the user has to choose
+a \hyperref[sec:setupFile]{detector setup file} from a dropdown menu. Consequently the user
+is presented with a hierarchical overview of the controller/chain/sensor topology as
+described inside the setup file (see figure \ref{fig:testgui_ssht}).
+Each sensor is represented by a rectangular area that will show a matrix plot of the
+fired pixels during a given time period, once the user clicks on the "run" button at the
+bottom of the page. Clicking on the button initiates the JTAG programming of all sensors
+in the setup, followed by a period of data acquisition. The data taking time is defined
+in a text field next to the "run" button.
+
+Alongside the plot area of each sensor there is another box labeled "quick editor".
+This quick edit area is an embedded miniature edition of the \hyperref[sec:jtageditor]{JTAG editor}
+which only shows a small selection of all possible JTAG settings. The selection is defined by
+creating a configuration XML file with the name "quickEditMask.xml";
+all settings inside this file (regardless of their values) are used to create a selection mask.
+By clicking on the XML file name at the top of the quick editor, the user is conveniently redirected
+to the full featured JTAG editor that opens the respective configuration file.
+
+\begin{figure}[H]
+\centering
+\includegraphics[width=1\textwidth]{testgui.png}
+\caption{Screenshot of the Testgui application}
+\label{fig:testgui_ssht}
+\end{figure}
+
+
+
+
+
+
\end{figure}
\subsection{JTAG configuration software}
-
+\label{sec:JTAG_configuration_software}
The JTAG configuration software is split into two layers:
\begin{itemize}
\item
The low level functionality layer with hex-encoded ini-style configuration files.
\end{itemize}
-The low level software layer\footnote{implemented by Bertram Neumann during his master thesis} handles
+The low level software layer\footnote{implemented by Bertram Neumann during his master thesis\cite{bertram_master}} handles
the communication with the JTAG controller entity and the transmission of the JTAG register contents
destined to be stored in the sensors. Therefore the programming script parses
ini-style configuration files, which contain a list of strings: each string represents
If the sensor is to be programmed with a configuration file, the perl script "xml2ini.pl" is called. It uses the
specifications file to generate a low level ini file with all registers set to default values.
These default values are then overwritten by the user's values as defined in the configuration file.
-This way the user has not to worry about the vast number of settings he does not want to touch at all.
+This way the user does not have to worry about the vast number of settings he does not want to touch at all.
Neither does he have to care how to align the values relative to the corresponding registers. With the
configuration file, the user has a clear "key->value" type interface to the sensor's JTAG settings.
XML file and has not to be given as an argument.
Under normal conditions this script is not used stand-alone but is called during the execution of
\hyperref[sec:startup.pl]{startup.pl}.
-\begin{verbatim}
+\begin{Verbatim}
xml2ini.pl -c config.xml [-o output.ini]
Options:
-c, --config specifies the input config xml file
-o, --output specifies the output filename, if ommitted,
the generated ini file is written to STDOUT
-\end{verbatim}
+\end{Verbatim}
\subsubsection{ini2xml.pl}
This script does the opposite of the above one. It parses a valid ini file and converts it back
to an XML configuration file. By default, only the settings deviant from the specification's defaults
are reconstructed and written to the output XML file.
-\begin{verbatim}
+\begin{Verbatim}
ini2xml.pl -i file.ini -s specFile.xml [-o output.xml]
Options:
the generated xml is written to STDOUT
-r, --redundant write settings to config file that are identical
with the specification defaults
-\end{verbatim}
+\end{Verbatim}
\subsubsection{xmlOperation.pl}
\label{sec:xmlOperation.pl}
The tool assumes, that the configuration XML files are stored in "../../mvdconfig/config/"
and the specification files are stored in "../specs/"
(relative to the location of xmlOperation.pl).
-\begin{verbatim}
+\begin{Verbatim}
usage:
via CGI/HTTP request:
copy config file
action=copyFile&configFile=[configFile]&newFile=[newFile]
-\end{verbatim}
+\end{Verbatim}
\subsubsection{changeConfigVal.pl}
Regarding \hyperref[sec:xmlOperation.pl]{xmlOperation.pl}, changeConfigVal.pl is redunant in its
Values can be entered as hex (with prefix "0x"), binary (with prefix "0b") or decimal number
(no prefix).
The configuration file has to be declared with its full path.
-\begin{verbatim}
+\begin{Verbatim}
changeConfigVal.pl -c config.xml [-v]
Options:
-v, --verbose detailed debugging info about ongoing actions
-c, --config specifies the input config xml file
(including path if necessary!)
-\end{verbatim}
+\end{Verbatim}
\subsubsection{startup.pl}
\label{sec:startup.pl}
the sensors.
(!!) It does not (yet) set the sensor enable, JTAG enable, and power switches on the Converter Board
to the correct settings! This has to be done manually! (!!)
-\begin{verbatim}
+\begin{Verbatim}
startup.pl /path/to/setupFile
Options:
-v, --verbose be verbose to STDERR
--dryrun create but don't run scripts
-\end{verbatim}
-
-
-\subsection{Graphical JTAG Editor}
-\label{sec:jtageditor}
-To further facilitate JTAG register manipulation an editor with graphical user interface has been
-implemented. When "mvdsensorcontrol/tools/jtageditor.pl" is invoked from a browser, the user will be
-presented with a three panel layout (see figure \ref{fig:jtageditor_ssht}). In the top panel
-the user can select an existing configuration file or create a new one, based on a distinct
-specification file.
-The bottom left panel provides a hierarchical view of the sensor's registers and data fields
-as defined in the specification XML file. The register tabs can be unfolded to view the underlying
-data fields. The values in the left panel can not be edited,
-whereas the bottom right panel becomes an editable representation of the previously selected or created
-configuration XML file.
-A newly created configuration file is empty. Entries can be added by clicking on the arrow symbols
-next to the data fields and registers in the bottom left panel. The selected entry is subsequently
-duplicated on the right panel, including its default value. This value can then be altered by
-editing the value in the corresponding text field or removed again by clicking on the "x" symbols
-next to the values.
-Values can be entered as hex (with prefix "0x"), binary (with prefix "0b") or decimal number
-(no prefix). By clicking on the equals sign in the center of a data field tab a small menu appears,
-that lets the user convert the current value to each of the other numeric bases.
-All changes in the bottom right panel are immediately applied to the configuration file
-(there is no "save" button).
-
-When the mouse pointer is held still over a register or data field in either of the columns a help
-message is displayed in a box next to the pointer.
-The message shows the register or field description from the specification file (taken from the
-MIMOSA26 datasheet) and the possible value range.
-
-A configuration file can also inherit settings from another (existing and valid) configuration file.
-Therefore an ancestor file can be selected in a dropdown menu at the top of the bottom right panel.
-All settings from the ancestor file are imported as new defaults, which are then partially overridden
-by the configuration's own settings. This feature can be used for example to operate a multitude
-of sensors with the same parameters from a common ancestor file, while each sensor's own configuration
-file contains merely individual tuning parameters.
-
-The editor assumes, that the configuration XML files are stored in "../../mvdconfig/config/"
-and the specification files are stored in "../specs/"
-(relative to the location of jtageditor.pl).
-
-\begin{figure}[H]
-\centering
-\includegraphics[width=.85\textwidth]{jtageditor.png}
-\caption{Screenshot of the JTAGeditor GUI}
-\label{fig:jtageditor_ssht}
-\end{figure}
-
-\subsection{Testgui}
-The Testgui application was designed to test the data acquisition of the sensors on the fly.
-It greatly facilitates experimenting with distinct sensor parameters
-while the reaction of the sensors can be directly observed.
-
-When "mvdsensorcontrol/tools/testgui.pl" is invoked from a browser the user has to choose
-a \hyperref[sec:setupFile]{detector setup file} from a dropdown menu. Consequently the user
-is presented with a hierarchical overview of the controller/chain/sensor topology as
-described inside the setup file (see figure \ref{fig:testgui_ssht}).
-Each sensor is represented by a rectangular area that will show a matrix plot of the
-fired pixels during a given time period, once the user clicks on the "run" button at the
-bottom of the page. Clicking on the button initiates the JTAG programming of all sensors
-in the setup, followed by a period of data acquisition. The data taking time is defined
-in a text field next to the "run" button.
-
-Alongside the plot area of each sensor there is another box labeled "quick editor".
-This quick edit area is an embedded miniature edition of the \hyperref[sec:jtageditor]{JTAG editor}
-which only shows a small selection of all possible JTAG settings. The selection is defined by
-creating a configuration XML file with the name "quickEditMask.xml";
-all settings inside this file (regardless of their values) are used to create a selection mask.
-By clicking on the XML file name at the top of the quick editor, the user is conveniently redirected
-to the full featured JTAG editor that opens the respective configuration file.
-
-\begin{figure}[H]
-\centering
-\includegraphics[width=1\textwidth]{testgui.png}
-\caption{Screenshot of the Testgui application}
-\label{fig:testgui_ssht}
-\end{figure}
-
-
-
+\end{Verbatim}
The JTAG enable and Sensor enable switches in the converter boards are not set by statup.pl!
\item
We don't have multiple JTAG chains and CbControllers in the peripheral FPGA yet.
+\item
+In start.pl the handling of the (readout)-system is not yet generic we still have
+\begin{Verbatim}
+if($system eq 'Vacuum') {
+ trb_write($ccu,0x00c0,0x00e1);
+ trb_write($ccu,0x00c1,0x00e1);
+ trb_write($ccu,0x00c3,0x00ff); #only slowcontrol for unused FPGA
+ }
+if($system eq 'ELab') {
+ trb_write($ccu,0x00c0,0x00e4);
+ trb_write($ccu,0x00c1,0x00e4);
+ trb_write($ccu,0x00c3,0x00fc); #only slowcontrol for unused FPGA
+ }
+\end{Verbatim}
+This should not be much work to generalize?!, use the roc entries in the system file
+to activate the rocs
\end{itemize}
\subsection{Naming consistency notes}
\begin{itemize}
\subsection{ToDo}
\begin{itemize}
\item
+put description of low level daq scripts in appendix
+\item
+complete summary of converter board control registers (appendix?)
+\item
+programmable DAC chapter -> link to slow control registers
+\item
+setup file explanation -> hyperref to above table of converter board registers.
+\item
+explain sensor specific slices in CbConf
+\item
Elaborate on the elements of the config XML file.
\item
Elaborate on the microcontroller -> FPGA register synchronization
\item
write about current sensor FPC?
\end{itemize}
+\subsection{is this explained?}
+\begin{itemize}
+\item
+what is slow control
+\item
+what is a DAQOPSERVER?
+\end{itemize}
\subsection{to investigate}
\begin{itemize}
jspc29 / mvd_docu.git / commitdiff