MuDAQ (micro-DAQ) is a readout environment that performs similar functions to the LHCb miniDAQ environment. It is a lower cost alternative intended for smaller laboratory or test set-ups. Each muDAQ module can control and read out one full RichPdmdb (1 controls link + 6 data links). The module is controlled via a USB interface.


Quick start guide

GUI installation

The GUI is called JPDMDBDepp. It runs on Windows or Linux and can be downloaded here. This version is built with Java 11 (e.g. openjdk11) but you do not need to install Java 11 if you just want to run it as is. Unpack the tar file into a local directory and run it by typing


for Cygwin or


for Linux installations.

The USB interface uses the Digilent Adept runtime environment. It can be downloaded here. The "System" or "runtime" environment should be installed. The "Utilities" are also useful but the SDK is not required.

The GUI must be run on the PC to which the muDaq USB is connected but can send commands and receive responses from another system through a network socket. This is used to issue commands to the PDMDB module tester microcontroller host or to the Oxford tester board system. The address of the network socket can be set from the Main menu. Select Set MTB socket... and enter the network address in URL notation. If your GUI and microcontroller host are the same, you can use http://:7999 as the network address. More generally, if the machines are different, you can use http://host.domain:7999 instead, where host.domain is the IP address of the micrcontroller host. If you change the setting, you should restart the Java GUI to open a new connection.

Hardware set-up and configuration

First power up the muDAQ and PDMDB.

ALERT! Different versions of MuDAQ require different voltages. MuDAQv2 requires 2A@3.3V. MuDAQv3 requires 2A@5.5V.

ALERT!The muDAQ power connector is slightly different than the Chimaera2 so take care.

Start the GUI as described above. A panel similar to the following should appear:

Top panel

To correctly establish the communication the guiding principle is to follow the master link path configuring first the MGT.TX on the muDAQ side followed by the master GBTX on the TCM, then the MGT.RX on the muDAQ side then the SCA chip. Once communication to the SCA is established, the PDMDB FPGAs, DTMs and ECs may be configured.

For example:

  1. On the Main panel, muDAQ configure.
  2. On the Main panel, Configure master link.
  3. On the Main panel, SCA setup.
  4. Configure DTMs (and PDMDB FPGAs)
    1. On the Main panel, DTM0 program GBTX.
    2. On the Main panel, DTM0 program FPGA.
    3. Repeat for the remaining DTMs
  5. Configure the ECs (loads the registers from the chosen file that contains the CLARO registers for the complete PDMDB)
    1. On the Main panel, Configure EC0.
    2. Repeat for the remaining ECs.

Completion of each button action is indicated by the button becoming green.

IDEA! The precise wording and ordering of the buttons on the panel may differ from the above as this is set by an external XML file when the GUI starts.

ALERT! There are buttons on the main panel related to e-fusing the TCM GBTX. Except when using the production testing hardware, there should be no risk of accidentally fusing any registers since the required voltages are not provided by the hardware. For additional protection the feature is usually disabled in the XML file so no action is taken even if the fuse button is selected. To be extra careful, one can Discard the fusing token at the top of the main panel.

Technical user guide

MuDAQ is capable of excercising both controls and data acquisition path of the PDMDB.

Host interface

Communication with the PC is through the Digilent Adept USB API and the Cypress FX2LP chip on the muDAQ module. The toolkit provides an asynchronous 8-bit parallel port API (DEPP) and a JTAG TAP API (DJTG). Digilent also provides a plug-in to allow FPGA programming via the FX2LP using the Xilinx programming tools. The DEPP API is used to access muDAQ configuration and status registers and to transfer data to and from the PDMDB through the I2C and HDLC interfaces implemented in the muDAQ firmware.


The GUI is a Java program. It uses JNI (Java Native Interface) to wrap the Adept API calls and JAXB (Java XML Binding) to provide data-driven GUI configuration with XML. The XML binding makes it easy to use the same GUI for both PDMDB-R and PDMDB-H by simply editing an XML file.

Configuration and localisation

When started, the GUI will detect any devices connected to the PC and will present a list from which the user can select the board. Therefore make sure that the muDAQ module is connected and powered before starting the GUI.

