To implement the Waveform Match Trigger, we create an array from the user-defined trigger limits/constraints, an array of the min and max limits. This is sent to a set of FPGA registers, implemented as shift registers in LabVIEW FPGA. Once the Waveform Match Trigger IDL is configured and enabled, ADC samples are sent through the pipeline created by the trigger limits. The output from the trigger limits pipeline is then used to drive the Reference Trigger of the Multirecord Acquisition sample project.
The Trigger Limits
The area defined by these arrays creates a keep-in area, and a valid trigger occurs when all the samples under comparison are found within this keep-in zone as shown in the blue region of Figure 12. Specifically, this IP triggers when all the ADC samples are less than all the upper limits and greater than the lower limits. From now on, we refer to these bounds as the trigger limits or, simply, limits. When we define the limits, they are created in pairs, an upper limit and a lower limit, the limit values themselves being voltage values. The entire trigger limit arrays are composed of these pairs, where the time difference between each set of limits is a constant value (dt). As the samples become available from the ADC, they are compared to the limits. The following animation gives a high-level overview of the Waveform Match Trigger functionality. As the ADC acquires new samples, they are added to the waveform and all the acquired samples shift to the next set of limits to be compared against. Once all the waveform samples are within the keep-in zone/constraints, the trigger condition is met, and a trigger signal is sent to the Multirecord Acquisition Engine.
Figure 12. Animation of Waveform Samples Moving Through User-Defined Trigger Limits
The Limits Pipeline
The trigger limits are implemented in the FPGA as a pipeline that consists of a set of LabVIEW Feedback Nodes connected together serially. With an FPGA pipeline, we can take advantage of the parallel processing capabilities of the FPGA, the code between each Feedback Node running concurrently in the FPGA. For more information on pipelining with LabVIEW FPGA and how data flows through each stage, see the white paper article: Pipelining to Optimize FPGA VIs.
For our Waveform Match Trigger, each stage in the pipeline looks something like Figure 13.
Figure 13. Waveform Match Trigger Comparator (1 SPC) Implementation (FPGA)
The data limits are sent to the hardware one set at a time, and then on the rising edge of the “compare valid in” signal, the limit set is saved into the corresponding Feedback Node. When “compare valid in” is FALSE, the saved value is read out of the Feedback Node, acting like an FPGA register. With multiple instances of Figure 13 implemented and connected together (“compare out” is connected to “compare in” on the next instance, and so on), the effect of writing one limit pair is that the pairs in each Feedback Node are passed to the next implementation, effectively shifting the limits by one down the implemented pipeline.
Data flows through the pipeline in the same way, as it is implemented identically. In Figure 13, the top Feedback Node is part of the data pipeline, and the bottom Feedback Node is part of the limits pipeline. They have separate valid input signals, so the data and the limits can flow through the respective pipelines independently. This is needed because the limits pipeline is filled with the user-defined limits, before we shift any data through, and when we begin shifting the data through the pipeline, the limits are not shifted and remain static.
A comparator as shown in Figure 13 is implemented in each segment of the pipeline and performs the comparisons between the input data and the trigger limits. The output of a single comparator is a Boolean value indicating if the input data is within the limits and is labeled “in ranges.” This output is then combined with each stage of the pipeline and, because there are no Feedback Nodes between the comparator outputs, the aggregated comparator outputs can be evaluated in a single clock cycle to determine if a trigger condition has occurred: the data from ALL comparators are “in range.” This comparison is implemented as a logic AND.
When one sample is generated per clock cycle, then for each clock cycle, we push one more sample into the comparators pipeline. Table 1 shows how the comparator pipeline fills with data one clock cycle at a time. Because all comparators are implemented in parallel, each row is evaluated simultaneously, with empty cells indicating comparisons that are discarded (comparisons with uninitialized values are garbage).
Table 1. Comparator Pipeline (1 Sample per Cycle) Filling With Samples
Comparator Complications: Multiple Samples per Cycle
For the NI PXIe-5171R family, the ADCs generate two samples per cycle (2 SPC) in the data loop on the FPGA. This means that in each clock cycle in the acquisition loop, we have an array of two fixed-point numbers for each channel, instead of one.
Devices that generate more than one sample per cycle (1 SPC) complicate the comparators in the limits pipeline, as we now need more comparators to compare the additional samples and samples between consecutive clock cycles. For N samples generated per cycle, we need 2N comparators to compare each sample generated to each comparator in a given segment.
For the 2 SPC case, two comparators are needed for comparing the first and second sample generated to the first and second comparator in each segment respectively. Another comparator is needed to compare the first sample to the second comparator value. The fourth comparator is needed to compare the first sample from the previous segment to the first comparator in the current segment. This is illustrated in Table 2. Each clock cycle compares the two new samples to the two comparators in each pipeline stage, with the extra comparators comparisons highlighted. Notice how the extra comparators fill in the jumps such that each sample gets compared to each comparator, like the 1 SPC case shown in Table 1.
Table 2. Comparator Pipeline (2 SPC) With Extra Required Comparators Highlighted and Bold (Each Pipeline Stage Is Color-Coded)
Thus, for the 2 SPC case, the following figure illustrates how the limits pipeline and comparators are implemented to handle the extra samples in each clock cycle. Additional notes show how the implementation can be compared to the pipeline in Table 2. The Feedback Nodes have been labeled to indicate the waveform data and limit pairs stored in each, causing it to represents the Stage 2 comparators in Table 2 during the second clock cycle.
Figure 14. Waveform Match Trigger Comparator (2 SPC) Implementation (FPGA)
In Figure 14, the “data in” is an array of clusters with two elements: max and min. The array length matches the number of cycles per sample generated by the hardware. The cluster was implemented this way to support sending either waveform data or summarized data from the Interval Min & Max Hold.vi (which is the default implementation). To represent a single waveform sample, the two values in the cluster are identical. Implementing the data input in this way allows us to summarize multiple waveform samples to send through the limits pipeline instead of each individual sample. In the next section, we discuss this design decision in further detail.
Resource Utilization and the Need for Data Decimation/Summarization
When sending waveform data directly into the limits pipeline, we can test for waveform matches, granular down to the individual samples. Without the ability to summarize multiple waveform samples, the maximum length of our limits array is limited by the number of pipeline segments implemented in hardware, which is fixed at compile and can be very resource intensive, leaving little room in the FPGA for other customizations. With fewer segments, we use fewer resources; however, we also have a smaller window of time in which our unique waveform match event must occur, which is defined by the following equation:
Time Window = Segment Length * Sample Rate Period
Thus, our time window with 512 pipeline segments, with the default sample rate of 250 Mhz on the NI PXIe-5171R is:
512 * 1/250 MHz = 2.05 µS
If our triggering event cannot be described completely within ~2µS, a longer envelope is needed, which in turn requires more segments and more FPGA resources.
To overcome this problem, we can abstract the data flowing into the limits pipeline from representing one data sample per comparator to multiple samples. One way to do this would be to keep track of the minimum and maximum values of a set of N samples. Then, just send the min and max values through the comparator pipeline, thus representing N points with just one set of comparisons, allowing for an elongated time window. This method is implemented in the Interval Min & Max Hold.vi.
Figure 15. Interval Min & Max Hold.vi
For example, if N = 10, we can track the min and max value over 10 samples. Once we have the min and max for the 10 samples, we need to send only these two values through the limits pipeline, giving us a 10x time window of 20.5 uS. The limitation of this design is that all N samples must share the same min and max limit; therefore, we can increase the time window at the expense of time resolution of the mask.