Page History

This manual serves as an end-user manual to be able to configure and use the DaqMux in softwarethrough the IOC. 

...

Overview

The DaqMux sub-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 with 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  streams of data routed to its input. The DaqMux also allows not only continuous (continuous mode) streaming of multiplexed streams, but also it allows that a fixed size of the stream is burst upon a reception of a trigger (trigger mode).. 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 words (i.e. Frame count) is sent to software with or without a header. Finally, single many-times-acquisition is just a sub-case of single acquisitions, however; auto re-arm is enabled, and every time there is a trigger, a number of configured words (i.e. Frame count) is sent to software with or without a header.

The DaqMux functionality can be summarized as follows:

• Multiplex up to 4 streams and send forward (to software)
• Streams can be acquired continuously every time a trigger arrives in continuous mode, or only once upon trigger with or without header (meta data) in trigger mode, or many times with or without header (meta data) in trigger mode when auto re-arm is enabled
• Possibility of cascading trigger of DaqMux blocks
• Pause streaming by not overwriting buffers (freeze functionality), therefore nothing is forwarded to software
• Down sampling and averaging

Image Added

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 choose perform the basicfollowing:

• Choose the source of each of the 4 streams of each DaqMux

...

• Stimulate a software trigger in any of the two DaqMuxes

...

• Open complete DaqMux settings
• View the AMC Up Converter and Down Converter card front panel image
  • There are several variations of the AMC cards (Not just the up and down converters used for LLRF). Here is a list of cards and the managing entities
    • BPM Stripline AMC card: Managed by Andrew Young
    • BPM cavity/generic card: Managed by Larry Ruckman
    • LLRF Up converter and Down converter cards: Managed by John Dusatko

Image Added

Clicking on the Down Converter Front Panel Image and the Up Converter Front Panel Image shows the up converters and the down converters AMC card front panel images respectively, and are shown in Figure 3. Each port on the AMC card front panel has a name and may be referenced in the DaqMux output stream selection drop box. 

Image AddedImage Added

The DaqMux output stream selection dropbox example is shown in Figure 4.

Image Added                   Image Added

The syntax used in the DaqMux output stream selection dropbox is one of the following options:

• 3 parts →  X : Y : Z
  1. X: DaqMux input number
  2. Y: Source of the DaqMux stream
  3. Z: ADC/DAC where that source is connected - intermediate path (Not really important for end users)
• 2 parts → X : Y
  1. X: DaqMux input number
  2. Y: It can be 
     1. a source generated from
        1. the application side (i.e. DBG/Debug, Test)
        2. Unused DAC/ADC port
     2. Disabled
     3. Test (Simple counter data)

All possible options of the DaqMux input and their descriptions are summarized in Table 1.

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.

Image Added

The DaqMux settings setup contains 3 tabs:

• DaqMux Settings : Contains general settings to ocnfigure the DaqMux
• Waveform Engine Settings (Next  component in the data streaming pipeline to server - out of the scope of this document)
• Stream Settings : Contains channel specific settings (one for each of the 4 channels)

The possible functionalities that can be performed using the DaqMux settings tab are as follows: (Note if the configuration name in GUI differs from the control register Alias, the mapped Alias is shown between parenthesis)

• 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)

The Stream settings tab on the other hand contains channel specific settings, and are described as follows (Similarly, if the configuration name in GUI differs from the control register/PV Alias, the mapped Alias is shown between parenthesis):

• Trigger Daq (SW Trigger Pulse) : Sends a pulse to the software trigger enable register to stimulate an acquisition
• Stream Pause : Debug - set when frame is written to DRAM
• Stream Ready : Debug -  Denote that the waveform engine is ready to forward data to software (set when waveform engine FIFO master input ready signal is set)
• Stream Overflow : Debug - denote overflow, however not used (set to 0 in waveform engine)
• Stream Error : Debug - Denote error during last acquisition
• Input Data Valid : Debug - Denoting that the incoming data is valid
• Stream Enabled : Debug - Denote that output stream in enabled
• Frame count (Frame Count) : Number of frames forwarded
• Format Sign Width (Sign Bit Position) : Position of the sign bit given that the first bit number is 0.
• Format Data Width (Data Width) : choose 32 (0) or 16 bits (1)
• Format Sign (Sign Enable): Enable sign (1) or not (0) 
• Decimation (Decimation Averaging Enable): set if averaging is enabled

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

Image Removed

Figure 1: DaqMux Graphical user interface

The set of sources can are summarized here

...

....

The Register/PV mapping can be seen in the following table. 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.

Sequence PVs

...

Legend:      

• 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 of the ATCACommon EPICS module, 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
• DaqMux Intro and Howto presentation