After selecting the device the GUI will ask you to choose the hardware. You will probably need to enter something like mudaqr, mudaqh or mudaq. The name corresponds to the hardware configuration XML that you want to use.

Next the GUI will ask for the sequence name which might be something like testerSequence. This name selects the XML file that will be used to populate the main panel.

If the configuration XML file doesn't exist or is unreadable, the GUI connects to the Cambridge webserver and downloads the the file, adding the prefix www-. The GUI then configures itself from this cached copy. If you need to make local modifications to the configuration or avoid the need for network connectivity or simply wish to keep a stable configuration you should make a local copy without the www- prefix. To always use the web version of the configuration, or to refresh the local copy, simply remove the local copy from the current directory then restart the GUI while connected to the network.

Several other XML files are accessed in a similar way during GUI configuration. These include:

File Usage
mudaq.xml muDaq hardware configuration description
mudaq-csr-config.xml muDaq configuration register descriptors
mudaq-csr-status.xml muDaq status register descriptors
claro.xml CLARO register descriptors
gbtx2.xml GBTX register descriptors
SCATXCommands.xml SCA command descriptors
SCARXCommands.xml SCA response descriptors
testerSequence.xml Command sequence definition

It is likely that mudaq.xml and testerSequence.xml would be customised for each local installation but it is recommended that the GUI is allowed to cache the others from the remote server.

User interface

The simplest way to interact with muDaq is through the main panel which can be configured to provide a collection of high-level operations that can either be invoked individually or run automatically as part of a pre-defined sequence. For lower-level interactions the GUI provides a set of panels to allow manual configuration and expert operations.

On the main panel, the Play button executes the whole sequence from the beginning. The Pause button flags the sequence to stop at the next opportunity. Resume will continue from where the sequence paused.

Step executes the commands consecutively one at a time on each click. First step resets to the beginning of the sequence and executes the first command. Resume can be used in step mode to continue automatically from the last executed command.

Individual commands may be executed by clicking the corresponding button. However, this does not change the current position in the sequence as used by Step and Resume. This is a convenient way of retrying a failed command.

In case the GUI aborts a transaction, it may be necessary to empty the response FIFO. A Read flush button is provided on the tester sequence panel to do this. It reads the FIFO in a loop until a timeout occurs indicating that the FIFO is empty. After this a NOP instruction should be sent to synchronise with the tester.

The muDaq panel
The upper part of the panel displays the contents of the status and configuration registers. The Decode buttons generate a decoded version of the registers on the console using the XML register descriptors. The lower left panel is for setting up the muDAQ MGT transceivers. It is recommended to use the power down feature for unused MGTs (RX and TX can be separately powered down). The lower right part of the panel is for special functions. For example, the DRP controls allow a statistical eye-diagram for a selected MGT to be generated.
Main panel

The master link panel
This panel is the principal controls interface to the PDMDB. It is divided into sections for the configuration and monitoring of the ECs, the DTMs and the FPGAs.
Master link panel

The VTRX I2C panel
This panel is for programming the master link GBTX through its I2C interface.
Master link GBTX I2C panel

Test sequence XML

The appearance of the main panel is governed by the XML file testerSequence.xml. The file describes a sequence of commands that can be executed either individually or automatically in sequence. An example XML fragment is given below.

  <command label="muDAQ configure" targetClass="TesterSequence" targetMethod="configureMuDaq"/>
  <command label="muDAQ configure master link" targetClass="TesterSequence" targetMethod="configureMasterLink" data="i2c" stopOnFail="true"/>
  <command label="SCA setup" targetClass="TesterSequence" targetMethod="setupSca"/>
  <command label="SCA set DACs" targetClass="TesterSequence" targetMethod="setDac" data="0|33?1|127?2|75?3|92"/>
  <command label="SCA set GPIO[7:1]" targetClass="TesterSequence" targetMethod="setGpio" data="7|1"/>
  <command label="MTB NOP" targetClass="PdmdbModuleTester" targetMethod="exec" data="NOP">
    <response opcode="ACK_OK" timeout="500" incrementSequenceNumber="true"/>
  <command label="MTB measure power" targetClass="PdmdbModuleTester" targetMethod="exec" data="MEASURE_POWER|1111">
    <response opcode="ACK_OK" timeout="500" incrementSequenceNumber="true"/>
    <response opcode="MEASURE_POWER" timeout="3000"/>
  <command label="Do analysis" targetClass="Command" targetMethod="shell" data="/lhcb/lhcbrich/Upgrade/PDMDBTesting/PDMDBKIT/|arg1"/>

