Page History

...

This manual serves as an end-user manual to configure and use the DaqMux in software. 

Overview

The DaqMux system is shown in Figure 1. The DaqMux component of the FPGA in the application board of the ATCA allows the user to choose to stream up to four streams to the software (IOC) of the input streams routed to the DaqMux. All ATCA projects are configured to have two DaqMuxes, one associated with each AMC daughter board, summing a total of 8 streams routed to software. Each of the two DaqMux has 20 streams of data routed to its input. Acquisition can be either continuous, single, or single many times. In all three cases a trigger is needed. In the continuous case (i.e. continuous mode), at every trigger, the DaqMux acquires a number of configured bytes (i.e. Frame count) and sends them up to software. In single acquisition (trigger mode), the DaqMux is armed only once, and a number of configured bytes (i.e. Frame count) is sent to software with or without a header. Single many times acquisition is just a sub-case of single acquisitions, however; auto re-arm is enabled, and everytime there is a trigger a number of configured bytes (i.e. Frame count) is sent to software with or without a header.

...

DaqMux screens

The Graphical user interface of a DaqMux is shown in Figure 2. The main graphical user interface for configuring the DaqMux is quite simple and masks a lot of the DaqMux configurations. It only allows the user to perform the following

...

DaqMux Settings setup

The DaqMux settings setup page allows the user to fine control the DaqMux by reading and writing to and from the DaqMux registers and some CPSW sequencers (program sequences of writings to a register). The DaqMux settings setup GUI is shown in Figure 5.

...

• Freeze buffer (SW Freeze Buffer): If enabled, freezes all enabled circular buffers in firmware, hence all new data is discarded in firmware and software does not see new data
• Trigger count: Counts valid data acquisition triggers. 
• Arm hardware trigger (Arm HW Trigger): Arm the trigger and wait for a trigger signal to arrive. Frame acquisition starts after trigger arrival and trigger is dis-armed
• Cascaded Trigger (Cascade Trigger enable) : Enable / Disable cascaded trigger between DaqMux module
• Auto re-arm (Auto Rearm HW Trigger): In trigger mode, once the acquisition finished, a new trigger will start a new acquisition automatically
• Daq Mode (DAQ Mode): Chose the acquisition mode (Continuous or Trigger mode)
• Packet Header (Packet Header Enable): Enable a 14-byte header containing information and a snapshot of the DaqMux configurations that is prepended to the acquired frame
• Hardware Freeze (HW Freeze Buffer Enable): Enable the use of the hardware freeze buffer input signal of the DaqMux
• Decimation rate divisor: Defines new down sampled rate
• Buffer size (Data Buffer Size) : Number of 32-bit words to be acquired including header if enabled
• Debug Input Valid : All DaqMux AXI input streams valid signals concatenated together (Debug)
• Debug link Ready: All DaqMux AXI input streams ready signals concatenated together (Debug)
• Time stamp (Timestamp[31:0] and Timestamp[63:32]) : The time stamp read from the timing core upon at trigger formatted in nano seconds (left) and seconds (right)

DaqMux register & PV description

A full list of all PVs and their Register mapping and description can be seen in Table 2. This table was extracted from the firmware YAML file of the DaqMux. Registers with a blank PV name are not exported to EPICS. PVs with not register names are generated in CPSW libraries, and eventually control registers by applying a sequence of values to them.

...

• HeaderWord[0]: dmod(31:0) - Timing pattern information
• HeaderWord[1]: dmod(63:32) - Timing pattern information 
• HeaderWord[2]: dmod(95:64) - Timing pattern information 
• HeaderWord[3]: dmod(127:96) - Timing pattern information 
• HeaderWord[4]: dmod(159:128) - Timing pattern information 
• HeaderWord[5]: dmod(191:160) - Timing pattern information 
• HeaderWord[6]: timeStamp_i(31:0)   –  secPastEpoch
• HeaderWord[7]: timeStamp_i(63:32)  –  nses 
• HeaderWord[8]: bsa(127:96) - edefAvgDn
• HeaderWord[9]: bsa(95:64) -edefMinor
• HeaderWord[10]: bsa(63:32) -edefMajor
• HeaderWord[11]: bsa(31:0) -edefInit
• HeaderWord[12]: packetSize_i
• HeaderWord[13]: Firmware specific signals
  
  • [BIT31:BIT27] = "00000"
  • [BIT26:BIT26] = Trigger Header: Hardware Trigger – s_trigHw
  • [BIT25:BIT25] = Trigger Header: Cascaded Trigger – s_trigCascRe
  • [BIT24:BIT24] = Trigger Header: Software Trigger – s_trigSw
  • [BIT23:BIT23] = Data format – dec16or32_i
  • [BIT22:BIT22] = Enable decimation averaging – averaging_i
  • [BIT21:BIT21] = Test mode – test_i
  • [BIT20:BIT20] = AMC BAY Index – BAY_INDEX_G
  • [BIT19:BIT16] = Channel Index – axiNum_i
  • [BIT15:BIT00] = decimation rate divide – rateDiv_i

How to get the DaqMux streams

The DaqMux streams are routed to the DRAM on the application board, and are read using another series of components and exported to the software using the cpswDebugStreamAsynDriverConfigure IOC shell command, which is out of the scope of this document. This module provides all stream information in format of PVs. The available exported PVs are shown in Table 3. As can be seen, this module exports the streams represented with STR (and no longer with DAQMUX). Usually the software engineer would keep the numbering the same and just changing the string to minimize confusion.

Other references

• DaqMux original requirements

...