Author

Jeromy Tompkins

Date

7/28/2016

What is Validation?

The Pixie-16 digitizers are always digitizing the signals that are fed them on their inputs. The streams of data generated are also always being sent through the trigger and energy filters to identify when a signal of interest has arrived. Once the fast filter threshold is satisfied, a fast trigger is generated that will be used to determine whether the data is worth keeping. The process of determining when data is worth keeping is called validation. One can draw an analogy between the validation process in a Pixie-16 digitizer and defining a trigger condition in a traditional electronics circuit.

A validation condition is a coincidence requirement between a fast trigger and another signal. There are three different validation requirements that can be set up. The first uses a fast trigger to validate itself. Self-validation is the simplest validation mode to set up because it has no extra parameters to configure. The second validation mode requires that fast triggers on different channels occur in coincidence. In channel validation mode, it is possible to look for coincidences in groups of channels and specify a minimum channel multiplicity. It is quite flexible. The final validation mode is external validation mode. In this last mode, a fast trigger must be coincident with a validation gate that is generated by the arrival of an external signal. It allows logic external to the Pixie-16 digitizer to control when to acquire data.

When a fast trigger is validated, the data corresponding to it is moved into the FIFO to be readout. If the trigger is not validated, then the data is discarded.

Test Signals

Because channel and external validation require the user to set up a coincidence between two signals and those signals are internal to the module, the Pixie-16 provides a mechanism to view them. All Pixie-16 modules provide the following signals as outputs on the front I/O LVTTL output if configured to do so:

In the table above, the delayed local fast trigger is the fast trigger that was generated when the trigger condition was satisfied and then delayed. The manner in which each of these signals are used in the various validation modes will be described in subsequent sections.

Note

The test signals are not outputted unless a the "FP" bit is set in the TrigConfig0 dialog. This bit controls whether or not the internal signals for ch.0 will be routed to the front panel or not. If "FP" is not selected, that simply means that they will not be viewable on the scope. They will still be present internal to the module and performing their roles in the validation process despite not being visible.

Channel validation

The channel validation requires that the delayed local fast trigger is coincident with the stretched channel validation trigger. To enable the channel validation mode, the appropriate bits need to be set in the CSRA dialog. The column of checkboxes labeled "CT" is used to enable or disable channel trigger validation mode. Please select all or none of the checkboxes to either enable or disable channel validation mode. The next step is to set up the channel coincidence requirements. Those are set in the "Mult Coincidence." dialog located under the UV_Setup drop-down menu. In the multiple coincidence dialog, there are options to select how to group channels, the minimum number of coincident channels that need to be present in each channel group, and then the width of the stretched channel validation trigger. The channel groupings begin with channel 0 always. The 8x2 mode groups channels 0 and 1, channels 2 and 3, etc. The 5x3 option groups channels 0-2, channel 3-5, and so on. The 4x4 option creates four groups of four, the 2x8 option create two groups of 8, and the 1x16 option creates a single group of sixteen channels.

Once channel validation mode is enabled and configured, use the oscilloscope to view the delayed local fast triggers (o0) and the stretched channel validation trigger (o4). Use the Timing Controls dialog in the UV_Setup to adjust the delay on the fast trigger ("Fast Trig Delay") and Mult Coincidence dialog to adjust the width of the stretched channel validation trigger. These must be configured to overlap in time.

External validation

As already described, external validation is the requirement that a fast trigger be coincident with a signal generated by the arrival of an external pulse.

The external trigger validation requires that some settings are configured using nscope. The first of these settings is in the UV_Setup > CSRA drop-down menu. In the CSRA settings dialog, there is a column labeled "GV" which stands for "Global Validation". For any channel that is intended to be configured for external trigger validation, its corresponding checkbox needs to be selected. Once all of these have been selected, the new settings should be applied to the module. At this point, the module is configured to require an external validation.

In the external validation mode, an input is validated if the delayed fast trigger is coincident with the stretched external global validation trigger created by the arrival of a signal on the i4 input. When these two signals overlap in time, the trigger will be validated.

Note

If the global validation bit is not set in the CSRA dialog, the o3 output will not be generated even when a signal is present on i4.

To adjust the timing of these signals, the user has two parameters to adjust. These parameters are editable using the Timing Controls dialog located under the UV_Setup drop-down menu. In this dialog, the "Fast Trig Delay" will adjust timing of the delayed fast trigger with respect to the external validation gate. The "Ext Trig Width" parameter will adjust the width of the external global validation gate signal. Use an oscilloscope to find a parameter set where the two signals overlap.

External and Channel Validation

It is possible to validate with both channel and external modes enabled. Doing so requires that each of their validation requirements are satisfied.