--- /dev/null
+
+\section{Overview of the daqscripts (draft!)}
+\subsection{run.pl}
+\label{sec:run.pl}
+\begin{description}
+\item[is called by]
+testgui.pl with parameters "setupFile" and "runtime" (CGI/HTTP request)
+\item[does]
+\begin{itemize}
+\item
+parse \hyperref[sec:setupFile]{setupFile}, extract systemName
+\item
+parse \hyperref[sec:systemFile]{systemFile}, extract gbe address and gbe port(s), extract daqopserver and set this as env variable.
+\item
+remove stale hld dumps, remove stale matrix plots
+\end{itemize}
+\item[calls]
+startup.pl with parameter setupFile
+\item[calls]
+./preview/exec\_evtbuild\_t.pl with arguments runtime, dumpPath, systemName and ports
+\item[calls]
+./preview/unpack\_hld.pl with arguments dumpfile, picPath and systemName
+\end{description}
+
+\subsection{exec\_evtbuild\_t.pl}
+\begin{description}
+\item[is called by]
+\hyperref[sec:run.pl]{run.pl} with arguments runtime, dumpPath, systemName and ports
+\item[calls]
+daq\_netmem with timeout and shm name
+\item[calls]
+daq\_evtbuild with timeout and shm name
+\end{description}
+
+\subsection{start.pl}
+\begin{description}
+\item[is called by] manual with argument systemName
+\item[does]
+\begin{itemize}
+\item
+Parse corresponding systemFile to systemName
+\item
+Extract addresses of hub, gbe and roc
+\item
+Set addresses of FPGAs according to database definitions
+\item
+Set GbE Configuration (common for all boards) (??)
+\item
+Send arbiter start signal
+\end{itemize}
+
+\end{description}
+
+\subsection{startup.pl}
+Run the necessary steps to configure and start MAPS sensors.
+(see also section \hyperref[sec:startup.pl]{startup.pl})
+\begin{description}
+\item[is called by]
+run.pl or manual with argument setupFile
+\item[does]
+\begin{itemize}
+\item
+extract sensor, chain and controller parameters from setup file
+\item
+generate all necessary low lewel JTAG configuration ini files from the high level configuration
+XML files
+\item
+call JTAG programmer, program and initialize the sensors
+\end{itemize}
+\end{description}
\ No newline at end of file
\usepackage{geometry}
\usepackage{eurosym}
\usepackage{amsmath}
-\usepackage{listings}
+% \usepackage{listings}
+\usepackage{hyperref}
\geometry{verbose,tmargin=3cm,bmargin=3cm,lmargin=3cm,rmargin=3cm}
% \include{bib}
\newpage
-
-\section{JTAG programming}
-
-\subsection{MIMOSA26 registers and the JTAG controller entity}
-
-\begin{figure}[H]
-\centering
-\includegraphics[width=.80\textwidth]{registers.pdf}
-\caption{Schema of the MIMOSA26 config registers and the JTAG controller logic entity implemented on FPGA.}
-\label{fig::M26andItsRegisters}
-\end{figure}
-
-
-The MIMOSA26 chip posesses 11 JTAG settings registers, wich are hardwired to distinct functionalities in the
-readout logic part of the sensor (see Figure \ref{fig::M26andItsRegisters}). Most registers are sub-divided
-into multiple data fields of variable length (see Figure \ref{fig::datafields}). Each of the in total 82
-datafields corresponds to a distinct function or configurable quantity inside the sensor.
-The JTAG programming is handled by a dedicated FPGA design entity, the JTAG Controller.
-This entity receives commands from the programming software on a regular PC.
-
-\begin{figure}[H]
-\centering
-\includegraphics[width=.90\textwidth]{fields.pdf}
-\caption{Schema of an example register, divided into multiple data fields.}
-\label{fig::datafields}
-\end{figure}
-
-\subsection{JTAG configuration software}
-
-The JTAG configuration software is split into two layers:
+\section{Prerequisites (draft)}
\begin{itemize}
\item
-The high level user interface with its transparent XML-type configuration files.
+A Linux system.
+\item
+Perl has to be installed.
\item
-The low level functionality layer with hex-encoded ini-style configuration files.
+An Apache webserver has to be running that executes perl scripts when they are requested
+via HTTP (even outside a cgi-bin directory). (link to a tutorial?)
+\item
+libxml-perl has to be installed.
+\item
+(how is it called?) storable perl module
+\item
+git
\end{itemize}
-The low level software layer\footnote{implemented by Bertram Neumann during his master thesis} 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
-the hex encoded content of one MIMOSA26 register.
-Without knowledge about the technical details of the MIMOSA26
-registers these files should not be edited by hand. Normal users, i.e. non-developers, should ignore
-this layer.
-
-\begin{figure}[H]
-\centering
-\includegraphics[width=.95\textwidth]{001_lowLevelChain.pdf}
-\caption{The low level functionality layer.}
-\label{fig::lowLevelchain}
-\end{figure}
-
-The high level interface layer was added to make the JTAG configuration files and their manipulation more
-transparent and less error-prone.
-The confguration files make use of the XML format. XML is strictly hierarchically structured and human
-readable.
-While all data fields in the sensor's registers have to be programmed with a defined value, only few of
-these ever have to be set to different values than the manufacturer's defaults.
-Therefore information to program the sensor is split into two files:
-\begin{description}
-\item[specification]
-The specification XML file contains the specifications of all the sensor's JTAG registers. Each register in the specification
-file has a unique register id, a register name and a size (length of register in bits); it possesses
-one or more data fields as child nodes. Each datafield has a start, end and size value which define the
-relative position of the datafield inside the register. Furthermore the datafield has a name and default value
-attribute.
-For each register and field there is a short description included along the above specifications.
-All specifications and descriptions were adapted from the MIMOSA26 user manual v1.5 without
-alteration\footnote{apart from correcting a field size mismatch}.
-\item[settings]
-The settings XML file containst the actual settings that are defined by the user.
-In this XML hierarchy, too, there are registers with data fields as child nodes. Here registers and
-data fields are referenced only by ther unique names. Each data field has a value attribute.
-The settings file is very streamlined and self-explanatory.
-Data fields and registers that are not defined in the settings file are assumed to get the default
-values assigned to them.
-\end{description}
-
-\begin{figure}[H]
-\centering
-\includegraphics[width=.5\textwidth]{xml2ini.pdf}
-\caption{The programming information for the sensor is split into a register specification including default values
-and an individual settings file for each sensor.}
-\label{fig::xml2ini}
-\end{figure}
-
-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.
-Neither does he has 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.
-
-\subsection{List of JTAG related tools}
-
-\paragraph{xml2ini.pl}
-This script creates a low level ini file for the JTAG programming script from a valid configuration XML
-file. The specification file which is used to build the ini file is referenced inside the configuration
-XML file and has not to be given as an argument.
-\begin{lstlisting}
-xml2ini.pl -c config.xml [-o output.ini]
-
- Options:
- -h, --help brief help message
- -v, --verbose detailed debugging info about ongoing actions
- -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{lstlisting}
-
-\paragraph{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{lstlisting}
-ini2xml.pl -i file.ini -s specFile.xml [-o output.xml] [-d]
-
- Options:
- -h, --help brief help message
- -v, --verbose detailed debugging info about ongoing actions
- -i, --ini specifies the input .ini file
- -s, --spec specifies the specification xml file by
- which the .ini file is to be decoded
- -o, --output specifies the output filename, if ommitted
- the generated xml is written to STDOUT
- -r, --redundant write settings to config file that are identical
- with the specification defaults
-\end{lstlisting}
-
-
-
-
-
-
-
+\section{DAQ set-up (draft)}
+[what is where]
+to explain
+\begin{itemize}
+\item
+hub
+\item
+ccu
+\item
+roc
+ \begin{itemize}
+ \item
+ actual roc
+ \item
+ JTAG
+ \item
+ CbController
+ \end{itemize}
+\item
+tjah
+\end{itemize}
+\section{The prototype DAQ configuration file structure}
+In this section the MVD DAQ prototype configuration file structure is explained top to bottom.
+\subsection{Directories (draft)}
+[Which file is stored where?]
+\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/
+\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.
+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
+} for the entire system is defined in this file.
+
+
+Example:
+\begin{verbatim}
+<?xml version="1.0" encoding="utf-8" ?>
+<DaqSetup xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:noNamespaceSchemaLocation="../schema/detectorsetup.xsd"
+ name="Elab"
+ >
+ <description>The Elab maps system setup file</description>
+
+ <daqopserver>jspc55:88</daqopserver>
+ <ccu address="8880" />
+ <hub address="8880" />
+ <roc address="d882" name="roc1" />
+ <gbe address="8880" port="50088" name="central link" />
+
+</DaqSetup>
+\end{verbatim}
+
+
+\subsection{The setup configuration file}
+\label{sec:setupFile}
+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},
+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{
+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
+specific.
+
+Example:
+\begin{verbatim}
+<?xml version="1.0" encoding="utf-8" ?>
+<DetectorSetup xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:noNamespaceSchemaLocation="../schema/detectorsetup.xsd"
+ name="Prototype"
+ >
+ <description>The main MVD prototype system setup file</description>
+
+ <readoutsystem name="ELab" />
+
+ <controller id="0" address="d882" name="board01">
+ <chain id="0" name="chain0">
+ <sensor id="0000"
+ serial="20"
+ name="sensorG03"
+ 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"
+ />
+ </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>
+ </chain>
+ <config>waitbeforestart_6us</config>
+ <config>trigger_init_sequence</config>
+ </controller>
+</DetectorSetup>
+\end{verbatim}
+
+\include{jtag}
+\include{daqscripts}
+\include{remarks}
\end{document}
--- /dev/null
+\section{JTAG programming}
+
+\subsection{MIMOSA26 registers and the JTAG controller entity}
+
+\begin{figure}[H]
+\centering
+\includegraphics[width=.80\textwidth]{registers.pdf}
+\caption{Schema of the MIMOSA26 config registers and the JTAG controller logic entity implemented on FPGA.}
+\label{fig:M26andItsRegisters}
+\end{figure}
+
+
+The MIMOSA26 chip posesses 11 JTAG settings registers, wich are hardwired to distinct functionalities in the
+readout logic part of the sensor (see Figure \ref{fig:M26andItsRegisters}). Most registers are sub-divided
+into multiple data fields of variable length (see Figure \ref{fig:datafields}). Each of the in total 82
+datafields corresponds to a distinct function or configurable quantity inside the sensor.
+The JTAG programming is handled by a dedicated FPGA design entity, the JTAG Controller.
+This entity receives commands from the programming software on a regular PC.
+
+\begin{figure}[H]
+\centering
+\includegraphics[width=.90\textwidth]{fields.pdf}
+\caption{Schema of an example register, divided into multiple data fields.}
+\label{fig:datafields}
+\end{figure}
+
+\subsection{JTAG configuration software}
+
+The JTAG configuration software is split into two layers:
+\begin{itemize}
+\item
+The high level user interface with its transparent XML-type configuration files.
+\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 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
+the hex encoded content of one MIMOSA26 register.
+Without knowledge about the technical details of the MIMOSA26
+registers these files should not be edited by hand. Normal users, i.e. non-developers, should ignore
+this layer.
+
+\begin{figure}[H]
+\centering
+\includegraphics[width=.95\textwidth]{001_lowLevelChain.pdf}
+\caption{The low level functionality layer.}
+\label{fig:lowLevelchain}
+\end{figure}
+
+The high level interface layer was added to make the JTAG configuration files and their manipulation more
+transparent and less error-prone.
+The confguration files make use of the XML format. XML is strictly hierarchically structured and human
+readable.
+While all data fields in the sensor's registers have to be programmed with a defined value, only few of
+these ever have to be set to different values than the manufacturer's defaults.
+Therefore information to program the sensor is split into two files (see figure \ref{fig:xml2ini}):
+\begin{description}
+\item[specification]
+The specification XML file contains the specifications of all the sensor's JTAG registers. Each register in the specification
+file has a unique register id, a register name and a size (length of register in bits); it possesses
+one or more data fields as child nodes. Each datafield has a start, end and size value which define the
+relative position of the datafield inside the register. Furthermore the datafield has a name and default value
+attribute.
+For each register and field there is a short description included along the above specifications.
+All specifications and descriptions were adapted from the MIMOSA26 user manual v1.5 without
+alteration\footnote{apart from correcting a field size mismatch}.
+\item[settings]
+The settings XML file contains the actual settings that are defined by the user.
+In this XML hierarchy, too, there are registers with data fields as child nodes. Here registers and
+data fields are referenced only by their unique names. Each data field has a value attribute.
+Data fields and registers that are not defined in the settings file are assumed to get the default
+values assigned to them,
+therefore the settings file can be very streamlined.
+\end{description}
+
+\begin{figure}[H]
+\centering
+\includegraphics[width=.5\textwidth]{xml2ini.pdf}
+\caption{The programming information for the sensor is split into a register specification including default values
+and an individual settings file for each sensor.}
+\label{fig:xml2ini}
+\end{figure}
+
+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.
+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.
+
+\subsection{List of JTAG related command line tools}
+
+\subsubsection{xml2ini.pl}
+\label{sec:xml2ini.pl}
+This script creates a low level ini file for the JTAG programming script from a valid configuration XML
+file. The specification file which is used to build the ini file is referenced inside the configuration
+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}
+xml2ini.pl -c config.xml [-o output.ini]
+
+ Options:
+ -h, --help brief help message
+ -v, --verbose detailed debugging info about ongoing actions
+ -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}
+
+\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}
+ini2xml.pl -i file.ini -s specFile.xml [-o output.xml]
+
+ Options:
+ -h, --help brief help message
+ -v, --verbose detailed debugging info about ongoing actions
+ -i, --ini specifies the input .ini file
+ -s, --spec specifies the specification xml file by
+ which the .ini file is to be decoded
+ -o, --output specifies the output filename, if ommitted
+ the generated xml is written to STDOUT
+ -r, --redundant write settings to config file that are identical
+ with the specification defaults
+\end{verbatim}
+\subsubsection{changeConfigVal.pl}
+The script parses STDIN for attribution directives in the format "registerName/fieldName=value" and applies
+these attributions to a denoted configuration XML file. Multiple attributions can be processed at
+the same time when separated by semicolon or line break.
+Values can be entered as hex (with prefix "0x"), binary (with prefix "0b") or decimal number
+(no prefix).
+\begin{verbatim}
+changeConfigVal.pl -c config.xml [-v]
+
+ Options:
+ -h, --help brief help message
+ -v, --verbose detailed debugging info about ongoing actions
+ -c, --config specifies the input config xml file
+ (including path if necessary!)
+\end{verbatim}
+\subsubsection{xmlOperation.pl}
+This script is a tool to edit parameters of an XML configuration file. It can edit any editable
+entry of a given configuration file, but can only process one command at a time. The script has
+a CGI interface (invoked via HTTP request) but it can also be used from the command line.
+
+\begin{verbatim}
+usage:
+
+ via CGI/HTTP request:
+ http://[...]/mvdsensorcontrol/tools/xmlOperation.pl?\
+ action=[action]&[parameter]&[parameter]& ...
+
+ via command line:
+ xmlOperation.pl action=[action] [parameter] [parameter] ...
+ (just like the CGI request, just leave out ? and &)
+
+possible actions: save, delete, copyDefaultRegister,
+ createFile, deleteFile, changeAncestor
+
+parameter explanation:
+
+ save a value into a specific field, optional: if you enter a numeric base,
+ value will be saved in the specified format.:
+ action=save&configFile=[configFile]®ister=[register]&field=[field]&\
+ value=[value]&base=[base]
+
+ delete a specific field:
+ action=delete&configFile=[configFile]®ister=[register]&field=[field]
+
+ delete a whole register:
+ action=delete&configFile=[configFile]®ister=[register]
+
+ copy a register including default values from the specification
+ to the config file:
+ action=copyDefaultRegister&configFile=[configFile]®ister=[register]
+
+ create a new config file based on the given specification file
+ action=createFile&configFile=[configFile]&specFile=[specFile]
+
+ delete a config file
+ action=deleteFile&configFile=[configFile]
+
+ change the ancestor (include directive) of config file
+ action=changeAncestor&configFile=[configFile]&newAncestor=[newAncestor]
+
+ move/rename config file
+ action=moveFile&configFile=[configFile]&newFile=[newFile]
+
+ copy config file
+ action=copyFile&configFile=[configFile]&newFile=[newFile]
+\end{verbatim}
+
+
+
+\subsubsection{startup.pl}
+\label{sec:startup.pl}
+The script runs the necessary steps to configure and start the MAPS sensors. From a given
+\hyperref[sec:setupFile]{setup configuration file} the script extracts:
+\begin{itemize}
+\item
+The topology of the setup, i.e. how many controllers (and their addresses), how many chains, how many
+sensors in each chain
+\item
+Which JTAG configuration XML file is associated to which sensor
+\end{itemize}
+Subsequently the script builds a set of low level JTAG configuration ini files (using
+\hyperref[sec:xml2ini.pl]{xml2ini.pl}) and calls the JTAG programming tools to program and start
+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}
+startup.pl setupFile
+
+ Options:
+ -h, --help brief help message
+ -v, --verbose be verbose to STDERR
+ --dryrun create but don't run scripts
+
+\end{verbatim}
+
+
+\subsection{Graphical JTAG Editor}
+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}
+
+
--- /dev/null
+\section{Remarks}
+\subsection{System and setup configuration files}
+There are certain ambiguities in the naming conventions in/between the system and setup
+configuration files.
+\begin{itemize}
+\item
+\hyperref[sec:systemFile]{system} <-> DaqSetup
+\item
+\hyperref[sec:setupFile]{setup} <-> DetectorSetup
+\item
+<config> should be called <JTAGconfig>
+\item
+<controller> should be called roc
+\item
+Why are there rocs defined in the system file? Are the controller entries in the setup file
+not sufficient? -> for renaming by start.pl
+\item
+<serial> seems to have no use at all
+\end{itemize}
+\subsection{Tripping hazards from not implemented features}
+\begin{itemize}
+\item
+\label{trap:jtagswitch}
+The JTAG enable and Sensor enable switches in the converter boards are not set by statup.pl!
+\end{itemize}
+\subsection{Naming consistency notes}
+\begin{itemize}
+\item
+Converter Board
+\item
+Front End Board ??
+\end{itemize}
+\subsection{ToDo}
+\begin{itemize}
+\item
+Elaborate on the elements of the config XML file.
+
+\end{itemize}
\ No newline at end of file
jspc29 / mvd_docu.git / commitdiff