The commands reference static methods in the various Java GUI classes. The class (relative to cbsw.lhcb.pdmdb) is given in the targetClass attribute and the method in the targetMethod attribute. The fully-qualified target method signature is then

public static String cbsw.lhcb.pdmdb.targetClass.targetMethod(String [])

Any new methods that are added must conform to this signature. The String[] argument contains the tokenised target method data split at the | characters. The returned String starts with mandatory OK or FAIL text followed by | and any optional data.

For example. the tester MEASURE_POWER command results in a call

public static String cbsw.lhcb.pdmdb.PdmdbModuleTester.exec({"MEASURE_POWER","1111"})

Commands are executed in the order they are given in the XML. Where the commands target the test board, the GUI waits for each of the listed responses before proceeding. A timeout in milliseconds can be applied to the tester responses. The GUI will abort the sequence when a timeout occurs or when an unexpected response is received.

The label attribute is used as the test button label on the tester sequence panel.

If the same command needs to be executed several times by the same target method this can be done by concatenating the target method data using the ? character as separator. See, for example, the setDac method in the XML above.

The incrementSequenceNumber="true" attribute should normally appear on the first response of each command. However, under some circumstances, responses after the initial ACK_OK may be handled in the response list of the next command. In this case the attribute should not appear on the deferred response.

The method allows to run a shell script as part of the sequence. The Do analysis command in the above xml fragment is an example of this. The shell script must follow certain rules relating to IO redirection so some care is needed in preparing it.

For details of the individual Java methods, refer to the Javadoc documentation. Most of the methods can be found in the TesterSequence class but some are scattered elsewhere.

Optical links

These provide the control and data paths between muDaq and PDMDB. They are implemented in the hardware through the Xilinx MGTs (multi-gigabit transceivers). The GBT protocol FPGA implementation is based on a simplified version of the CERN GBT FPGA core. The XC7K70T Kintex-7 FPGA has eight MGT transceivers which are specified to operate at rates of up to 6Gbit/s. All eight transceivers are routed to SFP connectors compatible with 3.3V commercial optical transceiver plug-ins. Six MGT transceivers are configured in wide-bus mode as data receivers and one is used in transceiver mode with FEC for the master link. The muDaq firmware assigns them as follows:

PCB legend FPGA MGT RX usage TX usage
SFP7 1 Unused Unused
SFP6 2 DTM0.GBTX0.TX Unused
SFP5 3 DTM0.GBTX1.TX Unused
SFP4 4 DTM1.GBTX0.TX Unused
SFP3 5 DTM1.GBTX1.TX Unused
SFP2 6 DTM2.GBTX0.TX Unused
SFP1 7 DTM2.GBTX1.TX Unused

Master link

The controls interface can be used to send fast synchronous commands to the PDMDB and as the configuration and monitoring interface. The synchronous commands are described in the discussion of the data path.

On the PDMDB, the GBT-SCA on the TCM implements all of the configuration and monitoring interfaces used by the front-end. The SCA is connected to the dedicated master link EC port and responds to the HDLC protocol. MuDAQ implements a simple HDLC engine in firmware that reads commands locally buffered in the muDAQ FPGA and sends them to the SCA through the master link.

Production TCMs are by default designed so that the GBTX should be programmed through the master link after an initial minimal set of e-fuses have been burnt. All registers may be read or written in a single operation (be careful not to change the registers that are initialised from the e-fuses). The protocol is sketched out in the GBTX manual. Not shown, however, is the dummy byte that must be sent as the first byte after the 0x7e frame delimiter and before the GBTX ID byte. Also not made clear is the fact that the parity byte does not cover the GBTX ID byte. A similar bitstuffing procedure is applied as for the SC channel. However, the idle sequence is 11111111... and each frame is delimited with 01111110. Byte ordering is little-endian and bytes are transmitted LSB first. The GBTX ID is 1 for all production TCMs.

