| Data Inputs |
There are 5 separate inputs to the DF module, one from each of the 3 phonon ADC chips and from each of the 2 charge ADC chips. Each ADC input is processed in a separate DF submodule. Each phonon ADC output includes 4 parallel channels, while each charge ADC output includes 2 parallel channels.
|
| Configuration and Control Inputs |
|
| Outputs |
There are 5 separate streaming outputs, which go to the
Synchronizer module. Each DF submodule pushes out the
outputs from the corresponding input channels.
|
| Internal Registers |
This module requires some information to be retained from one time step to the next. It will
be stored in internal registers which are not visible or accessible from outside the module.
They are mentioned and named here in order to simplify the detailed description of the
module's functionality given below.
|
| Tuned parameters |
There are a few parameters which must be specified to define our CIC filters. More detail
about some of the parameter choices can be found below. These
parameters have been chosen in a qualitative, heuristic fashion. They may need to be
re-tuned once early noise and pulse data from SNOLAB is available.
|
| Functionality |
Brief functional description:
The full sampling rate of the phonon channels (625 kHz) and charge channels (2.5 MHz) needs to be reduced in order to maximize the sensitivity of the trigger. This sensitivity optimization involves a tradeoff between a high sampling rate (which allows access to higher-frequency information) and a longer baseline for the Finite Impulse Response (FIR) module (which allows access to lower-frequency information). Downsampling by a larger factor reduces the sampling rate and lengthens the baseline. Downsampling by a smaller factor increases the sampling rate and shortens the baseline. This module downsamples both the phonon and charge channels to 39.0625 kHz. The choice of 39.0625 kHz seems, judging from Soudan detector pulses, to provide a good balance between low-frequency and high-frequency information, leading to a sensitive trigger while conserving FPGA resources. Any downsampling procedure will result in aliasing of high-frequency components down to lower frequencies. Our signals mostly occupy low frequencies, and the higher frequencies are dominated by noise. Therefore we want to filter out the high-frequency components before downsampling so that our signals are not swamped by aliased noise. To do this we have chosen a Cascaded Integrator-Comb (CIC) filter to reduce aliased noise. For more details on how CIC filters work and are implemented, we recommend starting with the wikipedia page. The CIC filter is chosen for certain desirable properties:
A CIC filter is a cascade of moving-average filters (a moving average of a moving average of a moving average) in the time domain. In the case of one of our phonon submodules, we have $R=16$, $N=3$, $M=1$. Thus each value of the output is a triple sum of recent input samples: \[y[n] = \sum_{j=0}^{15} \sum_{k=0}^{15} \sum_{l=0}^{15} x[n - j - k - l] \text{, where}\]
To understand the performance of this cascaded moving average as an anti-aliasing filter, we should look at the frequency response function. The frequency response function tells us whether this filter adequately attenuates noisy high frequencies while transmitting the desired low frequencies. In the frequency domain, each value of the output $\tilde{y}(\omega)$ is derived from multiplying the input $\tilde{x}(\omega)$ by the filter's frequency response function \(H(\omega)\): \[\tilde{y}(\omega) = H(\omega) \tilde{x}(\omega), \text{where}\]
This module is implemented as an Altera CIC IP Core, which requires certain parameters to be set at design time in order to specify the exact functionality that is needed from a fairly general-purpose piece of code. The list of parameters and the values we use are given later in this document (CIC IP Core parameters). This module also includes a simple wrapper to adapt the inputs and outputs of the CIC IP Core to match our needs. The design of this wrapper is detailed later on this page. Our choice of the parameters \(R\), \(M\), and \(N\) is somewhat qualitative and heuristic, since we do not yet know the exact characteristics of the pulses we will record in the SNOLAB detectors. We anticipate re-visiting these parameter choices once we have early data from SNOLAB. At that point it will be simple to take random-triggered data and pulse data and re-optimize the CIC parameters based on the noise and signal. Currently, we envision the following values:
The output of a CIC filter necessarily has more bits than the input. The number of additional bits is \(N \log_2 (RM)\) 2. For each phonon channel, this is 12 additional bits for a total of 28 bits. For the charge channels, this is 18 additional bits for a total of 34 bits. More detailed description (including data transfer information):We will instantiate five copies of the CIC IP Core, one for each of the 5 DF submodules: three will handle the three phonon ADC inputs, and the remaining two will handle the two charge ADC inputs. Each copy of the CIC IP Core will be wrapped by a single copy of the wrapper code. The CIC IP Core is configured in such a way that it expects its multi-channel inputs to arrive in serial (e.g. phonon channel 0 on clock cycle 1, phonon channel 1 on clock cycle 2, phonon channel 2 on clock cycle 3, and phonon channel 3 on clock cycle 4). This configuration was chosen to conserve FPGA resources. The inputs from the ADCs, on the other hand, arrive in parallel (e.g. all four phonon channels on clock cycle 1). The wrapper's primary role is to serialize the ADC input data. Although the inputs from the ADCs are not formally Avalon-ST streams, they may be treated as such by treating the "data ready" signal as the Avalon-ST "valid" signal and storing the input data in a register. This translation is accomplished by the wrapper. The CIC IP Core input requires several signals:
Note that the CIC IP Core does not have a "channel" input, even though it accepts multi-channel input data. We do not know the reason for this aspect of the design, but we have ascertained by reading the documentation and by trial and error that the CIC IP Core expects the data for its input channels to always arrive in order, never skipping nor duplicating any input data. The wrapper accommodates this requirement. The wrapper uses a shift register to serialize the parallel inputs. The shift register has a depth of 4 (2) steps for phonon (charge) channels, and a width of 19 bits. When the wrapper sees the "data ready" signal set on a rising clock edge, the data for the first input channel is put into the first 16 bits of the first step of the shift register. The data for the second input channel is put into the second step of the shift register, etc. The next bit of each step of the shift register is set to 1 to supply the valid signal. The next bit of the first step of the shift register is set to 1 but set to zero for all other steps to supply the start-of-packet signal. And the last bit is set to 1 for the last step and set to 0 for all other steps to supply the end-of-packet signal. On each clock cycle, the shift register is shifted by one step. The current contents of the "first step" are discarded, all the other steps are shifted forward by one, and the last step is filled with all zeros. The output of the first step of the shift register is connected directly to the data, valid, start-of-packet, and end-of-packet signals input to the CIC IP Core. In this way, a single, four-datum, parallel input from the ADCs is serialized and delivered to the CIC IP Core along with the required Avalon-ST control signals over the course of four clock cycles (or two clock cycles for charge submodules). The 2 bit wide error signal input to the CIC IP Core is always set to "00", because we do not need to tell the CIC IP Core about any error conditions. The output of the CIC IP Core is also adapted by the wrapper, although the output part of the wrapper is purely passive. The data, valid, channel, start-of-packet, and end-of-packet signals are passed straight through the wrapper. The 2 bit wide error signal output by the CIC IP Core is ignored, as it does not give us any useful error information. Lastly, the CIC IP Core expects a "ready" signal on its input. We do not use this feature, so the wrapper sets this signal always to 1. The following description is at a very high level because we are not implementing the CIC filter ourselves. Instead, we are using the CIC IP Core from Altera. Since it is closed source, we only describe in general terms what is done. Step-by-stepOn each rising clock edge, do the following:
Reset Signal:When the reset signal is asserted,
|
| Notes |
|
| Testing Plan |
| CIC Filter Specification Parameter | Value |
| Filter type | Decimator |
| Number of stages (\(N\)) | 3 |
| Differential delay (\(M\)) | 1 |
| Enable variable rate change factor | Off |
| Rate change factor (\(R\)) | 16 (phonon) or 64 (charge) |
| Number of interfaces | 1 |
| Number of channels per interface | 4 (phonon) or 2 (charge) |
| Input data width | 16 bits |
| Output rounding options | None |