MuDAQ implements an I2C interface that allows initial configuration of the master link GBTX. The connector pin assignments are:

SK4 Pin FPGA IO Signal
1   NC
2   3V3
3   GND
5 E21 SDA
7 C21 SCL
8 B21  

Most TCM GBTXs are now e-fused and the default hardware behaviour on production PDMDBs is for the IC (optical link) configuration path to be active. The type attribute of the <gbtx> xml element in mudaq.xml file must be set to i2c for configuration through the I2C interface or ic for configuration through the optical link. The <gbtxI2c> xml element should always be present and should not need to be changed.

SCA commands

The following links tabulate the parameters of the SCA commands. The SCA manual appears to have many typos, errors, inconsistencies or ambiguities in the command descriptions. These linked tables are generated from the XML files that are also used by the muDAQ GUI to build the SCA commands. The XML data, originally taken from the SCA manual, has been corrected where problems have been found but not every possible command has been tested.


The GBT-SCA chip operates with a command and acknowledge protocol; every successfully completed command results in an acknowledge message. The muDAQ exploits this to allow a batch of SCA commands to be sent from the GUI to the muDAQ FPGA. A small protocol core in the FPGA then sends these commands through the master link to the SCA waiting for an acknowledge messsage after sending each command. This is much more efficient than sending individual commands from the GUI and waiting for a response before sending the next. However, in some cases the SCA may not send a response, for example, the ADC_GO command appears not to send a response if the ADC input exceeds the upper conversion limit (1V). To allow for this, the FPGA core implements a timeout; if a response to a command is not received within about 1ms the core continues with the next command. Of course, the commands following a timeout may no longer produce well-defined responses from the SCA so the user should be aware of this. Also, in some cases, a successful SCA command might exceed the command timeout (e.g. a 128bit I2C transaction at the lowest clock speed) which might also result in the following transactions not behaving as expected.

While the batched SCA transactions are in progress, a new USB transaction will block until the complete batch has been processed (using the DEPP wait mechanism). The blocked transaction will then continue without further intervention. In this way, the GUI is also synchronised with the hardware without the need to poll. The DEPP wait mehanism itself implements a timeout of 10ms. In some cases (for a single batch of commands expected to exceed 10ms) it is necessary for the GUI to retry the USB operation one or more times in case of timeout.

Data path

The muDAQ GUI currently only support a limited monitoring of the data received on the data links from the PDMDB. It is possible to monitor the GBT frames in the status registers and the GUI can generate fast synchronous DAQ commands on the master link for test purposes.

DAC (test pulse) scans are implemented. The test pulse alignment is trimmed in the PDMDB firmware with a hard-coded value of 5 (6.25ns clock cycles).

In the current implementation, a value of 0x1b for daq.latency-compensation will then make the data appear in the second of the four timesolots that are read out for each trigger.

Phase scans to help optimise the e-port alignment are also implemented or the GBTX automatic phase alignment can be used.

The Kintex7 GT receivers apparently do not always reset into a stable mode without bit errors. Sometimes, more than one reset of the GTRX channel is needed to obtain stable data. The reason for this is not clear. Once a stable condition has been obtained, it appears to remain stable until the next GTRX channel reset.

The GTRX channel reset is generated synchronously to the 40MHz clock. With this, the data path latency is fixed/deterministic. It is stable across GTRX reset or power cycle and for different firmware implementations.

For reference

Register maps

GBTX settings

The best data link performance so far has been achieved with the GBTX xPLLs bypassed. The setting of ps.pll.resistor for the GBTX.0 phase shifter appears to be critical for the quality of the data from GBTX.1. A value 4 seems to be best. It is not clear whether this configuration is necessarily best also in the miniDAQ environment.

Hardware updates

.bin files may be used to program the flash memory or the FPGA directly. Utilities for programming/flashing are described here.

PDMDB signal mapping

Please see the RichPdmdb topic.

Edit | Attach | Watch | Print version | History: r42 < r41 < r40 < r39 < r38 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r42 - 2020-01-03 - StephenWotton
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback